On Tue, Nov 17, 2020 at 11:53 AM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > > On 17-11-20, 10:47, Nicola Mazzucato wrote: > > Freq-invariance has been mentioned. I suppose the fix will depend on which > > strategy we prefer to solve this. > > I am not sure how FIE will use this information, as I thought the > problem is about knowing the current frequency on a CPU instead of > which CPUs are related. Anyway, EM is good enough to get this stuff > going. > > > As a reminder, two solutions: > > 1) dependent_cpus cpumask in cpufreq and involved entities pick this info > > Yeah, this one. And it will be called freqdomain_cpus. Add support for > freqdomain_cpus in core, update acpi-cpufreq to reuse it instead of > adding its own and you can have it in other drivers then. Is this really a cpufreq thing, though, or is it arch stuff? I think the latter, because it is not necessary for anything in cpufreq. Yes, acpi-cpufreq happens to know this information, because it uses processor_perflib, but the latter may as well be used by the arch enumeration of CPUs and the freqdomain_cpus mask may be populated from there. As far as cpufreq is concerned, if the interface to the hardware is per-CPU, there is one CPU per policy and cpufreq has no business knowing anything about the underlying hardware coordination.
