ARM: mxs: Print silicon version on boot

From: Fabio Estevam <[email protected]>

Introduce functions that identify the SoC type (i.MX23 or iMX28) and also report the silicon revision.

---
Changes since v1:
- Use MXS as prefix in the revision definitions
- Retrieve the base address from dt
- Remove unneeded blank line
- Treat 0x0 as TO1.1
- Use u32

 arch/arm/mach-mxs/mach-mxs.c | 86 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 86 insertions(+)

index 66fe810..462fa14 100644
@@ -38,12 +38,27 @@
 #define MXS_DIGCTL_SAIF_CLKMUX_EXTMSTR0		0x2
 #define MXS_DIGCTL_SAIF_CLKMUX_EXTMSTR1		0x3
 
+#define HW_DIGCTL_CHIPID	0x310
+#define HW_DIGCTL_CHIPID_MASK	(0xffff << 16)
+#define HW_DIGCTL_REV_MASK	0xff
+#define HW_DIGCTL_CHIPID_MX23	(0x3780 << 16)
+#define HW_DIGCTL_CHIPID_MX28	(0x2800 << 16)
+
+#define MXS_CHIP_REVISION_1_0	0x10
+#define MXS_CHIP_REVISION_1_1	0x11
+#define MXS_CHIP_REVISION_1_2	0x12
+#define MXS_CHIP_REVISION_1_3	0x13
+#define MXS_CHIP_REVISION_1_4	0x14
+#define MXS_CHIP_REV_UNKNOWN	0xff
+
 #define MXS_GPIO_NR(bank, nr)	((bank) * 32 + (nr))
 
 #define MXS_SET_ADDR		0x4
 #define MXS_CLR_ADDR		0x8
 #define MXS_TOG_ADDR		0xc
 
+static void __iomem *digctl_base;
+
 static inline void __mxs_setl(u32 mask, void __iomem *reg)
 {
 	__raw_writel(mask, reg + MXS_SET_ADDR);

@@ -361,8 +376,79 @@ static void __init cfa10037_init(void)
 	update_fec_mac_prop(OUI_CRYSTALFONTZ);
 }
 
+static const char *mxs_get_cpu_type(void)
+{
+	u32 reg;
+	struct device_node *np;
+
+	np = of_find_compatible_node(NULL, NULL, "fsl,imx28-digctl");
+	digctl_base = of_iomap(np, 0);
+	WARN_ON(!digctl_base);
+
+	reg = readl(digctl_base + HW_DIGCTL_CHIPID) & HW_DIGCTL_CHIPID_MASK;
+	switch (reg) {
+	case HW_DIGCTL_CHIPID_MX23:
+		return "23";
+	case HW_DIGCTL_CHIPID_MX28:
+		return "28";
+	default:
+		return "unknown";
+	}
+}
+
+static int mxs_get_cpu_rev(void)
+{
+	u32 reg, rev;
+
+	reg = readl(digctl_base + HW_DIGCTL_CHIPID) & HW_DIGCTL_CHIPID_MASK;
+	rev = readl(digctl_base + HW_DIGCTL_CHIPID) & HW_DIGCTL_REV_MASK;
+
+	switch (reg) {
+	case HW_DIGCTL_CHIPID_MX23:
+		switch (rev) {
+		case 0x0:
+			return MXS_CHIP_REVISION_1_0;
+		case 0x1:
+			return MXS_CHIP_REVISION_1_1;
+		case 0x2:
+			return MXS_CHIP_REVISION_1_2;
+		case 0x3:
+			return MXS_CHIP_REVISION_1_3;
+		case 0x4:
+			return MXS_CHIP_REVISION_1_4;
+		default:
+			return MXS_CHIP_REV_UNKNOWN;
+		}
+	case HW_DIGCTL_CHIPID_MX28:
+		switch (rev) {
+		case 0x0:
+			return MXS_CHIP_REVISION_1_1;
+		case 0x1:
+			return MXS_CHIP_REVISION_1_2;
+		default:
+			return MXS_CHIP_REV_UNKNOWN;
+		}
+	default:
+		return MXS_CHIP_REV_UNKNOWN;
+	}
+}
+
+static void mxs_print_silicon_rev(const char *cpu, int srev)
+{
+	if (srev == MXS_CHIP_REV_UNKNOWN)
+		pr_info("CPU identified as i.MX%s, unknown revision\n", cpu);
+	else
+		pr_info("CPU identified as i.MX%s, silicon rev %d.%d\n",
+				cpu, (srev >> 4) & 0xf, srev & 0xf);
+}
+
 static void __init mxs_machine_init(void)
 {
+	const char *cpu_char = mxs_get_cpu_type();
+	int cpu_rev = mxs_get_cpu_rev();
+
+	mxs_print_silicon_rev(cpu_char, cpu_rev);
+
 	if (of_machine_is_compatible("fsl,imx28-evk"))
 		imx28_evk_init();
 	else if (of_machine_is_compatible("bluegiga,apx4devkit"))

1.8.1.2

From: Fabio Estevam <[email protected]>

Some mxs userspace tools, such as multimedia plugins and kobs-ng (tool used to burn boot images to NAND) rely on the 'Revision' field reported by '/proc/cpuinfo'.

Provide a mechanism to pass such information, so that now we can get:

$ cat /proc/cpuinfo                                             
processor       : 0                                                             
model name      : ARM926EJ-S rev 5 (v5l)                                        
BogoMIPS        : 226.09                                                        
Features        : swp half fastmult edsp java                                   
CPU implementer : 0x41                                                          
CPU architecture: 5TEJ                                                          
CPU variant     : 0x0                                                           
CPU part        : 0x926                                                         
CPU revision    : 5                                                             

Hardware : Freescale i.MX28 Evaluation Kit
Revision : 28012
Serial : 0000000000000000

---
Changes since v1:
- No changes

 arch/arm/mach-mxs/mach-mxs.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

index 462fa14..0d7e1eb 100644
@@ -29,6 +29,7 @@
 #include <asm/mach/map.h>
 #include <asm/mach/time.h>
 #include <asm/system_misc.h>
+#include <asm/system_info.h>
 
 #include "pm.h"
 

@@ -442,12 +443,26 @@ static void mxs_print_silicon_rev(const char *cpu, int srev)
 				cpu, (srev >> 4) & 0xf, srev & 0xf);
 }
 
+static void mxs_pass_sysrev(void)
+{
+	int cputype = 0;
+
+	if (strcmp(mxs_get_cpu_type(), "MX23"))
+		cputype = 0x23000;
+
+	if (strcmp(mxs_get_cpu_type(), "MX28"))
+		cputype = 0x28000;
+
+	system_rev = (cputype | mxs_get_cpu_rev());
+}
+
 static void __init mxs_machine_init(void)
 {
 	const char *cpu_char = mxs_get_cpu_type();
 	int cpu_rev = mxs_get_cpu_rev();
 
 	mxs_print_silicon_rev(cpu_char, cpu_rev);
+	mxs_pass_sysrev();
 
 	if (of_machine_is_compatible("fsl,imx28-evk"))
 		imx28_evk_init();

1.8.1.2

Hi Fabio,

Am Freitag, 31. Mai 2013, 19:42:07 schrieb Fabio Estevam:

Hi Michael,

Can you please provide some real examples?

For mx28 I see no boards passing ATAGS from bootloader to the kernel.

If you look at FSL kernel code the system revision is hardcoded in the board file.

For mx5/mx6 boards we do pass ATAGS from bootloader to kernel in the same format it was used here.

For example: on mx53 it will be 0x53112 (where 0x53 means mx53, 1 is the board revision and 12 means TO1.2)

As I mentioned in the commit log, the only reason we are doing this here is to allow a mainline kernel to run som mxs applications like Gstreamer plugins and kobs-ng.

Regards,

Fabio Estevam

Hi Fabio,

Am Samstag, 1. Juni 2013, 11:58:18 schrieb Fabio Estevam:

Please have a look at e.g. mach-orion5x/dns323-setup.c or grep for system_rev in arch/arm.
An out-of-vanilla-tree example is a board I've worked on:
https://github.com/iequalize/linux-mxs/blob/v2.6.35.14-openwrt-fsl-tq-ieq/arch/arm/mach-mx28/board-homebox.c
In arm/mach-omap2/board-omap3touchbook.c I'm not able to tell whether the use system_rev to encode a PCB revision or a CPU revision.

I see it. But I still wonder whether this is the right direction to pass the SoC revision to user-space. And I feel uncomfortable when we're mixing it with a board revision. I would prefer dedicated lines in /proc/cpuinfo. Is there a policy about adding line which would prohibit this?

I only know the kobs-ng util but I got the point: these tools (only) look at the revision line and cannot be used with a mainline kernel at the moment as a vanilla kernel don't pass the information required by these tools.

However, the revision field is arm platform specific and should be used with the same purpose over all mach types. Interpreting it for different SoCs in a different manner is IMO not a good idea.

So my question are:
What was/is the real intension for system_rev? Is passing a PCB revision via ATAG obsoleted by DT?

Regards,
Michael

+1

Now I feel strongly that we should use soc infrastructure (drivers/base/soc.c) to export soc ID and revision to user space. Maybe it's time to change those incompatible user applications.

Shawn