From nobody Tue Jun 30 10:16:38 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22498C433F5 for ; Wed, 19 Jan 2022 13:50:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354940AbiASNu4 (ORCPT ); Wed, 19 Jan 2022 08:50:56 -0500 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:33451 "EHLO relay9-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235698AbiASNum (ORCPT ); Wed, 19 Jan 2022 08:50:42 -0500 Received: (Authenticated sender: foss@0leil.net) by mail.gandi.net (Postfix) with ESMTPSA id 3930EFF802; Wed, 19 Jan 2022 13:50:35 +0000 (UTC) From: quentin.schulz@theobroma-systems.com To: robh+dt@kernel.org, heiko@sntech.de Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, Jakob Unterwurzacher , Quentin Schulz , Quentin Schulz Subject: [PATCH] arm64: dts: rockchip: fix rk3399-puma eMMC HS400 signal integrity Date: Wed, 19 Jan 2022 14:49:48 +0100 Message-Id: <20220119134948.1444965-1-quentin.schulz@theobroma-systems.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jakob Unterwurzacher 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 Signed-off-by: Jakob Unterwurzacher Signed-off-by: Quentin Schulz --- 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/boo= t/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 { }; =20 &sdhci { + /* + * Signal integrity isn't great at 200MHz but 100MHz has proven stable + * enough. + */ + max-frequency =3D <100000000>; + bus-width =3D <8>; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; --=20 2.34.1