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