Re: [[PATCH] 0/3] imx-dma: fixes

[Vinod Koul]

On Sun, Sep 29, 2013 at 01:56:03AM +0200, Michael Grzeschik wrote:
> Hi Christoph,
> 
> On Tue, Sep 24, 2013 at 08:35:03AM +0200, Christoph Fritz wrote:
> > On Mon, 2013-09-23 at 09:49 +0530, Vinod Koul wrote:
> > > On Tue, Sep 17, 2013 at 03:56:05PM +0200, Michael Grzeschik wrote:
> > > > Hello,
> > > > 
> > > > this series is solving some lockdep issues in the imx-dma code.
> > > > There are some list_head and deadlock issues in the code,
> > > > that is running the implementation into unsafe situations.
> > > Thanks for this, I have trying to fix this with testing done by Christoph. I had
> > > similar set of fixes
> > > 
> > > Christoph can you pls try runnning this on your setup and check and we can apply
> > > these
> > 
> > Thanks for the update, I added Michaels imx-dma patchset to Kernel
> > 3.4.62 and gave it a shot:
> > 
> > In contrast to DMA-disabled, a 'dd' copy still results in a hung:
> > 
> >    dd if=/dev/zero of=/mnt/dd-test.bin count=102400 bs=1K
> > 
> > Please see the full log from boot to hung with DEBUG enabled below.
> > With 2.6.31, copying to an SD-Card with DMA enabled works flawlessly,
> > this log is also below.
> > 
> > Michael, any ideas? I suppose you have the same board?
> 
> The hardware we tested these patches for/with was custom hardware. But
> yes, we have this board you refer. We will need to setup the same
> situation first for debugging.
> 
> Did you realize that the stalling mem2dev transfer in 3.4.62
> is generating this footprint:
> 
> > [   60.579646] imx-dma imx-dma: imxdma_xfer_desc channel: 0 sg=c70ff000 sgcount=8 total length=32768 dev_addr=0x10014038 (mem2dev)
> > [   60.591192] imx-dma imx-dma:  imxdma_sg_next channel: 0 dst 0x10014038, src 0xa5527000, size 0x00001000
> > [   60.600624] imx-dma imx-dma: imxdma_enable_hw channel 0
> > [   60.605887] imx-dma imx-dma:  imxdma_sg_next channel: 0 dst 0x10014038, src 0xa5525000, size 0x00001000
> > [   60.795424] imx-dma imx-dma: dma_irq_handler called, disr=0x00000001
> > [   60.801857] imx-dma imx-dma:  imxdma_sg_next channel: 0 dst 0x10014038, src 0xa5523000, size 0x00001000
> > [   61.290221] imx-dma imx-dma: channel 0: watchdog timeout!
> 
> Beside on 2.6.31 the same transfer results in no failure.
> 
> > [   55.270000] imxdma0: imx_dma_setup_sg sg=c7ae3800 sgcount=9 total length=32768 dev_addr=0x10014038 for write
> > [   55.280000] imxdma0: next sg chunk dst 0x10014038, src 0xa73a1c00, size 0x00001000
> > [   55.290000] imxdma0: imx_dma_enable
> > [   55.290000] imxdma: dma_irq_handler called, disr=0x00000001
> > [   55.290000] imxdma0: next sg chunk dst 0x10014038, src 0xa73a2c00, size 0x00000400
> > [   55.300000] imxdma: dma_irq_handler called, disr=0x00000001
> > [   55.300000] imxdma0: next sg chunk dst 0x10014038, src 0xa73a5000, size 0x00001000
> > [   55.320000] imxdma: dma_irq_handler called, disr=0x00000001
> > [   55.320000] imxdma0: next sg chunk dst 0x10014038, src 0xa73a7000, size 0x00001000
> > [   55.330000] imxdma: dma_irq_handler called, disr=0x00000001
> > [   55.330000] imxdma0: next sg chunk dst 0x10014038, src 0xa73a9000, size 0x00001000
> > [   55.340000] imxdma: dma_irq_handler called, disr=0x00000001
> > [   55.340000] imxdma0: next sg chunk dst 0x10014038, src 0xa73ab000, size 0x00001000
> > [   55.360000] imxdma: dma_irq_handler called, disr=0x00000001
> > [   55.360000] imxdma0: next sg chunk dst 0x10014038, src 0xa73ad000, size 0x00001000
> > [   55.380000] imxdma: dma_irq_handler called, disr=0x00000001
> > [   55.380000] imxdma0: next sg chunk dst 0x10014038, src 0xa73af000, size 0x00001000
> > [   55.390000] imxdma: dma_irq_handler called, disr=0x00000001
> > [   55.390000] imxdma0: next sg chunk dst 0x10014038, src 0xa73b1000, size 0x00000c00
> > [   55.400000] imxdma: dma_irq_handler called, disr=0x00000001
> > [   55.410000] imxdma0: imx_dma_disable
> 
> It looks suspicious that the same same transfer in the newer kernel should take
> less amount of sg (sgcount=8 vs. sgcount=9) with the same amount of payload data.
> 
> I don't think this issue is related to the patch series I posted. But
> anyway needs to be investigated.
Yes Looks like we had same result with my patches too. So I will try applying
these and we can fix these along. I would like some working driver rather than
broken one :)

~Vinod
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/