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]

Date:   Fri, 27 Jan 2023 14:14:56 +0100
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Luca Weiss <luca.weiss@...rphone.com>,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.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 27.01.2023 14:11, Luca Weiss wrote:
> On Fri Jan 27, 2023 at 1:49 PM CET, Bryan O'Donoghue wrote:
>> On 27/01/2023 12:45, Luca Weiss wrote:
>>> 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
>>
>> Doh I meant to say a power-domain to an mmcx a la
>>
>> power-domains = <&rpmhpd SM8250_MMCX>;
>> required-opps = <&rpmhpd_opp_low_svs>;
>>
>> TITAN_TOP should be in your cci and camss dt nodes.
> 
> Okay, that makes more sense.
> 
> What I don't quite understand is why sm8250 only has MMCX listed there
> since downstream has both vdd_mx-supply = <&VDD_MX_LEVEL> and
> vdd_mm-supply = <&VDD_MMCX_LEVEL> and both "supplies" are used for
> different clocks using .vdd_class
> 
> But back to sm6350, downstream has vdd_mx-supply = <&VDD_MX_LEVEL> and
> vdd_cx-supply = <&VDD_CX_LEVEL> and like sm8250 uses cx and mx for
> different clocks.
> Not sure if I should add both, and I guess mainline also currently
> doesn't use higher ops for the power domain when higher clock rate is
> needed, from what I understand?
Basically if you don't need to power any of these power rails to
have access to the clock controller, you don't need any of them.

What you will need to do however, is make sure that they are scaled with
child devices then.. but that's no bueno since they all need TITAN_GDSC.
That's why Bryan suggests leaving a vote on a power rail in the clock
controller, so that if no other votes are present (as improbable as
that may be), you will still be able to get the clocks going.

That OTOH will require you to add power management support (PM ops)
to the clock controller, as otherwise you can say goodbye to battery
life..

Konrad
> 
>>
>> ---
>> bod
>