[PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux

[Dragan Simic]

Hello Jaehoon,

On 2024-04-17 01:33, Jaehoon Chung wrote:
>> -----Original Message-----
>> From: Quentin Schulz <quentin.schulz at theobroma-systems.com>
>> Sent: Wednesday, April 10, 2024 5:57 PM
>> To: Dragan Simic <dsimic at manjaro.org>
>> Cc: Jonas Karlman <jonas at kwiboo.se>; Peng Fan <peng.fan at nxp.com>; 
>> Jaehoon Chung
>> <jh80.chung at samsung.com>; Tom Rini <trini at konsulko.com>; 
>> u-boot at lists.denx.de
>> Subject: Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to 
>> match linux
>> 
>> On 4/9/24 21:28, Dragan Simic wrote:
>> 
>> [...]
>> 
>> > Let's keep in mind that the troublesome DT properties describe the
>> > capabilities of the MMC controller and the board, not the capabilities
>> > of the MMC storage device.  As we know, eMMC devices provide automatic
>> > detection capabilities, to allow the host to determine its supported
>> > modes, and match them with the ones the host is configured to support.
>> > It's all described in the JEDEC standards.
> 
> I didn't see the above mail in my mailbox. So I can miss something.

It seems that, for some reason, the mail server(s) for @samsung.com
don't like the IP address of the @manjaro.org mail server, so my email
messages to you get rejected.

>> So why do we have those properties specified in board DTSes instead of
>> in the SoC DTSI? Logic would want us to have this defined in one place
>> only. I assume the issue is that even if the eMMC chip itself says it
>> supports HS400 but the HW routing or some other issue make it 
>> impossible
>> to use, we need a way to disable it from the DT for that board?
>> 
>> > Having that in mind, I find the approach in the Linux kernel rather
>> > reasonable, because I highly doubt that some MMC controllers support,
>> > for example, HS400 without supporting DDR52, or HS400 without supporting
>> > DDR52.  A reasonable approach for an MMC IP block is to make it capable
>> > of supporting all the speeds below its highest supported speed, to make
>> > itself capable of supporting more, if not all, MMC storage devices.
>> >
>> 
>> That's true for the IP block which is self-contained in the SoC, but
>> it's forgetting about the other part, the eMMC chip/card. It depends 
>> on
>> the HW routing, where mistakes/limitations can happen. And I don't 
>> think
>> we have a mechanism today to disable the modes set in the MMC 
>> controller
>> for a given MMC card from DT (aside from /delete-property/ in board 
>> files).
> 
> The both opinions make sense.
> But, It doesn't set to all capabilities when nodes has mmc-hs400-* 
> property.
> 
> That's why it's describing to each property is because they want to
> clarify only which mode they use.
> 
> AFAIK, I can't remember exactly, there were some boards that even
> though HS400 is working fine,
> but HS200 was not working fine. (It's depends on which IP board is 
> using.)

That's really good to know, thanks.

> There were too many cases not to work fine because of *HW* design.
> eMMC and Host IP were supporting the HS400/200 and all modes, but
> there was a problem of handling clock.
> So it couldn't use HS200/400 and other dual modes.

Yes, there are all kinds of eMMC signal integrity issues on different
designs.  There are also similar issues with different microSD cards,
causing some of them not to work in SDR104 mode on a particular board,
for example.

> And We needs to know if it's working fine.
> If we want to use hs400 mode, but board can be working to other mode
> without any error.
> Of course, we can see a mode as log. But it's at least approach to 
> limit.
> 
>> > In fact, I'll probably go ahead and submit a Linux kernel patch that
>> > updates the descriptions in the binding, to hopefully eliminate any
>> > ambiguities like these.  I hope you agree.
>> 
>> I for sure do not have enough knowledge in MMC to argue more than I 
>> just
>> did, so having people with more experience/knowledge have a look at 
>> this
>> would make sense, let's see what they have to say :)