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
