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