linux-kernel - Re: [PATCH v2] arm64: dts: ti: k3-am65: Add support for UHS-I modes in MMCSD1 subsystem

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <95539fea-8190-7a3d-05aa-90824eb03293@siemens.com>
Date:   Tue, 11 May 2021 17:26:52 +0200
From:   Jan Kiszka <jan.kiszka@...mens.com>
To:     Aswath Govindraju <a-govindraju@...com>
Cc:     Vignesh Raghavendra <vigneshr@...com>,
        Lokesh Vutla <lokeshvutla@...com>,
        Kishon Vijay Abraham I <kishon@...com>,
        Nishanth Menon <nm@...com>, Tero Kristo <kristo@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] arm64: dts: ti: k3-am65: Add support for UHS-I modes
 in MMCSD1 subsystem

On 11.05.21 12:13, Aswath Govindraju wrote:
> Hi Jan,
> 
> On 11/05/21 3:31 pm, Jan Kiszka wrote:
>> On 11.05.21 11:53, Aswath Govindraju wrote:
>>> UHS-I speed modes are supported in AM65 S.R. 2.0 SoC[1].
>>>
>>> Add support by removing the no-1-8-v tag and including the voltage
>>> regulator device tree nodes for power cycling.
>>>
>>> However, the 4 bit interface of AM65 SR 1.0 cannot be supported at 3.3 V or
>>> 1.8 V because of erratas i2025 and i2026 [2]. As the SD card is the primary
>>> boot mode for development usecases, continue to enable SD card and disable
>>> UHS-I modes in it to minimize any ageing issues happening because of
>>> erratas.
>>>
>>> k3-am6528-iot2050-basic and k3-am6548-iot2050-advanced boards use S.R. 1.0
>>> version of AM65 SoC. Therefore, add no-1-8-v in sdhci1 device tree nodes
>>> for these boards.
>>>
>>> [1] - https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf
>>> [2] - https://www.ti.com/lit/er/sprz452e/sprz452e.pdf
>>>
>>> Signed-off-by: Aswath Govindraju <a-govindraju@...com>
>>> ---
>>>  arch/arm64/boot/dts/ti/k3-am65-main.dtsi      |  1 -
>>>  .../boot/dts/ti/k3-am6528-iot2050-basic.dts   |  4 +++
>>>  .../arm64/boot/dts/ti/k3-am654-base-board.dts | 33 +++++++++++++++++++
>>>  .../dts/ti/k3-am6548-iot2050-advanced.dts     |  4 +++
>>>  4 files changed, 41 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>> index cb340d1b401f..632f32fce4a1 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>> @@ -301,7 +301,6 @@
>>>  		ti,otap-del-sel = <0x2>;
>>>  		ti,trm-icp = <0x8>;
>>>  		dma-coherent;
>>> -		no-1-8-v;
>>>  	};
>>>  
>>>  	scm_conf: scm-conf@...000 {
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
>>> index 4f7e3f2a6265..485266960d5f 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
>>> +++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
>>> @@ -40,6 +40,10 @@
>>>  	status = "disabled";
>>>  };
>>>  
>>> +&sdhci1 {
>>> +	no-1-8-v;
>>> +};
>>> +
>>
>> Let's move that to k3-am65-iot2050-common.dtsi, to avoid repeating
>> yourself. There is already a sdhci1 extension.
>>
> 
> The reason why I added these tags in board dts and not in the common
> dtsi is because if it was added in the common board then for all the iot
> boards this will be applicable and in future if a different version of
> iot boards use S.R. 2.0 then we might have to change it again.

Yes, we will have to take care of the split-up for SR2.0-based variants.
I didn't have the chance study their DTs yet but I strongly suspect that
there will be more differences. Then we may add some
k3-am65-iot2050-common-{SR1,SR2}.dtsi.

So, I would not try to refactor when not all variables are on the table yet.

Thanks
Jan


-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux