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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 11/27/25 8:33 PM, 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 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.

Would you happen to have access to a Snapdragon phone from a similar era?

Could you insert it there and see if you have any issues?

Konrad