diff options
| author | Sebastian Andrzej Siewior <bigeasy@linutronix.de> | 2014-12-03 15:09:49 +0100 |
|---|---|---|
| committer | Vinod Koul <vinod.koul@intel.com> | 2014-12-09 10:15:41 +0100 |
| commit | 6f9d70568f3128411c49dd049498d0c13cd3bbc1 (patch) | |
| tree | 601017aa49005ec7ec53221f456f41e5c7f4a809 | |
| parent | dmaengine: fsl-edma: fixup reg offset and hw S/G support in big-endian model (diff) | |
| download | linux-6f9d70568f3128411c49dd049498d0c13cd3bbc1.tar.xz 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.c | 2 |
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) { |