Re: [PATCH] OMAP3 PM export chip IDCODE, Production ID and Die ID
Eduardo Valentin writes: > Hello Tony and Kevin, > > On Wed, Oct 14, 2009 at 11:44:07AM +0200, De-Schrijver Peter > (Nokia-D/Helsinki) wrote: >> On Tue, Oct 13, 2009 at 09:51:30PM +0200, ext Kevin Hilman wrote: >> > On Tue, Oct 13, 2009 at 12:48 PM, Tony Lindgren wrote: >> > > * Kevin Hilman [091013 12:09]: >> > >> "Peter 'p2' De Schrijver" writes: >> > >> >> > >> > From: De-Schrijver Peter (Nokia-D/Helsinki) >> > >> > >> > >> > >> > >> > This patch exports the OMAP3 IDCODE, Production ID and Die ID to >> > >> > userspace via >> > >> > sysfs. This can be used to track down silicon specific issues. The >> > >> > info is >> > >> > exported via sysfs because it should be possible to include this in >> > >> > corematic >> > >> > dumps. >> > >> > >> > >> > Signed-off-by: Peter 'p2' De Schrijver >> > >> >> > >> Please export these via debugfs. >> > > >> > > I don't think we want to export unique chip identifiers by default. >> > > >> > >> > Right, which is why I suggested using debugfs, which is something that >> > probably wouldn't be enabled/exported on default production kernels. >> > >> >> Which is why I do not want it in debugfs as we log this info in >> crash reports on devices which might not have debugfs enabled. > > As Peter said here, this patch is to identify the chip from user land. > So it is not really a debug tool, but a identification tool. > > Any good reason why we should not have it? > > Another thing is, it could go into /proc/cpuinfo. Currently I don't > see any OMAP related info there, only ARM. Do you guys know why we don't > put anything in /proc/cpuinfo? I don't know any reason not to. This sounds like a good candiate for OMAP specific details in /proc/cpuinfo. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 PM export chip IDCODE, Production ID and Die ID
Hello Tony and Kevin, On Wed, Oct 14, 2009 at 11:44:07AM +0200, De-Schrijver Peter (Nokia-D/Helsinki) wrote: > On Tue, Oct 13, 2009 at 09:51:30PM +0200, ext Kevin Hilman wrote: > > On Tue, Oct 13, 2009 at 12:48 PM, Tony Lindgren wrote: > > > * Kevin Hilman [091013 12:09]: > > >> "Peter 'p2' De Schrijver" writes: > > >> > > >> > From: De-Schrijver Peter (Nokia-D/Helsinki) > > >> > > > >> > > > >> > This patch exports the OMAP3 IDCODE, Production ID and Die ID to > > >> > userspace via > > >> > sysfs. This can be used to track down silicon specific issues. The > > >> > info is > > >> > exported via sysfs because it should be possible to include this in > > >> > corematic > > >> > dumps. > > >> > > > >> > Signed-off-by: Peter 'p2' De Schrijver > > >> > > >> Please export these via debugfs. > > > > > > I don't think we want to export unique chip identifiers by default. > > > > > > > Right, which is why I suggested using debugfs, which is something that > > probably wouldn't be enabled/exported on default production kernels. > > > > Which is why I do not want it in debugfs as we log this info in > crash reports on devices which might not have debugfs enabled. As Peter said here, this patch is to identify the chip from user land. So it is not really a debug tool, but a identification tool. Any good reason why we should not have it? Another thing is, it could go into /proc/cpuinfo. Currently I don't see any OMAP related info there, only ARM. Do you guys know why we don't put anything in /proc/cpuinfo? > > Cheers, > > Peter. > > -- > goa is a state of mind > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html BR, -- Eduardo Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 PM export chip IDCODE, Production ID and Die ID
On Tue, Oct 13, 2009 at 09:51:30PM +0200, ext Kevin Hilman wrote: > On Tue, Oct 13, 2009 at 12:48 PM, Tony Lindgren wrote: > > * Kevin Hilman [091013 12:09]: > >> "Peter 'p2' De Schrijver" writes: > >> > >> > From: De-Schrijver Peter (Nokia-D/Helsinki) > >> > > >> > > >> > This patch exports the OMAP3 IDCODE, Production ID and Die ID to > >> > userspace via > >> > sysfs. This can be used to track down silicon specific issues. The info > >> > is > >> > exported via sysfs because it should be possible to include this in > >> > corematic > >> > dumps. > >> > > >> > Signed-off-by: Peter 'p2' De Schrijver > >> > >> Please export these via debugfs. > > > > I don't think we want to export unique chip identifiers by default. > > > > Right, which is why I suggested using debugfs, which is something that > probably wouldn't be enabled/exported on default production kernels. > Which is why I do not want it in debugfs as we log this info in crash reports on devices which might not have debugfs enabled. Cheers, Peter. -- goa is a state of mind -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 PM export chip IDCODE, Production ID and Die ID
On Tue, Oct 13, 2009 at 12:48 PM, Tony Lindgren wrote: > * Kevin Hilman [091013 12:09]: >> "Peter 'p2' De Schrijver" writes: >> >> > From: De-Schrijver Peter (Nokia-D/Helsinki) >> > >> > This patch exports the OMAP3 IDCODE, Production ID and Die ID to userspace >> > via >> > sysfs. This can be used to track down silicon specific issues. The info is >> > exported via sysfs because it should be possible to include this in >> > corematic >> > dumps. >> > >> > Signed-off-by: Peter 'p2' De Schrijver >> >> Please export these via debugfs. > > I don't think we want to export unique chip identifiers by default. > Right, which is why I suggested using debugfs, which is something that probably wouldn't be enabled/exported on default production kernels. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 PM export chip IDCODE, Production ID and Die ID
* Kevin Hilman [091013 12:09]:
> "Peter 'p2' De Schrijver" writes:
>
> > From: De-Schrijver Peter (Nokia-D/Helsinki)
> >
> > This patch exports the OMAP3 IDCODE, Production ID and Die ID to userspace
> > via
> > sysfs. This can be used to track down silicon specific issues. The info is
> > exported via sysfs because it should be possible to include this in
> > corematic
> > dumps.
> >
> > Signed-off-by: Peter 'p2' De Schrijver
>
> Please export these via debugfs.
I don't think we want to export unique chip identifiers by default.
Please search "CPU serial number disabled" for some earlier handling
of things like these for x86, and see function
squash_the_stupid_serial_number(struct cpuinfo_x86 *c) in
arch/x86/kernel/cpu/common.c :)
Regards,
Tony
>
> Kevin
>
> > ---
> > arch/arm/mach-omap2/id.c | 36
> > 1 files changed, 36 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> > index 2c5e0a3..97670e2 100644
> > --- a/arch/arm/mach-omap2/id.c
> > +++ b/arch/arm/mach-omap2/id.c
> > @@ -70,6 +70,10 @@ EXPORT_SYMBOL(omap_type);
> >
> > /**/
> >
> > #define OMAP_TAP_IDCODE0x0204
> > +#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
> > @@ -77,6 +81,10 @@ EXPORT_SYMBOL(omap_type);
> >
> > #define read_tap_reg(reg) __raw_readl(tap_base + (reg))
> >
> > +static ssize_t idcode_show(struct kobject *, struct kobj_attribute *, char
> > *);
> > +static struct kobj_attribute idcode_attr = __ATTR(idcode, 0444,
> > idcode_show,
> > + NULL);
> > +
> > struct omap_id {
> > u16 hawkeye;/* Silicon type (Hawkeye id) */
> > u8 dev;/* Device type from production_id reg */
> > @@ -96,6 +104,23 @@ static struct omap_id omap_ids[] __initdata = {
> > static void __iomem *tap_base;
> > static u16 tap_prod_id;
> >
> > +static ssize_t idcode_show(struct kobject *kobj, struct kobj_attribute
> > *attr,
> > + char *buf)
> > +{
> > + return sprintf(buf, "IDCODE: %08x\nProduction ID: %08x %08x %08x %08x\n"
> > + "Die ID: %08x %08x %08x %08x\n",
> > + 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),
> > + 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));
> > +
> > +}
> > +
> > void __init omap24xx_check_revision(void)
> > {
> > int i, j;
> > @@ -259,3 +284,14 @@ void __init omap2_set_globals_tap(struct omap_globals
> > *omap2_globals)
> > else
> > tap_prod_id = 0x0208;
> > }
> > +
> > +void __init export_omapid(void)
> > +{
> > + int error;
> > +
> > + error = sysfs_create_file(power_kobj, &idcode_attr.attr);
> > + if (error)
> > + printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
> > +}
> > +
> > +late_initcall(export_omapid);
> > --
> > 1.6.2.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 PM export chip IDCODE, Production ID and Die ID
"Peter 'p2' De Schrijver" writes:
> From: De-Schrijver Peter (Nokia-D/Helsinki)
>
> This patch exports the OMAP3 IDCODE, Production ID and Die ID to userspace via
> sysfs. This can be used to track down silicon specific issues. The info is
> exported via sysfs because it should be possible to include this in corematic
> dumps.
>
> Signed-off-by: Peter 'p2' De Schrijver
Please export these via debugfs.
Kevin
> ---
> arch/arm/mach-omap2/id.c | 36
> 1 files changed, 36 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 2c5e0a3..97670e2 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -70,6 +70,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_00x0218
> #define OMAP_TAP_DIE_ID_10x021C
> #define OMAP_TAP_DIE_ID_20x0220
> @@ -77,6 +81,10 @@ EXPORT_SYMBOL(omap_type);
>
> #define read_tap_reg(reg)__raw_readl(tap_base + (reg))
>
> +static ssize_t idcode_show(struct kobject *, struct kobj_attribute *, char
> *);
> +static struct kobj_attribute idcode_attr = __ATTR(idcode, 0444, idcode_show,
> + NULL);
> +
> struct omap_id {
> u16 hawkeye;/* Silicon type (Hawkeye id) */
> u8 dev;/* Device type from production_id reg */
> @@ -96,6 +104,23 @@ static struct omap_id omap_ids[] __initdata = {
> static void __iomem *tap_base;
> static u16 tap_prod_id;
>
> +static ssize_t idcode_show(struct kobject *kobj, struct kobj_attribute *attr,
> + char *buf)
> +{
> + return sprintf(buf, "IDCODE: %08x\nProduction ID: %08x %08x %08x %08x\n"
> + "Die ID: %08x %08x %08x %08x\n",
> + 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),
> + 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));
> +
> +}
> +
> void __init omap24xx_check_revision(void)
> {
> int i, j;
> @@ -259,3 +284,14 @@ void __init omap2_set_globals_tap(struct omap_globals
> *omap2_globals)
> else
> tap_prod_id = 0x0208;
> }
> +
> +void __init export_omapid(void)
> +{
> + int error;
> +
> + error = sysfs_create_file(power_kobj, &idcode_attr.attr);
> + if (error)
> + printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
> +}
> +
> +late_initcall(export_omapid);
> --
> 1.6.2.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 PM export chip IDCODE, Production ID and Die ID
On Mon, Oct 12, 2009 at 5:51 PM, Peter 'p2' De Schrijver
wrote:
> From: De-Schrijver Peter (Nokia-D/Helsinki)
>
> This patch exports the OMAP3 IDCODE, Production ID and Die ID to userspace via
> sysfs. This can be used to track down silicon specific issues. The info is
> exported via sysfs because it should be possible to include this in corematic
> dumps.
>
> Signed-off-by: Peter 'p2' De Schrijver
> ---
> arch/arm/mach-omap2/id.c | 36
> 1 files changed, 36 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 2c5e0a3..97670e2 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -70,6 +70,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
> @@ -77,6 +81,10 @@ EXPORT_SYMBOL(omap_type);
>
> #define read_tap_reg(reg) __raw_readl(tap_base + (reg))
>
> +static ssize_t idcode_show(struct kobject *, struct kobj_attribute *, char
> *);
> +static struct kobj_attribute idcode_attr = __ATTR(idcode, 0444, idcode_show,
> + NULL);
> +
> struct omap_id {
> u16 hawkeye; /* Silicon type (Hawkeye id) */
> u8 dev; /* Device type from production_id reg */
> @@ -96,6 +104,23 @@ static struct omap_id omap_ids[] __initdata = {
> static void __iomem *tap_base;
> static u16 tap_prod_id;
>
> +static ssize_t idcode_show(struct kobject *kobj, struct kobj_attribute *attr,
> + char *buf)
> +{
> + return sprintf(buf, "IDCODE: %08x\nProduction ID: %08x %08x %08x
> %08x\n"
> + "Die ID: %08x %08x %08x %08x\n",
> + 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),
> + 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));
> +
> +}
> +
> void __init omap24xx_check_revision(void)
> {
> int i, j;
> @@ -259,3 +284,14 @@ void __init omap2_set_globals_tap(struct omap_globals
> *omap2_globals)
> else
> tap_prod_id = 0x0208;
> }
> +
> +void __init export_omapid(void)
> +{
> + int error;
> +
> + error = sysfs_create_file(power_kobj, &idcode_attr.attr);
This will not build when CONFIG_PM is off; power_kobj will not be available.
> + if (error)
> + printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
> +}
> +
> +late_initcall(export_omapid);
> --
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3 PM export chip IDCODE, Production ID and Die ID
From: De-Schrijver Peter (Nokia-D/Helsinki)
This patch exports the OMAP3 IDCODE, Production ID and Die ID to userspace via
sysfs. This can be used to track down silicon specific issues. The info is
exported via sysfs because it should be possible to include this in corematic
dumps.
Signed-off-by: Peter 'p2' De Schrijver
---
arch/arm/mach-omap2/id.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2c5e0a3..97670e2 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -70,6 +70,10 @@ EXPORT_SYMBOL(omap_type);
/**/
#define OMAP_TAP_IDCODE0x0204
+#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
@@ -77,6 +81,10 @@ EXPORT_SYMBOL(omap_type);
#define read_tap_reg(reg) __raw_readl(tap_base + (reg))
+static ssize_t idcode_show(struct kobject *, struct kobj_attribute *, char *);
+static struct kobj_attribute idcode_attr = __ATTR(idcode, 0444, idcode_show,
+ NULL);
+
struct omap_id {
u16 hawkeye;/* Silicon type (Hawkeye id) */
u8 dev;/* Device type from production_id reg */
@@ -96,6 +104,23 @@ static struct omap_id omap_ids[] __initdata = {
static void __iomem *tap_base;
static u16 tap_prod_id;
+static ssize_t idcode_show(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "IDCODE: %08x\nProduction ID: %08x %08x %08x %08x\n"
+ "Die ID: %08x %08x %08x %08x\n",
+ 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),
+ 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));
+
+}
+
void __init omap24xx_check_revision(void)
{
int i, j;
@@ -259,3 +284,14 @@ void __init omap2_set_globals_tap(struct omap_globals
*omap2_globals)
else
tap_prod_id = 0x0208;
}
+
+void __init export_omapid(void)
+{
+ int error;
+
+ error = sysfs_create_file(power_kobj, &idcode_attr.attr);
+ if (error)
+ printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
+}
+
+late_initcall(export_omapid);
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
