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
