Re: [PATCH RFC/WIP 1/4] arm64: dts: qcom: sm8750: Add display (MDSS) with Display CC

[Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>]

On 05/05/2025 08:49, Krzysztof Kozlowski wrote:
> On 30/04/2025 09:46, Konrad Dybcio wrote:
>> On 4/30/25 1:07 AM, Abhinav Kumar wrote:
>>>
>>>
>>> On 4/28/2025 2:31 PM, Konrad Dybcio wrote:
>>>> On 4/24/25 3:04 PM, Krzysztof Kozlowski wrote:
>>>>> Add device nodes for entire display: MDSS, DPU, DSI, DSI PHYs,
>>>>> DisplayPort and Display Clock Controller.
>>>>>
>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> +                mdp_opp_table: opp-table {
>>>>> +                    compatible = "operating-points-v2";
>>>>> +
>>>>
>>>> The computer tells me there's also a 156 MHz rate @ SVS_D1
>>>>
>>>> Maybe Abhinav could chime in whether we should add it or not
>>>>
>>>
>>> Yes I also see a 156Mhz for LOW_SVS_D1 but we had a similar entry even for sm8650 and did not publish it in the dt.
>>>
>>> It was present till sm8450.dtsi but dropped in sm8550/sm8650 even though LOW_SVS_D1 is present even on those.
>>>
>>> I think the reason could be that the displays being used on the reference boards will need a pixel clock of atleast >= low_svs and the MDP clock usually depends on the value of the DSI pixel clock (which has a fixed relationship to the byte clock) to maintain the data rate. So as a result perhaps even if we add it, for most displays this level will be unused.
>>>
>>> If we end up using displays which are so small that the pixel clock requirement will be even lower than low_svs, we can add those.
>>>
>>> OR as an alternative, we can leave this patch as it is and add the low_svs_d1 for all chipsets which support it together in another series that way it will have the full context of why we are adding it otherwise it will look odd again of why sm8550/sm8650 was left out but added in sm8750.
>>
>> I would assume that with VRR even fancy panels at low refresh rate (in
>> the 1-5 Hz range) may make use of this, so I would be happy to go with
>> option 2
> 
> Corner cases, at least high frequency, was omitted intentionally because
> for example NOM_L1 simply cause hardware reboot. Something else is
> missing in rpmh, but I don't mind documenting all of them.

Lower frequencies work, so I will include them.

Best regards,
Krzysztof