linux-kernel - Re: [PATCH] arm64: dts: rockchip: fix rk3399-puma eMMC HS400 signal integrity

Open Source and information security mailing list archives

Date:   Thu, 20 Jan 2022 10:06:43 -0500
From:   Peter Geis <pgwipeout@...il.com>
To:     quentin.schulz@...obroma-systems.com
Cc:     Rob Herring <robh+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
        devicetree <devicetree@...r.kernel.org>,
        arm-mail-list <linux-arm-kernel@...ts.infradead.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jakob Unterwurzacher <jakob.unterwurzacher@...obroma-systems.com>,
        Quentin Schulz <foss+kernel@...il.net>
Subject: Re: [PATCH] arm64: dts: rockchip: fix rk3399-puma eMMC HS400 signal integrity

On Wed, Jan 19, 2022 at 8:52 AM <quentin.schulz@...obroma-systems.com> wrote:
>
> From: Jakob Unterwurzacher <jakob.unterwurzacher@...obroma-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@...il.net>
> Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@...obroma-systems.com>
> Signed-off-by: Quentin Schulz <quentin.schulz@...obroma-systems.com>
> ---
>
> Note/RFC: as opposed to gru DTSI, max-frequency is used here instead of
> 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 controller
> inside the SoC. max-frequency does not interact with the clock subsystem
> 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 potentially
> 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/arm64/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 proven stable
> +        * enough.
> +        */
> +       max-frequency = <100000000>;
> +
>         bus-width = <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?
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@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives