[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Eduardo Valentin]

Hello all,

Here is the version 5 of the change to export OMAP data to userspace
(name, revision, id code, production id and die id).

Basically, this version is still attempting to create a new file under /proc.
It is the /proc/socinfo, which should be used to export bits which are SoC specific
(not CPU related, nor machine related).

So, differences between previous version are:
- merged patch 02/04 with 03/04 to avoid compilation breakages.
- simplified the seq_file usage by using the single_open and single_release functions
- exported a function to register a seq_operation .show callback
- adapted the changes accordingly

As usual, comments are welcome.

BR,

-------------------------------------------------------------------------------
v4:

Here is the patch set to export OMAP id code, production id and die id.
The history of this change is as follows:

1. First attempt tried adding those data under sysfs node. Original patch by
Peter De Schrijver [1]. Then, it was suggested to move it to debugfs, which was
rejected as this info is actually needed in production systems.

2. Then it has been moved to /proc/cpuinfo [2]. Then, it was suggested to do
not add this kind of info there, as it is not really CPU data.

Now, I'm sending this version which will introduce first the /proc/socinfo.
Then, following patches will add OMAP data into that node. And finally,
will add OMAP id, production and die id code.

Just for reference, I'm also pasting the previous 0/4 message:

-------------------------------------------------------------------------------
v3:
I'm resending this series with minor change in the subject prefix of patch 4/4.
Removed the PM: prefix. Everything else is same. So, I kept the v3 prefix as well.

And now v3 of this series. Basically a minor change wrt string manipulation.
No need to use strlen in so many places. Previous log for reference:

-------------------------------------------------------------------------------
v2:

Here is the version 2 of this series. Now die id is protected using
same x86 protection mechanism to hide x86 product number. Besides,
a compilation Kconfig option has been added for DIE ID as well.

Here is previous PATCH 0/4 message:

-------------------------------------------------------------------------------
v1:

This series is to continue what has been discussed several weeks ago
wrt IDCODE patch. Original patch was made by Peter and discussion is here:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg17553.html

So, the conclusion was that IDCODE info is useful even in production systems,
and for that debugfs is not a good choice to export it. One suggestion was to
add it under /proc/cpuinfo. However this entry nowadays exports only ARM related
information.

So this series does the trick by extending the ARM /proc/cpuinfo to include
soc info data. There are a few ways to add a hook for soc specific data. But
I've decided to implement it via the simplest way I found. Basically it is
same thing which is done for system_rev, system_serial_low and system_serial_high.
Then, now we have system_soc_info, which is printed only if there is something
useful there.

As usual, comments are welcome.

-------------------------------------------------------------------------------
BR,

Eduardo Valentin (3):
  procfs: Introduce socinfo under /proc
  OMAP: export OMAP info under /proc/socinfo
  OMAP3: export chip IDCODE, Production ID and Die ID

 Documentation/filesystems/proc.txt  |    1 +
 Documentation/kernel-parameters.txt |    2 +
 arch/arm/Kconfig                    |    1 +
 arch/arm/mach-omap1/id.c            |   31 ++++++++++---
 arch/arm/mach-omap2/Kconfig         |   10 ++++
 arch/arm/mach-omap2/id.c            |   65 +++++++++++++++++++++++++---
 fs/proc/Kconfig                     |    7 +++
 fs/proc/Makefile                    |    1 +
 fs/proc/socinfo.c                   |   80 +++++++++++++++++++++++++++++++++++
 include/linux/socinfo.h             |   17 +++++++
 10 files changed, 202 insertions(+), 13 deletions(-)
 create mode 100644 fs/proc/socinfo.c
 create mode 100644 include/linux/socinfo.h

[PATCHv5 1/3] procfs: Introduce socinfo under /proc

[Eduardo Valentin]

From: Eduardo Valentin <eduardo.valentin@nokia.com>

This patch introduce the /proc/socinfo node. Its purpose is to
export System on Chip information and specific bits.

Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
---
 Documentation/filesystems/proc.txt |    1 +
 fs/proc/Kconfig                    |    7 +++
 fs/proc/Makefile                   |    1 +
 fs/proc/socinfo.c                  |   80 ++++++++++++++++++++++++++++++++++++
 include/linux/socinfo.h            |   17 ++++++++
 5 files changed, 106 insertions(+), 0 deletions(-)
 create mode 100644 fs/proc/socinfo.c
 create mode 100644 include/linux/socinfo.h

diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index a4f30fa..039bcb7 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -415,6 +415,7 @@ Table 1-5: Kernel info in /proc
  bus         Directory containing bus specific information     
  cmdline     Kernel command line                               
  cpuinfo     Info about the CPU                                
+ socinfo     Info about the System on Chip                     
  devices     Available devices (block and character)           
  dma         Used DMS channels                                 
  filesystems Supported filesystems                             
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 50f8f06..e683d62 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -67,3 +67,10 @@ config PROC_PAGE_MONITOR
 	  /proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
 	  /proc/kpagecount, and /proc/kpageflags. Disabling these
           interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_SOCINFO
+ 	default y
+	depends on PROC_FS
+	bool "Enable /proc/socinfo" if EMBEDDED
+ 	help
+	  Say Y here if you need to see information about the your System on Chip.
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 11a7b5c..7757d44 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -26,3 +26,4 @@ proc-$(CONFIG_PROC_VMCORE)	+= vmcore.o
 proc-$(CONFIG_PROC_DEVICETREE)	+= proc_devtree.o
 proc-$(CONFIG_PRINTK)	+= kmsg.o
 proc-$(CONFIG_PROC_PAGE_MONITOR)	+= page.o
+proc-$(CONFIG_PROC_SOCINFO)	+= socinfo.o
diff --git a/fs/proc/socinfo.c b/fs/proc/socinfo.c
new file mode 100644
index 0000000..09a889d
--- /dev/null
+++ b/fs/proc/socinfo.c
@@ -0,0 +1,80 @@
+/*
+ *  fs/proc/socinfo.c
+ *
+ *  Copyright (C) 2010 Nokia Corporation
+ *
+ *  Contact: Eduardo Valentin <eduardo.valentin@nokia.com>
+ *
+ *  proc socinfo file
+ */
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/init.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+#include <linux/socinfo.h>
+
+/*
+ * Function pointer to soc core code which knows how to grab soc info
+ */
+static int (*socinfo_show)(struct seq_file *, void *);
+static void *socinfo_data;
+static DEFINE_MUTEX(socinfo_mutex);
+
+/**
+ * register_socinfo_show() - register a call back to provide SoC information
+ * @show:	The function callback. It is expected to be in the same format
+ *		as the .show of struct seq_operations.
+ * @data:	A void * which will be passed as argument when show is called.
+ *
+ * This function will store the reference for a function and its data. The show
+ * argument will be called when filling up the seq_file of /proc/socinfo.
+ * Usually, this function should be called just once, while executing the SoC
+ * core initialization code.
+ */
+void register_socinfo_show(int (*show)(struct seq_file *, void *), void *data)
+{
+	mutex_lock(&socinfo_mutex);
+	socinfo_show = show;
+	socinfo_data = data;
+	mutex_unlock(&socinfo_mutex);
+}
+
+static int socinfo_show_local(struct seq_file *sfile, void *data)
+{
+	int r;
+
+	/* Just fall back to those who know how to grab the info */
+	mutex_lock(&socinfo_mutex);
+	if (socinfo_show)
+		r = socinfo_show(sfile, socinfo_data);
+	else
+		r = seq_printf(sfile, "No data\n");
+	mutex_unlock(&socinfo_mutex);
+
+	return r;
+}
+
+static int socinfo_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, socinfo_show_local, NULL);
+}
+
+static const struct file_operations proc_socinfo_operations = {
+	.owner		= THIS_MODULE,
+	.open		= socinfo_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= single_release,
+};
+
+static int __init proc_socinfo_init(void)
+{
+	if (!proc_create("socinfo", 0, NULL, &proc_socinfo_operations)) {
+		pr_info("Failed to create /proc/socinfo\n");
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+module_init(proc_socinfo_init);
diff --git a/include/linux/socinfo.h b/include/linux/socinfo.h
new file mode 100644
index 0000000..aa870f1
--- /dev/null
+++ b/include/linux/socinfo.h
@@ -0,0 +1,17 @@
+/*
+ *  include/linux/socinfo.h
+ *
+ *  Copyright (C) 2010 Nokia Corporation
+ *
+ *  Contact: Eduardo Valentin <eduardo.valentin@nokia.com>
+ *
+ *  proc socinfo file
+ */
+
+#ifndef __SOCINFO_H
+#define __SOCINFO_H
+
+#include <linux/seq_file.h>
+
+void register_socinfo_show(int (*show)(struct seq_file *, void *), void *data);
+#endif
-- 
1.7.0.4.361.g8b5fe.dirty

[PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo

[Eduardo Valentin]

From: Eduardo Valentin <eduardo.valentin@nokia.com>

Export OMAP name and rev under /proc/socinfo node.

Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
---
 arch/arm/Kconfig         |    1 +
 arch/arm/mach-omap1/id.c |   31 ++++++++++++++++++++++++-------
 arch/arm/mach-omap2/id.c |   32 ++++++++++++++++++++++++++------
 3 files changed, 51 insertions(+), 13 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 92622eb..fbd3c50 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -326,6 +326,7 @@ config ARCH_EP93XX
 	select COMMON_CLKDEV
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_HAS_HOLES_MEMORYMODEL
+	select PROC_SOC_INFO
 	help
 	  This enables support for the Cirrus EP93xx series of CPUs.
 
diff --git a/arch/arm/mach-omap1/id.c b/arch/arm/mach-omap1/id.c
index a0e3560..ef3caf1 100644
--- a/arch/arm/mach-omap1/id.c
+++ b/arch/arm/mach-omap1/id.c
@@ -15,6 +15,8 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/io.h>
+#include <linux/socinfo.h>
+#include <linux/seq_file.h>
 #include <plat/cpu.h>
 
 #define OMAP_DIE_ID_0		0xfffe1800
@@ -118,9 +120,21 @@ static u8 __init omap_get_die_rev(void)
 	return die_rev;
 }
 
+#define SOCINFO_SZ		128
+
+static int omap1_socinfo_show(struct seq_file *m, void *v)
+{
+	char *socinfo = v;
+
+	seq_printf(m, "SoC\t: %s\n", socinfo);
+
+	return 0;
+}
+
 void __init omap_check_revision(void)
 {
-	int i;
+	int i, sz;
+	char socinfo[SOCINFO_SZ];
 	u16 jtag_id;
 	u8 die_rev;
 	u32 omap_id;
@@ -194,11 +208,14 @@ void __init omap_check_revision(void)
 		printk(KERN_INFO "Unknown OMAP cpu type: 0x%02x\n", cpu_type);
 	}
 
-	printk(KERN_INFO "OMAP%04x", omap_revision >> 16);
+	sz = snprintf(socinfo, SOCINFO_SZ, "OMAP%04x", omap_revision >> 16);
 	if ((omap_revision >> 8) & 0xff)
-		printk(KERN_INFO "%x", (omap_revision >> 8) & 0xff);
-	printk(KERN_INFO " revision %i handled as %02xxx id: %08x%08x\n",
-	       die_rev, omap_revision & 0xff, system_serial_low,
-	       system_serial_high);
+		snprintf(socinfo + sz, SOCINFO_SZ - sz, "%x",
+						(omap_revision >> 8) & 0xff);
+	pr_info("%s revision %i handled as %02xxx id: %08x%08x\n",
+		socinfo, die_rev, omap_revision & 0xff, system_serial_low,
+		system_serial_high);
+
+	/* register function to show SoC info under /proc/socinfo */
+	register_socinfo_show(omap1_socinfo_show, kstrdup(socinfo, GFP_KERNEL));
 }
-
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37b8a1a..b67486b 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6 +18,8 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/io.h>
+#include <linux/socinfo.h>
+#include <linux/seq_file.h>
 
 #include <asm/cputype.h>
 
@@ -101,10 +103,12 @@ static struct omap_id omap_ids[] __initdata = {
 
 static void __iomem *tap_base;
 static u16 tap_prod_id;
+#define SOCINFO_SZ		128
+static char socinfo[SOCINFO_SZ];
 
 void __init omap24xx_check_revision(void)
 {
-	int i, j;
+	int i, j, sz;
 	u32 idcode, prod_id;
 	u16 hawkeye;
 	u8  dev_type, rev;
@@ -152,10 +156,11 @@ void __init omap24xx_check_revision(void)
 		j = i;
 	}
 
-	pr_info("OMAP%04x", omap_rev() >> 16);
+	sz = snprintf(socinfo, SOCINFO_SZ, "OMAP%04x", omap_rev() >> 16);
 	if ((omap_rev() >> 8) & 0x0f)
-		pr_info("ES%x", (omap_rev() >> 12) & 0xf);
-	pr_info("\n");
+		snprintf(socinfo + sz, SOCINFO_SZ - sz, "ES%x",
+						(omap_rev() >> 12) & 0xf);
+	pr_info("%s\n", socinfo);
 }
 
 #define OMAP3_CHECK_FEATURE(status,feat)				\
@@ -286,7 +291,9 @@ void __init omap4_check_revision(void)
 	if ((hawkeye == 0xb852) && (rev == 0x0)) {
 		omap_revision = OMAP4430_REV_ES1_0;
 		omap_chip.oc |= CHIP_IS_OMAP4430ES1;
-		pr_info("OMAP%04x %s\n", omap_rev() >> 16, rev_name);
+		snprintf(socinfo, SOCINFO_SZ, "OMAP%04x %s\n",
+				omap_rev() >> 16, rev_name);
+		pr_info("%s\n", socinfo);
 		return;
 	}
 
@@ -356,7 +363,8 @@ void __init omap3_cpuinfo(void)
 	}
 
 	/* Print verbose information */
-	pr_info("%s ES%s (", cpu_name, cpu_rev);
+	snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
+	pr_info("%s (", socinfo);
 
 	OMAP3_SHOW_FEATURE(l2cache);
 	OMAP3_SHOW_FEATURE(iva);
@@ -368,6 +376,15 @@ void __init omap3_cpuinfo(void)
 	printk(")\n");
 }
 
+static int omap_socinfo_show(struct seq_file *m, void *v)
+{
+	char *socinfop = v;
+
+	seq_printf(m, "SoC\t: %s\n", socinfop);
+
+	return 0;
+}
+
 /*
  * Try to detect the exact revision of the omap we're running on
  */
@@ -391,6 +408,9 @@ void __init omap2_check_revision(void)
 		pr_err("OMAP revision unknown, please fix!\n");
 	}
 
+	/* also register call back to report SoC data under /proc/socinfo */
+	register_socinfo_show(omap_socinfo_show, socinfo);
+
 	/*
 	 * OK, now we know the exact revision. Initialize omap_chip bits
 	 * for powerdowmain and clockdomain code.
-- 
1.7.0.4.361.g8b5fe.dirty

Re: [PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo

[Nishanth Menon]

Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following:
> From: Eduardo Valentin <eduardo.valentin@nokia.com>
> 
> Export OMAP name and rev under /proc/socinfo node.
> 
> Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
> ---
>  arch/arm/Kconfig         |    1 +
>  arch/arm/mach-omap1/id.c |   31 ++++++++++++++++++++++++-------
>  arch/arm/mach-omap2/id.c |   32 ++++++++++++++++++++++++++------
>  3 files changed, 51 insertions(+), 13 deletions(-)
> 
[..]

> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 37b8a1a..b67486b 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
[..]

> @@ -356,7 +363,8 @@ void __init omap3_cpuinfo(void)
>  	}
>  
>  	/* Print verbose information */
> -	pr_info("%s ES%s (", cpu_name, cpu_rev);
> +	snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
> +	pr_info("%s (", socinfo);
>  
>  	OMAP3_SHOW_FEATURE(l2cache);
>  	OMAP3_SHOW_FEATURE(iva);
Just a minor comment -> is it a good idea to pushin the features to SOC 
info as well? currently this is being displayed at bootlog and not 
beyond.. might be a better approach to move it into socinfo..


[..]

-- 
Regards,
Nishanth Menon

Re: [PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo

[Eduardo Valentin]

Hello Nishanth,

On Tue, May 11, 2010 at 04:28:15PM +0200, ext Nishanth Menon wrote:
> Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following:
> > From: Eduardo Valentin <eduardo.valentin@nokia.com>
> > 
> > Export OMAP name and rev under /proc/socinfo node.
> > 
> > Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
> > ---
> >  arch/arm/Kconfig         |    1 +
> >  arch/arm/mach-omap1/id.c |   31 ++++++++++++++++++++++++-------
> >  arch/arm/mach-omap2/id.c |   32 ++++++++++++++++++++++++++------
> >  3 files changed, 51 insertions(+), 13 deletions(-)
> > 
> [..]
> 
> > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> > index 37b8a1a..b67486b 100644
> > --- a/arch/arm/mach-omap2/id.c
> > +++ b/arch/arm/mach-omap2/id.c
> [..]
> 
> > @@ -356,7 +363,8 @@ void __init omap3_cpuinfo(void)
> >  	}
> >  
> >  	/* Print verbose information */
> > -	pr_info("%s ES%s (", cpu_name, cpu_rev);
> > +	snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
> > +	pr_info("%s (", socinfo);
> >  
> >  	OMAP3_SHOW_FEATURE(l2cache);
> >  	OMAP3_SHOW_FEATURE(iva);
> Just a minor comment -> is it a good idea to pushin the features to SOC 
> info as well? currently this is being displayed at bootlog and not 
> beyond.. might be a better approach to move it into socinfo..

Yeah. I would expect that someone would ask this. When I was writing this part
I also thought that would be nice to just duplicate all info which is printed
into kernel log buffer. But then I decided to proceed with only the info we are
needing from userspace. If you think that would be useful to know those as well,
then why not adding them.

> 
> 
> [..]
> 
> -- 
> Regards,
> Nishanth Menon

Re: [PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo

[Eduardo Valentin]

Hello,

On Tue, May 11, 2010 at 06:58:46PM +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote:
> Hello Nishanth,
> 
> On Tue, May 11, 2010 at 04:28:15PM +0200, ext Nishanth Menon wrote:
> > Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following:
> > > From: Eduardo Valentin <eduardo.valentin@nokia.com>
> > > 
> > > Export OMAP name and rev under /proc/socinfo node.
> > > 
> > > Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
> > > ---
> > >  arch/arm/Kconfig         |    1 +
> > >  arch/arm/mach-omap1/id.c |   31 ++++++++++++++++++++++++-------
> > >  arch/arm/mach-omap2/id.c |   32 ++++++++++++++++++++++++++------
> > >  3 files changed, 51 insertions(+), 13 deletions(-)
> > > 
> > [..]
> > 
> > > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> > > index 37b8a1a..b67486b 100644
> > > --- a/arch/arm/mach-omap2/id.c
> > > +++ b/arch/arm/mach-omap2/id.c
> > [..]
> > 
> > > @@ -356,7 +363,8 @@ void __init omap3_cpuinfo(void)
> > >  	}
> > >  
> > >  	/* Print verbose information */
> > > -	pr_info("%s ES%s (", cpu_name, cpu_rev);
> > > +	snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
> > > +	pr_info("%s (", socinfo);
> > >  
> > >  	OMAP3_SHOW_FEATURE(l2cache);
> > >  	OMAP3_SHOW_FEATURE(iva);
> > Just a minor comment -> is it a good idea to pushin the features to SOC 
> > info as well? currently this is being displayed at bootlog and not 
> > beyond.. might be a better approach to move it into socinfo..
> 
> Yeah. I would expect that someone would ask this. When I was writing this part
> I also thought that would be nice to just duplicate all info which is printed
> into kernel log buffer. But then I decided to proceed with only the info we are
> needing from userspace. If you think that would be useful to know those as well,
> then why not adding them.

As discussed in #linux-omap IRC channel, we agreed that it would be nice and useful
to export the OMAP FEATURES under this interface. But as the code to detect omap features is
under re-work currently, for now we are going to leave it out of this patch set.

> 
> > 
> > 
> > [..]
> > 
> > -- 
> > Regards,
> > Nishanth Menon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo

[Nishanth Menon]

Eduardo Valentin had written, on 05/12/2010 07:34 AM, the following:
> Hello,
> 
> On Tue, May 11, 2010 at 06:58:46PM +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote:
>> Hello Nishanth,
>>
>> On Tue, May 11, 2010 at 04:28:15PM +0200, ext Nishanth Menon wrote:
>>> Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following:
>>>> From: Eduardo Valentin <eduardo.valentin@nokia.com>
>>>>
>>>> Export OMAP name and rev under /proc/socinfo node.
>>>>
>>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
>>>> ---
>>>>  arch/arm/Kconfig         |    1 +
>>>>  arch/arm/mach-omap1/id.c |   31 ++++++++++++++++++++++++-------
>>>>  arch/arm/mach-omap2/id.c |   32 ++++++++++++++++++++++++++------
>>>>  3 files changed, 51 insertions(+), 13 deletions(-)
>>>>
>>> [..]
>>>
>>>> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
>>>> index 37b8a1a..b67486b 100644
>>>> --- a/arch/arm/mach-omap2/id.c
>>>> +++ b/arch/arm/mach-omap2/id.c
>>> [..]
>>>
>>>> @@ -356,7 +363,8 @@ void __init omap3_cpuinfo(void)
>>>>  	}
>>>>  
>>>>  	/* Print verbose information */
>>>> -	pr_info("%s ES%s (", cpu_name, cpu_rev);
>>>> +	snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
>>>> +	pr_info("%s (", socinfo);
>>>>  
>>>>  	OMAP3_SHOW_FEATURE(l2cache);
>>>>  	OMAP3_SHOW_FEATURE(iva);
>>> Just a minor comment -> is it a good idea to pushin the features to SOC 
>>> info as well? currently this is being displayed at bootlog and not 
>>> beyond.. might be a better approach to move it into socinfo..
>> Yeah. I would expect that someone would ask this. When I was writing this part
>> I also thought that would be nice to just duplicate all info which is printed
>> into kernel log buffer. But then I decided to proceed with only the info we are
>> needing from userspace. If you think that would be useful to know those as well,
>> then why not adding them.
> 
> As discussed in #linux-omap IRC channel, we agreed that it would be nice and useful
> to export the OMAP FEATURES under this interface. But as the code to detect omap features is
> under re-work currently, for now we are going to leave it out of this patch set.
> 
Agreed. other than this, I dont see an issue :) thanks for the work..

Acked-by: Nishanth Menon <nm@ti.com>

>>>
>>> [..]
>>>
>>> -- 
>>> Regards,
>>> Nishanth Menon
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/


-- 
Regards,
Nishanth Menon

[PATCHv5 3/3] OMAP3: export chip IDCODE, Production ID and Die ID

[Eduardo Valentin]

From: Eduardo Valentin <eduardo.valentin@nokia.com>

This patch exports the OMAP3 IDCODE and Production ID to userspace
via /proc/socinfo.

Die ID is also exported depending on what users pass as kernel
parameter. It is same protection mechanism made for x86 product
number. So, if user passes "omap3_die_id" parameter, it will append
die id code into /proc/socinfo as well. A Kconfig option has been
added as well, so it can be configurable during compilation time.

This can be used to track down silicon specific issues. The info is
exported via /proc/socinfo because then it can be possible to include this
in corematic dumps.

This is based on Peter De Schrijver patch, which export same info via sysfs.

Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
---
 Documentation/kernel-parameters.txt |    2 ++
 arch/arm/mach-omap2/Kconfig         |   10 ++++++++++
 arch/arm/mach-omap2/id.c            |   35 ++++++++++++++++++++++++++++++++++-
 3 files changed, 46 insertions(+), 1 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 839b21b..8010cfb 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1809,6 +1809,8 @@ and is between 256 and 4096 characters. It is defined in the file
 			waiting for the ACK, so if this is set too high
 			interrupts *may* be lost!
 
+	omap3_die_id	[OMAP] Append DIE ID info under /proc/socinfo
+
 	omap_mux=	[OMAP] Override bootloader pin multiplexing.
 			Format: <mux_mode0.mode_name=value>...
 			For example, to override I2C bus2:
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 2455dcc..fb8abed 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -169,3 +169,13 @@ config OMAP3_SDRC_AC_TIMING
 	  wish to say no.  Selecting yes without understanding what is
 	  going on could result in system crashes;
 
+config OMAP3_EXPORT_DIE_ID
+	bool "Export DIE ID code under /proc/socinfo"
+	depends on ARCH_OMAP3
+	default n
+	help
+	  Say Y here if you need DIE ID code to be exported via /proc/socinfo
+	  in production systems. You will need also to explicitly flag it by
+	  appending the "omap3_die_id" parameter to your boot command line.
+
+
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index b67486b..b4f5630 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -78,6 +78,10 @@ EXPORT_SYMBOL(omap_type);
 /*----------------------------------------------------------------------------*/
 
 #define OMAP_TAP_IDCODE		0x0204
+#define OMAP_TAP_PROD_ID_0      0x0208
+#define OMAP_TAP_PROD_ID_1      0x020c
+#define OMAP_TAP_PROD_ID_2      0x0210
+#define OMAP_TAP_PROD_ID_3      0x0214
 #define OMAP_TAP_DIE_ID_0	0x0218
 #define OMAP_TAP_DIE_ID_1	0x021C
 #define OMAP_TAP_DIE_ID_2	0x0220
@@ -306,6 +310,7 @@ void __init omap4_check_revision(void)
 
 void __init omap3_cpuinfo(void)
 {
+	int sz;
 	u8 rev = GET_OMAP_REVISION();
 	char cpu_name[16], cpu_rev[16];
 
@@ -363,7 +368,7 @@ void __init omap3_cpuinfo(void)
 	}
 
 	/* Print verbose information */
-	snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
+	sz = snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
 	pr_info("%s (", socinfo);
 
 	OMAP3_SHOW_FEATURE(l2cache);
@@ -374,7 +379,35 @@ void __init omap3_cpuinfo(void)
 	OMAP3_SHOW_FEATURE(192mhz_clk);
 
 	printk(")\n");
+
+	/* Append OMAP3 IDCODE and Production ID to /proc/socinfo */
+	snprintf(socinfo + sz, SOCINFO_SZ - sz,
+			"\nIDCODE\t: %08x\nPr. ID\t: %08x %08x %08x %08x",
+			read_tap_reg(OMAP_TAP_IDCODE),
+			read_tap_reg(OMAP_TAP_PROD_ID_0),
+			read_tap_reg(OMAP_TAP_PROD_ID_1),
+			read_tap_reg(OMAP_TAP_PROD_ID_2),
+			read_tap_reg(OMAP_TAP_PROD_ID_3));
+
+}
+
+#ifdef CONFIG_OMAP3_EXPORT_DIE_ID
+static int __init omap3_die_id_setup(char *s)
+{
+	int sz;
+
+	sz = strlen(socinfo);
+	snprintf(socinfo + sz, SOCINFO_SZ - sz,
+			"\nDie ID\t: %08x %08x %08x %08x",
+			read_tap_reg(OMAP_TAP_DIE_ID_0),
+			read_tap_reg(OMAP_TAP_DIE_ID_1),
+			read_tap_reg(OMAP_TAP_DIE_ID_2),
+			read_tap_reg(OMAP_TAP_DIE_ID_3));
+
+	return 1;
 }
+__setup("omap3_die_id", omap3_die_id_setup);
+#endif
 
 static int omap_socinfo_show(struct seq_file *m, void *v)
 {
-- 
1.7.0.4.361.g8b5fe.dirty

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Andrew Morton]

On Tue, 11 May 2010 17:15:28 +0300
Eduardo Valentin <eduardo.valentin@nokia.com> wrote:

> Here is the version 5 of the change to export OMAP data to userspace
> (name, revision, id code, production id and die id).
> 
> Basically, this version is still attempting to create a new file under /proc.
> It is the /proc/socinfo, which should be used to export bits which are SoC specific
> (not CPU related, nor machine related).
> 
> So, differences between previous version are:
> - merged patch 02/04 with 03/04 to avoid compilation breakages.
> - simplified the seq_file usage by using the single_open and single_release functions
> - exported a function to register a seq_operation .show callback
> - adapted the changes accordingly
> 
> As usual, comments are welcome.

This changelog would be rather more useful if it was to show us some
sample output from /proc/socinfo, perhaps accompanied with an
explanation for people who aren't familar with this area of the kernel.

I'd have thought that sysfs was an appropriate place for this info. 
Perhaps under /sys/devices/platform?  Or /sys/devices/system?  Peter's
original patch didn't tell us where in the hierarchy the file was
placed, nor why it was placed there, not what its contents look like. 
But crappy changelogs are the norm :(

The objections stated in this email:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg17630.html
appear to still apply to this version of the patches?

Kevin didn't explain why he said "Please export these via debugfs". 
Tony didn't clearly explain why he said "I don't think we want to
export unique chip identifiers by default".



So apart from having certain opinions regarding communication skills
and wondering why people cc me on stuff without vaguely providing
enough info for me to understand what they're thinking, I don't know
what to make of it all :(

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Eduardo Valentin]

Hello Andrew,

On Thu, May 13, 2010 at 12:24:24AM +0200, Andrew Morton wrote:
> On Tue, 11 May 2010 17:15:28 +0300
> Eduardo Valentin <eduardo.valentin@nokia.com> wrote:
> 
> > Here is the version 5 of the change to export OMAP data to userspace
> > (name, revision, id code, production id and die id).
> > 
> > Basically, this version is still attempting to create a new file under /proc.
> > It is the /proc/socinfo, which should be used to export bits which are SoC specific
> > (not CPU related, nor machine related).
> > 
> > So, differences between previous version are:
> > - merged patch 02/04 with 03/04 to avoid compilation breakages.
> > - simplified the seq_file usage by using the single_open and single_release functions
> > - exported a function to register a seq_operation .show callback
> > - adapted the changes accordingly
> > 
> > As usual, comments are welcome.
> 
> This changelog would be rather more useful if it was to show us some
> sample output from /proc/socinfo, perhaps accompanied with an
> explanation for people who aren't familar with this area of the kernel.

Indeed. So, after applying this series, one example of output would be,
in case of OMAP3:

/ # cat /proc/socinfo
SoC     : OMAP3430 ES3.1
IDCODE  : 4b7ae02f
Pr. ID  : 00000000 00000000 000000cc cafeb7ae

These ids can be used, for instance, to track down silicon specific issues.

> 
> I'd have thought that sysfs was an appropriate place for this info. 
> Perhaps under /sys/devices/platform?  Or /sys/devices/system?  Peter's
> original patch didn't tell us where in the hierarchy the file was
> placed, nor why it was placed there, not what its contents look like. 
> But crappy changelogs are the norm :(

IIRC, originally, Peter's patch was creating /sys/power/idcode. The content
was very similar:


Nokia-N900:~# cat /sys/power/idcode 
IDCODE: 4b7ae02f
Production ID: 00000000 00000000 000000cc cafeb7ae
Die ID: 05018019 04033312 00000000 54500024


> 
> The objections stated in this email:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg17630.html
> appear to still apply to this version of the patches?

Yeah, it is not applied on all IDs actually. At some point, the complain has changed.
More recently, Tony complained about Die ID:
http://marc.info/?l=linux-omap&m=127230649306842&w=2

And that's what is in patch 03/03 of this series. So, there are two things:
1. A separated config option to have DIE ID code in
2. User also have to explicitly pass the omap3_die_id kernel parameter.
Just like the "serialnumber" parameter for x86's.

Once the user has a kernel with CONFIG_OMAP3_EXPORT_DIE_ID and boots it with omap3_die_id parameter,
the first output I posted above would also include die id:

/ # cat /proc/socinfo 
SoC     : OMAP3430 ES3.1
IDCODE  : 4b7ae02f
Pr. ID  : 00000000 00000000 000000cc cafeb7ae
Die ID	: 05018019 04033312 00000000 54500024


> 
> Kevin didn't explain why he said "Please export these via debugfs". 
> Tony didn't clearly explain why he said "I don't think we want to
> export unique chip identifiers by default".
> 
> 
> 
> So apart from having certain opinions regarding communication skills
> and wondering why people cc me on stuff without vaguely providing
> enough info for me to understand what they're thinking, I don't know
> what to make of it all :(

Yeah, I agree here that there are some piece of info missing here and there.
Anyways, I believe the main point here is what is the best place to export these bits.

Originally was under sysfs (maybe not the correct place: /sys/power/idcode). Then I suggested
to move it to /proc/cpuinfo, which has been denied because these bits do not belong to CPU.
Then, it has been suggested to be under /proc/socinfo, which is the current version.
Now, I think your suggestion is to move back to sysfs, but under sys/devices/platform or /sys/devices/system, right ?



Thanks for your comments,

--
Eduardo Valentin

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Tony Lindgren]

* Andrew Morton <akpm@linux-foundation.org> [100512 15:19]:
> 
> I'd have thought that sysfs was an appropriate place for this info. 
> Perhaps under /sys/devices/platform?  Or /sys/devices/system?  Peter's
> original patch didn't tell us where in the hierarchy the file was
> placed, nor why it was placed there, not what its contents look like. 
> But crappy changelogs are the norm :(

To me both proc and sys work, I'm fine either way.
 
> The objections stated in this email:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg17630.html
> appear to still apply to this version of the patches?
>
> Kevin didn't explain why he said "Please export these via debugfs". 
> Tony didn't clearly explain why he said "I don't think we want to
> export unique chip identifiers by default".
 
The issue I had was with the unique silicon ID getting exposed
by default to avoid the Pentium id number situation :)

It's now handled with a Kconfig and cmdline option, basically the
same way as the id on x86. So the issues in the email thread
above are sorted out.

Regards,

Tony 

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Linus Walleij]

2010/5/11 Eduardo Valentin <eduardo.valentin@nokia.com>:

> Here is the version 5 of the change to export OMAP data to userspace
> (name, revision, id code, production id and die id).
>
> Basically, this version is still attempting to create a new file under /proc.
> It is the /proc/socinfo, which should be used to export bits which are SoC specific
> (not CPU related, nor machine related).
>
> So, differences between previous version are:
> - merged patch 02/04 with 03/04 to avoid compilation breakages.
> - simplified the seq_file usage by using the single_open and single_release functions
> - exported a function to register a seq_operation .show callback
> - adapted the changes accordingly
>
> As usual, comments are welcome.

Eduardo, what has happened to this patchset?

Now we need something similar for arch/arm/mach-ux500 and I was sort of
hoping that this infrastructure would be in place already... wrong I was.

Do you want help in picking it up and try to polish it up?

Yours,
Linus Walleij

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Eduardo Valentin]

Hello Linus,

On Tue, Feb 15, 2011 at 01:58:00PM +0100, ext Linus Walleij wrote:
> 2010/5/11 Eduardo Valentin <eduardo.valentin@nokia.com>:
> 
> > Here is the version 5 of the change to export OMAP data to userspace
> > (name, revision, id code, production id and die id).
> >
> > Basically, this version is still attempting to create a new file under /proc.
> > It is the /proc/socinfo, which should be used to export bits which are SoC specific
> > (not CPU related, nor machine related).
> >
> > So, differences between previous version are:
> > - merged patch 02/04 with 03/04 to avoid compilation breakages.
> > - simplified the seq_file usage by using the single_open and single_release functions
> > - exported a function to register a seq_operation .show callback
> > - adapted the changes accordingly
> >
> > As usual, comments are welcome.
> 
> Eduardo, what has happened to this patchset?

Got forgotten :-(. Unfortunately I didn't pushed it hard enough.

> 
> Now we need something similar for arch/arm/mach-ux500 and I was sort of
> hoping that this infrastructure would be in place already... wrong I was.

Right.

> 
> Do you want help in picking it up and try to polish it up?

Yeah, but it would need a refactoring. IIRC, result of last discussion was that
we should not mess with /proc. So, maybe moving back to something under sysfs.
Perhaps /sys/devices/soc or so?

> 
> Yours,
> Linus Walleij

-- 
Eduardo Valentin

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Maxime Coquelin]

Hello Eduardo,

On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
> Hello Linus,
>
> On Tue, Feb 15, 2011 at 01:58:00PM +0100, ext Linus Walleij wrote:
>> 2010/5/11 Eduardo Valentin<eduardo.valentin@nokia.com>:
>>
>>> Here is the version 5 of the change to export OMAP data to userspace
>>> (name, revision, id code, production id and die id).
>>>
>>> Basically, this version is still attempting to create a new file under /proc.
>>> It is the /proc/socinfo, which should be used to export bits which are SoC specific
>>> (not CPU related, nor machine related).
>>>
>>> So, differences between previous version are:
>>> - merged patch 02/04 with 03/04 to avoid compilation breakages.
>>> - simplified the seq_file usage by using the single_open and single_release functions
>>> - exported a function to register a seq_operation .show callback
>>> - adapted the changes accordingly
>>>
>>> As usual, comments are welcome.
>> Eduardo, what has happened to this patchset?
> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
  I propose to refactor your patchset, moving from procfs to sysfs.
>> Do you want help in picking it up and try to polish it up?
> Yeah, but it would need a refactoring. IIRC, result of last discussion was that
> we should not mess with /proc. So, maybe moving back to something under sysfs.
> Perhaps /sys/devices/soc or so?
About the location of this new sysfs entry, where do you think it should be?
I propose to create a new directory named "soc" in /sys/devices/system/.

As platform vendors have several/different kind of IDs to export to 
sysfs, I propose each vendor to create file entries related to their IDs 
(eg. /sys/devices/system/soc/idcode for OMAP platforms).

However, I think we should have a common file entry to export the unique 
ID of the platforms. Indeed, user-space applications should have a 
unified way to get this kind of ID, regardless of the platform (eg. 
/sys/devices/system/soc/unique_id).

Do you agree with my proposal?

Thanks for your comments.

Regards,

Maxime Coquelin

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 02/28/2011 02:28 AM, Maxime Coquelin wrote:
> Hello Eduardo,
>
> On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
>>> Eduardo, what has happened to this patchset?
>> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
> I propose to refactor your patchset, moving from procfs to sysfs.

>>> Do you want help in picking it up and try to polish it up?
>> Yeah, but it would need a refactoring. IIRC, result of last discussion
>> was that we should not mess with /proc. So, maybe moving back
 >> to something under sysfs. Perhaps /sys/devices/soc or so?
> About the location of this new sysfs entry, where do you think it should
> be?
> I propose to create a new directory named "soc" in /sys/devices/system/.
>
> As platform vendors have several/different kind of IDs to export to
> sysfs, I propose each vendor to create file entries related to their IDs
> (eg. /sys/devices/system/soc/idcode for OMAP platforms).

I think the path /sys/devices/system/soc/ will work for the MSM too. I 
would have ideally liked it to be /sys/devices/system/soc/msm, 
/sys/devices/system/soc/omap, etc, but we can't get to pick names for 
devices under a class. So, we can make do with /sys/devices/system/soc/.

> However, I think we should have a common file entry to export the unique
> ID of the platforms. Indeed, user-space applications should have a
> unified way to get this kind of ID, regardless of the platform (eg.
> /sys/devices/system/soc/unique_id).

I like the idea of have a common file across all implementations that 
will let user space identify what implementation is exporting the other 
files and how to interpret them.

I would like to propose an "arch" file to identify the arch the soc info 
file are for. I'm guessing within an arch, the soc files would mostly be 
the same? If there are other minor differences, we can let the arch 
specific code deal with how the files are interpreted.

Does "arch" work for everyone?

Thanks,
Saravana
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Andrei Warkentin]

On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
<skannan@codeaurora.org> wrote:
> On 02/28/2011 02:28 AM, Maxime Coquelin wrote:
>>
>> Hello Eduardo,
>>
>> On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
>>>>
>>>> Eduardo, what has happened to this patchset?
>>>
>>> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
>>
>> I propose to refactor your patchset, moving from procfs to sysfs.
>
>>>> Do you want help in picking it up and try to polish it up?
>>>
>>> Yeah, but it would need a refactoring. IIRC, result of last discussion
>>> was that we should not mess with /proc. So, maybe moving back
>
>>> to something under sysfs. Perhaps /sys/devices/soc or so?
>>
>> About the location of this new sysfs entry, where do you think it should
>> be?
>> I propose to create a new directory named "soc" in /sys/devices/system/.
>>
>> As platform vendors have several/different kind of IDs to export to
>> sysfs, I propose each vendor to create file entries related to their IDs
>> (eg. /sys/devices/system/soc/idcode for OMAP platforms).
>
> I think the path /sys/devices/system/soc/ will work for the MSM too. I would
> have ideally liked it to be /sys/devices/system/soc/msm,
> /sys/devices/system/soc/omap, etc, but we can't get to pick names for
> devices under a class. So, we can make do with /sys/devices/system/soc/.
>
>> However, I think we should have a common file entry to export the unique
>> ID of the platforms. Indeed, user-space applications should have a
>> unified way to get this kind of ID, regardless of the platform (eg.
>> /sys/devices/system/soc/unique_id).
>
> I like the idea of have a common file across all implementations that will
> let user space identify what implementation is exporting the other files and
> how to interpret them.
>
> I would like to propose an "arch" file to identify the arch the soc info
> file are for. I'm guessing within an arch, the soc files would mostly be the
> same? If there are other minor differences, we can let the arch specific
> code deal with how the files are interpreted.
>
> Does "arch" work for everyone?
>

Sorry to butt in, but what kind of info are you guys talking about?
Like SOC revision, serial numbers, etc...?

What would an "arch" file mean? The name of the soc platform?

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
> <skannan@codeaurora.org>  wrote:
>> On 02/28/2011 02:28 AM, Maxime Coquelin wrote:
>>>
>>> Hello Eduardo,
>>>
>>> On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
>>>>>
>>>>> Eduardo, what has happened to this patchset?
>>>>
>>>> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
>>>
>>> I propose to refactor your patchset, moving from procfs to sysfs.
>>
>>>>> Do you want help in picking it up and try to polish it up?
>>>>
>>>> Yeah, but it would need a refactoring. IIRC, result of last discussion
>>>> was that we should not mess with /proc. So, maybe moving back
>>
>>>> to something under sysfs. Perhaps /sys/devices/soc or so?
>>>
>>> About the location of this new sysfs entry, where do you think it should
>>> be?
>>> I propose to create a new directory named "soc" in /sys/devices/system/.
>>>
>>> As platform vendors have several/different kind of IDs to export to
>>> sysfs, I propose each vendor to create file entries related to their IDs
>>> (eg. /sys/devices/system/soc/idcode for OMAP platforms).
>>
>> I think the path /sys/devices/system/soc/ will work for the MSM too. I would
>> have ideally liked it to be /sys/devices/system/soc/msm,
>> /sys/devices/system/soc/omap, etc, but we can't get to pick names for
>> devices under a class. So, we can make do with /sys/devices/system/soc/.
>>
>>> However, I think we should have a common file entry to export the unique
>>> ID of the platforms. Indeed, user-space applications should have a
>>> unified way to get this kind of ID, regardless of the platform (eg.
>>> /sys/devices/system/soc/unique_id).
>>
>> I like the idea of have a common file across all implementations that will
>> let user space identify what implementation is exporting the other files and
>> how to interpret them.
>>
>> I would like to propose an "arch" file to identify the arch the soc info
>> file are for. I'm guessing within an arch, the soc files would mostly be the
>> same? If there are other minor differences, we can let the arch specific
>> code deal with how the files are interpreted.
>>
>> Does "arch" work for everyone?
>>
>
> Sorry to butt in, but what kind of info are you guys talking about?

Please do butt in :-), that's what a community discussion is for.

> Like SOC revision, serial numbers, etc...?

Like SOC type (to identify different chipsets), revision, etc.

> What would an "arch" file mean? The name of the soc platform?

The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or 
similar paths. If that info is already available elsewhere, then that 
file is not needed. I proposed using the arch since that will remove the 
need to maintain some database of unique/reserved names/numbers for each 
implementation of socinfo (like the machinetypes list we have).

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 06:41 PM, Ryan Mallon wrote:
> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>> I don't have any attachment to the "arch" file suggestion. If there is a
>> better solution to identify the different implementations of socinfo
>> without having to maintain some "unique id" list in the kernel, then I'm
>> all for it. But cpuinfo is not it.
>
> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
> file makes a bit more sense, but should probably be called 'mach' rather
> than 'arch' to avoid this confusion :-).

Sorry for the confusion. Sure, I don't care much for the filename as 
long as we can all agree on it. I care more about the content of the 
file (using names very close to xxxx in mach-xxxx). I like "soc-family" 
better since it's generic enough to not force, say omap3 and omap4, to 
report different values.

Linus Walleij, Eduardo, Maxime, Andrei,

Would like to hear your opinion on the file name (soc-family vs. mach vs 
<somethingelse>) and the path /sys/devices/system/soc/.

If we settle on this, may be it would be easier to get this through.

> I still think it is a solution in search of a problem though. What
> userspace programs need to know what specific SoC they are on? My
> feeling is that if userspace needs to know this information, then it is
> probably dicking around with things that should be managed by the
> kernel. Differences in available peripherals, etc can be determined by
> looking at existing sysfs files.

I certainly have seen several use cases. Couple of easy examples:

* A lot of test scripts would find this very useful. For example, some 
clock (present is all/most MSMs) shouldn't be tested on some SOCs as it 
would lock up the system if you try to turn it off while the CPU is running.

* Some of the user space tools might want to report different "product 
id/type" (nothing to do with USB, etc) depending on what SOC it is 
running on.

Thank,
Saravana
P.S: Removed felipe.balbi@nokia.com <felipe.balbi@nokia.com> since I 
keep getting delivery failure emails.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 03:55 PM, Saravana Kannan wrote:
> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>> I don't have any attachment to the "arch" file suggestion. If there is a
>>> better solution to identify the different implementations of socinfo
>>> without having to maintain some "unique id" list in the kernel, then I'm
>>> all for it. But cpuinfo is not it.
>>
>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>> file makes a bit more sense, but should probably be called 'mach' rather
>> than 'arch' to avoid this confusion :-).
> 
> Sorry for the confusion. Sure, I don't care much for the filename as
> long as we can all agree on it. I care more about the content of the
> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
> better since it's generic enough to not force, say omap3 and omap4, to
> report different values.
> 
> Linus Walleij, Eduardo, Maxime, Andrei,
> 
> Would like to hear your opinion on the file name (soc-family vs. mach vs
> <somethingelse>) and the path /sys/devices/system/soc/.

'family' sounds good. I don't think we need the 'soc-' prefix on
filenames if they are already in /sys/devices/system/soc/.

> 
> If we settle on this, may be it would be easier to get this through.
> 
>> I still think it is a solution in search of a problem though. What
>> userspace programs need to know what specific SoC they are on? My
>> feeling is that if userspace needs to know this information, then it is
>> probably dicking around with things that should be managed by the
>> kernel. Differences in available peripherals, etc can be determined by
>> looking at existing sysfs files.
> 
> I certainly have seen several use cases. Couple of easy examples:
> 
> * A lot of test scripts would find this very useful. For example, some
> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
> would lock up the system if you try to turn it off while the CPU is
> running.

I don't follow here. Do you mean a struct clk clock or something else?
Why is userspace allowed to disable a clock which will effectively hang
the system? :-).

> * Some of the user space tools might want to report different "product
> id/type" (nothing to do with USB, etc) depending on what SOC it is
> running on.

This makes more sense. It would actually be useful for custom USB
devices (gadget) which can be done from user space.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 07:11 PM, Ryan Mallon wrote:
> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>>> I don't have any attachment to the "arch" file suggestion. If there is a
>>>> better solution to identify the different implementations of socinfo
>>>> without having to maintain some "unique id" list in the kernel, then I'm
>>>> all for it. But cpuinfo is not it.
>>>
>>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>>> file makes a bit more sense, but should probably be called 'mach' rather
>>> than 'arch' to avoid this confusion :-).
>>
>> Sorry for the confusion. Sure, I don't care much for the filename as
>> long as we can all agree on it. I care more about the content of the
>> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
>> better since it's generic enough to not force, say omap3 and omap4, to
>> report different values.
>>
>> Linus Walleij, Eduardo, Maxime, Andrei,
>>
>> Would like to hear your opinion on the file name (soc-family vs. mach vs
>> <somethingelse>) and the path /sys/devices/system/soc/.
>
> 'family' sounds good. I don't think we need the 'soc-' prefix on
> filenames if they are already in /sys/devices/system/soc/.

Makes sense. We can drop the soc- prefix. So the contenders left: family 
vs <somethingelse>. Would still be nice if the other folks chime in.

>> If we settle on this, may be it would be easier to get this through.
>>
>>> I still think it is a solution in search of a problem though. What
>>> userspace programs need to know what specific SoC they are on? My
>>> feeling is that if userspace needs to know this information, then it is
>>> probably dicking around with things that should be managed by the
>>> kernel. Differences in available peripherals, etc can be determined by
>>> looking at existing sysfs files.
>>
>> I certainly have seen several use cases. Couple of easy examples:
>>
>> * A lot of test scripts would find this very useful. For example, some
>> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
>> would lock up the system if you try to turn it off while the CPU is
>> running.
>
> I don't follow here. Do you mean a struct clk clock or something else?
> Why is userspace allowed to disable a clock which will effectively hang
> the system? :-).

Ah, sorry. Didn't give enough details. To give some context, I manage 
the clock stuff for MSM. The MSM clock driver exports clock control thru 
debugfs. We have test scripts that bang the clocks to test them. Each 
SoC has a different set of "touch me and you die" clocks that the test 
script shouldn't mess with. This socinfo would be useful for those test 
cases.

>> * Some of the user space tools might want to report different "product
>> id/type" (nothing to do with USB, etc) depending on what SOC it is
>> running on.
>
> This makes more sense. It would actually be useful for custom USB
> devices (gadget) which can be done from user space.

Hmm... didn't know USB devices/gadgets could be handled from userspace.

Thanks,
Saravana
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 04:21 PM, Saravana Kannan wrote:
> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>>>> I don't have any attachment to the "arch" file suggestion. If there
>>>>> is a
>>>>> better solution to identify the different implementations of socinfo
>>>>> without having to maintain some "unique id" list in the kernel,
>>>>> then I'm
>>>>> all for it. But cpuinfo is not it.
>>>>
>>>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>>>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>>>> file makes a bit more sense, but should probably be called 'mach'
>>>> rather
>>>> than 'arch' to avoid this confusion :-).
>>>
>>> Sorry for the confusion. Sure, I don't care much for the filename as
>>> long as we can all agree on it. I care more about the content of the
>>> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
>>> better since it's generic enough to not force, say omap3 and omap4, to
>>> report different values.
>>>
>>> Linus Walleij, Eduardo, Maxime, Andrei,
>>>
>>> Would like to hear your opinion on the file name (soc-family vs. mach vs
>>> <somethingelse>) and the path /sys/devices/system/soc/.
>>
>> 'family' sounds good. I don't think we need the 'soc-' prefix on
>> filenames if they are already in /sys/devices/system/soc/.
> 
> Makes sense. We can drop the soc- prefix. So the contenders left: family
> vs <somethingelse>. Would still be nice if the other folks chime in.
> 
>>> If we settle on this, may be it would be easier to get this through.
>>>
>>>> I still think it is a solution in search of a problem though. What
>>>> userspace programs need to know what specific SoC they are on? My
>>>> feeling is that if userspace needs to know this information, then it is
>>>> probably dicking around with things that should be managed by the
>>>> kernel. Differences in available peripherals, etc can be determined by
>>>> looking at existing sysfs files.
>>>
>>> I certainly have seen several use cases. Couple of easy examples:
>>>
>>> * A lot of test scripts would find this very useful. For example, some
>>> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
>>> would lock up the system if you try to turn it off while the CPU is
>>> running.
>>
>> I don't follow here. Do you mean a struct clk clock or something else?
>> Why is userspace allowed to disable a clock which will effectively hang
>> the system? :-).
> 
> Ah, sorry. Didn't give enough details. To give some context, I manage
> the clock stuff for MSM. The MSM clock driver exports clock control thru
> debugfs. We have test scripts that bang the clocks to test them. Each
> SoC has a different set of "touch me and you die" clocks that the test
> script shouldn't mess with. This socinfo would be useful for those test
> cases.

Ah, okay. This is still within a single SoC family though since we don't
yet (AFAIK) support mutliple SoCs in a single kernel.

>>> * Some of the user space tools might want to report different "product
>>> id/type" (nothing to do with USB, etc) depending on what SOC it is
>>> running on.
>>
>> This makes more sense. It would actually be useful for custom USB
>> devices (gadget) which can be done from user space.
> 
> Hmm... didn't know USB devices/gadgets could be handled from userspace.

The gadgetfs driver allows for writing custom usb device
implementations. The SoC info could be used to set the USB
vendor/product id. Again, I see this more useful within the SoC family
(ie at91sam9260 vs at91sam9263) rather than between families. From an
embedded perspective at least, I think it is unlikely for an application
to need to work on multiple SoC families.

The only real objection I have to adding the SoC family information is
basically to discourage it being abused by userspace. I can see it being
useful in debug situations, but I can also see stupid userspace
applications explicitly testing for some particular SoC, rather than
more correctly (IMHO) checking for presence of certain drivers etc.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 07:35 PM, Ryan Mallon wrote:
> On 03/02/2011 04:21 PM, Saravana Kannan wrote:
>> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>>>>> I don't have any attachment to the "arch" file suggestion. If there
>>>>>> is a
>>>>>> better solution to identify the different implementations of socinfo
>>>>>> without having to maintain some "unique id" list in the kernel,
>>>>>> then I'm
>>>>>> all for it. But cpuinfo is not it.
>>>>>
>>>>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>>>>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>>>>> file makes a bit more sense, but should probably be called 'mach'
>>>>> rather
>>>>> than 'arch' to avoid this confusion :-).
>>>>
>>>> Sorry for the confusion. Sure, I don't care much for the filename as
>>>> long as we can all agree on it. I care more about the content of the
>>>> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
>>>> better since it's generic enough to not force, say omap3 and omap4, to
>>>> report different values.
>>>>
>>>> Linus Walleij, Eduardo, Maxime, Andrei,
>>>>
>>>> Would like to hear your opinion on the file name (soc-family vs. mach vs
>>>> <somethingelse>) and the path /sys/devices/system/soc/.
>>>
>>> 'family' sounds good. I don't think we need the 'soc-' prefix on
>>> filenames if they are already in /sys/devices/system/soc/.
>>
>> Makes sense. We can drop the soc- prefix. So the contenders left: family
>> vs<somethingelse>. Would still be nice if the other folks chime in.
>>
>>>> If we settle on this, may be it would be easier to get this through.
>>>>
>>>>> I still think it is a solution in search of a problem though. What
>>>>> userspace programs need to know what specific SoC they are on? My
>>>>> feeling is that if userspace needs to know this information, then it is
>>>>> probably dicking around with things that should be managed by the
>>>>> kernel. Differences in available peripherals, etc can be determined by
>>>>> looking at existing sysfs files.
>>>>
>>>> I certainly have seen several use cases. Couple of easy examples:
>>>>
>>>> * A lot of test scripts would find this very useful. For example, some
>>>> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
>>>> would lock up the system if you try to turn it off while the CPU is
>>>> running.
>>>
>>> I don't follow here. Do you mean a struct clk clock or something else?
>>> Why is userspace allowed to disable a clock which will effectively hang
>>> the system? :-).
>>
>> Ah, sorry. Didn't give enough details. To give some context, I manage
>> the clock stuff for MSM. The MSM clock driver exports clock control thru
>> debugfs. We have test scripts that bang the clocks to test them. Each
>> SoC has a different set of "touch me and you die" clocks that the test
>> script shouldn't mess with. This socinfo would be useful for those test
>> cases.
>
> Ah, okay. This is still within a single SoC family though since we don't
> yet (AFAIK) support mutliple SoCs in a single kernel.

Yes, my example was within a single SoC family. But since this is user 
space example, it doesn't matter if a single kernel can support multiple 
SoCs/SoC families. We could still have one userspace code that might 
want to support multiple SoC families.

Anyway, I think we are in agreement here. So, will stop discussing this 
point.

>>>> * Some of the user space tools might want to report different "product
>>>> id/type" (nothing to do with USB, etc) depending on what SOC it is
>>>> running on.
>>>
>>> This makes more sense. It would actually be useful for custom USB
>>> devices (gadget) which can be done from user space.
>>
>> Hmm... didn't know USB devices/gadgets could be handled from userspace.
>
> The gadgetfs driver allows for writing custom usb device
> implementations. The SoC info could be used to set the USB
> vendor/product id. Again, I see this more useful within the SoC family
> (ie at91sam9260 vs at91sam9263) rather than between families. From an
> embedded perspective at least, I think it is unlikely for an application
> to need to work on multiple SoC families.
>
> The only real objection I have to adding the SoC family information is
> basically to discourage it being abused by userspace. I can see it being
> useful in debug situations, but I can also see stupid userspace
> applications explicitly testing for some particular SoC, rather than
> more correctly (IMHO) checking for presence of certain drivers etc.

True, but so many other things could be misused by stupid userspace 
programs. When there are legitimate usecases, I think we shouldn't 
prevent them just because we think a stupid userspace program could 
misuse it.

Again, although you might not be gung-ho about this, I think I have at 
least made you indifferent/mildly supportive to adding socinfo. If you 
don't mind, I would like to wait for others to chime in before 
continuing this discussion.

-Saravana
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 04:46 PM, Saravana Kannan wrote:
> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>> On 03/02/2011 04:21 PM, Saravana Kannan wrote:
>>> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:

<snip>

>> The only real objection I have to adding the SoC family information is
>> basically to discourage it being abused by userspace. I can see it being
>> useful in debug situations, but I can also see stupid userspace
>> applications explicitly testing for some particular SoC, rather than
>> more correctly (IMHO) checking for presence of certain drivers etc.
> 
> True, but so many other things could be misused by stupid userspace
> programs. When there are legitimate usecases, I think we shouldn't
> prevent them just because we think a stupid userspace program could
> misuse it.
> 
> Again, although you might not be gung-ho about this, I think I have at
> least made you indifferent/mildly supportive to adding socinfo. If you
> don't mind, I would like to wait for others to chime in before
> continuing this discussion.

Agreed.

In general I am in support of having the SoC information exposed
somewhere. I think we just want to be careful that it doesn't become a
dumping ground for anything and everything SoC related whether the
information is useful or not. I think each piece of exposed information
should have a genuine use case, not just "because we can".

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934