From: "Gautham R. Shenoy" <e...@linux.vnet.ibm.com> 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