Re: [RFC PATCH 1/4] dt-bindings: cpufreq-qcom-hw: Move clocks to CPU nodes

[Rob Herring]

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