On 02-11-20, 12:01, Nicola Mazzucato wrote: > This is a continuation of the previous v2, where we focused mostly on the > dt binding. > > I am seeking some feedback/comments on the following two approaches. > > Intro: > We have seen that in a system where performance control and hardware > description do not match (i.e. per-cpu), we still need the information of > how the v/f lines are shared among the cpus. We call this information > "performance dependencies". > We got this info through the opp-shared (the previous 2 patches aim for > that). > > Problem: > How do we share such info (retrieved from a cpufreq driver) to other > consumers that rely on it? I have two proposals. I haven't really stop thinking about what and how we should solve this, but I have few concerns first. > 2) drivers/thermal/cpufreq_cooling: Replace related_cpus with dependent_cpus I am not sure if I understand completely on how this is going to be modified/work. The only use of related_cpus in the cooling driver is in the helper cdev->get_requested_power(), where we need to find the total power being consumed by devices controlled by the cooling device. Right ? Now the cooling devices today are very closely related to the cpufreq policy, the registration function itself takes a cpufreq policy as an argument. Consider that you have an octa-core platform and all the CPUs are dependent on each other. With your suggested changes and hw control, we will have different cpufreq policies for each CPU. And so we will have a cooling device, cdev, for each CPU as well. When the IPA governor calls cdev->get_requested_power(), why should we ever bother to traverse the list of dependent_cpus and not related_cpus only ? Otherwise the same CPU will have its load contributed to the power of 8 cooling devices. -- viresh
