Hi Stephen
Thank you for your feedback
> Does the protected-clocks property work? That basically says "don't use
> these clks in the OS". The driver implementation would not register
> those clks and then the framework would be unaware of their existence,
> leading to them never being disabled during late init.
>
> This approach also looks OK to me, basically programmatically creating
> the protected-clocks list by parsing DT for reserved consumer nodes and
> then figuring out that no consumer exists so we can skip registering the
> clk entirely, or add the flag. I'm not sure we want to implement that
> policy globally, because maybe someone really wants to disable the clk
> still to clean up bootloader state and then let a remoteproc use the clk
> later.
>
> Do you want to keep those clks registered with the framework? Is there
> any benefit to keeping clks around if linux can't do anything with them?
Actually, this idea (= using "protected-clocks" property style) was our 1st
idea, but I noticed that it is not enough. Because clock driver is possible
to know which module was not used on Linux, but other driver can't, in this
idea. For example, power-domain control driver might want to know about it.
In case of using "protected-clocks" property, we need to have same/similar
settings on each driver, but in case of using "status = reserved", all
driver is possible to know it. It has consistent, and no contradict like
some module was listed as "protected-clocks" on clock / power driver,
but has "status = ok" on its driver, etc.
It seems we have different opinions around here ?
Our other idea was having "unassigned" node instead of
"status = reserved", like below.
clock driver checks "unassigned" node's "devices" property, and
ignore/disable listed device's "clocks".
unassigned {
devices = <&scif1>, <&hsusb>;
};
scif1: serial@xxxx {
status = "disabled";
clocks = <&cpg CPG_MOD 206>,
<&cpg CPG_CORE R8A7795_CLK_S3D1>,
<&scif_clk>;
...
};
hsusb: usb@xxxx {
status = "disabled";
clocks = <&cpg CPG_MOD 704>, <&cpg CPG_MOD 703>;
...
};
Thank you for your help !!
Best regards
---
Kuninori Morimoto
