lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <59e3e34d-83b6-4f83-be4c-eeaaba9a353e@oss.qualcomm.com>
Date: Wed, 30 Apr 2025 09:46:24 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Abhinav Kumar <quic_abhinavk@...cinc.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>
Cc: Jessica Zhang <jesszhan@...cinc.com>,
        Abhinav Kumar
 <abhinavk@...cinc.com>,
        Abel Vesa <abel.vesa@...aro.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC/WIP 1/4] arm64: dts: qcom: sm8750: Add display (MDSS)
 with Display CC

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@...aro.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

> 
>> [...]
>>
>>> +                mdss_dsi_opp_table: opp-table {
>>> +                    compatible = "operating-points-v2";
>>> +
>>
>> Similarly there's a 140.63 MHz rate at SVS_D1, but it seems odd
>> with the decimals
> 
> For this one, yes its true that LOW_SVS_D1 is 140.63Mhz for sm8750 but this voltage corner was somehow never used for DSI byte clock again I am thinking this is because for the display resolutions we use, we will always be >= low_svs so the low_svs_d1 will never hit even if we add it.

Alright

Konrad

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ