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