On 02-11-20, 12:01, Nicola Mazzucato wrote: > Hi All, > > In this V3 posting I have replaced the new dt-binding with minor changes/ > improvements for opp (since we are now using opp tables instead). > The RFC still stands on how to make this info available to sw consumers. > > In the RFC, I am proposing a simple addition of a performance dependencies > cpumask in CPUFreq core and an example of how drivers and consumers would > make use of it. > I also propose an alternative approach, which does not require changes in > CPUFreq core, but - possibly - in all the consumers. > > This is to support systems where exposed cpu performance controls are more > fine-grained that the platform's ability to scale cpus independently. I was talking to Vincent about what you are doing here and we got a bit confused and so here are few questions that we had: - Based on my previous understanding, you don't want software coordination of frequencies (which is done by cpufreq today), but want the hardware to do that and so you want per-cpu cpufreq policies. - What's the real benefit of hardware coordination ? Want to make sure I fully understand that. - Because of hardware co-ordination of otherwise co-ordinated CPUs, few things break. Thermal and EAS are some of the examples and so you are trying to fix them here by proving them the missing information again. - One other thing that breaks with this is freq-invariance in the scheduler, as the scheduler won't see the real frequencies the various CPUs are running at. Most of the hardware we have today doesn't have counters, like AMUs, not sure if all future ones based on SCMI will have that too, so how are they gong to be fixed ? And if we even have to fix this (freq invariance), what's hardware coordination giving us that makes all this worth it ? Sorry about the long list :) -- viresh
