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] [thread-next>] [day] [month] [year] [list]
Message-ID: <16CE34C3-ADAE-47EC-AAFB-4436C4D8C842@linaro.org>
Date:   Mon, 12 Dec 2022 13:53:59 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        linux-arm-msm@...r.kernel.org, andersson@...nel.org,
        agross@...nel.org, krzysztof.kozlowski@...aro.org
CC:     marijn.suijten@...ainline.org, Rob Clark <robdclark@...il.com>,
        Abhinav Kumar <quic_abhinavk@...cinc.com>,
        Sean Paul <sean@...rly.run>, David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] arm64: dts: qcom: sm8150: Add DISPCC node



On 12 December 2022 13:23:50 GMT+03:00, Konrad Dybcio <konrad.dybcio@...aro.org> wrote:
>
>
>On 12.12.2022 11:18, Dmitry Baryshkov wrote:
>> 
>> 
>> On 12 December 2022 12:33:13 GMT+03:00, Konrad Dybcio <konrad.dybcio@...aro.org> wrote:
>>> Years after the SoC support has been added, it's high time for it to
>>> get dispcc going. Add the node to ensure that.
>>>
>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>>> ---
>>> arch/arm64/boot/dts/qcom/sm8150.dtsi | 26 ++++++++++++++++++++++++++
>>> 1 file changed, 26 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>>> index a0c57fb798d3..ff04397777f4 100644
>>> --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>>> @@ -3579,6 +3579,32 @@ camnoc_virt: interconnect@...0000 {
>>> 			qcom,bcm-voters = <&apps_bcm_voter>;
>>> 		};
>>>
>>> +		dispcc: clock-controller@...0000 {
>>> +			compatible = "qcom,sm8150-dispcc";
>>> +			reg = <0 0x0af00000 0 0x10000>;
>>> +			clocks = <&rpmhcc RPMH_CXO_CLK>,
>>> +				 <0>,
>>> +				 <0>,
>>> +				 <0>,
>>> +				 <0>,
>>> +				 <0>,
>>> +				 <0>;
>>> +			clock-names = "bi_tcxo",
>>> +				      "dsi0_phy_pll_out_byteclk",
>>> +				      "dsi0_phy_pll_out_dsiclk",
>>> +				      "dsi1_phy_pll_out_byteclk",
>>> +				      "dsi1_phy_pll_out_dsiclk",
>>> +				      "dp_phy_pll_link_clk",
>>> +				      "dp_phy_pll_vco_div_clk";
>>> +			#clock-cells = <1>;
>>> +			#reset-cells = <1>;
>>> +			#power-domain-cells = <1>;
>>> +
>>> +			power-domains = <&rpmhpd SM8150_MMCX>;
>>> +			/* TODO: Maybe rpmhpd_opp_min_svs could work as well? */
>>> +			required-opps = <&rpmhpd_opp_low_svs>;
>> 
>> Is it required for the dispcc, for the DSI or for the dpu? We have stumbled upon the similar issue when working on the 8350, see the latest Robert's patchset.
>While I don't have any hard evidence, it seems like it is required for
>any "interesting" multimedia components, AFAIU even including video and
>camera clocks..
>
>Seems like it's a deep down dependency for a lot of things on this
>particular SoC (and likely also on newer ones, remember the initial
>mess with 8250 mmcx?)

Yes. I was questioning the opp level rather than the domain itself. Usually the least possible mmcx level is enough to get dispcc going. Then the consumers (via the PLLs) bump this requirement. 

In this particular case the vendor dtsi (sm8150-regulator.dtsi) declares that the minimum level for mmcx is low_svs. So, I think, you can drop the todo completely.


>
>Konrad
>> 
>> 
>>> +		};
>>> +
>>> 		pdc: interrupt-controller@...0000 {
>>> 			compatible = "qcom,sm8150-pdc", "qcom,pdc";
>>> 			reg = <0 0x0b220000 0 0x400>;
>> 

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ