Re: [PATCH 0/3] arm64: dts: qcom: sm8x50: Enable UHS-I SDR50 and SDR104 SD card modes

[Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>]

On 11/27/25 21:33, Val Packett wrote:
> On 11/27/25 10:47 AM, Konrad Dybcio wrote:
>> On 11/26/25 5:14 PM, Val Packett wrote:
>>> Hi,
>>>
>>> On 11/25/25 10:20 PM, Vladimir Zapolskiy wrote:
>>>> The reported problem of some non-working UHS-I speed modes on SM8450
>>>> originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree
>>>> for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered
>>>> platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable
>>>> SDHCI SDR104/SDR50 on all boards").
>>>>
>>>> The tests show that the rootcause of the problem was related to an
>>>> overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a
>>>> ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs").
>>>>
>>>> Due to a missed setting of an appropriate SDCC clock operations in
>>>> platform GCC driver the workaround of dropping SD card speeds from UHS-I
>>>> to high speed was spread to SM8550 and SM8650 platforms, and since
>>>> the fixes in the clock controller drivers are ready [1], it should be
>>>> safe to remove the speed mode restrictions from SM8450, SM8550 and
>>>> SM8650 platforms.
>>>> [..]
>>> I see you have tested with dd on the raw block device, but have you tested hotplugging SD cards that have partition tables and filesystems on them?
>>>
>>> We have this kind of issue on Hamoa where we get I/O errors early, right after the card is inserted and the partition table / filesystem headers are being read:
>>>
>>> [  714.057106] mmc0: new UHS-I speed SDR104 SDXC card at address 0001
>>> [  714.060567] mmcblk0: mmc0:0001 EC2QT 59.6 GiB
>>> [  714.503873] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
>>> [  714.505660] Buffer I/O error on dev mmcblk0, logical block 0, async page read
>>> [  714.513632] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
>>> [  714.516469] Buffer I/O error on dev mmcblk0, logical block 0, async page read
>>> [  714.516512]  mmcblk0: unable to read partition table
>> Before we start debugging, could you please confirm it's using the internal
>> (&sdhc_2) MMC controller, and not one connected over PCIe, like it's the
>> case on the Surface Laptop?
> Of course it is. I'm quite familiar with the DTS on this device, I
> pushed it over the finish line into upstream myself :)
>> Are the regulators supplying vmmc and vqmmc in high power mode?
> 
> Yes. regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; and no
> allow-set-load / allowed-modes (..hm, maybe we can actually add those to
> save power since sdhci-msm *does* do regulator_set_load..)
> 
> But turns out this is not a consistent problem with every card!.. At
> least *now* one of the two Kingston Canvas Select Plus cards I have
> attaches perfectly every time. (Another one of those though often fails
> to probe with "error -84 reading general info of SD ext reg" and
> sometimes has an early I/O error, but exFAT mounts even after that error
> — but this seems like just a "microSD cards are crap" thing.)
> 
> It's the Samsung Evo Plus card that consistently has early I/O errors
> preventing the partition table scan from succeeding (or if that

For the last 10 years it's known that a multitude of Samsung Evo SD cards
are fake.

> succeeds, prevents the exFAT mount). There is a *card compat* issue here
> for sure, as the card is not corrupted, it mounts every time on a
> different laptop with a PCIe card reader [1217:8621] in the same SDR104
> mode. But consistently has these errors on sdhci-msm.
> 

Please check the actual I/O speed of this card on a host, the given dd
command should be sufficient for that purpose. It might happen that if
the actually supported max speed is not close to SDR104, however the mode
is set by the Qualcomm SDHC driver due to info read from the card out,
the I/O may be faulty.

-- 
Best wishes,
Vladimir