[lkml]   [2017]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] cpufreq: powernv: Add support of frequency domain
On Tue, Dec 19, 2017 at 8:20 PM, Gautham R Shenoy
<> 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.

 \ /
  Last update: 2017-12-19 11:22    [W:0.069 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site