arch/arm64/boot/dts/qcom/hamoa.dtsi | 49 +++++++++++++++++-------------------- 1 file changed, 22 insertions(+), 27 deletions(-)
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>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
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
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
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.
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
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
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
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
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
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
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
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.
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
© 2016 - 2026 Red Hat, Inc.