Re: [v3 PATCH 3/3] powernv-cpufreq: Treat pstates as opaque 8-bit values
From: Balbir Singh <bsingharora@gmail.com>
Date: 2017-12-17 03:17:05
Also in:
linux-pm, lkml
On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy [off-list ref] wrote:
quoted hunk ↗ jump to hunk
From: "Gautham R. Shenoy" <redacted> On POWER8 and POWER9, the PMSR and the PMCR registers define pstates to be 8-bit wide values. The device-tree exports pstates as 32-bit wide values of which the lower byte is the actual pstate. The current implementation in the kernel treats pstates as integer type, since it used to use the sign of the pstate for performing some boundary-checks. This is no longer required after the patch "powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates". So, in this patch, we modify the powernv-cpufreq driver to uniformly treat pstates as opaque 8-bit values obtained from the device-tree or the PMCR. This simplifies the extract_pstate() helper function since we no longer no longer require to worry about the sign-extentions. Signed-off-by: Gautham R. Shenoy <redacted> --- drivers/cpufreq/powernv-cpufreq.c | 47 ++++++++++++++++----------------------- 1 file changed, 19 insertions(+), 28 deletions(-)diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c index 8e3dbca..8a4e2ce 100644 --- a/drivers/cpufreq/powernv-cpufreq.c +++ b/drivers/cpufreq/powernv-cpufreq.c@@ -110,12 +110,11 @@ struct global_pstate_info { * hashtable */ struct pstate_idx_revmap_data { - int pstate_id; + u8 pstate_id; unsigned int cpufreq_table_idx; struct hlist_node hentry; }; -u32 pstate_sign_prefix; static bool rebooting, throttled, occ_reset; static const char * const throttle_reason[] = {@@ -170,14 +169,9 @@ enum throttle_reason_type { bool wof_enabled; } powernv_pstate_info; -static inline int extract_pstate(u64 pmsr_val, unsigned int shift) +static inline u8 extract_pstate(u64 pmsr_val, unsigned int shift) { - int ret = ((pmsr_val >> shift) & 0xFF); - - if (!ret) - return ret; - - return (pstate_sign_prefix | ret); + return ((pmsr_val >> shift) & 0xFF); }
So we just added this and moved from an int to u8. I was going to ask if we still need an int in patch1, but I thought the driver dealt with just integers because of the larger framework. Balbir Singh.