[PATCH] powerpc: Export PIR data through sysfs

[PATCH] powerpc: Export PIR data through sysfs

[Ananth N Mavinakayanahalli]

The Processor Identification Register (PIR) on powerpc provides
information to decode the processor identification tag. Decoding
this information platform specfic.

Export PIR data via sysfs.

(Powerpc manuals state this register is 'optional'. I am not sure
though if there are any Linux supported powerpc platforms that
don't have it. Code in the kernel referencing PIR isn't under
a platform ifdef).

Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
---
 arch/powerpc/kernel/sysfs.c |    6 ++++++
 1 file changed, 6 insertions(+)

Index: linux-3.1/arch/powerpc/kernel/sysfs.c
===================================================================
--- linux-3.1.orig/arch/powerpc/kernel/sysfs.c
+++ linux-3.1/arch/powerpc/kernel/sysfs.c
@@ -177,11 +177,13 @@ SYSFS_PMCSETUP(mmcra, SPRN_MMCRA);
 SYSFS_PMCSETUP(purr, SPRN_PURR);
 SYSFS_PMCSETUP(spurr, SPRN_SPURR);
 SYSFS_PMCSETUP(dscr, SPRN_DSCR);
+SYSFS_PMCSETUP(pir, SPRN_PIR);
 
 static SYSDEV_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
 static SYSDEV_ATTR(spurr, 0600, show_spurr, NULL);
 static SYSDEV_ATTR(dscr, 0600, show_dscr, store_dscr);
 static SYSDEV_ATTR(purr, 0600, show_purr, store_purr);
+static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
 
 unsigned long dscr_default = 0;
 EXPORT_SYMBOL(dscr_default);
@@ -394,6 +396,8 @@ static void __cpuinit register_cpu_onlin
 		sysdev_create_file(s, &attr_dscr);
 #endif /* CONFIG_PPC64 */
 
+	sysdev_create_file(s, &attr_pir);
+
 	cacheinfo_cpu_online(cpu);
 }
 
@@ -464,6 +468,8 @@ static void unregister_cpu_online(unsign
 		sysdev_remove_file(s, &attr_dscr);
 #endif /* CONFIG_PPC64 */
 
+	sysdev_remove_file(s, &attr_pir);
+
 	cacheinfo_cpu_offline(cpu);
 }
 

Re: [PATCH] powerpc: Export PIR data through sysfs

[Scott Wood]

On 11/06/2011 10:47 PM, Ananth N Mavinakayanahalli wrote:
> The Processor Identification Register (PIR) on powerpc provides
> information to decode the processor identification tag. Decoding
> this information platform specfic.
> 
> Export PIR data via sysfs.
> 
> (Powerpc manuals state this register is 'optional'. I am not sure
> though if there are any Linux supported powerpc platforms that
> don't have it. Code in the kernel referencing PIR isn't under
> a platform ifdef).

Those references are in platform-specific files, under #ifdef
CONFIG_SMP, often in areas that would only be executed in the presence
of multiple CPUs (e.g. secondary release).  The reference in misc_32.S
is inside #ifdef CONFIG_KEXEC and is fairly recent -- it may not have
been tested on these systems.

I don't see PIR (other than in the acronym definition section) in
manuals for UP-only cores such as e300, 8xx, and 750.

What use does userspace have for this?  If you want to return the
currently executing CPU (which unless you're pinned could change as soon
as the value is read...), why not just return smp_processor_id() or
hard_smp_processor_id()?

-Scott

Re: [PATCH] powerpc: Export PIR data through sysfs

[Ananth N Mavinakayanahalli]

On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
> On 11/06/2011 10:47 PM, Ananth N Mavinakayanahalli wrote:
> > The Processor Identification Register (PIR) on powerpc provides
> > information to decode the processor identification tag. Decoding
> > this information platform specfic.
> > 
> > Export PIR data via sysfs.
> > 
> > (Powerpc manuals state this register is 'optional'. I am not sure
> > though if there are any Linux supported powerpc platforms that
> > don't have it. Code in the kernel referencing PIR isn't under
> > a platform ifdef).
> 
> Those references are in platform-specific files, under #ifdef
> CONFIG_SMP, often in areas that would only be executed in the presence
> of multiple CPUs (e.g. secondary release).  The reference in misc_32.S
> is inside #ifdef CONFIG_KEXEC and is fairly recent -- it may not have
> been tested on these systems.
> 
> I don't see PIR (other than in the acronym definition section) in
> manuals for UP-only cores such as e300, 8xx, and 750.

I saw that SPRN_PIR is defined for booke in reg_booke.h but wasn't sure
if it is applicable to all platforms. Thanks for the clarification.

> What use does userspace have for this?  If you want to return the
> currently executing CPU (which unless you're pinned could change as soon
> as the value is read...), why not just return smp_processor_id() or
> hard_smp_processor_id()?

Its not just the current cpu. Decoding PIR can tell you the core id,
thread id in case of SMT, and this information can be used by userspace
apps to set affinities, etc.

How does the following look?

Ananth
---

From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>

The Processor Identification Register (PIR) on powerpc provides
information to decode the processor identification tag. Decoding
this information platform specfic.

Export PIR data via sysfs.

Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
---
 arch/powerpc/kernel/sysfs.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

Index: linux-3.1/arch/powerpc/kernel/sysfs.c
===================================================================
--- linux-3.1.orig/arch/powerpc/kernel/sysfs.c
+++ linux-3.1/arch/powerpc/kernel/sysfs.c
@@ -330,6 +330,11 @@ static struct sysdev_attribute pa6t_attr
 #endif /* HAS_PPC_PMC_PA6T */
 #endif /* HAS_PPC_PMC_CLASSIC */
 
+#if defined(CONFIG_SMP) && defined(SPRN_PIR)
+SYSFS_PMCSETUP(pir, SPRN_PIR);
+static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
+#endif
+
 static void __cpuinit register_cpu_online(unsigned int cpu)
 {
 	struct cpu *c = &per_cpu(cpu_devices, cpu);
@@ -394,6 +399,10 @@ static void __cpuinit register_cpu_onlin
 		sysdev_create_file(s, &attr_dscr);
 #endif /* CONFIG_PPC64 */
 
+#if defined(CONFIG_SMP) && defined(SPRN_PIR)
+	sysdev_create_file(s, &attr_pir);
+#endif
+
 	cacheinfo_cpu_online(cpu);
 }
 
@@ -464,6 +473,10 @@ static void unregister_cpu_online(unsign
 		sysdev_remove_file(s, &attr_dscr);
 #endif /* CONFIG_PPC64 */
 
+#if defined(CONFIG_SMP) && defined(SPRN_PIR)
+	sysdev_remove_file(s, &attr_pir);
+#endif
+
 	cacheinfo_cpu_offline(cpu);
 }
 

Re: [PATCH] powerpc: Export PIR data through sysfs

[Scott Wood]

On 11/08/2011 12:58 AM, Ananth N Mavinakayanahalli wrote:
> On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
>> What use does userspace have for this?  If you want to return the
>> currently executing CPU (which unless you're pinned could change as soon
>> as the value is read...), why not just return smp_processor_id() or
>> hard_smp_processor_id()?
> 
> Its not just the current cpu. Decoding PIR can tell you the core id,
> thread id in case of SMT, and this information can be used by userspace
> apps to set affinities, etc.

Wouldn't it make more sense to expose the thread to core mappings in a
general way, not tied to hardware or what thread we're currently running on?

What's the use case for knowing this information only about the current
thread (or rather the state the current thread was in a few moments ago)?

> +#if defined(CONFIG_SMP) && defined(SPRN_PIR)
> +SYSFS_PMCSETUP(pir, SPRN_PIR);
> +static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
> +#endif

This only helps on architectures such as 8xx where you can't build as
SMP -- and I don't think #ifdef SPRN_PIR excludes any builds.

It doesn't help on chips like 750 or e300 where you can run a normal 6xx
SMP build, you just won't have multiple CPUs, and thus won't run things
like the secondary entry code.

-Scott

Re: [PATCH] powerpc: Export PIR data through sysfs

[Ananth N Mavinakayanahalli]

On Tue, Nov 08, 2011 at 10:59:46AM -0600, Scott Wood wrote:
> On 11/08/2011 12:58 AM, Ananth N Mavinakayanahalli wrote:
> > On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
> >> What use does userspace have for this?  If you want to return the
> >> currently executing CPU (which unless you're pinned could change as soon
> >> as the value is read...), why not just return smp_processor_id() or
> >> hard_smp_processor_id()?
> > 
> > Its not just the current cpu. Decoding PIR can tell you the core id,
> > thread id in case of SMT, and this information can be used by userspace
> > apps to set affinities, etc.
> 
> Wouldn't it make more sense to expose the thread to core mappings in a
> general way, not tied to hardware or what thread we're currently running on?

AFAIK, the information encoding in PIR is platform dependent. There is
no general way to expose this information unless you want have a
per-platform ifdef. Even then, I am not sure if that information will
generally be available or provided.

> What's the use case for knowing this information only about the current
> thread (or rather the state the current thread was in a few moments ago)?

Its not information about the thread but about the cpu. Unless you have
a shared LPAR environment, the data will be consistent and can be used
by applications with knowledge of the platform.

> > +#if defined(CONFIG_SMP) && defined(SPRN_PIR)
> > +SYSFS_PMCSETUP(pir, SPRN_PIR);
> > +static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
> > +#endif
> 
> This only helps on architectures such as 8xx where you can't build as
> SMP -- and I don't think #ifdef SPRN_PIR excludes any builds.
> 
> It doesn't help on chips like 750 or e300 where you can run a normal 6xx
> SMP build, you just won't have multiple CPUs, and thus won't run things
> like the secondary entry code.

Ugh! Booke builds seem to be fun :-)

I think this calls for a CPU_FTR_PIR. What do you suggest?

Ananth

Re: [PATCH] powerpc: Export PIR data through sysfs

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

On Tue, 2011-11-08 at 10:59 -0600, Scott Wood wrote:
> On 11/08/2011 12:58 AM, Ananth N Mavinakayanahalli wrote:
> > On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
> >> What use does userspace have for this?  If you want to return the
> >> currently executing CPU (which unless you're pinned could change as soon
> >> as the value is read...), why not just return smp_processor_id() or
> >> hard_smp_processor_id()?
> > 
> > Its not just the current cpu. Decoding PIR can tell you the core id,
> > thread id in case of SMT, and this information can be used by userspace
> > apps to set affinities, etc.
> 
> Wouldn't it make more sense to expose the thread to core mappings in a
> general way, not tied to hardware or what thread we're currently running on?

AFAIK that is already available in /sys/devices/system/cpu/cpuX/topology

cheers


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] powerpc: Export PIR data through sysfs

[Scott Wood]

On Wed, Nov 09, 2011 at 10:11:24AM +0530, Ananth N Mavinakayanahalli wrote:
> On Tue, Nov 08, 2011 at 10:59:46AM -0600, Scott Wood wrote:
> > On 11/08/2011 12:58 AM, Ananth N Mavinakayanahalli wrote:
> > > On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
> > >> What use does userspace have for this?  If you want to return the
> > >> currently executing CPU (which unless you're pinned could change as soon
> > >> as the value is read...), why not just return smp_processor_id() or
> > >> hard_smp_processor_id()?
> > > 
> > > Its not just the current cpu. Decoding PIR can tell you the core id,
> > > thread id in case of SMT, and this information can be used by userspace
> > > apps to set affinities, etc.
> > 
> > Wouldn't it make more sense to expose the thread to core mappings in a
> > general way, not tied to hardware or what thread we're currently running on?
> 
> AFAIK, the information encoding in PIR is platform dependent. There is
> no general way to expose this information unless you want have a
> per-platform ifdef. Even then, I am not sure if that information will
> generally be available or provided.
> 
> > What's the use case for knowing this information only about the current
> > thread (or rather the state the current thread was in a few moments ago)?
> 
> Its not information about the thread but about the cpu. Unless you have
> a shared LPAR environment, the data will be consistent and can be used
> by applications with knowledge of the platform.

I'm not sure what a "shared LPAR environment" is, but unless you're
pinned there's no guarantee the CPU you're running on once the read()
syscall returns is the same as the one that PIR was read on.  Do you mean
you're expecting this to be run from inside a partition that runs only on
one CPU, and thus whichever thread you'll be migrated to will have the
other data remain the same?

> > > +#if defined(CONFIG_SMP) && defined(SPRN_PIR)
> > > +SYSFS_PMCSETUP(pir, SPRN_PIR);
> > > +static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
> > > +#endif
> > 
> > This only helps on architectures such as 8xx where you can't build as
> > SMP -- and I don't think #ifdef SPRN_PIR excludes any builds.
> > 
> > It doesn't help on chips like 750 or e300 where you can run a normal 6xx
> > SMP build, you just won't have multiple CPUs, and thus won't run things
> > like the secondary entry code.
> 
> Ugh! Booke builds seem to be fun :-)

Those aren't booke.

> I think this calls for a CPU_FTR_PIR. What do you suggest?

Unless someone wants to test what actually happens when you read PIR on
all these CPUs...

What platform is this meant to be useful for?  Perhaps it could just be a
platform-specific sysfs entry?

-Scott

Re: [PATCH] powerpc: Export PIR data through sysfs

[Ananth N Mavinakayanahalli]

On Wed, Nov 09, 2011 at 09:48:25AM -0600, Scott Wood wrote:
> On Wed, Nov 09, 2011 at 10:11:24AM +0530, Ananth N Mavinakayanahalli wrote:
> > On Tue, Nov 08, 2011 at 10:59:46AM -0600, Scott Wood wrote:
> > > On 11/08/2011 12:58 AM, Ananth N Mavinakayanahalli wrote:
> > > > On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
> > > >> What use does userspace have for this?  If you want to return the
> > > >> currently executing CPU (which unless you're pinned could change as soon
> > > >> as the value is read...), why not just return smp_processor_id() or
> > > >> hard_smp_processor_id()?
> > > > 
> > > > Its not just the current cpu. Decoding PIR can tell you the core id,
> > > > thread id in case of SMT, and this information can be used by userspace
> > > > apps to set affinities, etc.
> > > 
> > > Wouldn't it make more sense to expose the thread to core mappings in a
> > > general way, not tied to hardware or what thread we're currently running on?
> > 
> > AFAIK, the information encoding in PIR is platform dependent. There is
> > no general way to expose this information unless you want have a
> > per-platform ifdef. Even then, I am not sure if that information will
> > generally be available or provided.
> > 
> > > What's the use case for knowing this information only about the current
> > > thread (or rather the state the current thread was in a few moments ago)?
> > 
> > Its not information about the thread but about the cpu. Unless you have
> > a shared LPAR environment, the data will be consistent and can be used
> > by applications with knowledge of the platform.
> 
> I'm not sure what a "shared LPAR environment" is, but unless you're
> pinned there's no guarantee the CPU you're running on once the read()
> syscall returns is the same as the one that PIR was read on.  Do you mean
> you're expecting this to be run from inside a partition that runs only on
> one CPU, and thus whichever thread you'll be migrated to will have the
> other data remain the same?

This will be used from a partition with a dedicated set of cpus and so
the data will remain consistent.

> > I think this calls for a CPU_FTR_PIR. What do you suggest?
> 
> Unless someone wants to test what actually happens when you read PIR on
> all these CPUs...
> 
> What platform is this meant to be useful for?  Perhaps it could just be a
> platform-specific sysfs entry?

Currently I only care about pseries and have tested the following patch
on them. I've therefore made the code similar to what currently exists
for other features unique to POWER.

Ananth
---

From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>

The Processor Identification Register (PIR) on some powerpc platforms
provides information to decode the processor identification tag.
Decoding this information is platform specific.

We currently need this information for POWERx processors and hence
follows a similar model as adopted for the other POWERx specific
features.

Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
---
 arch/powerpc/include/asm/cputable.h |    9 +++++----
 arch/powerpc/kernel/sysfs.c         |    8 ++++++++
 2 files changed, 13 insertions(+), 4 deletions(-)

Index: linux-3.2-rc1/arch/powerpc/include/asm/cputable.h
===================================================================
--- linux-3.2-rc1.orig/arch/powerpc/include/asm/cputable.h
+++ linux-3.2-rc1/arch/powerpc/include/asm/cputable.h
@@ -201,6 +201,7 @@ extern const char *powerpc_base_platform
 #define CPU_FTR_POPCNTB			LONG_ASM_CONST(0x0400000000000000)
 #define CPU_FTR_POPCNTD			LONG_ASM_CONST(0x0800000000000000)
 #define CPU_FTR_ICSWX			LONG_ASM_CONST(0x1000000000000000)
+#define CPU_FTR_PIR			LONG_ASM_CONST(0x2000000000000000)
 
 #ifndef __ASSEMBLY__
 
@@ -400,7 +401,7 @@ extern const char *powerpc_base_platform
 #define CPU_FTRS_POWER4	(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
 	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
 	    CPU_FTR_MMCRA | CPU_FTR_CP_USE_DCBTZ | \
-	    CPU_FTR_STCX_CHECKS_ADDRESS)
+	    CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_PIR)
 #define CPU_FTRS_PPC970	(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
 	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_201 | \
 	    CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA | \
@@ -408,19 +409,19 @@ extern const char *powerpc_base_platform
 	    CPU_FTR_HVMODE)
 #define CPU_FTRS_POWER5	(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
 	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
-	    CPU_FTR_MMCRA | CPU_FTR_SMT | \
+	    CPU_FTR_MMCRA | CPU_FTR_SMT | CPU_FTR_PIR | \
 	    CPU_FTR_COHERENT_ICACHE | CPU_FTR_PURR | \
 	    CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB)
 #define CPU_FTRS_POWER6 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
 	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
-	    CPU_FTR_MMCRA | CPU_FTR_SMT | \
+	    CPU_FTR_MMCRA | CPU_FTR_SMT | CPU_FTR_PIR | \
 	    CPU_FTR_COHERENT_ICACHE | \
 	    CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
 	    CPU_FTR_DSCR | CPU_FTR_UNALIGNED_LD_STD | \
 	    CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_CFAR)
 #define CPU_FTRS_POWER7 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
 	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_206 |\
-	    CPU_FTR_MMCRA | CPU_FTR_SMT | \
+	    CPU_FTR_MMCRA | CPU_FTR_SMT | CPU_FTR_PIR | \
 	    CPU_FTR_COHERENT_ICACHE | \
 	    CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
 	    CPU_FTR_DSCR | CPU_FTR_SAO  | CPU_FTR_ASYM_SMT | \
Index: linux-3.2-rc1/arch/powerpc/kernel/sysfs.c
===================================================================
--- linux-3.2-rc1.orig/arch/powerpc/kernel/sysfs.c
+++ linux-3.2-rc1/arch/powerpc/kernel/sysfs.c
@@ -177,11 +177,13 @@ SYSFS_PMCSETUP(mmcra, SPRN_MMCRA);
 SYSFS_PMCSETUP(purr, SPRN_PURR);
 SYSFS_PMCSETUP(spurr, SPRN_SPURR);
 SYSFS_PMCSETUP(dscr, SPRN_DSCR);
+SYSFS_PMCSETUP(pir, SPRN_PIR);
 
 static SYSDEV_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
 static SYSDEV_ATTR(spurr, 0600, show_spurr, NULL);
 static SYSDEV_ATTR(dscr, 0600, show_dscr, store_dscr);
 static SYSDEV_ATTR(purr, 0600, show_purr, store_purr);
+static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
 
 unsigned long dscr_default = 0;
 EXPORT_SYMBOL(dscr_default);
@@ -392,6 +394,9 @@ static void __cpuinit register_cpu_onlin
 
 	if (cpu_has_feature(CPU_FTR_DSCR))
 		sysdev_create_file(s, &attr_dscr);
+
+	if (cpu_has_feature(CPU_FTR_PIR))
+		sysdev_create_file(s, &attr_pir);
 #endif /* CONFIG_PPC64 */
 
 	cacheinfo_cpu_online(cpu);
@@ -462,6 +467,9 @@ static void unregister_cpu_online(unsign
 
 	if (cpu_has_feature(CPU_FTR_DSCR))
 		sysdev_remove_file(s, &attr_dscr);
+
+	if (cpu_has_feature(CPU_FTR_PIR))
+		sysdev_remove_file(s, &attr_pir);
 #endif /* CONFIG_PPC64 */
 
 	cacheinfo_cpu_offline(cpu);

Re: [PATCH] powerpc: Export PIR data through sysfs

[Benjamin Herrenschmidt]

On Thu, 2011-11-10 at 14:18 +0530, Ananth N Mavinakayanahalli wrote:

> 
> From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> 
> The Processor Identification Register (PIR) on some powerpc platforms
> provides information to decode the processor identification tag.
> Decoding this information is platform specific.
> 
> We currently need this information for POWERx processors and hence
> follows a similar model as adopted for the other POWERx specific
> features.

At this rate we're going to end up with no bits left for CPU features
way too quickly... Especially for something we only care about once at
boot time.

Wouldn't CPU_FTR_PPCAS_ARCH_V2 be a good enough test ?

Can you tell us a bit more about the real use for that feature ? I still
don't see what's the point of getting the underlying HW ID.

Cheers,
Ben.

> Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> ---
>  arch/powerpc/include/asm/cputable.h |    9 +++++----
>  arch/powerpc/kernel/sysfs.c         |    8 ++++++++
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> Index: linux-3.2-rc1/arch/powerpc/include/asm/cputable.h
> ===================================================================
> --- linux-3.2-rc1.orig/arch/powerpc/include/asm/cputable.h
> +++ linux-3.2-rc1/arch/powerpc/include/asm/cputable.h
> @@ -201,6 +201,7 @@ extern const char *powerpc_base_platform
>  #define CPU_FTR_POPCNTB			LONG_ASM_CONST(0x0400000000000000)
>  #define CPU_FTR_POPCNTD			LONG_ASM_CONST(0x0800000000000000)
>  #define CPU_FTR_ICSWX			LONG_ASM_CONST(0x1000000000000000)
> +#define CPU_FTR_PIR			LONG_ASM_CONST(0x2000000000000000)
>  
>  #ifndef __ASSEMBLY__
>  
> @@ -400,7 +401,7 @@ extern const char *powerpc_base_platform
>  #define CPU_FTRS_POWER4	(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
>  	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
>  	    CPU_FTR_MMCRA | CPU_FTR_CP_USE_DCBTZ | \
> -	    CPU_FTR_STCX_CHECKS_ADDRESS)
> +	    CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_PIR)
>  #define CPU_FTRS_PPC970	(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
>  	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_201 | \
>  	    CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA | \
> @@ -408,19 +409,19 @@ extern const char *powerpc_base_platform
>  	    CPU_FTR_HVMODE)
>  #define CPU_FTRS_POWER5	(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
>  	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
> -	    CPU_FTR_MMCRA | CPU_FTR_SMT | \
> +	    CPU_FTR_MMCRA | CPU_FTR_SMT | CPU_FTR_PIR | \
>  	    CPU_FTR_COHERENT_ICACHE | CPU_FTR_PURR | \
>  	    CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB)
>  #define CPU_FTRS_POWER6 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
>  	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
> -	    CPU_FTR_MMCRA | CPU_FTR_SMT | \
> +	    CPU_FTR_MMCRA | CPU_FTR_SMT | CPU_FTR_PIR | \
>  	    CPU_FTR_COHERENT_ICACHE | \
>  	    CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
>  	    CPU_FTR_DSCR | CPU_FTR_UNALIGNED_LD_STD | \
>  	    CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_CFAR)
>  #define CPU_FTRS_POWER7 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
>  	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_206 |\
> -	    CPU_FTR_MMCRA | CPU_FTR_SMT | \
> +	    CPU_FTR_MMCRA | CPU_FTR_SMT | CPU_FTR_PIR | \
>  	    CPU_FTR_COHERENT_ICACHE | \
>  	    CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
>  	    CPU_FTR_DSCR | CPU_FTR_SAO  | CPU_FTR_ASYM_SMT | \
> Index: linux-3.2-rc1/arch/powerpc/kernel/sysfs.c
> ===================================================================
> --- linux-3.2-rc1.orig/arch/powerpc/kernel/sysfs.c
> +++ linux-3.2-rc1/arch/powerpc/kernel/sysfs.c
> @@ -177,11 +177,13 @@ SYSFS_PMCSETUP(mmcra, SPRN_MMCRA);
>  SYSFS_PMCSETUP(purr, SPRN_PURR);
>  SYSFS_PMCSETUP(spurr, SPRN_SPURR);
>  SYSFS_PMCSETUP(dscr, SPRN_DSCR);
> +SYSFS_PMCSETUP(pir, SPRN_PIR);
>  
>  static SYSDEV_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
>  static SYSDEV_ATTR(spurr, 0600, show_spurr, NULL);
>  static SYSDEV_ATTR(dscr, 0600, show_dscr, store_dscr);
>  static SYSDEV_ATTR(purr, 0600, show_purr, store_purr);
> +static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
>  
>  unsigned long dscr_default = 0;
>  EXPORT_SYMBOL(dscr_default);
> @@ -392,6 +394,9 @@ static void __cpuinit register_cpu_onlin
>  
>  	if (cpu_has_feature(CPU_FTR_DSCR))
>  		sysdev_create_file(s, &attr_dscr);
> +
> +	if (cpu_has_feature(CPU_FTR_PIR))
> +		sysdev_create_file(s, &attr_pir);
>  #endif /* CONFIG_PPC64 */
>  
>  	cacheinfo_cpu_online(cpu);
> @@ -462,6 +467,9 @@ static void unregister_cpu_online(unsign
>  
>  	if (cpu_has_feature(CPU_FTR_DSCR))
>  		sysdev_remove_file(s, &attr_dscr);
> +
> +	if (cpu_has_feature(CPU_FTR_PIR))
> +		sysdev_remove_file(s, &attr_pir);
>  #endif /* CONFIG_PPC64 */
>  
>  	cacheinfo_cpu_offline(cpu);
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: Export PIR data through sysfs

[Ananth N Mavinakayanahalli]

On Fri, Nov 11, 2011 at 03:18:14PM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2011-11-10 at 14:18 +0530, Ananth N Mavinakayanahalli wrote:
> 
> > 
> > From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> > 
> > The Processor Identification Register (PIR) on some powerpc platforms
> > provides information to decode the processor identification tag.
> > Decoding this information is platform specific.
> > 
> > We currently need this information for POWERx processors and hence
> > follows a similar model as adopted for the other POWERx specific
> > features.
> 
> At this rate we're going to end up with no bits left for CPU features
> way too quickly... Especially for something we only care about once at
> boot time.
>
> Wouldn't CPU_FTR_PPCAS_ARCH_V2 be a good enough test ?

/me checks Cell manuals... yes, that test would be good enough. I will
cook up a patch to use this.
 
> Can you tell us a bit more about the real use for that feature ? I still
> don't see what's the point of getting the underlying HW ID.

This is a requirement from the hardware system test folks for use with
their core, node and thread tests.

Ananth

[PATCH V2] powerpc: Export PIR data through sysfs

[Ananth N Mavinakayanahalli]

On Fri, Nov 11, 2011 at 10:17:55AM +0530, Ananth N Mavinakayanahalli wrote:
> > 
> > At this rate we're going to end up with no bits left for CPU features
> > way too quickly... Especially for something we only care about once at
> > boot time.
> >
> > Wouldn't CPU_FTR_PPCAS_ARCH_V2 be a good enough test ?
> 
> /me checks Cell manuals... yes, that test would be good enough. I will
> cook up a patch to use this.

Here it is...
---

From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>

The Processor Identification Register (PIR) on some powerpc platforms
provides information to decode the processor identification tag that
can be used for node/core/thread affinity tests and for debugging.
Decoding this information is platform specific.

Export PIR contents through sysfs.

[V2] Use CPU_FTR_PPCAS_ARCH_V2 as a test for PIR's presence per
BenH's suggestion.

Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
---
 arch/powerpc/kernel/sysfs.c |    8 ++++++++
 1 file changed, 8 insertions(+)

Index: linux-3.2-rc1/arch/powerpc/kernel/sysfs.c
===================================================================
--- linux-3.2-rc1.orig/arch/powerpc/kernel/sysfs.c
+++ linux-3.2-rc1/arch/powerpc/kernel/sysfs.c
@@ -177,11 +177,13 @@ SYSFS_PMCSETUP(mmcra, SPRN_MMCRA);
 SYSFS_PMCSETUP(purr, SPRN_PURR);
 SYSFS_PMCSETUP(spurr, SPRN_SPURR);
 SYSFS_PMCSETUP(dscr, SPRN_DSCR);
+SYSFS_PMCSETUP(pir, SPRN_PIR);
 
 static SYSDEV_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
 static SYSDEV_ATTR(spurr, 0600, show_spurr, NULL);
 static SYSDEV_ATTR(dscr, 0600, show_dscr, store_dscr);
 static SYSDEV_ATTR(purr, 0600, show_purr, store_purr);
+static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
 
 unsigned long dscr_default = 0;
 EXPORT_SYMBOL(dscr_default);
@@ -392,6 +394,9 @@ static void __cpuinit register_cpu_onlin
 
 	if (cpu_has_feature(CPU_FTR_DSCR))
 		sysdev_create_file(s, &attr_dscr);
+
+	if (cpu_has_feature(CPU_FTR_PPCAS_ARCH_V2))
+		sysdev_create_file(s, &attr_pir);
 #endif /* CONFIG_PPC64 */
 
 	cacheinfo_cpu_online(cpu);
@@ -462,6 +467,9 @@ static void unregister_cpu_online(unsign
 
 	if (cpu_has_feature(CPU_FTR_DSCR))
 		sysdev_remove_file(s, &attr_dscr);
+
+	if (cpu_has_feature(CPU_FTR_PPCAS_ARCH_V2))
+		sysdev_remove_file(s, &attr_pir);
 #endif /* CONFIG_PPC64 */
 
 	cacheinfo_cpu_offline(cpu);