Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20220119134948.1444965-1-quentin.schulz@theobroma-systems.com>
 <CAMdYzYr+UXU-x=OakdHnOzLe1e4Y0xdGR-rybsmpLCMGbsWwXg@mail.gmail.com> <3e87ed0a-8b79-006a-dce6-62becc9906ef@theobroma-systems.com>
In-Reply-To: <3e87ed0a-8b79-006a-dce6-62becc9906ef@theobroma-systems.com>
From:   Peter Geis <pgwipeout@gmail.com>
Date:   Thu, 20 Jan 2022 12:14:56 -0500
Message-ID: <CAMdYzYpT8BUrukUozRSQDHgiQHMPbS5GtV7huL4xFFRsdxw0qQ@mail.gmail.com>
Subject: Re: [PATCH] arm64: dts: rockchip: fix rk3399-puma eMMC HS400 signal integrity
To:     Quentin Schulz <quentin.schulz@theobroma-systems.com>
Cc:     Rob Herring <robh+dt@kernel.org>, Heiko Stuebner <heiko@sntech.de>,
        devicetree <devicetree@vger.kernel.org>,
        arm-mail-list <linux-arm-kernel@lists.infradead.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>,
        Quentin Schulz <foss+kernel@0leil.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Jan 20, 2022 at 11:03 AM Quentin Schulz
<quentin.schulz@theobroma-systems.com> wrote:
>
> Hi Peter,
>
> On 1/20/22 16:06, Peter Geis wrote:
> > On Wed, Jan 19, 2022 at 8:52 AM <quentin.schulz@theobroma-systems.com> =
wrote:
> >>
> >> From: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com=
>
> >>
> >> There are signal integrity issues running the eMMC at 200MHz on Puma
> >> RK3399-Q7.
> >>
> >> Similar to the work-around found for RK3399 Gru boards, lowering the
> >> frequency to 100MHz made the eMMC much more stable, so let's lower the
> >> frequency to 100MHz.
> >>
> >> It might be possible to run at 150MHz as on RK3399 Gru boards but only
> >> 100MHz was extensively tested.
> >>
> >> Cc: Quentin Schulz <foss+kernel@0leil.net>
> >> Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-sy=
stems.com>
> >> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> >> ---
> >>
> >> Note/RFC: as opposed to gru DTSI, max-frequency is used here instead o=
f
> >> assigned-clock-rates.
> >>
> >> AFAIU, max-frequency applies to the SD bus rate, while
> >> assigned-clock-rates applies to the clock fed to the SD host controlle=
r
> >> inside the SoC. max-frequency does not interact with the clock subsyst=
em
> >> AFAICT. assigned-clock-rates sets the clock rate at probe, regardless =
of
> >> eMMC tuning.
> >> Technically, the Arasan SDHC IP supports silicon-hardcoded clock
> >> multiplier so I think setting assigned-clock-rates as a way of rate
> >> limiting the eMMC block is incorrect and max-frequency should be used
> >> instead (as done in this patch). Otherwise the SDHC could still potent=
ially
> >> derive a 200MHz clock from a lower rate clock thanks to its multiplier=
.
> >>
> >>   arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 6 ++++++
> >>   1 file changed, 6 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm6=
4/boot/dts/rockchip/rk3399-puma.dtsi
> >> index fb67db4619ea..a6108578aae0 100644
> >> --- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
> >> +++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
> >> @@ -425,6 +425,12 @@ vcc5v0_host_en: vcc5v0-host-en {
> >>   };
> >>
> >>   &sdhci {
> >> +       /*
> >> +        * Signal integrity isn't great at 200MHz but 100MHz has prove=
n stable
> >> +        * enough.
> >> +        */
> >> +       max-frequency =3D <100000000>;
> >> +
> >>          bus-width =3D <8>;
> >>          mmc-hs400-1_8v;
> >>          mmc-hs400-enhanced-strobe;
> >
> > I don't have these boards nor the schematics handy for them, but
> > wouldn't it be better to simply switch to mmc-hs200-1_8v?
>
> Thanks for the suggestion, I just tested, by removing mmc-hs400-1_8v;
> and mmc-hs400-enhanced-strobe; but keeping the clock rate at 200MHz and
> adding mmc-hs200-1_8v; failed a basic dd test.

Quite understandable.
I more meant it may permit you to reach a higher clock rate than
100mhz and thus possibly a higher data rate, for example perhaps
150mhz would be reachable.
For example I would do a bandwidth test for hs400-es at 100mhz, then
test at hs200 and find the maximum stable clock rate.
If 200mhz is stable enough to probe and /sys/kernel/debug/mmc<x>/ios
shows you are in 8bit hs200, you can adjust the clock rate through
/sys/kernel/debug/mmc<x>/clock without needing to reboot.
It will speed up testing.

If hs200 permits a higher overall data rate than hs400-es, it would be
worth making that switch.

Always,
Peter

>
> Cheers,
> Quentin
>
> > Other rk3399 boards don't have issues with hs200 at full 200mhz, and
> > as I understand it hs400-es exhibits stability issues on most rk3399
> > boards.
> >
> > Feel free to disregard my comments if you've already tested this.
> >
> >> --
> >> 2.34.1
> >>
> >>
> >> _______________________________________________
> >> Linux-rockchip mailing list
> >> Linux-rockchip@lists.infradead.org
> >> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__lists.infradead.=
org_mailman_listinfo_linux-2Drockchip&d=3DDwIBaQ&c=3D_sEr5x9kUWhuk4_nFwjJtA=
&r=3DLYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=3DO=
Tusi9XARCbef1Ba5t1gv4_LqRkOaxFY3UtvYky6NVLpeiziqqmdOJ8-R5WXWFNr&s=3DxBnqhBu=
20rxvu_V-5EhXyA_yNxcJpa4Dq6HO2Ow3Gk8&e=3D