linux-kernel - Re: [PATCH v2 2/4] arm64: dts: qcom: sm6350: Add camera clock controller

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: <CQ2ZDQKO11XZ.HA5CXLK5MTFB@otso>
Date:   Fri, 27 Jan 2023 13:45:00 +0100
From:   "Luca Weiss" <luca.weiss@...rphone.com>
To:     "Bryan O'Donoghue" <bryan.odonoghue@...aro.org>,
        "Andy Gross" <agross@...nel.org>,
        "Bjorn Andersson" <andersson@...nel.org>,
        "Konrad Dybcio" <konrad.dybcio@...aro.org>,
        "Loic Poulain" <loic.poulain@...aro.org>,
        "Robert Foss" <rfoss@...nel.org>,
        "Rob Herring" <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>
Cc:     <~postmarketos/upstreaming@...ts.sr.ht>,
        <phone-devel@...r.kernel.org>, <linux-i2c@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/4] arm64: dts: qcom: sm6350: Add camera clock
 controller

On Tue Jan 24, 2023 at 4:25 PM CET, Bryan O'Donoghue wrote:
> On 24/01/2023 14:48, Luca Weiss wrote:
> > On Fri Jan 20, 2023 at 5:49 PM CET, Bryan O'Donoghue wrote:
> >> On 20/01/2023 13:13, Luca Weiss wrote:
> >>> +		camcc: clock-controller@...0000 {
> >>> +			compatible = "qcom,sm6350-camcc";
> >>> +			reg = <0 0x0ad00000 0 0x16000>;
> >>> +			clocks = <&rpmhcc RPMH_CXO_CLK>;
> >>> +			#clock-cells = <1>;
> >>> +			#reset-cells = <1>;
> >>> +			#power-domain-cells = <1>;
> >>> +		};
> >>
> >> Should you include
> >>
> >> required-opps = <&rpmhpd_opp_low_svs>;
> >>
> >> ?
> > 
> > I don't know, it works without. But doesn't this property not just
> > affect power-domains? I haven't passed any here.
> > 
>
> Should you have a TITAN_TOP pd though ?

Can I reference <&camcc TITAN_TOP_GDSC> from itself? I know that having
it on is required to turn on at least some clocks (maybe all clocks).
But from what I understand how power domains are normally handled, the
driver core enables them before the driver is probed, so self
referencing wouldn't work.

And at least no other SoC upstream references TITAN_TOP_GDSC in camcc.

Regards
Luca

>
> ---
> bod