Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07-10-20, 13:58, Nicola Mazzucato wrote:
> 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).

If the CPUs are in the same clock domain, they must be part of the
same cpufreq policy.

> 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.

Some, but I am still confused :(

Can you give a real example, with exact number of CPUs, how they share
clocks/voltage domains and what else the firmware needs in terms of
performance-domains ? That may make it easier for me to understand it.

-- 
viresh



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux