Re: [[PATCH] 0/3] imx-dma: fixes
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 a bunch for doing this. I had similar ones but couldnt test due to lack of HW. Lets keep improving this driver as it needs bunch of other fixes too... ~Vinod > > Regards, > Michael > > Michael Grzeschik (3): > dma: imx-dma: fix slow path issue in prep_dma_cyclic > dma: imx-dma: fix lockdep issue between irqhandler and tasklet > dma: imx-dma: fix callback path in tasklet > > drivers/dma/imx-dma.c | 31 +++ > 1 file changed, 15 insertions(+), 16 deletions(-) > > -- > 1.8.4.rc3 > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [[PATCH] 0/3] imx-dma: fixes
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 0x1000 > > [ 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 0x1000 > > [ 60.795424] imx-dma imx-dma: dma_irq_handler called, disr=0x0001 > > [ 60.801857] imx-dma imx-dma: imxdma_sg_next channel: 0 dst 0x10014038, > > src 0xa5523000, size 0x1000 > > [ 61.290221] imx-dma imx-dma: channel 0: watchdog timeout! > > Beside on 2.6.31 the same transfer results in no failure. > > > [ 55.27] imxdma0: imx_dma_setup_sg sg=c7ae3800 sgcount=9 total > > length=32768 dev_addr=0x10014038 for write > > [ 55.28] imxdma0: next sg chunk dst 0x10014038, src 0xa73a1c00, size > > 0x1000 > > [ 55.29] imxdma0: imx_dma_enable > > [ 55.29] imxdma: dma_irq_handler called, disr=0x0001 > > [ 55.29] imxdma0: next sg chunk dst 0x10014038, src 0xa73a2c00, size > > 0x0400 > > [ 55.30] imxdma: dma_irq_handler called, disr=0x0001 > > [ 55.30] imxdma0: next sg chunk dst 0x10014038, src 0xa73a5000, size > > 0x1000 > > [ 55.32] imxdma: dma_irq_handler called, disr=0x0001 > > [ 55.32] imxdma0: next sg chunk dst 0x10014038, src 0xa73a7000, size > > 0x1000 > > [ 55.33] imxdma: dma_irq_handler called, disr=0x0001 > > [ 55.33] imxdma0: next sg chunk dst 0x10014038, src 0xa73a9000, size > > 0x1000 > > [ 55.34] imxdma: dma_irq_handler called, disr=0x0001 > > [ 55.34] imxdma0: next sg chunk dst 0x10014038, src 0xa73ab000, size > > 0x1000 > > [ 55.36] imxdma: dma_irq_handler called, disr=0x0001 > > [ 55.36] imxdma0: next sg chunk dst 0x10014038, src 0xa73ad000, size > > 0x1000 > > [ 55.38] imxdma: dma_irq_handler called, disr=0x0001 > > [ 55.38] imxdma0: next sg chunk dst 0x10014038, src 0xa73af000, size > > 0x1000 > > [ 55.39] imxdma: dma_irq_handler called, disr=0x0001 > > [ 55.39] imxdma0: next sg chunk dst 0x10014038, src 0xa73b1000, size > > 0x0c00 > > [ 55.40] imxdma: dma_irq_handler called, disr=0x0001 > > [ 55.41] 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [[PATCH] 0/3] imx-dma: fixes
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 0x1000 [ 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 0x1000 [ 60.795424] imx-dma imx-dma: dma_irq_handler called, disr=0x0001 [ 60.801857] imx-dma imx-dma: imxdma_sg_next channel: 0 dst 0x10014038, src 0xa5523000, size 0x1000 [ 61.290221] imx-dma imx-dma: channel 0: watchdog timeout! Beside on 2.6.31 the same transfer results in no failure. [ 55.27] imxdma0: imx_dma_setup_sg sg=c7ae3800 sgcount=9 total length=32768 dev_addr=0x10014038 for write [ 55.28] imxdma0: next sg chunk dst 0x10014038, src 0xa73a1c00, size 0x1000 [ 55.29] imxdma0: imx_dma_enable [ 55.29] imxdma: dma_irq_handler called, disr=0x0001 [ 55.29] imxdma0: next sg chunk dst 0x10014038, src 0xa73a2c00, size 0x0400 [ 55.30] imxdma: dma_irq_handler called, disr=0x0001 [ 55.30] imxdma0: next sg chunk dst 0x10014038, src 0xa73a5000, size 0x1000 [ 55.32] imxdma: dma_irq_handler called, disr=0x0001 [ 55.32] imxdma0: next sg chunk dst 0x10014038, src 0xa73a7000, size 0x1000 [ 55.33] imxdma: dma_irq_handler called, disr=0x0001 [ 55.33] imxdma0: next sg chunk dst 0x10014038, src 0xa73a9000, size 0x1000 [ 55.34] imxdma: dma_irq_handler called, disr=0x0001 [ 55.34] imxdma0: next sg chunk dst 0x10014038, src 0xa73ab000, size 0x1000 [ 55.36] imxdma: dma_irq_handler called, disr=0x0001 [ 55.36] imxdma0: next sg chunk dst 0x10014038, src 0xa73ad000, size 0x1000 [ 55.38] imxdma: dma_irq_handler called, disr=0x0001 [ 55.38] imxdma0: next sg chunk dst 0x10014038, src 0xa73af000, size 0x1000 [ 55.39] imxdma: dma_irq_handler called, disr=0x0001 [ 55.39] imxdma0: next sg chunk dst 0x10014038, src 0xa73b1000, size 0x0c00 [ 55.40] imxdma: dma_irq_handler called, disr=0x0001 [ 55.41] 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [[PATCH] 0/3] imx-dma: fixes
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 a bunch for doing this. I had similar ones but couldnt test due to lack of HW. Lets keep improving this driver as it needs bunch of other fixes too... ~Vinod Regards, Michael Michael Grzeschik (3): dma: imx-dma: fix slow path issue in prep_dma_cyclic dma: imx-dma: fix lockdep issue between irqhandler and tasklet dma: imx-dma: fix callback path in tasklet drivers/dma/imx-dma.c | 31 +++ 1 file changed, 15 insertions(+), 16 deletions(-) -- 1.8.4.rc3 -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [[PATCH] 0/3] imx-dma: fixes
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 0x1000 > [ 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 0x1000 > [ 60.795424] imx-dma imx-dma: dma_irq_handler called, disr=0x0001 > [ 60.801857] imx-dma imx-dma: imxdma_sg_next channel: 0 dst 0x10014038, > src 0xa5523000, size 0x1000 > [ 61.290221] imx-dma imx-dma: channel 0: watchdog timeout! Beside on 2.6.31 the same transfer results in no failure. > [ 55.27] imxdma0: imx_dma_setup_sg sg=c7ae3800 sgcount=9 total > length=32768 dev_addr=0x10014038 for write > [ 55.28] imxdma0: next sg chunk dst 0x10014038, src 0xa73a1c00, size > 0x1000 > [ 55.29] imxdma0: imx_dma_enable > [ 55.29] imxdma: dma_irq_handler called, disr=0x0001 > [ 55.29] imxdma0: next sg chunk dst 0x10014038, src 0xa73a2c00, size > 0x0400 > [ 55.30] imxdma: dma_irq_handler called, disr=0x0001 > [ 55.30] imxdma0: next sg chunk dst 0x10014038, src 0xa73a5000, size > 0x1000 > [ 55.32] imxdma: dma_irq_handler called, disr=0x0001 > [ 55.32] imxdma0: next sg chunk dst 0x10014038, src 0xa73a7000, size > 0x1000 > [ 55.33] imxdma: dma_irq_handler called, disr=0x0001 > [ 55.33] imxdma0: next sg chunk dst 0x10014038, src 0xa73a9000, size > 0x1000 > [ 55.34] imxdma: dma_irq_handler called, disr=0x0001 > [ 55.34] imxdma0: next sg chunk dst 0x10014038, src 0xa73ab000, size > 0x1000 > [ 55.36] imxdma: dma_irq_handler called, disr=0x0001 > [ 55.36] imxdma0: next sg chunk dst 0x10014038, src 0xa73ad000, size > 0x1000 > [ 55.38] imxdma: dma_irq_handler called, disr=0x0001 > [ 55.38] imxdma0: next sg chunk dst 0x10014038, src 0xa73af000, size > 0x1000 > [ 55.39] imxdma: dma_irq_handler called, disr=0x0001 > [ 55.39] imxdma0: next sg chunk dst 0x10014038, src 0xa73b1000, size > 0x0c00 > [ 55.40] imxdma: dma_irq_handler called, disr=0x0001 > [ 55.41] 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. Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [[PATCH] 0/3] imx-dma: fixes
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 0x1000 [ 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 0x1000 [ 60.795424] imx-dma imx-dma: dma_irq_handler called, disr=0x0001 [ 60.801857] imx-dma imx-dma: imxdma_sg_next channel: 0 dst 0x10014038, src 0xa5523000, size 0x1000 [ 61.290221] imx-dma imx-dma: channel 0: watchdog timeout! Beside on 2.6.31 the same transfer results in no failure. [ 55.27] imxdma0: imx_dma_setup_sg sg=c7ae3800 sgcount=9 total length=32768 dev_addr=0x10014038 for write [ 55.28] imxdma0: next sg chunk dst 0x10014038, src 0xa73a1c00, size 0x1000 [ 55.29] imxdma0: imx_dma_enable [ 55.29] imxdma: dma_irq_handler called, disr=0x0001 [ 55.29] imxdma0: next sg chunk dst 0x10014038, src 0xa73a2c00, size 0x0400 [ 55.30] imxdma: dma_irq_handler called, disr=0x0001 [ 55.30] imxdma0: next sg chunk dst 0x10014038, src 0xa73a5000, size 0x1000 [ 55.32] imxdma: dma_irq_handler called, disr=0x0001 [ 55.32] imxdma0: next sg chunk dst 0x10014038, src 0xa73a7000, size 0x1000 [ 55.33] imxdma: dma_irq_handler called, disr=0x0001 [ 55.33] imxdma0: next sg chunk dst 0x10014038, src 0xa73a9000, size 0x1000 [ 55.34] imxdma: dma_irq_handler called, disr=0x0001 [ 55.34] imxdma0: next sg chunk dst 0x10014038, src 0xa73ab000, size 0x1000 [ 55.36] imxdma: dma_irq_handler called, disr=0x0001 [ 55.36] imxdma0: next sg chunk dst 0x10014038, src 0xa73ad000, size 0x1000 [ 55.38] imxdma: dma_irq_handler called, disr=0x0001 [ 55.38] imxdma0: next sg chunk dst 0x10014038, src 0xa73af000, size 0x1000 [ 55.39] imxdma: dma_irq_handler called, disr=0x0001 [ 55.39] imxdma0: next sg chunk dst 0x10014038, src 0xa73b1000, size 0x0c00 [ 55.40] imxdma: dma_irq_handler called, disr=0x0001 [ 55.41] 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. Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [[PATCH] 0/3] imx-dma: fixes
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 ~Vinod > > Regards, > Michael > > Michael Grzeschik (3): > dma: imx-dma: fix slow path issue in prep_dma_cyclic > dma: imx-dma: fix lockdep issue between irqhandler and tasklet > dma: imx-dma: fix callback path in tasklet > > drivers/dma/imx-dma.c | 31 +++ > 1 file changed, 15 insertions(+), 16 deletions(-) > > -- > 1.8.4.rc3 > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [[PATCH] 0/3] imx-dma: fixes
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 ~Vinod Regards, Michael Michael Grzeschik (3): dma: imx-dma: fix slow path issue in prep_dma_cyclic dma: imx-dma: fix lockdep issue between irqhandler and tasklet dma: imx-dma: fix callback path in tasklet drivers/dma/imx-dma.c | 31 +++ 1 file changed, 15 insertions(+), 16 deletions(-) -- 1.8.4.rc3 -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[[PATCH] 0/3] imx-dma: fixes
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. Regards, Michael Michael Grzeschik (3): dma: imx-dma: fix slow path issue in prep_dma_cyclic dma: imx-dma: fix lockdep issue between irqhandler and tasklet dma: imx-dma: fix callback path in tasklet drivers/dma/imx-dma.c | 31 +++ 1 file changed, 15 insertions(+), 16 deletions(-) -- 1.8.4.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[[PATCH] 0/3] imx-dma: fixes
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. Regards, Michael Michael Grzeschik (3): dma: imx-dma: fix slow path issue in prep_dma_cyclic dma: imx-dma: fix lockdep issue between irqhandler and tasklet dma: imx-dma: fix callback path in tasklet drivers/dma/imx-dma.c | 31 +++ 1 file changed, 15 insertions(+), 16 deletions(-) -- 1.8.4.rc3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
