diff mbox

[RFC,v3,1/2] ARM: kernel: update cpuinfo to print SoC model name

Message ID 1359558091-29251-2-git-send-email-ruslan.bilovol@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Ruslan Bilovol Jan. 30, 2013, 3:01 p.m. UTC
Currently, reading /proc/cpuinfo provides userspace with CPU ID of
the CPU carrying out the read from the file.
Userspace using this information may decide what module
to load or how to configure some specific (and processor-depended)
settings or so.
However, since really different SoCs can share same ARM core,
this information currently is not so useful.
For example, TI OMAP4460 and OMAP4470 SoCs show the same
information in the /proc/cpuinfo whereas they are different.
Since in most cases ARM CPU is a part of some system on a chip (SoC),
the "cpuinfo" file looks like exactly that place, where this
information have to be displayed.

So added new line "SoC name" in the "cpuinfo" output for system
on a chip name. It is placed between CPU information and machine
information, so the file structure looks gracefully (CPU-SoC-Hardware)

Example:

/ # cat proc/cpuinfo
[...]
CPU variant     : 0x2
CPU part        : 0xc09
CPU revision    : 10

SoC name        : OMAP4470

Hardware        : OMAP4 Blaze Tablet
Revision        : 20edb4
[...]

Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
---
 arch/arm/include/asm/setup.h |    1 +
 arch/arm/kernel/setup.c      |    9 +++++++++
 2 files changed, 10 insertions(+)

Comments

Nicolas Pitre Jan. 30, 2013, 7:07 p.m. UTC | #1
On Wed, 30 Jan 2013, Ruslan Bilovol wrote:

> Currently, reading /proc/cpuinfo provides userspace with CPU ID of
> the CPU carrying out the read from the file.
> Userspace using this information may decide what module
> to load or how to configure some specific (and processor-depended)
> settings or so.
> However, since really different SoCs can share same ARM core,
> this information currently is not so useful.
> For example, TI OMAP4460 and OMAP4470 SoCs show the same
> information in the /proc/cpuinfo whereas they are different.
> Since in most cases ARM CPU is a part of some system on a chip (SoC),
> the "cpuinfo" file looks like exactly that place, where this
> information have to be displayed.
> 
> So added new line "SoC name" in the "cpuinfo" output for system
> on a chip name. It is placed between CPU information and machine
> information, so the file structure looks gracefully (CPU-SoC-Hardware)
> 
> Example:
> 
> / # cat proc/cpuinfo
> [...]
> CPU variant     : 0x2
> CPU part        : 0xc09
> CPU revision    : 10
> 
> SoC name        : OMAP4470
> 
> Hardware        : OMAP4 Blaze Tablet

Please remove that extra blank line between "SoC name" and "Hardware".  
The blank line after "CPU revision" is fine.

Also, please rename this to "System name".  Not all systems are "on 
chip".  By using "System name" this is more universally useful.


Nicolas
Matt Sealey Jan. 30, 2013, 8:37 p.m. UTC | #2
On Wed, Jan 30, 2013 at 1:07 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Wed, 30 Jan 2013, Ruslan Bilovol wrote:
>
>> Currently, reading /proc/cpuinfo provides userspace with CPU ID of
>> the CPU carrying out the read from the file.
>> Userspace using this information may decide what module
>> to load or how to configure some specific (and processor-depended)
>> settings or so.
>> However, since really different SoCs can share same ARM core,
>> this information currently is not so useful.
>> For example, TI OMAP4460 and OMAP4470 SoCs show the same
>> information in the /proc/cpuinfo whereas they are different.
>> Since in most cases ARM CPU is a part of some system on a chip (SoC),
>> the "cpuinfo" file looks like exactly that place, where this
>> information have to be displayed.
>>
>> So added new line "SoC name" in the "cpuinfo" output for system
>> on a chip name. It is placed between CPU information and machine
>> information, so the file structure looks gracefully (CPU-SoC-Hardware)
>>
>> Example:
>>
>> / # cat proc/cpuinfo
>> [...]
>> CPU variant     : 0x2
>> CPU part        : 0xc09
>> CPU revision    : 10
>>
>> SoC name        : OMAP4470
>>
>> Hardware        : OMAP4 Blaze Tablet
>
> Please remove that extra blank line between "SoC name" and "Hardware".
> The blank line after "CPU revision" is fine.
>
> Also, please rename this to "System name".  Not all systems are "on
> chip".  By using "System name" this is more universally useful.

I can't agree with "System name", it is confusing in common
terminology since it's about the same definition as the current
"Hardware" line.

If we're just printing out the name of the device surrounding the CPU
- be it a Northbridge/Southbridge combination or SoC packaging -
"Chipset" might be a better name for it.
Nicolas Pitre Jan. 30, 2013, 9:02 p.m. UTC | #3
On Wed, 30 Jan 2013, Matt Sealey wrote:

> On Wed, Jan 30, 2013 at 1:07 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Wed, 30 Jan 2013, Ruslan Bilovol wrote:
> >
> >> Currently, reading /proc/cpuinfo provides userspace with CPU ID of
> >> the CPU carrying out the read from the file.
> >> Userspace using this information may decide what module
> >> to load or how to configure some specific (and processor-depended)
> >> settings or so.
> >> However, since really different SoCs can share same ARM core,
> >> this information currently is not so useful.
> >> For example, TI OMAP4460 and OMAP4470 SoCs show the same
> >> information in the /proc/cpuinfo whereas they are different.
> >> Since in most cases ARM CPU is a part of some system on a chip (SoC),
> >> the "cpuinfo" file looks like exactly that place, where this
> >> information have to be displayed.
> >>
> >> So added new line "SoC name" in the "cpuinfo" output for system
> >> on a chip name. It is placed between CPU information and machine
> >> information, so the file structure looks gracefully (CPU-SoC-Hardware)
> >>
> >> Example:
> >>
> >> / # cat proc/cpuinfo
> >> [...]
> >> CPU variant     : 0x2
> >> CPU part        : 0xc09
> >> CPU revision    : 10
> >>
> >> SoC name        : OMAP4470
> >>
> >> Hardware        : OMAP4 Blaze Tablet
> >
> > Please remove that extra blank line between "SoC name" and "Hardware".
> > The blank line after "CPU revision" is fine.
> >
> > Also, please rename this to "System name".  Not all systems are "on
> > chip".  By using "System name" this is more universally useful.
> 
> I can't agree with "System name", it is confusing in common
> terminology since it's about the same definition as the current
> "Hardware" line.
> 
> If we're just printing out the name of the device surrounding the CPU
> - be it a Northbridge/Southbridge combination or SoC packaging -
> "Chipset" might be a better name for it.

That suits me as well.


Nicolas
Jean-Christophe PLAGNIOL-VILLARD Jan. 30, 2013, 11:18 p.m. UTC | #4
On 17:01 Wed 30 Jan     , Ruslan Bilovol wrote:
> Currently, reading /proc/cpuinfo provides userspace with CPU ID of
> the CPU carrying out the read from the file.
> Userspace using this information may decide what module
> to load or how to configure some specific (and processor-depended)
> settings or so.
> However, since really different SoCs can share same ARM core,
> this information currently is not so useful.
> For example, TI OMAP4460 and OMAP4470 SoCs show the same
> information in the /proc/cpuinfo whereas they are different.
> Since in most cases ARM CPU is a part of some system on a chip (SoC),
> the "cpuinfo" file looks like exactly that place, where this
> information have to be displayed.
> 
> So added new line "SoC name" in the "cpuinfo" output for system
> on a chip name. It is placed between CPU information and machine
> information, so the file structure looks gracefully (CPU-SoC-Hardware)
Nack

this break the kernel ABI

and we have now socinfo via sysfs

Best Regards,
J.
> 
> Example:
> 
> / # cat proc/cpuinfo
> [...]
> CPU variant     : 0x2
> CPU part        : 0xc09
> CPU revision    : 10
> 
> SoC name        : OMAP4470
> 
> Hardware        : OMAP4 Blaze Tablet
> Revision        : 20edb4
> [...]
> 
> Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
> ---
>  arch/arm/include/asm/setup.h |    1 +
>  arch/arm/kernel/setup.c      |    9 +++++++++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
> index c50f056..621df40 100644
> --- a/arch/arm/include/asm/setup.h
> +++ b/arch/arm/include/asm/setup.h
> @@ -52,5 +52,6 @@ extern struct meminfo meminfo;
>  extern int arm_add_memory(phys_addr_t start, phys_addr_t size);
>  extern void early_print(const char *str, ...);
>  extern void dump_machine_table(void);
> +extern void set_soc_model_name(char *name);
>  
>  #endif
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 3f6cbb2..bb3805f 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -134,6 +134,7 @@ char elf_platform[ELF_PLATFORM_SIZE];
>  EXPORT_SYMBOL(elf_platform);
>  
>  static const char *cpu_name;
> +static const char *soc_name;
>  static const char *machine_name;
>  static char __initdata cmd_line[COMMAND_LINE_SIZE];
>  struct machine_desc *machine_desc __initdata;
> @@ -493,6 +494,11 @@ static void __init setup_processor(void)
>  	cpu_init();
>  }
>  
> +void set_soc_model_name(char *name)
> +{
> +	soc_name = name;
> +}
> +
>  void __init dump_machine_table(void)
>  {
>  	struct machine_desc *p;
> @@ -902,6 +908,9 @@ static int c_show(struct seq_file *m, void *v)
>  		seq_printf(m, "CPU revision\t: %d\n\n", cpuid & 15);
>  	}
>  
> +	if (soc_name)
> +		seq_printf(m, "SoC name\t: %s\n\n", soc_name);
> +
>  	seq_printf(m, "Hardware\t: %s\n", machine_name);
>  	seq_printf(m, "Revision\t: %04x\n", system_rev);
>  	seq_printf(m, "Serial\t\t: %08x%08x\n",
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Russell King - ARM Linux Jan. 30, 2013, 11:24 p.m. UTC | #5
On Wed, Jan 30, 2013 at 02:07:53PM -0500, Nicolas Pitre wrote:
> On Wed, 30 Jan 2013, Ruslan Bilovol wrote:
> 
> > Currently, reading /proc/cpuinfo provides userspace with CPU ID of
> > the CPU carrying out the read from the file.
> > Userspace using this information may decide what module
> > to load or how to configure some specific (and processor-depended)
> > settings or so.
> > However, since really different SoCs can share same ARM core,
> > this information currently is not so useful.
> > For example, TI OMAP4460 and OMAP4470 SoCs show the same
> > information in the /proc/cpuinfo whereas they are different.
> > Since in most cases ARM CPU is a part of some system on a chip (SoC),
> > the "cpuinfo" file looks like exactly that place, where this
> > information have to be displayed.
> > 
> > So added new line "SoC name" in the "cpuinfo" output for system
> > on a chip name. It is placed between CPU information and machine
> > information, so the file structure looks gracefully (CPU-SoC-Hardware)
> > 
> > Example:
> > 
> > / # cat proc/cpuinfo
> > [...]
> > CPU variant     : 0x2
> > CPU part        : 0xc09
> > CPU revision    : 10
> > 
> > SoC name        : OMAP4470
> > 
> > Hardware        : OMAP4 Blaze Tablet
> 
> Please remove that extra blank line between "SoC name" and "Hardware".  
> The blank line after "CPU revision" is fine.
> 
> Also, please rename this to "System name".  Not all systems are "on 
> chip".  By using "System name" this is more universally useful.

You may notice I've already suggested that this should be using the SoC
infrastructure to export this information, which was explicitly designed
to do this.

If we're going to have one SoC doing one thing and another SoC exporting
this information a completely different way, we're doomed.  We need to
make a decision and do it one way and one way only - and that decision
was made when drivers/base/soc.c was merged.

Unfortunately, I'd forgotten about that when I made my initial comments
about the difference between "CPU" and "SoC".
Nicolas Pitre Jan. 31, 2013, 12:33 a.m. UTC | #6
On Wed, 30 Jan 2013, Russell King - ARM Linux wrote:

> On Wed, Jan 30, 2013 at 02:07:53PM -0500, Nicolas Pitre wrote:
> > On Wed, 30 Jan 2013, Ruslan Bilovol wrote:
> > 
> > > Currently, reading /proc/cpuinfo provides userspace with CPU ID of
> > > the CPU carrying out the read from the file.
> > > Userspace using this information may decide what module
> > > to load or how to configure some specific (and processor-depended)
> > > settings or so.
> > > However, since really different SoCs can share same ARM core,
> > > this information currently is not so useful.
> > > For example, TI OMAP4460 and OMAP4470 SoCs show the same
> > > information in the /proc/cpuinfo whereas they are different.
> > > Since in most cases ARM CPU is a part of some system on a chip (SoC),
> > > the "cpuinfo" file looks like exactly that place, where this
> > > information have to be displayed.
> > > 
> > > So added new line "SoC name" in the "cpuinfo" output for system
> > > on a chip name. It is placed between CPU information and machine
> > > information, so the file structure looks gracefully (CPU-SoC-Hardware)
> > > 
> > > Example:
> > > 
> > > / # cat proc/cpuinfo
> > > [...]
> > > CPU variant     : 0x2
> > > CPU part        : 0xc09
> > > CPU revision    : 10
> > > 
> > > SoC name        : OMAP4470
> > > 
> > > Hardware        : OMAP4 Blaze Tablet
> > 
> > Please remove that extra blank line between "SoC name" and "Hardware".  
> > The blank line after "CPU revision" is fine.
> > 
> > Also, please rename this to "System name".  Not all systems are "on 
> > chip".  By using "System name" this is more universally useful.
> 
> You may notice I've already suggested that this should be using the SoC
> infrastructure to export this information, which was explicitly designed
> to do this.

Absolutely.  If a mechanism is already in place then it should be used.


Nicolas
Ruslan Bilovol Jan. 31, 2013, 11:50 a.m. UTC | #7
On Thu, Jan 31, 2013 at 1:24 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jan 30, 2013 at 02:07:53PM -0500, Nicolas Pitre wrote:
>> On Wed, 30 Jan 2013, Ruslan Bilovol wrote:
>>
>> > Currently, reading /proc/cpuinfo provides userspace with CPU ID of
>> > the CPU carrying out the read from the file.
>> > Userspace using this information may decide what module
>> > to load or how to configure some specific (and processor-depended)
>> > settings or so.
>> > However, since really different SoCs can share same ARM core,
>> > this information currently is not so useful.
>> > For example, TI OMAP4460 and OMAP4470 SoCs show the same
>> > information in the /proc/cpuinfo whereas they are different.
>> > Since in most cases ARM CPU is a part of some system on a chip (SoC),
>> > the "cpuinfo" file looks like exactly that place, where this
>> > information have to be displayed.
>> >
>> > So added new line "SoC name" in the "cpuinfo" output for system
>> > on a chip name. It is placed between CPU information and machine
>> > information, so the file structure looks gracefully (CPU-SoC-Hardware)
>> >
>> > Example:
>> >
>> > / # cat proc/cpuinfo
>> > [...]
>> > CPU variant     : 0x2
>> > CPU part        : 0xc09
>> > CPU revision    : 10
>> >
>> > SoC name        : OMAP4470
>> >
>> > Hardware        : OMAP4 Blaze Tablet
>>
>> Please remove that extra blank line between "SoC name" and "Hardware".
>> The blank line after "CPU revision" is fine.
>>
>> Also, please rename this to "System name".  Not all systems are "on
>> chip".  By using "System name" this is more universally useful.
>
> You may notice I've already suggested that this should be using the SoC
> infrastructure to export this information, which was explicitly designed
> to do this.
>
> If we're going to have one SoC doing one thing and another SoC exporting
> this information a completely different way, we're doomed.  We need to
> make a decision and do it one way and one way only - and that decision
> was made when drivers/base/soc.c was merged.
>
> Unfortunately, I'd forgotten about that when I made my initial comments
> about the difference between "CPU" and "SoC".

Yes agree - let's stop this discussion at this point. I'm going to
learn that soc framework and provide better solution.
Unfortunately, I didn't find it when looked into the kernel sources
for similar approaches.

Regards,
Ruslan
diff mbox

Patch

diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index c50f056..621df40 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -52,5 +52,6 @@  extern struct meminfo meminfo;
 extern int arm_add_memory(phys_addr_t start, phys_addr_t size);
 extern void early_print(const char *str, ...);
 extern void dump_machine_table(void);
+extern void set_soc_model_name(char *name);
 
 #endif
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..bb3805f 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -134,6 +134,7 @@  char elf_platform[ELF_PLATFORM_SIZE];
 EXPORT_SYMBOL(elf_platform);
 
 static const char *cpu_name;
+static const char *soc_name;
 static const char *machine_name;
 static char __initdata cmd_line[COMMAND_LINE_SIZE];
 struct machine_desc *machine_desc __initdata;
@@ -493,6 +494,11 @@  static void __init setup_processor(void)
 	cpu_init();
 }
 
+void set_soc_model_name(char *name)
+{
+	soc_name = name;
+}
+
 void __init dump_machine_table(void)
 {
 	struct machine_desc *p;
@@ -902,6 +908,9 @@  static int c_show(struct seq_file *m, void *v)
 		seq_printf(m, "CPU revision\t: %d\n\n", cpuid & 15);
 	}
 
+	if (soc_name)
+		seq_printf(m, "SoC name\t: %s\n\n", soc_name);
+
 	seq_printf(m, "Hardware\t: %s\n", machine_name);
 	seq_printf(m, "Revision\t: %04x\n", system_rev);
 	seq_printf(m, "Serial\t\t: %08x%08x\n",