From: Dong Aisheng <b29396@freescale.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Dong Aisheng <dongas86@gmail.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
Chris Ball <chris@printf.net>,
Stephen Warren <swarren@nvidia.com>,
Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>,
Adrian Hunter <adrian.hunter@intel.com>,
b51421@freescale.com
Subject: Re: [PATCH 00/13] mmc: Improve busy detection for MMC_CAP_WAIT_WHILE_BUSY
Date: Wed, 3 Sep 2014 15:24:57 +0800 [thread overview]
Message-ID: <20140903072452.GA6799@shlinux1.ap.freescale.net> (raw)
In-Reply-To: <CAPDyKFp55i7cMJ2jNnoLPzLFdkHfW7F_-86y0P1wb94usec3nA@mail.gmail.com>
On Wed, Sep 03, 2014 at 09:32:35AM +0200, Ulf Hansson wrote:
> On 3 September 2014 08:51, Dong Aisheng <dongas86@gmail.com> wrote:
> > Hi Ulf,
> >
> > On Thu, Jan 30, 2014 at 6:37 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >> This patchset improves the handling around busy detection in the mmc core layer
> >> while operating on host supporting MMC_CAP_WAIT_WHILE_BUSY.
> >>
> >> A R1B response is for an mmc command, specified as and R1 but with an optional
> >> busy assertion on the DAT0 line. Hosts supporting MMC_CAP_WAIT_WHILE_BUSY,
> >> normally has a busy detection mechanism build in it's controller HW.
> >>
> >> Using such a feature decreases the need for polling of the card's status using
> >> CMD13, which is the fallback method used by the mmc core for hosts that don't
> >> support MMC_CAP_WAIT_WHILE_BUSY.
> >>
> >> Typcial commands that expects R1B responses are CMD6 (SWITCH), CMD12 (STOP),
> >> CMD38 (ERASE) and CMD5 (SLEEP). This patchset adresses CMD6, CMD5 and improves
> >> some parts where CMD12 are used. If the implemented approach becomes accepted,
> >> a future patchset for CMD38 can be based on top if this patchset.
> >>
> >> Do note, the final two patches implements support for busy detection for the
> >> mmci host driver, since some of it's HW variants do supports busy detection.
> >>
> >> Future suggested improvements related to this patchset: (Please, feel free to
> >> implement any of them :-) ).
> >>
> >> a) For CMD38, select a fixed number maximum blocks to accept for
> >> erase/discard/trim operations. Compute the needed timeout depending on each
> >> card's erase information provided through it's CSD/EXT_CSD registers. Then
> >> follow the same principle as for sending a CMD6.
> >>
> >> b) At least for CMD38, but likely for other commands as well, we could benefit
> >> from doing a _periodic_ CMD13 polling to handle the busy completion. This will
> >> also be useful for hosts supporting MMC_CAP_WAIT_WHILE_BUSY, in particular for
> >> cases where the host are unable to support the needed busy timeout.
> >>
> >
> > Do you have the plan to implement above two items?
>
> Yes, it's on top of my TODO list for MMC. I really need to get this
> done asap. Thanks for pinging me about this.
>
Great!
> > Since currently the max_discard_sectors is still calculated based on
> > max_busy_timeout of host,
> > it is possible that for some eMMC chips, the max_discard_sectors is 1,
> > which then cause the erase operation terribly slow.
>
> Yes!
>
> Another issue to fix is get MMC_CAP_ERASE removed - and that should be
> possible once the above described problem has been solved.
>
Yes, seems MMC_CAP_ERASE is not needed anymore.
Regards
Dong Aisheng
> Kind regards
> Uffe
next prev parent reply other threads:[~2014-09-03 7:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-29 22:37 [PATCH 00/13] mmc: Improve busy detection for MMC_CAP_WAIT_WHILE_BUSY Ulf Hansson
2014-01-29 22:37 ` [PATCH 01/13] mmc: core: Rename max_discard_to to max_busy_timeout Ulf Hansson
2014-01-29 22:37 ` [PATCH 02/13] mmc: core: Rename cmd_timeout_ms to busy_timeout Ulf Hansson
2014-01-29 22:37 ` [PATCH 03/13] mmc: core: Add ignore_crc flag to __mmc_switch Ulf Hansson
2014-01-29 22:37 ` [PATCH 04/13] mmc: core: Minor simplifications " Ulf Hansson
2014-01-29 22:37 ` [PATCH 05/13] mmc: core: Fixup busy detection for mmc switch operations Ulf Hansson
2014-01-29 22:37 ` [PATCH 06/13] mmc: core: Use generic CMD6 time while switching to eMMC HS200 mode Ulf Hansson
2014-01-29 22:37 ` [PATCH 07/13] mmc: core: Respect host's max_busy_timeout when sending sleep cmd Ulf Hansson
2014-01-29 22:38 ` [PATCH 08/13] mmc: block: Use R1 responses for stop cmds for read requests Ulf Hansson
2014-01-29 22:38 ` [PATCH 09/13] mmc: block: Implement card_busy_detect() for busy detection Ulf Hansson
2014-01-29 22:38 ` [PATCH 10/13] mmc: block: Respect hw busy detection in card_busy_detect() Ulf Hansson
2014-01-29 22:38 ` [PATCH 11/13] mmc: block: Fixup busy detection while invoking stop cmd at recovery Ulf Hansson
2014-01-29 22:38 ` [PATCH 12/13] mmc: mmci: Handle CMD irq before DATA irq Ulf Hansson
2014-02-12 13:17 ` Ulf Hansson
2014-01-29 22:38 ` [PATCH 13/13] mmc: mmci: Enable support for busy detection for ux500 variant Ulf Hansson
2014-02-12 13:20 ` Ulf Hansson
2014-09-03 6:51 ` [PATCH 00/13] mmc: Improve busy detection for MMC_CAP_WAIT_WHILE_BUSY Dong Aisheng
2014-09-03 7:32 ` Ulf Hansson
2014-09-03 7:24 ` Dong Aisheng [this message]
2014-09-05 9:29 ` Jaehoon Chung
2014-09-05 11:02 ` Ulf Hansson
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=20140903072452.GA6799@shlinux1.ap.freescale.net \
--to=b29396@freescale.com \
--cc=adrian.hunter@intel.com \
--cc=b51421@freescale.com \
--cc=chris@printf.net \
--cc=dongas86@gmail.com \
--cc=linux-mmc@vger.kernel.org \
--cc=swarren@nvidia.com \
--cc=ulf.hansson@linaro.org \
--cc=vladimir_zapolskiy@mentor.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;
as well as URLs for NNTP newsgroup(s).