[PATCH V1 0/2] scsi: ufs: ufs-qcom: Add specified gear support for multi gear scaling

[PATCH V1 0/2] scsi: ufs: ufs-qcom: Add specified gear support for multi gear scaling

[Nitin Rawat]

This patch series adds support for configuring UFS gear speeds on a
per-OPP frequency basis for Qualcomm UFS host controllers, enabling
more flexible multi-gear scaling.

On certain Qualcomm platforms, the UFS clock frequency and gear speed
do not have a strict one-to-one mapping. To handle this, the first patch
introduces a device tree based configuration mechanism using the
"opp-level" property within the OPP table. This allows each supported
operating frequency to be explicitly associated with a specific HS gear
speed. When this property is absent, the driver gracefully falls back to
the existing default frequency-to-gear lookup table.

The second patch applies this configuration to the Hamoa platform,
assigning the appropriate HS gear levels (G1, G3, G5) to the
corresponding OPP frequency entries in the device tree.

Nitin Rawat (1):
  arm64: dts: qcom: Set specified gear configuration for Hamoa

Ziqi Chen (1):
  scsi: ufs: ufs-qcom: Add specified gear support for multi gear scaling

 arch/arm64/boot/dts/qcom/hamoa.dtsi |  3 +++
 drivers/ufs/host/ufs-qcom.c         | 30 +++++++++++++++++++++++++----
 2 files changed, 29 insertions(+), 4 deletions(-)

--
2.34.1

[PATCH V1 1/2] scsi: ufs: ufs-qcom: Add specified gear support for multi gear scaling

[Nitin Rawat]

From: Ziqi Chen <ziqi.chen@oss.qualcomm.com>

The UFS clock frequency and gear speed do not necessarily have a strict
one-to-one correspondence on all platforms. Introduce a device tree
based configuration interface that allows specifying the HS gear
speed for each supported operating frequency via the "opp-level"
property in the OPP table. When this property is not configured, the
driver falls back to the default frequency-to-gear mapping table.

Signed-off-by: Ziqi Chen <ziqi.chen@oss.qualcomm.com>
Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
---
 drivers/ufs/host/ufs-qcom.c | 30 ++++++++++++++++++++++++++----
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 0f2e083b04fd..aa2ac2cd2b69 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -2460,8 +2460,9 @@ static unsigned long ufs_qcom_opp_freq_to_clk_freq(struct ufs_hba *hba,
 	bool found = false;

 	opp = dev_pm_opp_find_freq_exact_indexed(hba->dev, freq, 0, true);
-	if (IS_ERR(opp)) {
-		dev_err(hba->dev, "Failed to find OPP for exact frequency %lu\n", freq);
+	if (IS_ERR_OR_NULL(opp)) {
+		dev_err(hba->dev, "%s: Failed to find OPP for exact frequency %lu\n",
+			__func__, freq);
 		return 0;
 	}

@@ -2489,12 +2490,32 @@ static unsigned long ufs_qcom_opp_freq_to_clk_freq(struct ufs_hba *hba,

 static u32 ufs_qcom_freq_to_gear_speed(struct ufs_hba *hba, unsigned long freq)
 {
-	u32 gear = UFS_HS_DONT_CHANGE;
+	struct dev_pm_opp *opp;
 	unsigned long unipro_freq;
+	u32 gear = UFS_HS_DONT_CHANGE;

 	if (!hba->use_pm_opp)
 		return gear;

+	opp = dev_pm_opp_find_freq_exact_indexed(hba->dev, freq, 0, true);
+	if (IS_ERR_OR_NULL(opp)) {
+		dev_err(hba->dev, "%s: Failed to find OPP for exact frequency %lu\n",
+			__func__, freq);
+		return gear;
+	}
+
+	/* Get HS gear speed from 'opp-level' */
+	gear = dev_pm_opp_get_level(opp);
+	dev_pm_opp_put(opp);
+
+	/*
+	 * Greater than max gear means that there is no specified gear configured in DT
+	 * or the specified gear is invalid.
+	 */
+	if (gear <= hba->max_pwr_info.info.gear_rx)
+		return gear;
+
+	gear = UFS_HS_DONT_CHANGE;
 	unipro_freq = ufs_qcom_opp_freq_to_clk_freq(hba, freq, "core_clk_unipro");
 	switch (unipro_freq) {
 	case 403000000:
@@ -2515,7 +2536,8 @@ static u32 ufs_qcom_freq_to_gear_speed(struct ufs_hba *hba, unsigned long freq)
 		gear = UFS_HS_G1;
 		break;
 	default:
-		dev_err(hba->dev, "%s: Unsupported clock freq : %lu\n", __func__, freq);
+		dev_err(hba->dev, "%s: Unsupported clock freq [sys_clk: %lu, unipro_clk: %lu]\n",
+			__func__, freq, unipro_freq);
 		return UFS_HS_DONT_CHANGE;
 	}

--
2.34.1

Re: [PATCH V1 1/2] scsi: ufs: ufs-qcom: Add specified gear support for multi gear scaling

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Valid `opp-level` DT gear configurations are improperly ignored and downgraded if they exceed the attached device's maximum supported gear, breaking forward compatibility.
--

commit d0c65635e24a4008e442b75486fc367af65e28be
Author: Ziqi Chen <ziqi.chen@oss.qualcomm.com>

scsi: ufs: ufs-qcom: Add specified gear support for multi gear scaling

This commit introduces a device tree based configuration interface that allows
specifying the HS gear speed for supported operating frequencies using the
"opp-level" property. If this property is not configured, the driver falls
back to a default frequency-to-gear mapping table.

> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> index 291c434487648..399269c3f0597 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c

[ ... ]

> @@ -2490,12 +2491,32 @@ static unsigned long ufs_qcom_opp_freq_to_clk_freq(struct ufs_hba *hba,
>  
>  static u32 ufs_qcom_freq_to_gear_speed(struct ufs_hba *hba, unsigned long freq)
>  {
> -	u32 gear = UFS_HS_DONT_CHANGE;
> +	struct dev_pm_opp *opp;
>  	unsigned long unipro_freq;
> +	u32 gear = UFS_HS_DONT_CHANGE;
>  
>  	if (!hba->use_pm_opp)
>  		return gear;
>  
> +	opp = dev_pm_opp_find_freq_exact_indexed(hba->dev, freq, 0, true);
> +	if (IS_ERR_OR_NULL(opp)) {
> +		dev_err(hba->dev, "%s: Failed to find OPP for exact frequency %lu\n",
> +			__func__, freq);
> +		return gear;
> +	}
> +
> +	/* Get HS gear speed from 'opp-level' */
> +	gear = dev_pm_opp_get_level(opp);
> +	dev_pm_opp_put(opp);
> +
> +	/*
> +	 * Greater than max gear means that there is no specified gear configured in DT
> +	 * or the specified gear is invalid.
> +	 */
> +	if (gear <= hba->max_pwr_info.info.gear_rx)
> +		return gear;
> +

[Severity: High]
Does this condition inadvertently downgrade valid DT gear configurations if
they exceed the attached device's maximum supported gear?

If a platform specifies a valid opp-level (e.g., 5) but the connected UFS
device supports a lower maximum gear (e.g., gear_rx = 4), this check
evaluates to false. The driver will then incorrectly fall back to the
legacy hardcoded mapping table instead of using the capped value.

If the frequency is not present in the fallback table, it returns
UFS_HS_DONT_CHANGE, which can cause a mismatch between the configured clock
and active gear speed. This mismatch could potentially lead to UFS link drops
and system panics during frequency scaling.

It appears this logic conflates a missing DT property (where gear might
evaluate to OPP_LEVEL_UNSET or U32_MAX) with a valid property that simply
exceeds the device capability.

Could this be addressed by explicitly checking if the property was provided,
and if so, safely capping it to the device's maximum supported gear using
min_t(u32, gear, hba->max_pwr_info.info.gear_rx)?

> +	gear = UFS_HS_DONT_CHANGE;
>  	unipro_freq = ufs_qcom_opp_freq_to_clk_freq(hba, freq, "core_clk_unipro");

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260829074355.946543-1-nitin.rawat@oss.qualcomm.com?part=1

[PATCH V1 2/2] arm64: dts: qcom: Set specified gear configuration for Hamoa

[Nitin Rawat]

Assign the appropriate UFS HS gear speed levels to each OPP frequency
entry in the device tree, enabling proper per-frequency gear
scaling (G1 at 75MHz, G3 at 150MHz, G5 at 300MHz).

Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/hamoa.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 8a96ea1bdb9c..ef7994c83bb7 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -3918,6 +3918,7 @@ opp-75000000 {
 						 /bits/ 64 <0>,
 						 /bits/ 64 <0>,
 						 /bits/ 64 <0>;
+					opp-level = <1>; /* HS-G1 */
 					required-opps = <&rpmhpd_opp_low_svs>;
 				};

@@ -3930,6 +3931,7 @@ opp-150000000 {
 						 /bits/ 64 <0>,
 						 /bits/ 64 <0>,
 						 /bits/ 64 <0>;
+					opp-level = <3>; /* HS-G3 */
 					required-opps = <&rpmhpd_opp_svs>;
 				};

@@ -3942,6 +3944,7 @@ opp-300000000 {
 						 /bits/ 64 <0>,
 						 /bits/ 64 <0>,
 						 /bits/ 64 <0>;
+					opp-level = <5>; /* HS-G5 */
 					required-opps = <&rpmhpd_opp_nom>;
 				};
 			};
--
2.34.1

Re: [PATCH V1 2/2] arm64: dts: qcom: Set specified gear configuration for Hamoa

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incorrect fallback logic when DT-specified `opp-level` exceeds the negotiated maximum gear.
--

commit 1074dd135232851ffc9d0417dea7de1323a012a4
Author: Nitin Rawat <nitin.rawat@oss.qualcomm.com>

arm64: dts: qcom: Set specified gear configuration for Hamoa

Assign the appropriate UFS HS gear speed levels to each OPP frequency
entry in the device tree, enabling proper per-frequency gear
scaling (G1 at 75MHz, G3 at 150MHz, G5 at 300MHz).

> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index 4ba751a65142b..bc7383937a293 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
[ ... ]
> @@ -3992,6 +3994,7 @@ opp-300000000 {
>  						 /bits/ 64 <0>,
>  						 /bits/ 64 <0>,
>  						 /bits/ 64 <0>;
> +					opp-level = <5>; /* HS-G5 */

[Severity: High]
Will adding this HS-G5 opp-level break devfreq gear scaling if the host is
paired with a slower UFS memory device, such as one with a maximum of G4?

Looking at ufs_qcom_freq_to_gear_speed() in drivers/ufs/host/ufs-qcom.c, the
retrieved opp-level is checked against the negotiated maximum gear:

    gear = dev_pm_opp_get_level(dev, freq);
    /* ... */
    /*
     * Greater than max gear means that there is no specified gear configured
     * in DT or the specified gear is invalid.
     */
    if (gear <= hba->max_pwr_info.info.gear_rx)
        return gear;

    gear = UFS_HS_DONT_CHANGE;

If this DT configures a gear level of 5 (HS-G5), but the attached UFS device
only supports gear 4 (HS-G4), the check `5 <= 4` evaluates to false.

Because dev_pm_opp_get_level() returns OPP_LEVEL_UNSET (U32_MAX) when the
property is missing, the code seems to conflate a missing property with a
gear that simply exceeds the attached device's maximum capability.

When the check fails, instead of capping the gear to the device's maximum,
the code falls through to the legacy hardcoded switch block. If the new
frequency is missing from that legacy block, it hits the default case, logs
an "Unsupported clock freq" error, and fails to scale entirely.

Does ufs_qcom_freq_to_gear_speed() need to explicitly check against
OPP_LEVEL_UNSET and cap the DT gear to the negotiated maximum instead of
falling back to the legacy behavior?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260829074355.946543-1-nitin.rawat@oss.qualcomm.com?part=2