On Fri, Nov 30, 2012 at 5:21 AM, Will Deacon <[email protected]> wrote: > On Thu, Nov 29, 2012 at 09:38:46PM +0000, Christoffer Dall wrote: >> On Mon, Nov 19, 2012 at 9:21 AM, Will Deacon <[email protected]> wrote: >> > On Sat, Nov 10, 2012 at 03:42:31PM +0000, Christoffer Dall wrote: >> >> Decoding the implementor and part number of the CPU id in the CPU ID >> >> register is needed by KVM, so we factor it out to share the code. >> >> >> >> Reviewed-by: Marcelo Tosatti <[email protected]> >> >> Signed-off-by: Christoffer Dall <[email protected]> > > [...] > >> >> +static inline unsigned int __attribute_const__ >> >> read_cpuid_implementor(void) >> >> +{ >> >> + return (read_cpuid_id() & 0xFF000000) >> 24; >> >> +} >> >> + >> >> +static inline unsigned int __attribute_const__ >> >> read_cpuid_part_number(void) >> >> +{ >> >> + return (read_cpuid_id() & 0xFFF0); >> >> +} >> > >> > Perhaps this should take the implementor as an argument, given that the >> > part number is described differently between implementors. The xscale >> > stuff can then move in here (we'll need to check the xscale docs in case >> > perf is using a subfield -- I can't remember off-hand). > > [...] > >> > If you stick this one in a separate patch, I can take it via the perf >> > tree (along with the CPUID rework above). >> > >> thanks, >> I sent a separate patch. > > Looks like we still have the ugly xscale cpuid parsing inline. Could you > move it as I suggested, please? > yes, sorry I missed that one. I went hunting through some old Xscale docs, but cannot find anything that specifies more details about the part number (or "product number" as intel calls it), so I preserved the existing bit parsing.
-Christoffer -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
