Kernel now handles all level shifter limitations related to SD card
modes.
As a result, the broken hardware capabilities for SDR104 and SDR50 modes
can be removed from the device tree.
Additionally, due to level shifter constraints, set the maximum
frequency for High Speed (HS) mode to 37.5 MHz using the
max-sd-hs-frequency property for sm8550.
Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 82cabf777cd2..2c770c979d39 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -3180,6 +3180,7 @@ sdhc_2: mmc@8804000 {
iommus = <&apps_smmu 0x540 0>;
qcom,dll-config = <0x0007642c>;
qcom,ddr-config = <0x80040868>;
+ max-sd-hs-frequency = <37500000>;
power-domains = <&rpmhpd RPMHPD_CX>;
operating-points-v2 = <&sdhc2_opp_table>;
@@ -3191,9 +3192,6 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
bus-width = <4>;
dma-coherent;
- /* Forbid SDR104/SDR50 - broken hw! */
- sdhci-caps-mask = <0x3 0>;
-
status = "disabled";
sdhc2_opp_table: opp-table {
--
2.34.1
On 6/18/25 9:28 AM, Sarthak Garg wrote: > Kernel now handles all level shifter limitations related to SD card > modes. > As a result, the broken hardware capabilities for SDR104 and SDR50 modes > can be removed from the device tree. > Additionally, due to level shifter constraints, set the maximum > frequency for High Speed (HS) mode to 37.5 MHz using the > max-sd-hs-frequency property for sm8550. It's a little bit hard to read text that is formatted like that, please stick to ~72 chars per line instead Konrad
On 18/06/2025 09:28, Sarthak Garg wrote:
> Kernel now handles all level shifter limitations related to SD card
> modes.
> As a result, the broken hardware capabilities for SDR104 and SDR50 modes
> can be removed from the device tree.
> Additionally, due to level shifter constraints, set the maximum
> frequency for High Speed (HS) mode to 37.5 MHz using the
> max-sd-hs-frequency property for sm8550.
>
> Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
> ---
> arch/arm64/boot/dts/qcom/sm8550.dtsi | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> index 82cabf777cd2..2c770c979d39 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> @@ -3180,6 +3180,7 @@ sdhc_2: mmc@8804000 {
> iommus = <&apps_smmu 0x540 0>;
> qcom,dll-config = <0x0007642c>;
> qcom,ddr-config = <0x80040868>;
> + max-sd-hs-frequency = <37500000>;
So my previous comments stay... This is SoC thus deducible from compatible.
Best regards,
Krzysztof
On 6/18/2025 1:11 PM, Krzysztof Kozlowski wrote:
> On 18/06/2025 09:28, Sarthak Garg wrote:
>> Kernel now handles all level shifter limitations related to SD card
>> modes.
>> As a result, the broken hardware capabilities for SDR104 and SDR50 modes
>> can be removed from the device tree.
>> Additionally, due to level shifter constraints, set the maximum
>> frequency for High Speed (HS) mode to 37.5 MHz using the
>> max-sd-hs-frequency property for sm8550.
>>
>> Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
>> ---
>> arch/arm64/boot/dts/qcom/sm8550.dtsi | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
>> index 82cabf777cd2..2c770c979d39 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
>> @@ -3180,6 +3180,7 @@ sdhc_2: mmc@8804000 {
>> iommus = <&apps_smmu 0x540 0>;
>> qcom,dll-config = <0x0007642c>;
>> qcom,ddr-config = <0x80040868>;
>> + max-sd-hs-frequency = <37500000>;
> So my previous comments stay... This is SoC thus deducible from compatible.
>
> Best regards,
> Krzysztof
" I agree that a DT property for the mmc controller would make sense.
Although, this seems limited to SD UHS-I speed modes, so perhaps
"max-sd-uhs-frequency" would be a better name for it?
Kind regards
Uffe "
https://patchwork.kernel.org/project/linux-mmc/cover/20250523105745.6210-1-quic_sartgarg@quicinc.com/
This was the comment given on V2 to introduce a generic dt
property.
Best regards,
Sarthak
On 18/06/2025 10:44, Sarthak Garg wrote:
>
>
> On 6/18/2025 1:11 PM, Krzysztof Kozlowski wrote:
>> On 18/06/2025 09:28, Sarthak Garg wrote:
>>> Kernel now handles all level shifter limitations related to SD card
>>> modes.
>>> As a result, the broken hardware capabilities for SDR104 and SDR50 modes
>>> can be removed from the device tree.
>>> Additionally, due to level shifter constraints, set the maximum
>>> frequency for High Speed (HS) mode to 37.5 MHz using the
>>> max-sd-hs-frequency property for sm8550.
>>>
>>> Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/sm8550.dtsi | 4 +---
>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
>>> index 82cabf777cd2..2c770c979d39 100644
>>> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
>>> @@ -3180,6 +3180,7 @@ sdhc_2: mmc@8804000 {
>>> iommus = <&apps_smmu 0x540 0>;
>>> qcom,dll-config = <0x0007642c>;
>>> qcom,ddr-config = <0x80040868>;
>>> + max-sd-hs-frequency = <37500000>;
>> So my previous comments stay... This is SoC thus deducible from compatible.
>>
>> Best regards,
>> Krzysztof
>
> " I agree that a DT property for the mmc controller would make sense.
>
> Although, this seems limited to SD UHS-I speed modes, so perhaps
> "max-sd-uhs-frequency" would be a better name for it?
>
> Kind regards
> Uffe "
>
> https://patchwork.kernel.org/project/linux-mmc/cover/20250523105745.6210-1-quic_sartgarg@quicinc.com/
>
> This was the comment given on V2 to introduce a generic dt
> property.
I know, it does not matter. If this is here, it is a 100% proof this is
SoC specific, thus you have compatible for that.
Best regards,
Krzysztof
© 2016 - 2026 Red Hat, Inc.