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