On Tue, Dec 19, 2017 at 8:20 PM, Gautham R Shenoy <e...@linux.vnet.ibm.com> wrote: > Hi Viresh, > On Mon, Dec 18, 2017 at 01:59:35PM +0530, Viresh Kumar wrote: >> On 18-12-17, 10:41, Abhishek wrote: >> > We need to do it in this way as the current implementation takes the max of >> > the PMSR of the cores. Thus, when the frequency is required to be ramped >> > up, >> > it suffices to write to just the local PMSR, but when the frequency is to >> > be >> > ramped down, if we don't send the IPI it breaks the compatibility with P8. >> >> Looks strange really that you have to program this differently for speeding >> up >> or down. These CPUs are part of one cpufreq policy and so I would normally >> expect changes to any CPU should reflect for other CPUs as well. >> >> @Goutham: Do you know why it is so ? >> > > These are due to some implementation quirks where the platform has > provided a PMCR per-core to be backward compatible with POWER8, but > controls the frequency at a quad-level, by taking the maximum of the > four PMCR values instead of the latest one. So, changes to any CPU in > the core will reflect on all the cores if the frequency is higher than > the current frequency, but not necessarily if the requested frequency > is lower than the current frequency. > > Without sending the extra IPIs, we will be breaking the ABI since if > we set userspace governor, and change the frequency of a core by > lowering it, then it will not reflect on the CPUs of the cores in the > quad.
What about cpufreq_policy->cpus/related_cpus? Am I missing something? > > Abhishek, > I think we can rework this by sending the extra IPIs only in the > presence of the quirk which can be indicated through a device-tree > parameter. If the future implementation fix this, then we won't need > the extra IPIs. Balbir Singh.
