linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mgr@pengutronix.de (Michael Grzeschik)
To: linux-arm-kernel@lists.infradead.org
Subject: [[PATCH] 0/3] imx-dma: fixes
Date: Sun, 29 Sep 2013 01:56:03 +0200	[thread overview]
Message-ID: <20130928235603.GB25376@pengutronix.de> (raw)
In-Reply-To: <1380004503.6145.16.camel@mars>

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.

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-5555 |

  parent reply	other threads:[~2013-09-28 23:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-17 13:56 [[PATCH] 0/3] imx-dma: fixes Michael Grzeschik
2013-09-17 13:56 ` [[PATCH] 1/3] dma: imx-dma: fix slow path issue in prep_dma_cyclic Michael Grzeschik
2013-09-17 13:56 ` [[PATCH] 2/3] dma: imx-dma: fix lockdep issue between irqhandler and tasklet Michael Grzeschik
2013-09-17 13:56 ` [[PATCH] 3/3] dma: imx-dma: fix callback path in tasklet Michael Grzeschik
2013-09-23  4:19 ` [[PATCH] 0/3] imx-dma: fixes Vinod Koul
     [not found]   ` <1380004503.6145.16.camel@mars>
2013-09-28 23:56     ` Michael Grzeschik [this message]
2013-10-03 15:06       ` Vinod Koul
2013-10-03 15:13 ` Vinod Koul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130928235603.GB25376@pengutronix.de \
    --to=mgr@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).