[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 6/9] x86/intel_pstate: the main boby of the intel_pstate driver
>>> On 08.06.15 at 03:47, <wei.w.wang@xxxxxxxxx> wrote: > On 26/05/2015 21:58, Jan Beulich wrote >> >>> On 13.05.16 at 09:50, <wei.w.wang@xxxxxxxxx> wrote: >> > +static int byt_get_min_pstate(void) >> > +{ >> > + u64 value; >> > + >> > + rdmsrl(BYT_RATIOS, value); >> > + return (value >> 8) & 0x7F; >> > +} >> > + >> > +static int byt_get_max_pstate(void) >> > +{ >> > + u64 value; >> > + >> > + rdmsrl(BYT_RATIOS, value); >> > + return (value >> 16) & 0x7F; >> > +} >> > + >> > +static int byt_get_turbo_pstate(void) { >> > + u64 value; >> > + >> > + rdmsrl(BYT_TURBO_RATIOS, value); >> > + return value & 0x7F; >> > +} >> > + >> > +static void byt_set_pstate(struct cpudata *cpudata, int pstate) { >> > + u64 val; >> > + int32_t vid_fp; >> > + u32 vid; >> > + >> > + val = pstate << 8; >> > + if (limits.no_turbo && !limits.turbo_disabled) >> > + val |= (u64)1 << 32; >> >> All of the literal numbers above (and there are more further down) would >> better become self-documenting manifest constants. > > I just realized that it would be better to remove these bay trail platform > related code. What do you think? First of all - why? Unless these are 32-bit only systems, I don't see why we wouldn't want to support Atoms at least on a best effort basis. And if you consider removal of code present in Linux, then this also needs to be done with the earlier mentioned "as little changes as possible compared to the Linux original" in mind. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |