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

[Jaehoon Chung]

Hi,

> -----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
> 
> Hi Dragan,
> 
> 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.

> 
> 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.)

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.

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.

Best Regards,
Jaehoon Chung

> 
> > 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 :)
> 
> Cheers,
> Quentin