linux-kernel - Re: [PATCH 2/2] clk: qcom: gdsc: Add pm

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: <ava6dkmz5g725skafuqyb4rly3qna5z4bhfmrqgogcmdcubzf3@eu4odajw6e6d>
Date: Tue, 26 Nov 2024 11:23:24 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc: Michael Turquette <mturquette@...libre.com>, 
	Stephen Boyd <sboyd@...nel.org>, linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] clk: qcom: gdsc: Add pm_runtime hooks

On Wed, Nov 20, 2024 at 05:09:08PM +0000, Bryan O'Donoghue wrote:
> On 19/11/2024 15:34, Bjorn Andersson wrote:
> > What I think you want is two things:
> > 1) When you're accessing the registers, you want the clock controller's
> > power-domain to be on.
> > 2) When the client vote for a GDSC, you want to have the PM framework
> > also ensure that parent power-domains are kept on.
> > For the single case, this is handled by the pm_genpd_add_subdomain()
> > call below. This, or something along those lines, seems like the
> > appropriate solution.
> 
> Yes.
> 
> I'm finding with this patch reverted but, keeping the first patch that it
> pretty much works as you'd want with the caveat that gdsc_register ->
> gdsc_en -> gdsc_toggle fails the first time.
> 

Can you clarify that call graph for me? The one case I can see where
gdsc_register() leads to gdsc_enable() is if the sc is marked ALWAYS_ON
and I don't think that is your case.

What you describe sounds like we're trying to turn on the power-domain
without first enabling the supplies, or perhaps there are clock
dependencies that are not in order when this is being attempted?

Regards,
Bjorn

> After that I see the GDSCs on/off as excpected
> 
> cat /sys/kernel/debug/pm_genpd/cam_cc_titan_top_gdsc/current_state
> off-0
> 
> cat /sys/kernel/debug/pm_genpd/cam_cc_ife_0_gdsc/current_state
> off-0
> 
> cam -c 1 --capture=10 --file
> 
> cat /sys/kernel/debug/pm_genpd/cam_cc_titan_top_gdsc/current_state
> off-0
> 
> cat /sys/kernel/debug/pm_genpd/cam_cc_ife_0_gdsc/current_state
> off-0
> 
> Perhaps we just need to fix the probe path @ gdsc_register()
> 
> ---
> bod