Linux MultiMedia Card development
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Simon Horman <horms@verge.net.au>,
	Kuninori Morimoto <kuninori.morimoto.gx@gmail.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>
Subject: Re: [RFC] mmc: host: tmio: ensure end of DMA and SD access are in sync
Date: Thu, 16 Feb 2017 09:44:07 +0100	[thread overview]
Message-ID: <20170216084406.GB1443@katana> (raw)
In-Reply-To: <CAPDyKFotpgrUHtTYQ9QQfzQ0pY6=MtU2JEDAjPX=wh50k=qGjA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]

On Thu, Feb 16, 2017 at 09:28:24AM +0100, Ulf Hansson wrote:
> On 15 February 2017 at 19:05, Wolfram Sang
> <wsa+renesas@sang-engineering.com> wrote:
> > The current code assumes that DMA is finished before SD access end is
> > flagged. Thus, it schedules the 'dma_complete' tasklet in the SD card
> > interrupt routine when DATAEND is set. The assumption is not safe,
> > though. Even by mounting an SD card, it can be seen that sometimes DMA
> > complete is first, sometimes DATAEND. It seems they are usually close
> > enough timewise to not cause problems. However, a customer reported that
> > with CMD53 sometimes things really break apart. As a result, the BSP has
> > a patch which introduces flags for both events and makes sure both flags
> > are set before scheduling the tasklet. The customer accepted the patch,
> > yet it doesn't seem a proper upstream solution to me.
> >
> > This patch refactors the code to replace the tasklet with already
> > existing and more lightweight mechanisms. First of all, we set the
> > callback in a DMA descriptor to automatically get notified when DMA is
> > done. In the callback, we then use a completion to make sure the SD
> > access has already ended. Then, we proceed as before.
> 
> I have similar experience and a HW behaviour. Your reasoning seems
> correct to me.

Great. Thanks for the review!

> > So, calling for early review here. And opinions how to proceed. I am not sure
> > we want this in renesas-drivers until the SDIO functionality has been verified?
> > Because it is the reason this patch exists in the first place :)
> 
> If there are no regressions, we could consider this as a nice
> clean-up, instead of waiting for the dependencies to be resolved.

Fine with me. I feel much more comfortable with your experience backing
up ours.

> 
> Did you run some performance test?

The throughput numbers of 'dd' are exactly the same. But maybe I could
run one or two more tests with specifically testing that.

> > index 2b349d48fb9a8a..891d400d2a7cf2 100644
> > --- a/drivers/mmc/host/tmio_mmc.h
> > +++ b/drivers/mmc/host/tmio_mmc.h
> > @@ -137,7 +137,7 @@ struct tmio_mmc_host {
> >         bool                    force_pio;
> >         struct dma_chan         *chan_rx;
> >         struct dma_chan         *chan_tx;
> > -       struct tasklet_struct   dma_complete;
> > +       struct completion       dma_dataend;
> >         struct tasklet_struct   dma_issue;
> 
> The next step would be to convert the driver to a use threaded IRQ
> handler in favour of the dma_issue tasklet. That should also work,
> right!? :-)

I'll check. I also identified this tasklet as the next target but I
haven't actually looked into it yet.

Thanks for looking into it right away,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      reply	other threads:[~2017-02-16  8:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-15 18:05 [RFC] mmc: host: tmio: ensure end of DMA and SD access are in sync Wolfram Sang
2017-02-16  8:28 ` Ulf Hansson
2017-02-16  8:44   ` Wolfram Sang [this message]

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=20170216084406.GB1443@katana \
    --to=wsa@the-dreams.de \
    --cc=horms@verge.net.au \
    --cc=kuninori.morimoto.gx@gmail.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=wsa+renesas@sang-engineering.com \
    /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