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