Messages in this thread | | | Date | Mon, 18 Jul 2022 14:46:51 -0600 | From | Rob Herring <> | Subject | Re: [RFC PATCH 1/4] dt-bindings: cpufreq-qcom-hw: Move clocks to CPU nodes |
| |
On Wed, Jul 13, 2022 at 12:22:56PM +0530, Viresh Kumar wrote: > cpufreq-hw is a hardware engine, which takes care of frequency > management for CPUs. The engine manages the clocks for CPU devices, but > it isn't the end consumer of the clocks, which are the CPUs in this > case.
The question is really where does the clock mux live?
> For this reason, it looks incorrect to keep the clock related properties > in the cpufreq-hw node. They should really be present at the end user, > i.e. the CPUs.
The issue is that the CPU itself probably only has 1 clock input (at least for its core frequency). Listing out all possible clock sources in CPU node 'clocks' is wrong too.
> The case was simple currently as all the devices, i.e. the CPUs, that > the engine manages share the same clock names. What if the clock names > are different for different CPUs or clusters ? How will keeping the > clock properties in the cpufreq-hw node work in that case ? > > This design creates further problems for frameworks like OPP, which > expects all such details (clocks) to be present in the end device node > itself, instead of another related node. > > Move the clocks properties to the node that uses them instead.
What's the purpose of freq-domain binding now? I thought the idea was to use that instead of clocks directly.
Rob
| |