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

[Val Packett <val@packett.cool>]

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

Thanks,
~val