linux-kernel - Re: [PATCH] clk: qcom: camcc-sc8280xp: Remove always-on GDSC hard-coding

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <454fc2ec-6679-2d51-2a6a-580838d6ba59@quicinc.com>
Date: Mon, 29 Jul 2024 16:27:42 +0530
From: "Satya Priya Kakitapalli (Temp)" <quic_skakitap@...cinc.com>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Bjorn Andersson
	<andersson@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen
 Boyd <sboyd@...nel.org>
CC: <dmitry.baryshkov@...aro.org>, <stable@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-clk@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] clk: qcom: camcc-sc8280xp: Remove always-on GDSC
 hard-coding


On 7/27/2024 2:01 AM, Bryan O'Donoghue wrote:
> On 26/07/2024 08:01, Satya Priya Kakitapalli (Temp) wrote:
>>
>> On 7/23/2024 2:59 PM, Bryan O'Donoghue wrote:
>>> On 22/07/2024 09:57, Satya Priya Kakitapalli (Temp) wrote:
>>>>> I have no idea. Why does it matter ?
>>>>>
>>>>
>>>> This clock expected to be kept always ON, as per design, or else 
>>>> the GDSC transition form ON to OFF (vice versa) wont work.
>>>
>>> Yes, parking to XO per this patch works for me. So I guess its 
>>> already on and is left in that state by the park.
>>>
>>>> Want to know the clock status after bootup, to understand if the 
>>>> clock got turned off during the late init. May I know exactly what 
>>>> you have tested? Did you test the camera usecases as well?
>>>
>>> Of course.
>>>
>>> The camera works on x13s with this patch. That's what I mean by tested.
>>>
>>
>> It might be working in your case, but it is not the HW design 
>> recommended way to do. The same should not be propagated to other 
>> target's camcc drivers, as I already observed it is not working on 
>> SM8150.
>
> I don't think the argument here really stands up.
>
> We've established that the GDSC clock and PDs will remain on when the 
> clock gets parked right ?
>
> Am I missing something obvious here ?
>

Yes, just parking the RCG at XO, does not ensure the branch clock, i.e, 
the 'cam_cc_gdsc_clk' as always ON. When I compiled the camcc-sm8150 
driver statically, I see that the clock is getting disabled in late_init 
if it is modelled.


Can you confirm if the camcc-sc8280xp driver is compiled statically or 
as a module at your end?


> ---
> bod
>