From: Avri Altman <Avri.Altman@wdc.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc <linux-mmc@vger.kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Brendan Peter <bpeter@lytx.com>
Subject: RE: [PATCH v4 1/2] mmc: block: Issue flush only if allowed
Date: Sat, 24 Apr 2021 18:28:39 +0000 [thread overview]
Message-ID: <DM6PR04MB657537C632B237572E6A4F7CFC449@DM6PR04MB6575.namprd04.prod.outlook.com> (raw)
In-Reply-To: <CAPDyKFoejcQz2jPgqzc+2W+mfaXOatGCdd8CdNYsk4FsUEb=7Q@mail.gmail.com>
> On Tue, 20 Apr 2021 at 15:46, Avri Altman <avri.altman@wdc.com> wrote:
> >
> > The cache may be flushed to the nonvolatile storage by writing to
> > FLUSH_CACHE byte (EXT_CSD byte [32]). When in command queueing mode,
> the
> > cache may be flushed by issuing a CMDQ_TASK_ DEV_MGMT (CMD48) with a
> > FLUSH_CACHE op-code. Either way, verify that The cache function is
> > turned ON before doing so.
> >
> > fixes: 1e8e55b67030 (mmc: block: Add CQE support)
> >
> > Reported-by: Brendan Peter <bpeter@lytx.com>
> > Tested-by: Brendan Peter <bpeter@lytx.com>
> > Signed-off-by: Avri Altman <avri.altman@wdc.com>
> > ---
> > drivers/mmc/core/block.c | 9 +++++++++
> > drivers/mmc/core/mmc.c | 2 +-
> > drivers/mmc/core/mmc_ops.h | 5 +++++
> > 3 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> > index 8bfd4d95b386..24e1ecbdd510 100644
> > --- a/drivers/mmc/core/block.c
> > +++ b/drivers/mmc/core/block.c
> > @@ -2186,6 +2186,11 @@ static int mmc_blk_wait_for_idle(struct
> mmc_queue *mq, struct mmc_host *host)
> > return mmc_blk_rw_wait(mq, NULL);
> > }
> >
> > +static bool mmc_blk_cache_disabled(struct mmc_card *card)
> > +{
> > + return mmc_card_mmc(card) && !mmc_flush_allowed(card);
>
> It's these kinds of use with mmc_card_mmc() that I think we need to
> strive towards avoiding when going forward.
>
> For example, newer SD cards support both cache and command queueing
> nowadays, which means that we need to make the code in the mmc block
> layer more agnostic. To do that, I think we should use the bus_ops
> callbacks. That's why I started out by adding the ->flush_cache()
> callback in the other patch.
Understood.
>
> > +}
> > +
> > enum mmc_issued mmc_blk_mq_issue_rq(struct mmc_queue *mq, struct
> request *req)
> > {
> > struct mmc_blk_data *md = mq->blkdata;
> > @@ -2225,6 +2230,10 @@ enum mmc_issued mmc_blk_mq_issue_rq(struct
> mmc_queue *mq, struct request *req)
> > case MMC_ISSUE_ASYNC:
> > switch (req_op(req)) {
> > case REQ_OP_FLUSH:
> > + if (mmc_blk_cache_disabled(mq->card)) {
>
> I suggest that you add a new bus ops callback ->cache_enabled() and
> implement it for the mmc bus type.
>
> From the mmc block layer point of view, it would then mean that if the
> callback isn't implemented, the cache ctrl isn't supported (which
> would be the case for SD then)
Done.
>
> > + blk_mq_end_request(req, BLK_STS_OK);
> > + return MMC_REQ_FINISHED;
> > + }
> > ret = mmc_blk_cqe_issue_flush(mq, req);
>
> > break;
> > case REQ_OP_READ:
> > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> > index 9ad4aa537867..e3da62ffcb5e 100644
> > --- a/drivers/mmc/core/mmc.c
> > +++ b/drivers/mmc/core/mmc.c
> > @@ -2037,7 +2037,7 @@ static int _mmc_flush_cache(struct mmc_card
> *card)
> > {
> > int err = 0;
> >
> > - if (card->ext_csd.cache_size > 0 && card->ext_csd.cache_ctrl & 1) {
> > + if (mmc_flush_allowed(card)) {
> > err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> > EXT_CSD_FLUSH_CACHE, 1,
> > CACHE_FLUSH_TIMEOUT_MS);
> > diff --git a/drivers/mmc/core/mmc_ops.h b/drivers/mmc/core/mmc_ops.h
> > index 5782fdf4e8e9..2682bf66708a 100644
> > --- a/drivers/mmc/core/mmc_ops.h
> > +++ b/drivers/mmc/core/mmc_ops.h
> > @@ -19,6 +19,11 @@ enum mmc_busy_cmd {
> > struct mmc_host;
> > struct mmc_card;
> >
> > +static inline bool mmc_flush_allowed(struct mmc_card *card)
> > +{
> > + return card->ext_csd.cache_size > 0 && card->ext_csd.cache_ctrl & 1;
> > +}
> > +
> > int mmc_select_card(struct mmc_card *card);
> > int mmc_deselect_cards(struct mmc_host *host);
> > int mmc_set_dsr(struct mmc_host *host);
> > --
> > 2.25.1
> >
>
> Having said the above, we clearly want to tag $subject patch for
> stable kernels as well, which means we need a simple patch as
> possible.
>
> Clearly $subject patch should have come first, prior to my patch where
> I added the ->flush_cache() bus ops callback, as it messes things up.
>
> Therefore, I decided to rebase my next branch to drop the patch adding
> the ->flush_cache() bus ops (I will re-post the patch after we have
> got your changes in).
>
> Can you please re-base $subject patch and address my comments? My
> apologies for the mess!
Done.
Thanks,
Avri
>
> Kind regards
> Uffe
next prev parent reply other threads:[~2021-04-24 18:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-20 13:46 [PATCH v4 0/2] Do not flush cache when it is disabled Avri Altman
2021-04-20 13:46 ` [PATCH v4 1/2] mmc: block: Issue flush only if allowed Avri Altman
2021-04-20 14:02 ` Adrian Hunter
2021-04-23 8:14 ` Ulf Hansson
2021-04-24 18:28 ` Avri Altman [this message]
2021-04-20 13:46 ` [PATCH v4 2/2] mmc: block: Update ext_csd.cache_ctrl if it was written Avri Altman
2021-04-23 8:14 ` Ulf Hansson
2021-04-22 9:41 ` [PATCH v4 0/2] Do not flush cache when it is disabled Avri Altman
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=DM6PR04MB657537C632B237572E6A4F7CFC449@DM6PR04MB6575.namprd04.prod.outlook.com \
--to=avri.altman@wdc.com \
--cc=adrian.hunter@intel.com \
--cc=bpeter@lytx.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@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;
as well as URLs for NNTP newsgroup(s).