From: Bean Huo <beanhuo@iokpp.de>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: adrian.hunter@intel.com, beanhuo@micron.com,
jakub.kwapisz@toradex.com, rafael.beims@toradex.com,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2] mmc: Add quirk MMC_QUIRK_BROKEN_CACHE_FLUSH for Micron eMMC Q2J54A
Date: Sun, 17 Sep 2023 22:11:24 +0200 [thread overview]
Message-ID: <c66810ae52446db41fd187ee4be24d04d40c1abb.camel@iokpp.de> (raw)
In-Reply-To: <CAPDyKFruYooG4yQ4yqrwEcrvy4xe6hYByF2Q57eQ1g0tiUtcug@mail.gmail.com>
Hi Ulf,
Thanks for your comment, much appreciated!
On Fri, 2023-09-15 at 00:09 +0200, Ulf Hansson wrote:
> On Thu, 14 Sept 2023 at 22:28, Bean Huo <beanhuo@iokpp.de> wrote:
> >
> > From: Bean Huo <beanhuo@micron.com>
> >
> > Micron MTFC4GACAJCN eMMC supports cache but requires that flush
> > cache
> > operation be allowed only after a write has occurred. Otherwise,
> > the
> > cache flush command or subsequent commands will time out.
>
> For my information, more exactly, how can we trigger this problem?
>
This issue may be likely reproduced in this command sequence:
eMMC power-cycle/reset-->...(other operations, but no data write)...-
>cache flush-->...... ->write data, must say, it is not 100%
reproducable.
> >
> > Signed-off-by: Bean Huo <beanhuo@micron.com>
> > Co-developed-by: Rafael Beims <rafael.beims@toradex.com>
> > Tested-by: Rafael Beims <rafael.beims@toradex.com>
> > Cc: stable@vger.kernel.org
> > ---
> > Changelog:
> >
> > v1--v2:
> > 1. Add Rafael's test-tag, and Co-developed-by.
> > 2. Check host->card whether NULL or not in
> > __mmc_start_request() before asserting host->card->->quirks
> >
> > ---
> > drivers/mmc/core/core.c | 7 +++++++
> > drivers/mmc/core/mmc.c | 5 +++++
> > drivers/mmc/core/quirks.h | 7 ++++---
> > include/linux/mmc/card.h | 2 ++
> > 4 files changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> > index 3d3e0ca52614..86a669b35b91 100644
> > --- a/drivers/mmc/core/core.c
> > +++ b/drivers/mmc/core/core.c
> > @@ -259,6 +259,13 @@ static void __mmc_start_request(struct
> > mmc_host *host, struct mmc_request *mrq)
> > host->cqe_ops->cqe_off(host);
> >
> > host->ops->request(host, mrq);
> > +
> > + if (host->card && host->card->quirks &
> > MMC_QUIRK_BROKEN_CACHE_FLUSH &&
> > + !host->card->written_flag) {
> > + if (mrq->cmd->opcode == MMC_WRITE_MULTIPLE_BLOCK ||
> > + mrq->cmd->opcode == MMC_WRITE_BLOCK)
> > + host->card->written_flag = true;
> > + }
>
> I don't quite like that we are adding the above code here - as it's
> used for *all* requests.
>
> Seems like the flag is better set from the mmc block device driver
> instead. Somewhere in the path when we serve I/O write requests.
>
yes, you are correct, I will update the patch and add this flag set in
mmc block driver mmc_blk_mq_issue_rq().
> > }
> >
> > static void mmc_mrq_pr_debug(struct mmc_host *host, struct
> > mmc_request *mrq,
> > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> > index 89cd48fcec79..a2edd065fa1b 100644
> > --- a/drivers/mmc/core/mmc.c
> > +++ b/drivers/mmc/core/mmc.c
> > @@ -1929,6 +1929,8 @@ static int mmc_init_card(struct mmc_host
> > *host, u32 ocr,
> > if (!oldcard)
> > host->card = card;
> >
> > + card->written_flag = false;
> > +
>
> According to your earlier reply, it sounds like the problem isn't
> really about the card being re-initialized, but rather that we
> actually need a write request to happen before a flush. No matter
> what, no?
>
> See more about this below.
>
Actually, it matters that the first cache flush command after
reboot/reset. means that for the first cache flush command, before
execution, the write data operation should occur,
After that, there is no problem even if there are no writes before the
cache is flushed.
> > return 0;
> >
> > free_card:
> > @@ -2081,6 +2083,9 @@ static int _mmc_flush_cache(struct mmc_host
> > *host)
> > {
> > int err = 0;
> >
> > + if (host->card->quirks & MMC_QUIRK_BROKEN_CACHE_FLUSH &&
> > !host->card->written_flag)
> > + return err;
> > +
>
> Could an option to the above, be to reset the flag here instead.
> After
> a successful cache flush has been done.
>
>
As I explained above, the first cache flush after a power cycle/reset
is important. We just want to eliminate the first unnecessary cache
flush.
We can eliminate all unnecessary cache flushes when the cache is empty.
But I don't want to change the current logic too much, only want to
focus on the first unnecessary cache flush, how do you think?
Kind regards,
Bean
prev parent reply other threads:[~2023-09-17 20:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-14 20:27 Bean Huo
2023-09-14 22:09 ` Ulf Hansson
2023-09-17 20:11 ` Bean Huo [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=c66810ae52446db41fd187ee4be24d04d40c1abb.camel@iokpp.de \
--to=beanhuo@iokpp.de \
--cc=adrian.hunter@intel.com \
--cc=beanhuo@micron.com \
--cc=jakub.kwapisz@toradex.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=rafael.beims@toradex.com \
--cc=stable@vger.kernel.org \
--cc=ulf.hansson@linaro.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
all inboxes | Powered by JetHome®