Re: [v3 PATCH 3/3] powernv-cpufreq: Treat pstates as opaque 8-bit values

From: Gautham R Shenoy
Date: Mon Dec 18 2017 - 03:43:44 EST


Hi Balbir,

On Sun, Dec 17, 2017 at 02:17:02PM +1100, Balbir Singh wrote:
> On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy
[..snip..]
> >
> > -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.

The larger framework is with respect to the device tree which defines
pstates as 32-bit integers (I am not aware of the reasons for this
choice, but perhaps device-tree doesn't have a s8/u8 type?!). The
driver still knows that pstates are only 8-bits wide because of the
PMSR,PMCR definitions. Before this patch, the driver was still doing
the conversions from 8-bit to int and vice-versa every time. With this
patch, we do it only once, i.e at the initialization. After that we
treat pstates as 8-bit integers.


>
> Balbir Singh.
>