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