Re: [PATCH 0/2] clk: qcom: Add support for multiple power-domains for a clock controller.

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

On 18/11/2024 13:22, Bryan O'Donoghue wrote:
> On 18/11/2024 13:15, Dmitry Baryshkov wrote:
>>> On x1e80100 and it's SKUs the Camera Clock Controller - CAMCC has
>>> multiple power-domains which power it. Usually with a single power- 
>>> domain
>>> the core platform code will automatically switch on the singleton
>>> power-domain for you. If you have multiple power-domains for a 
>>> device, in
>>> this case the clock controller, you need to switch those power-domains
>>> on/off yourself.
> 
>> I think the series misses the platform-specific part. 
> 
> I don't think I understand what you mean by that.
> 
> It is hard to
>> understand what kind of power relationship do you need to express. Is it
>> actually the whole CC being powered by several domains? Or are some of
>> those domains used to power up PLLs? Or as parents to some of GDSCs?
> 
> Well for example the TITAN_TOP_GDSC needs both PDs to be switched on.
> 
> We _could_ do this just for the CAMCC on x1e80100 - i.e. make it just 
> for the camcc device but then, the next clock controller that needs more 
> than one PD will have to implement the same fix.

Can some of the PLLs run with one PD or the other ?

Perhaps, but without _both_ PDs on the GDSC will stay stuck @ off for my 
test case on x1e80100 and looking at other places we manage PDs directly 
- drivers/media/platform/venus.c for example its generally just all or 
nothing.

There may be more granularity to extract but, I don't think there's more 
granularity for the first case here. Both PDs are needed or the GDSC 
will remain stuck @ off.

As I see it we can either address

1. At the drivers/clk/qcom/camcc-somesoc.c level
2. At drivers/clk/qcom/[gdsc.c|common.c] level

I think option 2 is more how you'd expect this to work though. Its not 
particularly obvious but ATM with singleton power-domains for the clock 
controllers the singletons just get turned on and left that way.

So managing the PD on/off inside of common.c/gdsc.c means the calling 
clock controller can stay as a simple probe() type driver and also means 
we can reuse the generic common.c/gdsc.c approach.

---
bod