linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Rui Miguel Silva" <rmfrfs@gmail.com>,
	"Johan Hovold" <johan@kernel.org>,
	"Alex Elder" <elder@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
	"Bruce Chang" <brucechang@via.com.tw>,
	"Harald Welte" <HaraldWelte@viatech.com>,
	"Alex Dubov" <oakad@yahoo.com>,
	"Sascha Sommer" <saschasommer@freenet.de>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Jesper Nilsson" <jesper.nilsson@axis.com>,
	"Lars Persson" <lars.persson@axis.com>,
	"Paul Cercueil" <paul@crapouillou.net>,
	"Ludovic Desroches" <ludovic.desroches@microchip.com>,
	"Nicolas Ferre" <nicolas.ferre@microchip.com>
Subject: Re: [PATCH 06/19] mmc: cb710: Inform the mmc core about the maximum busy timeout
Date: Fri, 8 May 2020 10:38:07 +0200	[thread overview]
Message-ID: <CAPDyKFqoe4goNa-K9gmRujgwL-_Hff0MRPvpod7etkj0L8wmzQ@mail.gmail.com> (raw)
In-Reply-To: <CAPDyKFr6yq+xA_dcRTDrZ_ek8Jjmiep+Fp_RYfozPdv7FFaW+Q@mail.gmail.com>

On Wed, 15 Apr 2020 at 09:41, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Tue, 14 Apr 2020 at 20:40, Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
> >
> > On Tue, Apr 14, 2020 at 06:14:00PM +0200, Ulf Hansson wrote:
> > > Some commands uses R1B responses, which means the card may assert the DAT0
> > > line to signal busy for a period of time, after it has received the
> > > command. The mmc core normally specifies the busy period for the command in
> > > the cmd->busy_timeout. Ideally the driver should respect it, but that
> > > requires quite some update of the code, so let's defer that to someone with
> > > the HW at hand.
> > >
> > > Instead, let's inform the mmc core about the maximum supported busy timeout
> > > in ->max_busy_timeout during ->probe(). This value corresponds to the fixed
> > > ~2s timeout of the polling loop, implemented in cb710_wait_for_event(). In
> > > this way, we let the mmc core validate the needed timeout, which may lead
> > > to that it converts from a R1B into a R1 response and then use CMD13 to
> > > poll for busy completion.
> > >
> > > In other words, this change enables support for commands with longer busy
> > > periods than 2s, like erase (CMD38) for example.
> > [...]
> > > +     /*
> > > +      * In cb710_wait_for_event() we use a fixed timeout of ~2s, hence let's
> > > +      * inform the core about it. A future improvement should instead make
> > > +      * use of the cmd->busy_timeout.
> > > +      */
> > [...]
> >
> > I'm not sure whether the controller limits busy signalling time.
> > Since this is rare HW now, I would just pass the timeout to
> > cb710_wait_for_event() and see if someone reports a bug.
>
> Alright, let me try something like that. Thanks for your suggestion.

I looked a bit more closely at your suggestion, but unfortunately it
requires quite some changes to the code.

To pass a timeout and need to move cb710_wait_for_event() from using a
fixed number of polling loops into using "timeout_ms" value instead.
Although, rather than open coding yet another new polling loop and
perhaps introduce new errors, I prefer moving to readx_poll_timeout().
However, to do that, even more changes are needed around
cb710_check_event().

Once that is done, we also have cb710_wait_while_busy(), that uses a
similar polling loop as cb710_wait_for_event(). So then it seems
reasonable to convert this one too.

To conclude, for now, I am going to apply $subject patch as is. Then
we can always do the above conversion later on, if we see that there
is a need for it.

Kind regards
Uffe

  reply	other threads:[~2020-05-08  8:38 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-14 16:13 [PATCH 00/19] mmc: Improve host driver's support for R1B responses Ulf Hansson
2020-04-14 16:13 ` [PATCH 01/19] mmc: atmel-mci: Keep timer enabled when queuing a next request Ulf Hansson
2020-04-17 20:39   ` ludovic.desroches
2020-04-14 16:13 ` [PATCH 02/19] mmc: atmel-mci: Set the timer per command rather than per request Ulf Hansson
2020-04-17 20:40   ` ludovic.desroches
2020-04-14 16:13 ` [PATCH 03/19] mmc: atmel-mci: Respect the cmd->busy_timeout from the mmc core Ulf Hansson
2020-04-17 20:44   ` ludovic.desroches
2020-04-14 16:13 ` [PATCH 04/19] mmc: jz4740: Inform the mmc core about the maximum busy timeout Ulf Hansson
2020-04-14 16:13 ` [PATCH 05/19] mmc: usdhi6rol0: " Ulf Hansson
2020-04-15  6:34   ` Jesper Nilsson
2020-04-14 16:14 ` [PATCH 06/19] mmc: cb710: " Ulf Hansson
2020-04-14 18:39   ` Michał Mirosław
2020-04-15  7:41     ` Ulf Hansson
2020-05-08  8:38       ` Ulf Hansson [this message]
2020-04-14 16:14 ` [PATCH 07/19] mmc: owl-mmc: Respect the cmd->busy_timeout from the mmc core Ulf Hansson
2020-04-14 16:14 ` [PATCH 08/19] mmc: sdricoh_cs: Drop unused defines Ulf Hansson
2020-04-14 16:14 ` [PATCH 09/19] mmc: sdricoh_cs: Use MMC_APP_CMD rather than a hardcoded number Ulf Hansson
2020-04-14 16:14 ` [PATCH 10/19] mmc: sdricoh_cs: Move MMC_APP_CMD handling to sdricoh_mmc_cmd() Ulf Hansson
2020-04-14 16:14 ` [PATCH 11/19] mmc: sdricoh_cs: Drop redundant in-parameter to sdricoh_query_status() Ulf Hansson
2020-04-14 16:14 ` [PATCH 12/19] mmc: sdricoh_cs: Throttle polling rate for data transfers Ulf Hansson
2020-04-14 16:14 ` [PATCH 13/19] mmc: sdricoh_cs: Throttle polling rate for commands Ulf Hansson
2020-04-14 16:14 ` [PATCH 14/19] mmc: sdricoh_cs: Respect the cmd->busy_timeout from the mmc core Ulf Hansson
2020-04-14 16:14 ` [PATCH 15/19] mmc: tifm_sd: Inform the mmc core about the maximum busy timeout Ulf Hansson
2020-04-14 16:14 ` [PATCH 16/19] mmc: via-sdmmc: Respect the cmd->busy_timeout from the mmc core Ulf Hansson
2020-04-14 16:14 ` [PATCH 17/19] mmc: mmc_spi: Add/rename defines for timeouts Ulf Hansson
2020-04-14 16:14 ` [PATCH 18/19] mmc: mmc_spi: Respect the cmd->busy_timeout from the mmc core Ulf Hansson
2020-04-14 16:14 ` [PATCH 19/19] staging: greybus: sdio: " Ulf Hansson
2020-04-15  8:30   ` Rui Miguel Silva
2020-04-16 10:25   ` Greg Kroah-Hartman

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=CAPDyKFqoe4goNa-K9gmRujgwL-_Hff0MRPvpod7etkj0L8wmzQ@mail.gmail.com \
    --to=ulf.hansson@linaro.org \
    --cc=HaraldWelte@viatech.com \
    --cc=adrian.hunter@intel.com \
    --cc=brucechang@via.com.tw \
    --cc=elder@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=j.neuschaefer@gmx.net \
    --cc=jesper.nilsson@axis.com \
    --cc=johan@kernel.org \
    --cc=lars.persson@axis.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ludovic.desroches@microchip.com \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=nicolas.ferre@microchip.com \
    --cc=oakad@yahoo.com \
    --cc=paul@crapouillou.net \
    --cc=rmfrfs@gmail.com \
    --cc=saschasommer@freenet.de \
    /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).