summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorSebastian Andrzej Siewior <bigeasy@linutronix.de>2014-12-03 15:09:49 +0100
committerVinod Koul <vinod.koul@intel.com>2014-12-09 14:45:41 +0530
commit6f9d70568f3128411c49dd049498d0c13cd3bbc1 (patch)
tree601017aa49005ec7ec53221f456f41e5c7f4a809
parent1e2dbdefe720372d9d8b04d50c29de54e932be3b (diff)
downloadblackbird-obmc-linux-6f9d70568f3128411c49dd049498d0c13cd3bbc1.tar.gz
blackbird-obmc-linux-6f9d70568f3128411c49dd049498d0c13cd3bbc1.zip
dma: cppi41: wait longer for the HW to return the descriptor
For a "complete" teardown we have to wait until the teardown descriptor is returned by the hardware. The g_zero testcase "testusb -a -t 9" triggers the following warning quite reliable: |------------[ cut here ]------------ |WARNING: CPU: 0 PID: 0 at drivers/dma/cppi41.c:609 cppi41_dma_control+0x198/0x304() |[<c003f84c>] (warn_slowpath_null) from [<c02be8d8>] |[<c02be8d8>] (cppi41_dma_control) from [<bf08d25c>] |[<bf08d25c>] (cppi41_dma_channel_abort [musb_hdrc]) |[<bf08bc38>] (nuke.constprop.10 [musb_hdrc]) |[<bf08bd08>] (musb_gadget_disable [musb_hdrc]) |[<bf252524>] (disable_endpoints [usb_f_ss_lb]) |[<bf2525d8>] (disable_source_sink [usb_f_ss_lb]) |[<bf25260c>] (sourcesink_set_alt [usb_f_ss_lb]) |[<bf23ad24>] (composite_setup [libcomposite]) |[<bf08a2f4>] (musb_g_ep0_irq [musb_hdrc]) |[<bf085ec4>] (musb_interrupt [musb_hdrc]) |[<bf0aeaf4>] (dsps_interrupt [musb_dsps]) |[<c0080ea8>] (handle_irq_event_percpu) |[<c008112c>] (handle_irq_event) |[<c008348c>] (handle_level_irq) |[<c00807a8>] (generic_handle_irq) |[<c000ee80>] (handle_IRQ) |[<c00085f0>] (omap3_intc_handle_irq) and complains about a TD descriptor which is not returned. I've been looking at several things and haven't noticed anything unusual that might lead to this. The manual says "to try again" until the descriptor comes out. I limited the amount of retries to 100 retries in order to avoid an infinite number of retries and so a busy-loop. Back then testing revealed that the number of retries were around 20-30 so 100 seemed a good upper limit. This g_zero test reaches without a problem 98 retries and it jumps sometimes to 101 on am335x-evm and so the WARN_ON() triggers. Same test run on beaglebone black and the retries start at 122 and my max value so far was at 128. So lets rise the limit to 500. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-rw-r--r--drivers/dma/cppi41.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index cf7633f6d474..3fb793188b60 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -567,7 +567,7 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
reg |= GCR_TEARDOWN;
cppi_writel(reg, c->gcr_reg);
c->td_queued = 1;
- c->td_retry = 100;
+ c->td_retry = 500;
}
if (!c->td_seen || !c->td_desc_seen) {
OpenPOWER on IntegriCloud