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

Quentin Schulz quentin.schulz at theobroma-systems.com
Thu Jan 20 08:03:44 PST 2022


Hi Peter,

On 1/20/22 16:06, Peter Geis wrote:
> On Wed, Jan 19, 2022 at 8:52 AM <quentin.schulz at theobroma-systems.com> wrote:
>>
>> From: Jakob Unterwurzacher <jakob.unterwurzacher at 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 at 0leil.net>
>> Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher at theobroma-systems.com>
>> Signed-off-by: Quentin Schulz <quentin.schulz at theobroma-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?

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.

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 at lists.infradead.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Drockchip&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=OTusi9XARCbef1Ba5t1gv4_LqRkOaxFY3UtvYky6NVLpeiziqqmdOJ8-R5WXWFNr&s=xBnqhBu20rxvu_V-5EhXyA_yNxcJpa4Dq6HO2Ow3Gk8&e=



More information about the Linux-rockchip mailing list