linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).