From: Michael Wu <michael@allwinnertech.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "Adrian Hunter" <adrian.hunter@intel.com>,
"Christian Löhle" <CLoehle@hyperstone.com>,
"Avri Altman" <avri.altman@wdc.com>,
"beanhuo@micron.com" <beanhuo@micron.com>,
"porzio@gmail.com" <porzio@gmail.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
allwinner-opensource-support
<allwinner-opensource-support@allwinnertech.com>
Subject: Re: [PATCH] mmc: block: enable cache-flushing when mmc cache is on
Date: Fri, 25 Mar 2022 13:45:52 +0800 [thread overview]
Message-ID: <a39e9f71-7a9c-bf0e-50d0-d45de3c2e132@allwinnertech.com> (raw)
In-Reply-To: <CAPDyKFqnFVd=mvQMnydT569Y6YFg3zPkttQ=amdzmT_yqYQeTg@mail.gmail.com>
On 24/03/2022 19:27, Ulf Hansson wrote:
> On Thu, 17 Mar 2022 at 10:14, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>
>> On Wed, 16 Mar 2022 at 17:08, Adrian Hunter <adrian.hunter@intel.com> wrote:
>>>
>>> On 16.3.2022 16.46, Christian Löhle wrote:
>>>>> So we are not going to let the block layer know about SD cache?
>>>>> Or is it a separate change?
>>>>
>>>> I have some code for this laying around, but as it requires reading, parsing and writing Function Registers,
>>>> in particular PEH, it's a lot of boilerplate code to get the functionality, but I'll clean it up and send a patch in the coming weeks.
>>>>
>>>
>>> We have the sd cache flush. We would presumably just need to call blk_queue_write_cache()
>>> for the !mmc_card_mmc(card) case e.g.
>>>
>>> if (mmc_has_reliable_write(card)) {
>>> md->flags |= MMC_BLK_REL_WR;
>>> enable_fua = true;
>>> }
>>>
>>> if (mmc_cache_enabled(card->host))
>>> enable_cache = true;
>>>
>>> blk_queue_write_cache(md->queue.queue, enable_cache, enable_fua);
>>
>> To me, this seems like the most reasonable thing to do.
>>
>> However, I have to admit that it's not clear to me, if there was a
>> good reason to why commit f4c5522b0a88 ("mmc: Reliable write
>> support.") also added support for REQ_FLUSH (write back cache) and why
>> not only REQ_FUA. I assumed this was wrong too, right?
>>
Hi Ulf,
1. I've found the reason. If we only enable REQ_FUA, there won't be any
effect -- The block layer won't send any request with FUA flag to the
driver.
If we want REQ_FUA to take effect, we must enable REQ_FLUSH. But on the
contrary, REQ_FLUSH does not rely on REQ_FUA.
In the previous patch(commit f4c5522b0a88 ("mmc: Reliable write
support.")), REQ_FLUSH was added to make REQ_FUA effective. I've done
experiments to prove this.
2. Why block layer requires REQ_FLUSH to make REQ_FUA effective? I did
not find the reason. Does anyone know about this? Thank you.
>> When it comes to patches for stable kernels. mmc_cache_enabled() was
>> introduced quite recently in v5.13, so for older kernels that call
>> needs to be replaced with something else.
>>
>> In any case, the relevant commits that can be considered as needs to
>> be fixed seems like these:
>> commit f4c5522b0a88 ("mmc: Reliable write support.")
>> commit 881d1c25f765 ("mmc: core: Add cache control for eMMC4.5 device")
>> commit 130206a615a9 ("mmc: core: Add support for cache ctrl for SD cards")
>>
>> [...]
>
> Michael, are you planning to send a v2 for this? Or are there any
> parts that are still unclear to you?
Dear Ulf, Sorry for the delay. I was trying to figure out the SD cache
stuff, so a few day was taken...
>
> Kind regards
> Uffe
--
Best Regards,
Michael Wu
next prev parent reply other threads:[~2022-03-25 5:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-12 4:43 [PATCH] mmc: block: enable cache-flushing when mmc cache is on Michael Wu
2022-03-14 6:54 ` Adrian Hunter
2022-03-14 9:20 ` Michael Wu
2022-03-14 9:37 ` Avri Altman
2022-03-16 9:54 ` Michael Wu
2022-03-16 11:09 ` Avri Altman
2022-03-16 11:28 ` Adrian Hunter
2022-03-16 14:46 ` Christian Löhle
2022-03-16 16:05 ` Adrian Hunter
2022-03-17 9:14 ` Ulf Hansson
2022-03-24 11:27 ` Ulf Hansson
2022-03-25 5:45 ` Michael Wu [this message]
2022-03-25 10:13 ` Ulf Hansson
2022-03-28 10:11 ` Michael Wu
2022-03-28 11:38 ` Ulf Hansson
2022-03-29 9:08 ` Michael Wu
2022-03-29 9:53 ` Ulf Hansson
2022-03-27 8:09 ` Avri Altman
2022-03-14 11:10 ` Avri Altman
2022-03-14 7:26 ` Avri Altman
2022-03-14 10:32 ` Adrian Hunter
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=a39e9f71-7a9c-bf0e-50d0-d45de3c2e132@allwinnertech.com \
--to=michael@allwinnertech.com \
--cc=CLoehle@hyperstone.com \
--cc=adrian.hunter@intel.com \
--cc=allwinner-opensource-support@allwinnertech.com \
--cc=avri.altman@wdc.com \
--cc=beanhuo@micron.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=porzio@gmail.com \
--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).