Hi Viresh, performance controls is what is exposed by the firmware through a protocol that is not capable of describing hardware (say SCMI). For example, the firmware can tell that the platform has N controls, but it can't say to which hardware they are "wired" to. This is done in dt, where, for example, we map these controls to cpus, gpus, etc. Let's focus on cpus. Normally we would have N of performance controls (what comes from f/w) that that correspond to hardware clock/dvfs domains. However, some firmware implementations might benefit from having finer grained information about the performance requirements (e.g. per-CPU) and therefore choose to present M performance controls to the OS. DT would be adjusted accordingly to "wire" these controls to cpus or set of cpus. In this scenario, the f/w will make aggregation decisions based on the requests it receives on these M controls. Here we would have M cpufreq policies which do not necessarily reflect the underlying clock domains, thus some s/w components will underperform (EAS and thermal, for example). A real example would be a platform in which the firmware describes the system having M per-cpu control, and the cpufreq subsystem will have M policies while in fact these cpus are "performance-dependent" each other (e.g. are in the same clock domain). This performance dependency information is essential for some components that take information from the cpufreq policy. To restore functionality we can use the optional node 'cpu-performance-dependencies' in dt which will provide such dependency information and we can add a new cpumask 'dependency_cpus' in policy. Hope it gives some clarity. Nicola On 10/6/20 8:19 AM, Viresh Kumar wrote: > On 24-09-20, 10:53, Nicola Mazzucato wrote: >> I am seeking some feedback/comments on the following approach. >> >> Intro: >> Info of performance depency for cpus will be beneficial for systems >> where f/w description of the CPU performance control domain is different >> from the clock domain, e.g. per-CPU control with multiple CPUs sharing >> clock, and kernel OSPM s/w components need to take CPU performance >> dependency into account. >> Essentially these s/w components will have to be provided with >> this information from dt and this RFC is presenting a possible way >> to do so. > > I am not sure I understand what performance control mean here. Can you please > elaborate a bit more on that ? For example, with current code and understanding, > a cpufreq policy belongs to a group of CPUs which change their frequency > together, which also mean that they change their performance level together and > so I am not able to understand what's going on here. Sorry about that. > > What kind of hardware configuration doesn't work with this ? >
