Message-Id: <1513148261-21097-1-git-send-email-ego@linux.vnet.ibm.com>
Date:   Wed, 13 Dec 2017 12:27:38 +0530
From:   "Gautham R. Shenoy" <ego@...ux.vnet.ibm.com>
To:     Shilpasri G Bhat <shilpa.bhat@...ux.vnet.ibm.com>,
        viresh.kumar@...aro.org, rjw@...ysocki.net,
        huntbag@...ux.vnet.ibm.com, akshay.adiga@...ux.vnet.ibm.com,
        Michael Ellerman <mpe@...erman.id.au>,
        Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
        Balbir Singh <bsingharora@...il.com>
Cc:     linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org,
        "Gautham R. Shenoy" <ego@...ux.vnet.ibm.com>
Subject: [v3 PATCH 0/3] powernv-cpufreq: Multiple pstate related fixes.

From: "Gautham R. Shenoy" <ego@...ux.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

Powered by blists - more mailing lists