UFS host controller, when scaling gears, should choose appropriate
performance state of RPMh power domain controller along with clock
frequency. So let's add the OPP table support to specify both clock
frequency and RPMh performance states replacing the old "freq-table-hz"
property.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/sm6350.dtsi | 42 +++++++++++++++++++++++++++---------
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index e6df0b7dae8baf39bfa7ff3856759e8cd200f0c8..77ca8990c7a096f40aab5666da9f69465f59b71e 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -1172,18 +1172,40 @@ ufs_mem_hc: ufshc@1d84000 {
<&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
<&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>,
<&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
- freq-table-hz =
- <50000000 200000000>,
- <0 0>,
- <0 0>,
- <37500000 150000000>,
- <0 0>,
- <0 0>,
- <0 0>,
- <0 0>,
- <75000000 300000000>;
+
+ operating-points-v2 = <&ufs_opp_table>;
status = "disabled";
+
+ ufs_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-50000000 {
+ opp-hz = /bits/ 64 <50000000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <37500000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <75000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <150000000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
};
ufs_mem_phy: phy@1d87000 {
--
2.48.1On Fri, Mar 14, 2025 at 10:17:03AM +0100, Luca Weiss wrote: > UFS host controller, when scaling gears, should choose appropriate > performance state of RPMh power domain controller along with clock > frequency. So let's add the OPP table support to specify both clock > frequency and RPMh performance states replacing the old "freq-table-hz" > property. > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > --- > arch/arm64/boot/dts/qcom/sm6350.dtsi | 42 +++++++++++++++++++++++++++--------- > 1 file changed, 32 insertions(+), 10 deletions(-) > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> -- With best wishes Dmitry
On 3/14/25 10:17 AM, Luca Weiss wrote:
> UFS host controller, when scaling gears, should choose appropriate
> performance state of RPMh power domain controller along with clock
> frequency. So let's add the OPP table support to specify both clock
> frequency and RPMh performance states replacing the old "freq-table-hz"
> property.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
[...]
> +
> + ufs_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-50000000 {
> + opp-hz = /bits/ 64 <50000000>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <37500000>,
This rate on this clk requires opp_svs (not low_svs)
with that:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
Hi Konrad,
On Fri Mar 14, 2025 at 11:08 PM CET, Konrad Dybcio wrote:
> On 3/14/25 10:17 AM, Luca Weiss wrote:
>> UFS host controller, when scaling gears, should choose appropriate
>> performance state of RPMh power domain controller along with clock
>> frequency. So let's add the OPP table support to specify both clock
>> frequency and RPMh performance states replacing the old "freq-table-hz"
>> property.
>>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>
> [...]
>
>> +
>> + ufs_opp_table: opp-table {
>> + compatible = "operating-points-v2";
>> +
>> + opp-50000000 {
>> + opp-hz = /bits/ 64 <50000000>,
>> + /bits/ 64 <0>,
>> + /bits/ 64 <0>,
>> + /bits/ 64 <37500000>,
>
> This rate on this clk requires opp_svs (not low_svs)
Not sure where you're seeing this?
This is from my msm-4.19 tree:
gcc_ufs_phy_axi_clk_src:
.rate_max = (unsigned long[VDD_NUM]) { [VDD_LOWER] = 50000000,
gcc_ufs_phy_unipro_core_clk_src:
.rate_max = (unsigned long[VDD_NUM]) { [VDD_LOWER] = 37500000,
gcc_ufs_phy_ice_core_clk_src:
.rate_max = (unsigned long[VDD_NUM]) { [VDD_LOWER] = 75000000,
[VDD_LOWER] = RPMH_REGULATOR_LEVEL_LOW_SVS,
My intepretation for this is we need low_svs?
Regards
Luca
>
> with that:
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Konrad
On 3/17/25 1:12 PM, Luca Weiss wrote:
> Hi Konrad,
>
> On Fri Mar 14, 2025 at 11:08 PM CET, Konrad Dybcio wrote:
>> On 3/14/25 10:17 AM, Luca Weiss wrote:
>>> UFS host controller, when scaling gears, should choose appropriate
>>> performance state of RPMh power domain controller along with clock
>>> frequency. So let's add the OPP table support to specify both clock
>>> frequency and RPMh performance states replacing the old "freq-table-hz"
>>> property.
>>>
>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>> ---
>>
>> [...]
>>
>>> +
>>> + ufs_opp_table: opp-table {
>>> + compatible = "operating-points-v2";
>>> +
>>> + opp-50000000 {
>>> + opp-hz = /bits/ 64 <50000000>,
>>> + /bits/ 64 <0>,
>>> + /bits/ 64 <0>,
>>> + /bits/ 64 <37500000>,
>>
>> This rate on this clk requires opp_svs (not low_svs)
>
> Not sure where you're seeing this?
>
> This is from my msm-4.19 tree:
>
> gcc_ufs_phy_axi_clk_src:
> .rate_max = (unsigned long[VDD_NUM]) { [VDD_LOWER] = 50000000,
> gcc_ufs_phy_unipro_core_clk_src:
> .rate_max = (unsigned long[VDD_NUM]) { [VDD_LOWER] = 37500000,
> gcc_ufs_phy_ice_core_clk_src:
> .rate_max = (unsigned long[VDD_NUM]) { [VDD_LOWER] = 75000000,
>
> [VDD_LOWER] = RPMH_REGULATOR_LEVEL_LOW_SVS,
>
> My intepretation for this is we need low_svs?
Hm, I took another look and it seems you're right, I must have misread
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
© 2016 - 2025 Red Hat, Inc.