From: Richard Weinberger <richard@nod.at>
To: Christian Loehle <CLoehle@hyperstone.com>
Cc: Biju Das <biju.das.jz@bp.renesas.com>,
linux-mmc <linux-mmc@vger.kernel.org>,
linux-renesas-soc <linux-renesas-soc@vger.kernel.org>,
wsa+renesas <wsa+renesas@sang-engineering.com>,
ulf hansson <ulf.hansson@linaro.org>
Subject: Re: Poor write performance to boot area using rcar-gen3-sdhi
Date: Tue, 18 Apr 2023 10:11:24 +0200 (CEST) [thread overview]
Message-ID: <522326845.127346.1681805484949.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <02ceda502af34bf0af53d52598a0b71f@hyperstone.com>
----- Ursprüngliche Mail -----
> Von: "Christian Loehle" <CLoehle@hyperstone.com>
> Your eMMC likely treats the boot partitions differently than the user area, e.g.
> in regards to cache.
> Is this reproducible for more 4k writes? What about larger writes?
Yes. So far every write size I tried is slow.
Sometimes (1 out of 50) small writes are fast, that's most likely a caching effect
of eMMC internals.
> The eMMC might not even have the mapping available after boot and first has to
> internally switch to it, in contrast to at u-boot stage?
Wouldn't that explain only the first slow write?
I see poor write speed also on repeated runs.
> Anyway this is probably more a question to your eMMC manufacturer and nothing
> the host is to be blamed, as you mentioned yourself, the time is spent at
> CMD25.
The eMMC manufacturer says there is nothing special about the boot area
and write speed should be equally fast.
Can it be that rcar-gen3-sdhi changes some timings after switching?
Either in software or on hardware.
Thanks,
//richard
next prev parent reply other threads:[~2023-04-18 8:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-17 20:08 Poor write performance to boot area using rcar-gen3-sdhi Richard Weinberger
2023-04-18 6:09 ` Biju Das
2023-04-18 6:16 ` Richard Weinberger
2023-04-18 7:48 ` Christian Loehle
2023-04-18 8:11 ` Richard Weinberger [this message]
2023-04-18 8:36 ` Christian Loehle
2023-04-18 11:58 ` Richard Weinberger
2023-04-20 15:18 ` Richard Weinberger
2023-04-21 16:23 ` Christian Loehle
2023-05-09 11:28 ` Richard Weinberger
2023-05-11 9:46 ` Christian Loehle
2023-05-11 10:35 ` Richard Weinberger
2023-04-18 8:12 ` Biju Das
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=522326845.127346.1681805484949.JavaMail.zimbra@nod.at \
--to=richard@nod.at \
--cc=CLoehle@hyperstone.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=wsa+renesas@sang-engineering.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.