| Message ID | 1359558091-29251-2-git-send-email-ruslan.bilovol@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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". -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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",
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(+)