[PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Abel Vesa]

According to internal documentation, the corners specific for each rate
from the DP link clock are:
 - LOWSVS_D1 -> 19.2 MHz
 - LOWSVS    -> 270 MHz
 - SVS       -> 540 MHz (594 MHz in case of DP3)
 - SVS_L1    -> 594 MHz
 - NOM       -> 810 MHz
 - NOM_L1    -> 810 MHz
 - TURBO     -> 810 MHz

So fix all tables for each of the four controllers according to the
documentation.

The 19.2 @ LOWSVS_D1 isn't needed as the controller will select 162 MHz
for RBR, which falls under the 270 MHz and it will vote for that LOWSVS
in that case.

Cc: stable@vger.kernel.org # v6.9+
Fixes: 1940c25eaa63 ("arm64: dts: qcom: x1e80100: Add display nodes")
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/hamoa.dtsi | 49 +++++++++++++++++--------------------
 1 file changed, 22 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 4b0784af4bd3..645bc412b0aa 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -5658,18 +5658,18 @@ mdss_dp0_out: endpoint {
 				mdss_dp0_opp_table: opp-table {
 					compatible = "operating-points-v2";
 
-					opp-160000000 {
-						opp-hz = /bits/ 64 <160000000>;
-						required-opps = <&rpmhpd_opp_low_svs>;
-					};
-
 					opp-270000000 {
 						opp-hz = /bits/ 64 <270000000>;
-						required-opps = <&rpmhpd_opp_svs>;
+						required-opps = <&rpmhpd_opp_low_svs>;
 					};
 
 					opp-540000000 {
 						opp-hz = /bits/ 64 <540000000>;
+						required-opps = <&rpmhpd_opp_svs>;
+					};
+
+					opp-594000000 {
+						opp-hz = /bits/ 64 <594000000>;
 						required-opps = <&rpmhpd_opp_svs_l1>;
 					};
 
@@ -5747,18 +5747,18 @@ mdss_dp1_out: endpoint {
 				mdss_dp1_opp_table: opp-table {
 					compatible = "operating-points-v2";
 
-					opp-160000000 {
-						opp-hz = /bits/ 64 <160000000>;
-						required-opps = <&rpmhpd_opp_low_svs>;
-					};
-
 					opp-270000000 {
 						opp-hz = /bits/ 64 <270000000>;
-						required-opps = <&rpmhpd_opp_svs>;
+						required-opps = <&rpmhpd_opp_low_svs>;
 					};
 
 					opp-540000000 {
 						opp-hz = /bits/ 64 <540000000>;
+						required-opps = <&rpmhpd_opp_svs>;
+					};
+
+					opp-594000000 {
+						opp-hz = /bits/ 64 <594000000>;
 						required-opps = <&rpmhpd_opp_svs_l1>;
 					};
 
@@ -5835,18 +5835,18 @@ mdss_dp2_out: endpoint {
 				mdss_dp2_opp_table: opp-table {
 					compatible = "operating-points-v2";
 
-					opp-160000000 {
-						opp-hz = /bits/ 64 <160000000>;
-						required-opps = <&rpmhpd_opp_low_svs>;
-					};
-
 					opp-270000000 {
 						opp-hz = /bits/ 64 <270000000>;
-						required-opps = <&rpmhpd_opp_svs>;
+						required-opps = <&rpmhpd_opp_low_svs>;
 					};
 
 					opp-540000000 {
 						opp-hz = /bits/ 64 <540000000>;
+						required-opps = <&rpmhpd_opp_svs>;
+					};
+
+					opp-594000000 {
+						opp-hz = /bits/ 64 <594000000>;
 						required-opps = <&rpmhpd_opp_svs_l1>;
 					};
 
@@ -5918,19 +5918,14 @@ mdss_dp3_out: endpoint {
 				mdss_dp3_opp_table: opp-table {
 					compatible = "operating-points-v2";
 
-					opp-160000000 {
-						opp-hz = /bits/ 64 <160000000>;
-						required-opps = <&rpmhpd_opp_low_svs>;
-					};
-
 					opp-270000000 {
 						opp-hz = /bits/ 64 <270000000>;
-						required-opps = <&rpmhpd_opp_svs>;
+						required-opps = <&rpmhpd_opp_low_svs>;
 					};
 
-					opp-540000000 {
-						opp-hz = /bits/ 64 <540000000>;
-						required-opps = <&rpmhpd_opp_svs_l1>;
+					opp-594000000 {
+						opp-hz = /bits/ 64 <594000000>;
+						required-opps = <&rpmhpd_opp_svs>;
 					};
 
 					opp-810000000 {

---
base-commit: a0ae2a256046c0c5d3778d1a194ff2e171f16e5f
change-id: 20260309-hamoa-fix-dp3-opp-table-453b8a5e3bc0

Best regards,
--  
Abel Vesa <abel.vesa@oss.qualcomm.com>

Re: [PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Dmitry Baryshkov]

On Mon, Mar 09, 2026 at 04:44:45PM +0200, Abel Vesa wrote:
> According to internal documentation, the corners specific for each rate
> from the DP link clock are:
>  - LOWSVS_D1 -> 19.2 MHz
>  - LOWSVS    -> 270 MHz
>  - SVS       -> 540 MHz (594 MHz in case of DP3)
>  - SVS_L1    -> 594 MHz
>  - NOM       -> 810 MHz
>  - NOM_L1    -> 810 MHz
>  - TURBO     -> 810 MHz
> 
> So fix all tables for each of the four controllers according to the
> documentation.
> 
> The 19.2 @ LOWSVS_D1 isn't needed as the controller will select 162 MHz
> for RBR, which falls under the 270 MHz and it will vote for that LOWSVS
> in that case.

The list of issues isn't limited to Hamoa. As we started to look at it,
could you please also fix Lemans (drop 160, 270, use 594 instead of
540, use single OPP table), Monaco (the same), SAR2130P (leave just 270
and 810), sc7180 (270 at low_svs, drop 160), etc.

> 
> Cc: stable@vger.kernel.org # v6.9+
> Fixes: 1940c25eaa63 ("arm64: dts: qcom: x1e80100: Add display nodes")
> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/hamoa.dtsi | 49 +++++++++++++++++--------------------
>  1 file changed, 22 insertions(+), 27 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index 4b0784af4bd3..645bc412b0aa 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -5658,18 +5658,18 @@ mdss_dp0_out: endpoint {
>  				mdss_dp0_opp_table: opp-table {
>  					compatible = "operating-points-v2";
>  
> -					opp-160000000 {
> -						opp-hz = /bits/ 64 <160000000>;
> -						required-opps = <&rpmhpd_opp_low_svs>;
> -					};
> -
>  					opp-270000000 {
>  						opp-hz = /bits/ 64 <270000000>;
> -						required-opps = <&rpmhpd_opp_svs>;
> +						required-opps = <&rpmhpd_opp_low_svs>;
>  					};
>  
>  					opp-540000000 {
>  						opp-hz = /bits/ 64 <540000000>;
> +						required-opps = <&rpmhpd_opp_svs>;
> +					};
> +
> +					opp-594000000 {
> +						opp-hz = /bits/ 64 <594000000>;
>  						required-opps = <&rpmhpd_opp_svs_l1>;
>  					};
>  
> @@ -5747,18 +5747,18 @@ mdss_dp1_out: endpoint {
>  				mdss_dp1_opp_table: opp-table {
>  					compatible = "operating-points-v2";
>  
> -					opp-160000000 {
> -						opp-hz = /bits/ 64 <160000000>;
> -						required-opps = <&rpmhpd_opp_low_svs>;
> -					};
> -
>  					opp-270000000 {
>  						opp-hz = /bits/ 64 <270000000>;
> -						required-opps = <&rpmhpd_opp_svs>;
> +						required-opps = <&rpmhpd_opp_low_svs>;
>  					};
>  
>  					opp-540000000 {
>  						opp-hz = /bits/ 64 <540000000>;
> +						required-opps = <&rpmhpd_opp_svs>;
> +					};
> +
> +					opp-594000000 {
> +						opp-hz = /bits/ 64 <594000000>;
>  						required-opps = <&rpmhpd_opp_svs_l1>;
>  					};
>  
> @@ -5835,18 +5835,18 @@ mdss_dp2_out: endpoint {
>  				mdss_dp2_opp_table: opp-table {
>  					compatible = "operating-points-v2";
>  
> -					opp-160000000 {
> -						opp-hz = /bits/ 64 <160000000>;
> -						required-opps = <&rpmhpd_opp_low_svs>;
> -					};
> -
>  					opp-270000000 {
>  						opp-hz = /bits/ 64 <270000000>;
> -						required-opps = <&rpmhpd_opp_svs>;
> +						required-opps = <&rpmhpd_opp_low_svs>;
>  					};
>  
>  					opp-540000000 {
>  						opp-hz = /bits/ 64 <540000000>;
> +						required-opps = <&rpmhpd_opp_svs>;
> +					};
> +
> +					opp-594000000 {
> +						opp-hz = /bits/ 64 <594000000>;
>  						required-opps = <&rpmhpd_opp_svs_l1>;
>  					};
>  
> @@ -5918,19 +5918,14 @@ mdss_dp3_out: endpoint {
>  				mdss_dp3_opp_table: opp-table {
>  					compatible = "operating-points-v2";
>  
> -					opp-160000000 {
> -						opp-hz = /bits/ 64 <160000000>;
> -						required-opps = <&rpmhpd_opp_low_svs>;
> -					};
> -
>  					opp-270000000 {
>  						opp-hz = /bits/ 64 <270000000>;
> -						required-opps = <&rpmhpd_opp_svs>;
> +						required-opps = <&rpmhpd_opp_low_svs>;
>  					};
>  
> -					opp-540000000 {
> -						opp-hz = /bits/ 64 <540000000>;
> -						required-opps = <&rpmhpd_opp_svs_l1>;
> +					opp-594000000 {
> +						opp-hz = /bits/ 64 <594000000>;
> +						required-opps = <&rpmhpd_opp_svs>;
>  					};
>  
>  					opp-810000000 {
> 
> ---
> base-commit: a0ae2a256046c0c5d3778d1a194ff2e171f16e5f
> change-id: 20260309-hamoa-fix-dp3-opp-table-453b8a5e3bc0
> 
> Best regards,
> --  
> Abel Vesa <abel.vesa@oss.qualcomm.com>
> 

-- 
With best wishes
Dmitry

Re: [PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Konrad Dybcio]

On 3/9/26 3:44 PM, Abel Vesa wrote:
> According to internal documentation, the corners specific for each rate
> from the DP link clock are:
>  - LOWSVS_D1 -> 19.2 MHz
>  - LOWSVS    -> 270 MHz
>  - SVS       -> 540 MHz (594 MHz in case of DP3)

This discrepancy sounds a little odd.. can we get some confirmation
that it's intended and not an internal copypasta? (+Jagadeesh, Taniya)
FWIW DP3 is not USB4- or MST-capable so it may as well be

>  - SVS_L1    -> 594 MHz
>  - NOM       -> 810 MHz
>  - NOM_L1    -> 810 MHz
>  - TURBO     -> 810 MHz
> 
> So fix all tables for each of the four controllers according to the
> documentation.

It sounds like a good move to instead keep only a single table for
DP012 and a separate one for DP3 if it's really different

> The 19.2 @ LOWSVS_D1 isn't needed as the controller will select 162 MHz
> for RBR, which falls under the 270 MHz and it will vote for that LOWSVS
> in that case.

Even though the Linux OPP framework agrees with that sentiment today (it
will set the correct rate via clk APIs and the correct rpmh vote for a rate
that's >= 162), I have mixed feelings about relying on that

Konrad

Re: [PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Dmitry Baryshkov]

On Tue, Mar 10, 2026 at 11:36:26AM +0100, Konrad Dybcio wrote:
> On 3/9/26 3:44 PM, Abel Vesa wrote:
> > According to internal documentation, the corners specific for each rate
> > from the DP link clock are:
> >  - LOWSVS_D1 -> 19.2 MHz
> >  - LOWSVS    -> 270 MHz
> >  - SVS       -> 540 MHz (594 MHz in case of DP3)
> 
> This discrepancy sounds a little odd.. can we get some confirmation
> that it's intended and not an internal copypasta? (+Jagadeesh, Taniya)
> FWIW DP3 is not USB4- or MST-capable so it may as well be

DP3 link_clock is sourced from the eDP PHY. I assume there might some 

> 
> >  - SVS_L1    -> 594 MHz
> >  - NOM       -> 810 MHz
> >  - NOM_L1    -> 810 MHz
> >  - TURBO     -> 810 MHz
> > 
> > So fix all tables for each of the four controllers according to the
> > documentation.
> 
> It sounds like a good move to instead keep only a single table for
> DP012 and a separate one for DP3 if it's really different
> 
> > The 19.2 @ LOWSVS_D1 isn't needed as the controller will select 162 MHz
> > for RBR, which falls under the 270 MHz and it will vote for that LOWSVS
> > in that case.
> 
> Even though the Linux OPP framework agrees with that sentiment today (it
> will set the correct rate via clk APIs and the correct rpmh vote for a rate
> that's >= 162), I have mixed feelings about relying on that

Why? 19.2 isn't an actual working frequency, as far as I can understand
anything. Or is it a working OPP for running "shared" clocks?

-- 
With best wishes
Dmitry

Re: [PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Konrad Dybcio]

On 3/13/26 6:39 PM, Dmitry Baryshkov wrote:
> On Tue, Mar 10, 2026 at 11:36:26AM +0100, Konrad Dybcio wrote:
>> On 3/9/26 3:44 PM, Abel Vesa wrote:
>>> According to internal documentation, the corners specific for each rate
>>> from the DP link clock are:
>>>  - LOWSVS_D1 -> 19.2 MHz
>>>  - LOWSVS    -> 270 MHz
>>>  - SVS       -> 540 MHz (594 MHz in case of DP3)
>>
>> This discrepancy sounds a little odd.. can we get some confirmation
>> that it's intended and not an internal copypasta? (+Jagadeesh, Taniya)
>> FWIW DP3 is not USB4- or MST-capable so it may as well be
> 
> DP3 link_clock is sourced from the eDP PHY. I assume there might some 
> 
>>
>>>  - SVS_L1    -> 594 MHz
>>>  - NOM       -> 810 MHz
>>>  - NOM_L1    -> 810 MHz
>>>  - TURBO     -> 810 MHz
>>>
>>> So fix all tables for each of the four controllers according to the
>>> documentation.
>>
>> It sounds like a good move to instead keep only a single table for
>> DP012 and a separate one for DP3 if it's really different
>>
>>> The 19.2 @ LOWSVS_D1 isn't needed as the controller will select 162 MHz
>>> for RBR, which falls under the 270 MHz and it will vote for that LOWSVS
>>> in that case.
>>
>> Even though the Linux OPP framework agrees with that sentiment today (it
>> will set the correct rate via clk APIs and the correct rpmh vote for a rate
>> that's >= 162), I have mixed feelings about relying on that
> 
> Why? 19.2 isn't an actual working frequency, as far as I can understand
> anything. Or is it a working OPP for running "shared" clocks?

No, I meant removing the 162 case and relying on OPP to pick up the
required-opps value from the next entry

Konrad

Re: [PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Dmitry Baryshkov]

On Mon, Mar 16, 2026 at 10:27:11AM +0100, Konrad Dybcio wrote:
> On 3/13/26 6:39 PM, Dmitry Baryshkov wrote:
> > On Tue, Mar 10, 2026 at 11:36:26AM +0100, Konrad Dybcio wrote:
> >> On 3/9/26 3:44 PM, Abel Vesa wrote:
> >>> According to internal documentation, the corners specific for each rate
> >>> from the DP link clock are:
> >>>  - LOWSVS_D1 -> 19.2 MHz
> >>>  - LOWSVS    -> 270 MHz
> >>>  - SVS       -> 540 MHz (594 MHz in case of DP3)
> >>
> >> This discrepancy sounds a little odd.. can we get some confirmation
> >> that it's intended and not an internal copypasta? (+Jagadeesh, Taniya)
> >> FWIW DP3 is not USB4- or MST-capable so it may as well be
> > 
> > DP3 link_clock is sourced from the eDP PHY. I assume there might some 
> > 
> >>
> >>>  - SVS_L1    -> 594 MHz
> >>>  - NOM       -> 810 MHz
> >>>  - NOM_L1    -> 810 MHz
> >>>  - TURBO     -> 810 MHz
> >>>
> >>> So fix all tables for each of the four controllers according to the
> >>> documentation.
> >>
> >> It sounds like a good move to instead keep only a single table for
> >> DP012 and a separate one for DP3 if it's really different
> >>
> >>> The 19.2 @ LOWSVS_D1 isn't needed as the controller will select 162 MHz
> >>> for RBR, which falls under the 270 MHz and it will vote for that LOWSVS
> >>> in that case.
> >>
> >> Even though the Linux OPP framework agrees with that sentiment today (it
> >> will set the correct rate via clk APIs and the correct rpmh vote for a rate
> >> that's >= 162), I have mixed feelings about relying on that
> > 
> > Why? 19.2 isn't an actual working frequency, as far as I can understand
> > anything. Or is it a working OPP for running "shared" clocks?
> 
> No, I meant removing the 162 case and relying on OPP to pick up the
> required-opps value from the next entry

Isn't it a documented way how the OPP tables work?

-- 
With best wishes
Dmitry

Re: [PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Konrad Dybcio]

On 3/16/26 3:27 PM, Dmitry Baryshkov wrote:
> On Mon, Mar 16, 2026 at 10:27:11AM +0100, Konrad Dybcio wrote:
>> On 3/13/26 6:39 PM, Dmitry Baryshkov wrote:
>>> On Tue, Mar 10, 2026 at 11:36:26AM +0100, Konrad Dybcio wrote:
>>>> On 3/9/26 3:44 PM, Abel Vesa wrote:
>>>>> According to internal documentation, the corners specific for each rate
>>>>> from the DP link clock are:
>>>>>  - LOWSVS_D1 -> 19.2 MHz
>>>>>  - LOWSVS    -> 270 MHz
>>>>>  - SVS       -> 540 MHz (594 MHz in case of DP3)
>>>>
>>>> This discrepancy sounds a little odd.. can we get some confirmation
>>>> that it's intended and not an internal copypasta? (+Jagadeesh, Taniya)
>>>> FWIW DP3 is not USB4- or MST-capable so it may as well be
>>>
>>> DP3 link_clock is sourced from the eDP PHY. I assume there might some 
>>>
>>>>
>>>>>  - SVS_L1    -> 594 MHz
>>>>>  - NOM       -> 810 MHz
>>>>>  - NOM_L1    -> 810 MHz
>>>>>  - TURBO     -> 810 MHz
>>>>>
>>>>> So fix all tables for each of the four controllers according to the
>>>>> documentation.
>>>>
>>>> It sounds like a good move to instead keep only a single table for
>>>> DP012 and a separate one for DP3 if it's really different
>>>>
>>>>> The 19.2 @ LOWSVS_D1 isn't needed as the controller will select 162 MHz
>>>>> for RBR, which falls under the 270 MHz and it will vote for that LOWSVS
>>>>> in that case.
>>>>
>>>> Even though the Linux OPP framework agrees with that sentiment today (it
>>>> will set the correct rate via clk APIs and the correct rpmh vote for a rate
>>>> that's >= 162), I have mixed feelings about relying on that
>>>
>>> Why? 19.2 isn't an actual working frequency, as far as I can understand
>>> anything. Or is it a working OPP for running "shared" clocks?
>>
>> No, I meant removing the 162 case and relying on OPP to pick up the
>> required-opps value from the next entry
> 
> Isn't it a documented way how the OPP tables work?

yes/no, there's a mention in dev_pm_opp_set_rate():

"""
An OPP entry specifies the highest frequency at which other
of the OPP entry apply. [...]
"""

if you insist, we can rely on it..

Konrad

Re: [PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Dmitry Baryshkov]

On Mon, Mar 16, 2026 at 04:15:38PM +0100, Konrad Dybcio wrote:
> On 3/16/26 3:27 PM, Dmitry Baryshkov wrote:
> > On Mon, Mar 16, 2026 at 10:27:11AM +0100, Konrad Dybcio wrote:
> >> On 3/13/26 6:39 PM, Dmitry Baryshkov wrote:
> >>> On Tue, Mar 10, 2026 at 11:36:26AM +0100, Konrad Dybcio wrote:
> >>>> On 3/9/26 3:44 PM, Abel Vesa wrote:
> >>>>> According to internal documentation, the corners specific for each rate
> >>>>> from the DP link clock are:
> >>>>>  - LOWSVS_D1 -> 19.2 MHz
> >>>>>  - LOWSVS    -> 270 MHz
> >>>>>  - SVS       -> 540 MHz (594 MHz in case of DP3)
> >>>>
> >>>> This discrepancy sounds a little odd.. can we get some confirmation
> >>>> that it's intended and not an internal copypasta? (+Jagadeesh, Taniya)
> >>>> FWIW DP3 is not USB4- or MST-capable so it may as well be
> >>>
> >>> DP3 link_clock is sourced from the eDP PHY. I assume there might some 
> >>>
> >>>>
> >>>>>  - SVS_L1    -> 594 MHz
> >>>>>  - NOM       -> 810 MHz
> >>>>>  - NOM_L1    -> 810 MHz
> >>>>>  - TURBO     -> 810 MHz
> >>>>>
> >>>>> So fix all tables for each of the four controllers according to the
> >>>>> documentation.
> >>>>
> >>>> It sounds like a good move to instead keep only a single table for
> >>>> DP012 and a separate one for DP3 if it's really different
> >>>>
> >>>>> The 19.2 @ LOWSVS_D1 isn't needed as the controller will select 162 MHz
> >>>>> for RBR, which falls under the 270 MHz and it will vote for that LOWSVS
> >>>>> in that case.
> >>>>
> >>>> Even though the Linux OPP framework agrees with that sentiment today (it
> >>>> will set the correct rate via clk APIs and the correct rpmh vote for a rate
> >>>> that's >= 162), I have mixed feelings about relying on that
> >>>
> >>> Why? 19.2 isn't an actual working frequency, as far as I can understand
> >>> anything. Or is it a working OPP for running "shared" clocks?
> >>
> >> No, I meant removing the 162 case and relying on OPP to pick up the
> >> required-opps value from the next entry
> > 
> > Isn't it a documented way how the OPP tables work?
> 
> yes/no, there's a mention in dev_pm_opp_set_rate():
> 
> """
> An OPP entry specifies the highest frequency at which other
> of the OPP entry apply. [...]
> """
> 
> if you insist, we can rely on it..

I was sure that DT bindings mandate it. However, the bindings don't
include anything supporting that definition. It simply says:
  Devices work at voltage-current-frequency combinations and some
  implementations have the liberty of choosing these.

Viresh, what is the more exact interpretation? If we have a valid rate
for which all other params match the other defined OPP, should we still
define that in the table?


-- 
With best wishes
Dmitry

Re: [PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Viresh Kumar]

On 16-03-26, 21:38, Dmitry Baryshkov wrote:
> I was sure that DT bindings mandate it. However, the bindings don't
> include anything supporting that definition. It simply says:
>   Devices work at voltage-current-frequency combinations and some
>   implementations have the liberty of choosing these.
> 
> Viresh, what is the more exact interpretation? If we have a valid rate
> for which all other params match the other defined OPP, should we still
> define that in the table?

The frequency in the OPP table entry is the highest frequency at which the
properties apply. You don't need duplicate entries in the OPP table if rest of
the properties are same. If you look at dev_pm_opp_set_rate(), it preserves the
frequency passed to it (well modifies it with the return value of round-rate),
which is then used to set the clock eventually. The opp-rate isn't directly
used.

-- 
viresh

Re: [PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Dmitry Baryshkov]

On Tue, Mar 17, 2026 at 03:39:34PM +0530, Viresh Kumar wrote:
> On 16-03-26, 21:38, Dmitry Baryshkov wrote:
> > I was sure that DT bindings mandate it. However, the bindings don't
> > include anything supporting that definition. It simply says:
> >   Devices work at voltage-current-frequency combinations and some
> >   implementations have the liberty of choosing these.
> > 
> > Viresh, what is the more exact interpretation? If we have a valid rate
> > for which all other params match the other defined OPP, should we still
> > define that in the table?
> 
> The frequency in the OPP table entry is the highest frequency at which the
> properties apply. You don't need duplicate entries in the OPP table if rest of
> the properties are same. If you look at dev_pm_opp_set_rate(), it preserves the
> frequency passed to it (well modifies it with the return value of round-rate),
> which is then used to set the clock eventually. The opp-rate isn't directly
> used.

Ack, thanks!

So we can drop 19.2 corner (and 192 ofc) and we don't need 162 corner.

-- 
With best wishes
Dmitry

Re: [PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Konrad Dybcio]

On 3/13/26 6:39 PM, Dmitry Baryshkov wrote:
> On Tue, Mar 10, 2026 at 11:36:26AM +0100, Konrad Dybcio wrote:
>> On 3/9/26 3:44 PM, Abel Vesa wrote:
>>> According to internal documentation, the corners specific for each rate
>>> from the DP link clock are:
>>>  - LOWSVS_D1 -> 19.2 MHz
>>>  - LOWSVS    -> 270 MHz
>>>  - SVS       -> 540 MHz (594 MHz in case of DP3)
>>
>> This discrepancy sounds a little odd.. can we get some confirmation
>> that it's intended and not an internal copypasta? (+Jagadeesh, Taniya)
>> FWIW DP3 is not USB4- or MST-capable so it may as well be
> 
> DP3 link_clock is sourced from the eDP PHY. I assume there might some 
> 
>>
>>>  - SVS_L1    -> 594 MHz
>>>  - NOM       -> 810 MHz
>>>  - NOM_L1    -> 810 MHz
>>>  - TURBO     -> 810 MHz
>>>
>>> So fix all tables for each of the four controllers according to the
>>> documentation.
>>
>> It sounds like a good move to instead keep only a single table for
>> DP012 and a separate one for DP3 if it's really different

Please do this and resend

Konrad

Re: [PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Abel Vesa]

On 26-03-17 16:06:48, Konrad Dybcio wrote:
> On 3/13/26 6:39 PM, Dmitry Baryshkov wrote:
> > On Tue, Mar 10, 2026 at 11:36:26AM +0100, Konrad Dybcio wrote:
> >> On 3/9/26 3:44 PM, Abel Vesa wrote:
> >>> According to internal documentation, the corners specific for each rate
> >>> from the DP link clock are:
> >>>  - LOWSVS_D1 -> 19.2 MHz
> >>>  - LOWSVS    -> 270 MHz
> >>>  - SVS       -> 540 MHz (594 MHz in case of DP3)
> >>
> >> This discrepancy sounds a little odd.. can we get some confirmation
> >> that it's intended and not an internal copypasta? (+Jagadeesh, Taniya)
> >> FWIW DP3 is not USB4- or MST-capable so it may as well be
> > 
> > DP3 link_clock is sourced from the eDP PHY. I assume there might some 
> > 
> >>
> >>>  - SVS_L1    -> 594 MHz
> >>>  - NOM       -> 810 MHz
> >>>  - NOM_L1    -> 810 MHz
> >>>  - TURBO     -> 810 MHz
> >>>
> >>> So fix all tables for each of the four controllers according to the
> >>> documentation.
> >>
> >> It sounds like a good move to instead keep only a single table for
> >> DP012 and a separate one for DP3 if it's really different
> 
> Please do this and resend

Will do.

Re: [PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Abel Vesa]

On 26-03-09 21:52:01, Dmitry Baryshkov wrote:
> On Mon, Mar 09, 2026 at 04:44:45PM +0200, Abel Vesa wrote:
> > According to internal documentation, the corners specific for each rate
> > from the DP link clock are:
> >  - LOWSVS_D1 -> 19.2 MHz
> >  - LOWSVS    -> 270 MHz
> >  - SVS       -> 540 MHz (594 MHz in case of DP3)
> >  - SVS_L1    -> 594 MHz
> >  - NOM       -> 810 MHz
> >  - NOM_L1    -> 810 MHz
> >  - TURBO     -> 810 MHz
> > 
> > So fix all tables for each of the four controllers according to the
> > documentation.
> > 
> > The 19.2 @ LOWSVS_D1 isn't needed as the controller will select 162 MHz
> > for RBR, which falls under the 270 MHz and it will vote for that LOWSVS
> > in that case.
> 
> The list of issues isn't limited to Hamoa. As we started to look at it,
> could you please also fix Lemans (drop 160, 270, use 594 instead of
> 540, use single OPP table), Monaco (the same), SAR2130P (leave just 270
> and 810), sc7180 (270 at low_svs, drop 160), etc.

For now, I'll just do Hamoa as this is the only one out of the ones you
mentioned here for which I have access to documentation (yet).

I have prepared patches for all the other ones, but I need to double
check the documentation, after I get access.

Re: [PATCH] arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

[Dmitry Baryshkov]

On Wed, Mar 18, 2026 at 04:22:59PM +0200, Abel Vesa wrote:
> On 26-03-09 21:52:01, Dmitry Baryshkov wrote:
> > On Mon, Mar 09, 2026 at 04:44:45PM +0200, Abel Vesa wrote:
> > > According to internal documentation, the corners specific for each rate
> > > from the DP link clock are:
> > >  - LOWSVS_D1 -> 19.2 MHz
> > >  - LOWSVS    -> 270 MHz
> > >  - SVS       -> 540 MHz (594 MHz in case of DP3)
> > >  - SVS_L1    -> 594 MHz
> > >  - NOM       -> 810 MHz
> > >  - NOM_L1    -> 810 MHz
> > >  - TURBO     -> 810 MHz
> > > 
> > > So fix all tables for each of the four controllers according to the
> > > documentation.
> > > 
> > > The 19.2 @ LOWSVS_D1 isn't needed as the controller will select 162 MHz
> > > for RBR, which falls under the 270 MHz and it will vote for that LOWSVS
> > > in that case.
> > 
> > The list of issues isn't limited to Hamoa. As we started to look at it,
> > could you please also fix Lemans (drop 160, 270, use 594 instead of
> > 540, use single OPP table), Monaco (the same), SAR2130P (leave just 270
> > and 810), sc7180 (270 at low_svs, drop 160), etc.
> 
> For now, I'll just do Hamoa as this is the only one out of the ones you
> mentioned here for which I have access to documentation (yet).
> 
> I have prepared patches for all the other ones, but I need to double
> check the documentation, after I get access.

Sure, thanks!

Please ping me if there are any questions or delays, we can check the
docs together.

-- 
With best wishes
Dmitry