Hello Jaehoon,
On 2024-04-17 01:33, Jaehoon Chung wrote:
-----Original Message-----
From: Quentin Schulz <quentin.sch...@theobroma-systems.com>
Sent: Wednesday, April 10, 2024 5:57 PM
To: Dragan Simic <dsi...@manjaro.org>
Cc: Jonas Karlman <jo...@kwiboo.se>; Peng Fan <peng....@nxp.com>;
Jaehoon Chung
<jh80.ch...@samsung.com>; Tom Rini <tr...@konsulko.com>;
u-boot@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 :)
