summaryrefslogtreecommitdiffstats
path: root/drivers/dma
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 /drivers/dma
parent1e2dbdefe720372d9d8b04d50c29de54e932be3b (diff)
downloadop-kernel-dev-6f9d70568f3128411c49dd049498d0c13cd3bbc1.zip
op-kernel-dev-6f9d70568f3128411c49dd049498d0c13cd3bbc1.tar.gz
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>
Diffstat (limited to 'drivers/dma')
-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 cf7633f..3fb7931 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