From: "Gautham R. Shenoy"
This is a third version of the patch to fix pstate related issues in
the powernv-cpufreq driver.
The previous versions can be found here:
[v2]: https://lkml.org/lkml/2017/12/7/1562
[v1]: https://lkml.org/lkml/2017/11/29/1338
On POWERNV platform, Pstates are 8-bit values. On POWER8 they are
negatively numbered while on POWER9 they are positively
numbered. Thus, on POWER9, the maximum number of pstates could be as
high as 256.
In multiple places, the current code interprets pstates as a signed
8-bit value which subsequently gets assigned to a signed integer
variable. This causes a problem on POWER9 platforms which have more
than 128 pstates. On such systems, on a CPU that is in a lower
pstate whose number is greater than 128, querying the current pstate
via the pstate_to_idx() returns a "pstate X is out of bound" error
message and the current pstate is reported as the nominal
pstate. This is due to the manner in which the bounds are checked in
pstate_to_idx which again depends on the sign of pstates and whether
the pstates max to min are monotonically increasing or decreasing.
Further the current code makes a couple of assumptions which is not
guaranteed by the device-tree bindings:
1) Pstate ids are continguous.
2) Every Pstate should always lie between the max and the min
pstates that are explicitly reported in the device tree.
Both these assumptions are unwarranted and can change on future
platforms.
In this patch-series, we fix the implementation via the following
changes:
PATCH 1: Define a helper function to correctly extract the pstates
from the PMCR and take care of any sign extentions. This is
an immediate fix to add the ability to handle more than 128
pstates on POWER9 systems.
PATCH 2: Define a hash-map which will return the index into the
cpufreq frequency table for a given pstate. Use this hashmap
in the implementation of pstate_to_idx(). This does away with
the assumptions (1) mentioned above, and will work with non
continguous pstate ids. If no entry exists for a particular
pstate, then such a pstate is treated as being out of
bounds. This gets rid of assumption (2).
PATCH 3: Treat pstates as opaque 8-bit values consistent with the
definitions in the PMSR and PMCR. We no longer need any
sign-extentions nor do we require to interpret the sign of
the pstates anywhere in the code.
Gautham R. Shenoy (3):
powernv-cpufreq: Add helper to extract pstate from PMSR
powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates
powernv-cpufreq: Treat pstates as opaque 8-bit values
drivers/cpufreq/powernv-cpufreq.c | 139 --
1 file changed, 90 insertions(+), 49 deletions(-)
--
1.9.4
