[PATCH] x86: CPU detection for RDC System-on-Chip

[PATCH] x86: CPU detection for RDC System-on-Chip

[Florian Fainelli]

From: Mark Kelly <mark@bifferos.com>

The RDC System-on-Chip i486 compatible core does not support the cpuid
instruction and specific detection logic is required for this chip. The patch
below adds proper vendor and SoC type detection.

Signed-off-by: Mark Kelly <mark@bifferos.com>
Tested-by: Florian Fainelli <florian@openwrt.org>
---
diff --git a/Documentation/x86/rdc.txt b/Documentation/x86/rdc.txt
new file mode 100644
index 0000000..f9591af
--- /dev/null
+++ b/Documentation/x86/rdc.txt
@@ -0,0 +1,69 @@
+
+Introduction
+============
+
+RDC (http://www.rdc.com.tw) have been manufacturing x86-compatible SoC
+(system-on-chips) for a number of years.  They are not the fastest of
+CPUs (clock speeds ranging from 133-150MHz) but 486SX compatibility
+coupled with very low power consumption[1] and low cost make them ideal
+for embedded applications.
+
+
+Where to find
+=============
+
+RDC chips show up in numerous embedded devices, but be careful since
+many of them will not run Linux 2.6 without significant expertise.
+
+There are several variants of what the linux kernel refers to generically
+as RDC321X:  R8610, R321x, S3282 and AMRISC20000.
+
+R321x: Found in various routers, see the OpenWrt project for details,
+   http://wiki.openwrt.org/oldwiki/rdcport
+
+R8610: Found on the RDC evaluation board
+   http://www.ivankuten.com/system-on-chip-soc/rdc-r8610/
+
+AMRISC20000: Found in the MGB-100 wireless hard disk
+   http://tintuc.no-ip.com/linux/tipps/mgb100/
+
+S3282: Found in various NAS devices, including the Bifferboard
+   http://www.bifferos.com
+
+
+Kernel Configuration
+====================
+
+Add support for this CPU with CONFIG_X86_RDC321X.  Ensure that maths
+emulation is included (CONFIG_MATH_EMULATION selected) and avoid MCE
+(CONFIG_X86_MCE not selected).
+
+
+CPU detection
+=============
+
+None of these chips support the cpuid instruction, so as with some
+other x86 compatible SoCs, we must check the north bridge and look
+for specific 'signature' PCI device config.
+
+The current detection code has been tested only on the Bifferboard
+(S3282 CPU), please send bug reports or success stories with
+other devices to bifferos@yahoo.co.uk.
+
+
+Credits
+=======
+
+Many thanks to RDC for providing the customer codes to allow
+detection of all known variants, without which this detection code
+would have been very hard to ascertain.
+
+
+References
+==========
+
+[1] S3282 in certain NAS solutions consumes less than 1W
+
+
+mark@bifferos.com 2009
+
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 39e8e10..21b02f2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -419,6 +419,7 @@ config X86_RDC321X
 	bool "RDC R-321x SoC"
 	depends on X86_32
 	depends on X86_EXTENDED_PLATFORM
+	select PCI
 	select M486
 	select X86_REBOOTFIXUPS
 	---help---
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 5a51379..eddf979 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -122,7 +122,8 @@ struct cpuinfo_x86 {
 #define X86_VENDOR_CENTAUR	5
 #define X86_VENDOR_TRANSMETA	7
 #define X86_VENDOR_NSC		8
-#define X86_VENDOR_NUM		9
+#define X86_VENDOR_RDC		9
+#define X86_VENDOR_NUM		10
 
 #define X86_VENDOR_UNKNOWN	0xff
 
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 3a785da..af2d4a6 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
 obj-$(CONFIG_CPU_SUP_CENTAUR)		+= centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
+obj-$(CONFIG_X86_RDC321X)		+= rdc.o
 
 obj-$(CONFIG_PERF_EVENTS)		+= perf_event.o
 
diff --git a/arch/x86/kernel/cpu/rdc.c b/arch/x86/kernel/cpu/rdc.c
new file mode 100644
index 0000000..f49bfed
--- /dev/null
+++ b/arch/x86/kernel/cpu/rdc.c
@@ -0,0 +1,71 @@
+/*
+ * See Documentation/x86/rdc.txt
+ *
+ * mark@bifferos.com
+ */
+
+#include <linux/pci.h>
+#include <asm/pci-direct.h>
+#include "cpu.h"
+
+
+static void __cpuinit rdc_identify(struct cpuinfo_x86 *c)
+{
+	u16 vendor, device;
+	u32 customer_id;
+
+	if (!early_pci_allowed())
+		return;
+
+	/* RDC CPU is SoC (system-on-chip), Northbridge is always present */
+	vendor = read_pci_config_16(0, 0, 0, PCI_VENDOR_ID);
+	device = read_pci_config_16(0, 0, 0, PCI_DEVICE_ID);
+
+	if (vendor != PCI_VENDOR_ID_RDC || device != PCI_DEVICE_ID_RDC_R6020)
+		return;  /* not RDC */
+	/*
+	 * NB: We could go on and check other devices, e.g. r6040 NIC, but
+	 * that's probably overkill
+	 */
+
+	customer_id = read_pci_config(0, 0, 0, 0x90);
+
+	switch (customer_id) {
+		/* id names are from RDC */
+	case 0x00321000:
+		strcpy(c->x86_model_id, "R3210/R3211");
+		break;
+	case 0x00321001:
+		strcpy(c->x86_model_id, "AMITRISC20000/20010");
+		break;
+	case 0x00321002:
+		strcpy(c->x86_model_id, "R3210X/Edimax");
+		break;
+	case 0x00321003:
+		strcpy(c->x86_model_id, "R3210/Kcodes");
+		break;
+	case 0x00321004:  /* tested */
+		strcpy(c->x86_model_id, "S3282/CodeTek");
+		break;
+	case 0x00321007:
+		strcpy(c->x86_model_id, "R8610");
+		break;
+	default:
+		pr_info("RDC CPU: Unrecognised Customer ID (0x%x) please "
+			"report to: linux-kernel@vger.kernel.org\n",
+			customer_id);
+		return;
+	}
+
+	strcpy(c->x86_vendor_id, "RDC");
+	c->x86_vendor = X86_VENDOR_RDC;
+}
+
+static const struct cpu_dev __cpuinitconst rdc_cpu_dev = {
+	.c_vendor	= "RDC",
+	.c_ident	= { "RDC" },
+	.c_identify	= rdc_identify,
+	.c_x86_vendor	= X86_VENDOR_RDC,
+};
+
+cpu_dev_register(rdc_cpu_dev);

Re: [PATCH] x86: CPU detection for RDC System-on-Chip

[Alan Cox]

> +	case 0x00321004:  /* tested */
> +		strcpy(c->x86_model_id, "S3282/CodeTek");
> +		break;
> +	case 0x00321007:
> +		strcpy(c->x86_model_id, "R8610");
> +		break;
> +	default:
> +		pr_info("RDC CPU: Unrecognised Customer ID (0x%x) please "
> +			"report to: linux-kernel@vger.kernel.org\n",
> +			customer_id);

Surely this should be a break as you want to set the vendor. You've
established its an RDC at this point have you not - so you want to set
x86_vendor.

Alan

Re: [PATCH] x86: CPU detection for RDC System-on-Chip

[Florian Fainelli]

Le dimanche 16 mai 2010 15:19:17, Alan Cox a écrit :
> > +	case 0x00321004:  /* tested */
> > +		strcpy(c->x86_model_id, "S3282/CodeTek");
> > +		break;
> > +	case 0x00321007:
> > +		strcpy(c->x86_model_id, "R8610");
> > +		break;
> > +	default:
> > +		pr_info("RDC CPU: Unrecognised Customer ID (0x%x) please "
> > +			"report to: linux-kernel@vger.kernel.org\n",
> > +			customer_id);
> 
> Surely this should be a break as you want to set the vendor. You've
> established its an RDC at this point have you not - so you want to set
> x86_vendor.

Right, please find updated version below.
--
From: Mark Kelly <mark@bifferos.com>

The RDC System-on-Chip i486 compatible core does not support the cpuid
instruction and specific detection logic is required for this chip. The patch
below adds proper vendor and SoC type detection.

Signed-off-by: Mark Kelly <mark@bifferos.com>
Tested-by: Florian Fainelli <florian@openwrt.org>
---
diff --git a/Documentation/x86/rdc.txt b/Documentation/x86/rdc.txt
new file mode 100644
index 0000000..f9591af
--- /dev/null
+++ b/Documentation/x86/rdc.txt
@@ -0,0 +1,69 @@
+
+Introduction
+============
+
+RDC (http://www.rdc.com.tw) have been manufacturing x86-compatible SoC
+(system-on-chips) for a number of years.  They are not the fastest of
+CPUs (clock speeds ranging from 133-150MHz) but 486SX compatibility
+coupled with very low power consumption[1] and low cost make them ideal
+for embedded applications.
+
+
+Where to find
+=============
+
+RDC chips show up in numerous embedded devices, but be careful since
+many of them will not run Linux 2.6 without significant expertise.
+
+There are several variants of what the linux kernel refers to generically
+as RDC321X:  R8610, R321x, S3282 and AMRISC20000.
+
+R321x: Found in various routers, see the OpenWrt project for details,
+   http://wiki.openwrt.org/oldwiki/rdcport
+
+R8610: Found on the RDC evaluation board
+   http://www.ivankuten.com/system-on-chip-soc/rdc-r8610/
+
+AMRISC20000: Found in the MGB-100 wireless hard disk
+   http://tintuc.no-ip.com/linux/tipps/mgb100/
+
+S3282: Found in various NAS devices, including the Bifferboard
+   http://www.bifferos.com
+
+
+Kernel Configuration
+====================
+
+Add support for this CPU with CONFIG_X86_RDC321X.  Ensure that maths
+emulation is included (CONFIG_MATH_EMULATION selected) and avoid MCE
+(CONFIG_X86_MCE not selected).
+
+
+CPU detection
+=============
+
+None of these chips support the cpuid instruction, so as with some
+other x86 compatible SoCs, we must check the north bridge and look
+for specific 'signature' PCI device config.
+
+The current detection code has been tested only on the Bifferboard
+(S3282 CPU), please send bug reports or success stories with
+other devices to bifferos@yahoo.co.uk.
+
+
+Credits
+=======
+
+Many thanks to RDC for providing the customer codes to allow
+detection of all known variants, without which this detection code
+would have been very hard to ascertain.
+
+
+References
+==========
+
+[1] S3282 in certain NAS solutions consumes less than 1W
+
+
+mark@bifferos.com 2009
+
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 39e8e10..21b02f2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -419,6 +419,7 @@ config X86_RDC321X
 	bool "RDC R-321x SoC"
 	depends on X86_32
 	depends on X86_EXTENDED_PLATFORM
+	select PCI
 	select M486
 	select X86_REBOOTFIXUPS
 	---help---
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 5a51379..eddf979 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -122,7 +122,8 @@ struct cpuinfo_x86 {
 #define X86_VENDOR_CENTAUR	5
 #define X86_VENDOR_TRANSMETA	7
 #define X86_VENDOR_NSC		8
-#define X86_VENDOR_NUM		9
+#define X86_VENDOR_RDC		9
+#define X86_VENDOR_NUM		10
 
 #define X86_VENDOR_UNKNOWN	0xff
 
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 3a785da..af2d4a6 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
 obj-$(CONFIG_CPU_SUP_CENTAUR)		+= centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
+obj-$(CONFIG_X86_RDC321X)		+= rdc.o
 
 obj-$(CONFIG_PERF_EVENTS)		+= perf_event.o
 
diff --git a/arch/x86/kernel/cpu/rdc.c b/arch/x86/kernel/cpu/rdc.c
new file mode 100644
index 0000000..909c2b5
--- /dev/null
+++ b/arch/x86/kernel/cpu/rdc.c
@@ -0,0 +1,71 @@
+/*
+ * See Documentation/x86/rdc.txt
+ *
+ * mark@bifferos.com
+ */
+
+#include <linux/pci.h>
+#include <asm/pci-direct.h>
+#include "cpu.h"
+
+
+static void __cpuinit rdc_identify(struct cpuinfo_x86 *c)
+{
+	u16 vendor, device;
+	u32 customer_id;
+
+	if (!early_pci_allowed())
+		return;
+
+	/* RDC CPU is SoC (system-on-chip), Northbridge is always present */
+	vendor = read_pci_config_16(0, 0, 0, PCI_VENDOR_ID);
+	device = read_pci_config_16(0, 0, 0, PCI_DEVICE_ID);
+
+	if (vendor != PCI_VENDOR_ID_RDC || device != PCI_DEVICE_ID_RDC_R6020)
+		return;  /* not RDC */
+	/*
+	 * NB: We could go on and check other devices, e.g. r6040 NIC, but
+	 * that's probably overkill
+	 */
+
+	customer_id = read_pci_config(0, 0, 0, 0x90);
+
+	switch (customer_id) {
+		/* id names are from RDC */
+	case 0x00321000:
+		strcpy(c->x86_model_id, "R3210/R3211");
+		break;
+	case 0x00321001:
+		strcpy(c->x86_model_id, "AMITRISC20000/20010");
+		break;
+	case 0x00321002:
+		strcpy(c->x86_model_id, "R3210X/Edimax");
+		break;
+	case 0x00321003:
+		strcpy(c->x86_model_id, "R3210/Kcodes");
+		break;
+	case 0x00321004:  /* tested */
+		strcpy(c->x86_model_id, "S3282/CodeTek");
+		break;
+	case 0x00321007:
+		strcpy(c->x86_model_id, "R8610");
+		break;
+	default:
+		pr_info("RDC CPU: Unrecognised Customer ID (0x%x) please "
+			"report to: linux-kernel@vger.kernel.org\n",
+			customer_id);
+		break;
+	}
+
+	strcpy(c->x86_vendor_id, "RDC");
+	c->x86_vendor = X86_VENDOR_RDC;
+}
+
+static const struct cpu_dev __cpuinitconst rdc_cpu_dev = {
+	.c_vendor	= "RDC",
+	.c_ident	= { "RDC" },
+	.c_identify	= rdc_identify,
+	.c_x86_vendor	= X86_VENDOR_RDC,
+};
+
+cpu_dev_register(rdc_cpu_dev);

Re: [PATCH] x86: CPU detection for RDC System-on-Chip

[H. Peter Anvin]

On 05/16/2010 06:21 AM, Florian Fainelli wrote:
>  
> diff --git a/arch/x86/kernel/cpu/rdc.c b/arch/x86/kernel/cpu/rdc.c
> new file mode 100644
> index 0000000..909c2b5
> --- /dev/null
> +++ b/arch/x86/kernel/cpu/rdc.c
> @@ -0,0 +1,71 @@
> +/*
> + * See Documentation/x86/rdc.txt
> + *
> + * mark@bifferos.com
> + */
> +
> +#include <linux/pci.h>
> +#include <asm/pci-direct.h>
> +#include "cpu.h"
> +
> +
> +static void __cpuinit rdc_identify(struct cpuinfo_x86 *c)
> +{
> +	u16 vendor, device;
> +	u32 customer_id;
> +
> +	if (!early_pci_allowed())
> +		return;
> +
> +	/* RDC CPU is SoC (system-on-chip), Northbridge is always present */
> +	vendor = read_pci_config_16(0, 0, 0, PCI_VENDOR_ID);
> +	device = read_pci_config_16(0, 0, 0, PCI_DEVICE_ID);
> +
> +	if (vendor != PCI_VENDOR_ID_RDC || device != PCI_DEVICE_ID_RDC_R6020)
> +		return;  /* not RDC */
> +	/*
> +	 * NB: We could go on and check other devices, e.g. r6040 NIC, but
> +	 * that's probably overkill
> +	 */
> +
> +	customer_id = read_pci_config(0, 0, 0, 0x90);
> +
> +	switch (customer_id) {
> +		/* id names are from RDC */
> +	case 0x00321000:
> +		strcpy(c->x86_model_id, "R3210/R3211");
> +		break;
> +	case 0x00321001:
> +		strcpy(c->x86_model_id, "AMITRISC20000/20010");
> +		break;
> +	case 0x00321002:
> +		strcpy(c->x86_model_id, "R3210X/Edimax");
> +		break;
> +	case 0x00321003:
> +		strcpy(c->x86_model_id, "R3210/Kcodes");
> +		break;
> +	case 0x00321004:  /* tested */
> +		strcpy(c->x86_model_id, "S3282/CodeTek");
> +		break;
> +	case 0x00321007:
> +		strcpy(c->x86_model_id, "R8610");
> +		break;
> +	default:
> +		pr_info("RDC CPU: Unrecognised Customer ID (0x%x) please "
> +			"report to: linux-kernel@vger.kernel.org\n",
> +			customer_id);
> +		break;

This pr_info() is completely useless... reporting things to LKML is very
likely to get lost in the din.  If someone (like yourself) wants to be
the maintainer for it that's one thing, otherwise it's probably better
to tell them to file a bugzilla... or just report it as "unknown" like
we do for all other CPU vendors.

> +	}
> +
> +	strcpy(c->x86_vendor_id, "RDC");
> +	c->x86_vendor = X86_VENDOR_RDC;
> +}
> +
> +static const struct cpu_dev __cpuinitconst rdc_cpu_dev = {
> +	.c_vendor	= "RDC",
> +	.c_ident	= { "RDC" },
> +	.c_identify	= rdc_identify,
> +	.c_x86_vendor	= X86_VENDOR_RDC,
> +};
> +
> +cpu_dev_register(rdc_cpu_dev);

.c_ident here is bogus: c_ident is supposed to represent the CPUID
string, but this device apparently doesn't have CPUID.

This adds at least one PCI reference to every boot on every device.  As
such, at least please read vendor and device as a single 32-bit
reference.  Since this identification isn't actually used for any real
purpose (like workarounds) we could also set it up as a PCI quirk... but
it's probably better to just keep the same code flow.

	-hpa



-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH] x86: CPU detection for RDC System-on-Chip

[Florian Fainelli]

Hi,

Le lundi 17 mai 2010 00:07:48, H. Peter Anvin a écrit :
> On 05/16/2010 06:21 AM, Florian Fainelli wrote:
> > diff --git a/arch/x86/kernel/cpu/rdc.c b/arch/x86/kernel/cpu/rdc.c
> > new file mode 100644
> > index 0000000..909c2b5
> > --- /dev/null
> > +++ b/arch/x86/kernel/cpu/rdc.c
> > @@ -0,0 +1,71 @@
> > +/*
> > + * See Documentation/x86/rdc.txt
> > + *
> > + * mark@bifferos.com
> > + */
> > +
> > +#include <linux/pci.h>
> > +#include <asm/pci-direct.h>
> > +#include "cpu.h"
> > +
> > +
> > +static void __cpuinit rdc_identify(struct cpuinfo_x86 *c)
> > +{
> > +	u16 vendor, device;
> > +	u32 customer_id;
> > +
> > +	if (!early_pci_allowed())
> > +		return;
> > +
> > +	/* RDC CPU is SoC (system-on-chip), Northbridge is always present */
> > +	vendor = read_pci_config_16(0, 0, 0, PCI_VENDOR_ID);
> > +	device = read_pci_config_16(0, 0, 0, PCI_DEVICE_ID);
> > +
> > +	if (vendor != PCI_VENDOR_ID_RDC || device != PCI_DEVICE_ID_RDC_R6020)
> > +		return;  /* not RDC */
> > +	/*
> > +	 * NB: We could go on and check other devices, e.g. r6040 NIC, but
> > +	 * that's probably overkill
> > +	 */
> > +
> > +	customer_id = read_pci_config(0, 0, 0, 0x90);
> > +
> > +	switch (customer_id) {
> > +		/* id names are from RDC */
> > +	case 0x00321000:
> > +		strcpy(c->x86_model_id, "R3210/R3211");
> > +		break;
> > +	case 0x00321001:
> > +		strcpy(c->x86_model_id, "AMITRISC20000/20010");
> > +		break;
> > +	case 0x00321002:
> > +		strcpy(c->x86_model_id, "R3210X/Edimax");
> > +		break;
> > +	case 0x00321003:
> > +		strcpy(c->x86_model_id, "R3210/Kcodes");
> > +		break;
> > +	case 0x00321004:  /* tested */
> > +		strcpy(c->x86_model_id, "S3282/CodeTek");
> > +		break;
> > +	case 0x00321007:
> > +		strcpy(c->x86_model_id, "R8610");
> > +		break;
> > +	default:
> > +		pr_info("RDC CPU: Unrecognised Customer ID (0x%x) please "
> > +			"report to: linux-kernel@vger.kernel.org\n",
> > +			customer_id);
> > +		break;
> 
> This pr_info() is completely useless... reporting things to LKML is very
> likely to get lost in the din.  If someone (like yourself) wants to be
> the maintainer for it that's one thing, otherwise it's probably better
> to tell them to file a bugzilla... or just report it as "unknown" like
> we do for all other CPU vendors.

Allright, filling a bugzilla entry sounds okay with me.

> 
> > +	}
> > +
> > +	strcpy(c->x86_vendor_id, "RDC");
> > +	c->x86_vendor = X86_VENDOR_RDC;
> > +}
> > +
> > +static const struct cpu_dev __cpuinitconst rdc_cpu_dev = {
> > +	.c_vendor	= "RDC",
> > +	.c_ident	= { "RDC" },
> > +	.c_identify	= rdc_identify,
> > +	.c_x86_vendor	= X86_VENDOR_RDC,
> > +};
> > +
> > +cpu_dev_register(rdc_cpu_dev);
> 
> .c_ident here is bogus: c_ident is supposed to represent the CPUID
> string, but this device apparently doesn't have CPUID.
> 
> This adds at least one PCI reference to every boot on every device.  As
> such, at least please read vendor and device as a single 32-bit
> reference.  Since this identification isn't actually used for any real
> purpose (like workarounds) we could also set it up as a PCI quirk... but
> it's probably better to just keep the same code flow.

More precisely, every device that has X86_RDC321X set in its kernel. I want to
get this merged first before actually using it, but the real purpose is to have 
different board flavors which register platform devices for the various models 
of RDC-based devices. Having this detection logic based on the RDC model is 
imho much cleaner than poking at the first bytes of the NOR flash and check the 
vendor firmware header.

As where to put those board files, this is another topic.
--
Florian

Re: [PATCH] x86: CPU detection for RDC System-on-Chip

[Florian Fainelli]

On Monday 17 May 2010 00:07:48 H. Peter Anvin wrote:
> On 05/16/2010 06:21 AM, Florian Fainelli wrote:
> > diff --git a/arch/x86/kernel/cpu/rdc.c b/arch/x86/kernel/cpu/rdc.c
> > new file mode 100644
> > index 0000000..909c2b5
> > --- /dev/null
> > +++ b/arch/x86/kernel/cpu/rdc.c
> > @@ -0,0 +1,71 @@
> > +/*
> > + * See Documentation/x86/rdc.txt
> > + *
> > + * mark@bifferos.com
> > + */
> > +
> > +#include <linux/pci.h>
> > +#include <asm/pci-direct.h>
> > +#include "cpu.h"
> > +
> > +
> > +static void __cpuinit rdc_identify(struct cpuinfo_x86 *c)
> > +{
> > +	u16 vendor, device;
> > +	u32 customer_id;
> > +
> > +	if (!early_pci_allowed())
> > +		return;
> > +
> > +	/* RDC CPU is SoC (system-on-chip), Northbridge is always present */
> > +	vendor = read_pci_config_16(0, 0, 0, PCI_VENDOR_ID);
> > +	device = read_pci_config_16(0, 0, 0, PCI_DEVICE_ID);
> > +
> > +	if (vendor != PCI_VENDOR_ID_RDC || device != 
PCI_DEVICE_ID_RDC_R6020)
> > +		return;  /* not RDC */
> > +	/*
> > +	 * NB: We could go on and check other devices, e.g. r6040 NIC, but
> > +	 * that's probably overkill
> > +	 */
> > +
> > +	customer_id = read_pci_config(0, 0, 0, 0x90);
> > +
> > +	switch (customer_id) {
> > +		/* id names are from RDC */
> > +	case 0x00321000:
> > +		strcpy(c->x86_model_id, "R3210/R3211");
> > +		break;
> > +	case 0x00321001:
> > +		strcpy(c->x86_model_id, "AMITRISC20000/20010");
> > +		break;
> > +	case 0x00321002:
> > +		strcpy(c->x86_model_id, "R3210X/Edimax");
> > +		break;
> > +	case 0x00321003:
> > +		strcpy(c->x86_model_id, "R3210/Kcodes");
> > +		break;
> > +	case 0x00321004:  /* tested */
> > +		strcpy(c->x86_model_id, "S3282/CodeTek");
> > +		break;
> > +	case 0x00321007:
> > +		strcpy(c->x86_model_id, "R8610");
> > +		break;
> > +	default:
> > +		pr_info("RDC CPU: Unrecognised Customer ID (0x%x) please "
> > +			"report to: linux-kernel@vger.kernel.org\n",
> > +			customer_id);
> > +		break;
> 
> This pr_info() is completely useless... reporting things to LKML is very
> likely to get lost in the din.  If someone (like yourself) wants to be
> the maintainer for it that's one thing, otherwise it's probably better
> to tell them to file a bugzilla... or just report it as "unknown" like
> we do for all other CPU vendors.
> 
> > +	}
> > +
> > +	strcpy(c->x86_vendor_id, "RDC");
> > +	c->x86_vendor = X86_VENDOR_RDC;
> > +}
> > +
> > +static const struct cpu_dev __cpuinitconst rdc_cpu_dev = {
> > +	.c_vendor	= "RDC",
> > +	.c_ident	= { "RDC" },
> > +	.c_identify	= rdc_identify,
> > +	.c_x86_vendor	= X86_VENDOR_RDC,
> > +};
> > +
> > +cpu_dev_register(rdc_cpu_dev);
> 
> .c_ident here is bogus: c_ident is supposed to represent the CPUID
> string, but this device apparently doesn't have CPUID.

What do you suggest to use instead? Shall I put the x86_model_id there?

> 
> This adds at least one PCI reference to every boot on every device.  As
> such, at least please read vendor and device as a single 32-bit
> reference.  Since this identification isn't actually used for any real
> purpose (like workarounds) we could also set it up as a PCI quirk... but
> it's probably better to just keep the same code flow.
> 
> 	-hpa

[PATCH v3] x86: CPU detection for RDC System-on-Chip

[Florian Fainelli]

From: Mark Kelly <mark@bifferos.com>

The RDC System-on-Chip i486 compatible core does not support the cpuid
instruction and specific detection logic is required for this chip. The patch
below adds proper vendor and SoC type detection.

Signed-off-by: Mark Kelly <mark@bifferos.com>
Tested-by: Florian Fainelli <florian@openwrt.org>
---
Changes from v3:
- read vendor and device id with a single 32-bits read

Changes from v2:
- change report url to bugzilla.kernel.org
- set vendor name to RDC even if customer id is not known

diff --git a/Documentation/x86/rdc.txt b/Documentation/x86/rdc.txt
new file mode 100644
index 0000000..f3dc7cf
--- /dev/null
+++ b/Documentation/x86/rdc.txt
@@ -0,0 +1,67 @@
+
+Introduction
+============
+
+RDC (http://www.rdc.com.tw) have been manufacturing x86-compatible SoC
+(system-on-chips) for a number of years.  They are not the fastest of
+CPUs (clock speeds ranging from 133-150MHz) but 486SX compatibility
+coupled with very low power consumption[1] and low cost make them ideal
+for embedded applications.
+
+
+Where to find
+=============
+
+RDC chips show up in numerous embedded devices, but be careful since
+many of them will not run Linux 2.6 without significant expertise.
+
+There are several variants of what the linux kernel refers to generically
+as RDC321X:  R8610, R321x, S3282 and AMRISC20000.
+
+R321x: Found in various routers, see the OpenWrt project for details,
+   http://wiki.openwrt.org/oldwiki/rdcport
+
+R8610: Found on the RDC evaluation board
+   http://www.ivankuten.com/system-on-chip-soc/rdc-r8610/
+
+AMRISC20000: Found in the MGB-100 wireless hard disk
+   http://tintuc.no-ip.com/linux/tipps/mgb100/
+
+S3282: Found in various NAS devices, including the Bifferboard
+   http://www.bifferos.com
+
+
+Kernel Configuration
+====================
+
+Add support for this CPU with CONFIG_X86_RDC321X.  Ensure that maths
+emulation is included (CONFIG_MATH_EMULATION selected) and avoid MCE
+(CONFIG_X86_MCE not selected).
+
+
+CPU detection
+=============
+
+None of these chips support the cpuid instruction, so as with some
+other x86 compatible SoCs, we must check the north bridge and look
+for specific 'signature' PCI device config.
+
+If you run a kernel on an unsupported customer id device, please file
+a bug with your customer id to: http://bugzilla.kernel.org/.
+
+Credits
+=======
+
+Many thanks to RDC for providing the customer codes to allow
+detection of all known variants, without which this detection code
+would have been very hard to ascertain.
+
+
+References
+==========
+
+[1] S3282 in certain NAS solutions consumes less than 1W
+
+
+mark@bifferos.com 2009
+
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 39e8e10..21b02f2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -419,6 +419,7 @@ config X86_RDC321X
 	bool "RDC R-321x SoC"
 	depends on X86_32
 	depends on X86_EXTENDED_PLATFORM
+	select PCI
 	select M486
 	select X86_REBOOTFIXUPS
 	---help---
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 5a51379..eddf979 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -122,7 +122,8 @@ struct cpuinfo_x86 {
 #define X86_VENDOR_CENTAUR	5
 #define X86_VENDOR_TRANSMETA	7
 #define X86_VENDOR_NSC		8
-#define X86_VENDOR_NUM		9
+#define X86_VENDOR_RDC		9
+#define X86_VENDOR_NUM		10
 
 #define X86_VENDOR_UNKNOWN	0xff
 
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 3a785da..af2d4a6 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
 obj-$(CONFIG_CPU_SUP_CENTAUR)		+= centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
+obj-$(CONFIG_X86_RDC321X)		+= rdc.o
 
 obj-$(CONFIG_PERF_EVENTS)		+= perf_event.o
 
diff --git a/arch/x86/kernel/cpu/rdc.c b/arch/x86/kernel/cpu/rdc.c
new file mode 100644
index 0000000..c2bcdcc
--- /dev/null
+++ b/arch/x86/kernel/cpu/rdc.c
@@ -0,0 +1,73 @@
+/*
+ * See Documentation/x86/rdc.txt
+ *
+ * mark@bifferos.com
+ */
+
+#include <linux/pci.h>
+#include <asm/pci-direct.h>
+#include "cpu.h"
+
+
+static void __cpuinit rdc_identify(struct cpuinfo_x86 *c)
+{
+	u32 id;
+	u16 vendor, device;
+	u32 customer_id;
+
+	if (!early_pci_allowed())
+		return;
+
+	/* RDC CPU is SoC (system-on-chip), Northbridge is always present */
+	id = read_pci_config(0, 0, 0, PCI_VENDOR_ID);
+	vendor = id & 0xffff;
+	device = (id >> 16) & 0xffff;
+
+	if (vendor != PCI_VENDOR_ID_RDC || device != PCI_DEVICE_ID_RDC_R6020)
+		return;  /* not RDC */
+	/*
+	 * NB: We could go on and check other devices, e.g. r6040 NIC, but
+	 * that's probably overkill
+	 */
+
+	customer_id = read_pci_config(0, 0, 0, 0x90);
+
+	switch (customer_id) {
+		/* id names are from RDC */
+	case 0x00321000:
+		strcpy(c->x86_model_id, "R3210/R3211");
+		break;
+	case 0x00321001:
+		strcpy(c->x86_model_id, "AMITRISC20000/20010");
+		break;
+	case 0x00321002:
+		strcpy(c->x86_model_id, "R3210X/Edimax");
+		break;
+	case 0x00321003:
+		strcpy(c->x86_model_id, "R3210/Kcodes");
+		break;
+	case 0x00321004:  /* tested */
+		strcpy(c->x86_model_id, "S3282/CodeTek");
+		break;
+	case 0x00321007:
+		strcpy(c->x86_model_id, "R8610");
+		break;
+	default:
+		pr_info("RDC CPU: Unrecognised Customer ID (0x%x) please "
+			"report to: http://bugzilla.kernel.org/\n",
+			customer_id);
+		break;
+	}
+
+	strcpy(c->x86_vendor_id, "RDC");
+	c->x86_vendor = X86_VENDOR_RDC;
+}
+
+static const struct cpu_dev __cpuinitconst rdc_cpu_dev = {
+	.c_vendor	= "RDC",
+	.c_ident	= { "RDC" },
+	.c_identify	= rdc_identify,
+	.c_x86_vendor	= X86_VENDOR_RDC,
+};
+
+cpu_dev_register(rdc_cpu_dev);

Re: [PATCH v3] x86: CPU detection for RDC System-on-Chip

[Florian Fainelli]

On Wednesday 19 May 2010 09:27:12 Florian Fainelli wrote:
> From: Mark Kelly <mark@bifferos.com>
> 
> The RDC System-on-Chip i486 compatible core does not support the cpuid
> instruction and specific detection logic is required for this chip. The
> patch below adds proper vendor and SoC type detection.

Is this version acceptable like it is now?

Thank you for your answer.

> 
> Signed-off-by: Mark Kelly <mark@bifferos.com>
> Tested-by: Florian Fainelli <florian@openwrt.org>
> ---
> Changes from v3:
> - read vendor and device id with a single 32-bits read
> 
> Changes from v2:
> - change report url to bugzilla.kernel.org
> - set vendor name to RDC even if customer id is not known
> 
> diff --git a/Documentation/x86/rdc.txt b/Documentation/x86/rdc.txt
> new file mode 100644
> index 0000000..f3dc7cf
> --- /dev/null
> +++ b/Documentation/x86/rdc.txt
> @@ -0,0 +1,67 @@
> +
> +Introduction
> +============
> +
> +RDC (http://www.rdc.com.tw) have been manufacturing x86-compatible SoC
> +(system-on-chips) for a number of years.  They are not the fastest of
> +CPUs (clock speeds ranging from 133-150MHz) but 486SX compatibility
> +coupled with very low power consumption[1] and low cost make them ideal
> +for embedded applications.
> +
> +
> +Where to find
> +=============
> +
> +RDC chips show up in numerous embedded devices, but be careful since
> +many of them will not run Linux 2.6 without significant expertise.
> +
> +There are several variants of what the linux kernel refers to generically
> +as RDC321X:  R8610, R321x, S3282 and AMRISC20000.
> +
> +R321x: Found in various routers, see the OpenWrt project for details,
> +   http://wiki.openwrt.org/oldwiki/rdcport
> +
> +R8610: Found on the RDC evaluation board
> +   http://www.ivankuten.com/system-on-chip-soc/rdc-r8610/
> +
> +AMRISC20000: Found in the MGB-100 wireless hard disk
> +   http://tintuc.no-ip.com/linux/tipps/mgb100/
> +
> +S3282: Found in various NAS devices, including the Bifferboard
> +   http://www.bifferos.com
> +
> +
> +Kernel Configuration
> +====================
> +
> +Add support for this CPU with CONFIG_X86_RDC321X.  Ensure that maths
> +emulation is included (CONFIG_MATH_EMULATION selected) and avoid MCE
> +(CONFIG_X86_MCE not selected).
> +
> +
> +CPU detection
> +=============
> +
> +None of these chips support the cpuid instruction, so as with some
> +other x86 compatible SoCs, we must check the north bridge and look
> +for specific 'signature' PCI device config.
> +
> +If you run a kernel on an unsupported customer id device, please file
> +a bug with your customer id to: http://bugzilla.kernel.org/.
> +
> +Credits
> +=======
> +
> +Many thanks to RDC for providing the customer codes to allow
> +detection of all known variants, without which this detection code
> +would have been very hard to ascertain.
> +
> +
> +References
> +==========
> +
> +[1] S3282 in certain NAS solutions consumes less than 1W
> +
> +
> +mark@bifferos.com 2009
> +
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 39e8e10..21b02f2 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -419,6 +419,7 @@ config X86_RDC321X
>  	bool "RDC R-321x SoC"
>  	depends on X86_32
>  	depends on X86_EXTENDED_PLATFORM
> +	select PCI
>  	select M486
>  	select X86_REBOOTFIXUPS
>  	---help---
> diff --git a/arch/x86/include/asm/processor.h
> b/arch/x86/include/asm/processor.h index 5a51379..eddf979 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -122,7 +122,8 @@ struct cpuinfo_x86 {
>  #define X86_VENDOR_CENTAUR	5
>  #define X86_VENDOR_TRANSMETA	7
>  #define X86_VENDOR_NSC		8
> -#define X86_VENDOR_NUM		9
> +#define X86_VENDOR_RDC		9
> +#define X86_VENDOR_NUM		10
> 
>  #define X86_VENDOR_UNKNOWN	0xff
> 
> diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
> index 3a785da..af2d4a6 100644
> --- a/arch/x86/kernel/cpu/Makefile
> +++ b/arch/x86/kernel/cpu/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
>  obj-$(CONFIG_CPU_SUP_CENTAUR)		+= centaur.o
>  obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
>  obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
> +obj-$(CONFIG_X86_RDC321X)		+= rdc.o
> 
>  obj-$(CONFIG_PERF_EVENTS)		+= perf_event.o
> 
> diff --git a/arch/x86/kernel/cpu/rdc.c b/arch/x86/kernel/cpu/rdc.c
> new file mode 100644
> index 0000000..c2bcdcc
> --- /dev/null
> +++ b/arch/x86/kernel/cpu/rdc.c
> @@ -0,0 +1,73 @@
> +/*
> + * See Documentation/x86/rdc.txt
> + *
> + * mark@bifferos.com
> + */
> +
> +#include <linux/pci.h>
> +#include <asm/pci-direct.h>
> +#include "cpu.h"
> +
> +
> +static void __cpuinit rdc_identify(struct cpuinfo_x86 *c)
> +{
> +	u32 id;
> +	u16 vendor, device;
> +	u32 customer_id;
> +
> +	if (!early_pci_allowed())
> +		return;
> +
> +	/* RDC CPU is SoC (system-on-chip), Northbridge is always present */
> +	id = read_pci_config(0, 0, 0, PCI_VENDOR_ID);
> +	vendor = id & 0xffff;
> +	device = (id >> 16) & 0xffff;
> +
> +	if (vendor != PCI_VENDOR_ID_RDC || device != PCI_DEVICE_ID_RDC_R6020)
> +		return;  /* not RDC */
> +	/*
> +	 * NB: We could go on and check other devices, e.g. r6040 NIC, but
> +	 * that's probably overkill
> +	 */
> +
> +	customer_id = read_pci_config(0, 0, 0, 0x90);
> +
> +	switch (customer_id) {
> +		/* id names are from RDC */
> +	case 0x00321000:
> +		strcpy(c->x86_model_id, "R3210/R3211");
> +		break;
> +	case 0x00321001:
> +		strcpy(c->x86_model_id, "AMITRISC20000/20010");
> +		break;
> +	case 0x00321002:
> +		strcpy(c->x86_model_id, "R3210X/Edimax");
> +		break;
> +	case 0x00321003:
> +		strcpy(c->x86_model_id, "R3210/Kcodes");
> +		break;
> +	case 0x00321004:  /* tested */
> +		strcpy(c->x86_model_id, "S3282/CodeTek");
> +		break;
> +	case 0x00321007:
> +		strcpy(c->x86_model_id, "R8610");
> +		break;
> +	default:
> +		pr_info("RDC CPU: Unrecognised Customer ID (0x%x) please "
> +			"report to: http://bugzilla.kernel.org/\n",
> +			customer_id);
> +		break;
> +	}
> +
> +	strcpy(c->x86_vendor_id, "RDC");
> +	c->x86_vendor = X86_VENDOR_RDC;
> +}
> +
> +static const struct cpu_dev __cpuinitconst rdc_cpu_dev = {
> +	.c_vendor	= "RDC",
> +	.c_ident	= { "RDC" },
> +	.c_identify	= rdc_identify,
> +	.c_x86_vendor	= X86_VENDOR_RDC,
> +};
> +
> +cpu_dev_register(rdc_cpu_dev);

Re: [PATCH v3] x86: CPU detection for RDC System-on-Chip

[Florian Fainelli]

On Thursday 20 May 2010 16:58:48 Florian Fainelli wrote:
> On Wednesday 19 May 2010 09:27:12 Florian Fainelli wrote:
> > From: Mark Kelly <mark@bifferos.com>
> > 
> > The RDC System-on-Chip i486 compatible core does not support the cpuid
> > instruction and specific detection logic is required for this chip. The
> > patch below adds proper vendor and SoC type detection.
> 
> Is this version acceptable like it is now?

Ping? Anything that should be reworked?

Thank you.

> 
> Thank you for your answer.
> 
> > Signed-off-by: Mark Kelly <mark@bifferos.com>
> > Tested-by: Florian Fainelli <florian@openwrt.org>
> > ---
> > Changes from v3:
> > - read vendor and device id with a single 32-bits read
> > 
> > Changes from v2:
> > - change report url to bugzilla.kernel.org
> > - set vendor name to RDC even if customer id is not known
> > 
> > diff --git a/Documentation/x86/rdc.txt b/Documentation/x86/rdc.txt
> > new file mode 100644
> > index 0000000..f3dc7cf
> > --- /dev/null
> > +++ b/Documentation/x86/rdc.txt
> > @@ -0,0 +1,67 @@
> > +
> > +Introduction
> > +============
> > +
> > +RDC (http://www.rdc.com.tw) have been manufacturing x86-compatible SoC
> > +(system-on-chips) for a number of years.  They are not the fastest of
> > +CPUs (clock speeds ranging from 133-150MHz) but 486SX compatibility
> > +coupled with very low power consumption[1] and low cost make them ideal
> > +for embedded applications.
> > +
> > +
> > +Where to find
> > +=============
> > +
> > +RDC chips show up in numerous embedded devices, but be careful since
> > +many of them will not run Linux 2.6 without significant expertise.
> > +
> > +There are several variants of what the linux kernel refers to
> > generically +as RDC321X:  R8610, R321x, S3282 and AMRISC20000.
> > +
> > +R321x: Found in various routers, see the OpenWrt project for details,
> > +   http://wiki.openwrt.org/oldwiki/rdcport
> > +
> > +R8610: Found on the RDC evaluation board
> > +   http://www.ivankuten.com/system-on-chip-soc/rdc-r8610/
> > +
> > +AMRISC20000: Found in the MGB-100 wireless hard disk
> > +   http://tintuc.no-ip.com/linux/tipps/mgb100/
> > +
> > +S3282: Found in various NAS devices, including the Bifferboard
> > +   http://www.bifferos.com
> > +
> > +
> > +Kernel Configuration
> > +====================
> > +
> > +Add support for this CPU with CONFIG_X86_RDC321X.  Ensure that maths
> > +emulation is included (CONFIG_MATH_EMULATION selected) and avoid MCE
> > +(CONFIG_X86_MCE not selected).
> > +
> > +
> > +CPU detection
> > +=============
> > +
> > +None of these chips support the cpuid instruction, so as with some
> > +other x86 compatible SoCs, we must check the north bridge and look
> > +for specific 'signature' PCI device config.
> > +
> > +If you run a kernel on an unsupported customer id device, please file
> > +a bug with your customer id to: http://bugzilla.kernel.org/.
> > +
> > +Credits
> > +=======
> > +
> > +Many thanks to RDC for providing the customer codes to allow
> > +detection of all known variants, without which this detection code
> > +would have been very hard to ascertain.
> > +
> > +
> > +References
> > +==========
> > +
> > +[1] S3282 in certain NAS solutions consumes less than 1W
> > +
> > +
> > +mark@bifferos.com 2009
> > +
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 39e8e10..21b02f2 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -419,6 +419,7 @@ config X86_RDC321X
> > 
> >  	bool "RDC R-321x SoC"
> >  	depends on X86_32
> >  	depends on X86_EXTENDED_PLATFORM
> > 
> > +	select PCI
> > 
> >  	select M486
> >  	select X86_REBOOTFIXUPS
> >  	---help---
> > 
> > diff --git a/arch/x86/include/asm/processor.h
> > b/arch/x86/include/asm/processor.h index 5a51379..eddf979 100644
> > --- a/arch/x86/include/asm/processor.h
> > +++ b/arch/x86/include/asm/processor.h
> > @@ -122,7 +122,8 @@ struct cpuinfo_x86 {
> > 
> >  #define X86_VENDOR_CENTAUR	5
> >  #define X86_VENDOR_TRANSMETA	7
> >  #define X86_VENDOR_NSC		8
> > 
> > -#define X86_VENDOR_NUM		9
> > +#define X86_VENDOR_RDC		9
> > +#define X86_VENDOR_NUM		10
> > 
> >  #define X86_VENDOR_UNKNOWN	0xff
> > 
> > diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
> > index 3a785da..af2d4a6 100644
> > --- a/arch/x86/kernel/cpu/Makefile
> > +++ b/arch/x86/kernel/cpu/Makefile
> > @@ -25,6 +25,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
> > 
> >  obj-$(CONFIG_CPU_SUP_CENTAUR)		+= centaur.o
> >  obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
> >  obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
> > 
> > +obj-$(CONFIG_X86_RDC321X)		+= rdc.o
> > 
> >  obj-$(CONFIG_PERF_EVENTS)		+= perf_event.o
> > 
> > diff --git a/arch/x86/kernel/cpu/rdc.c b/arch/x86/kernel/cpu/rdc.c
> > new file mode 100644
> > index 0000000..c2bcdcc
> > --- /dev/null
> > +++ b/arch/x86/kernel/cpu/rdc.c
> > @@ -0,0 +1,73 @@
> > +/*
> > + * See Documentation/x86/rdc.txt
> > + *
> > + * mark@bifferos.com
> > + */
> > +
> > +#include <linux/pci.h>
> > +#include <asm/pci-direct.h>
> > +#include "cpu.h"
> > +
> > +
> > +static void __cpuinit rdc_identify(struct cpuinfo_x86 *c)
> > +{
> > +	u32 id;
> > +	u16 vendor, device;
> > +	u32 customer_id;
> > +
> > +	if (!early_pci_allowed())
> > +		return;
> > +
> > +	/* RDC CPU is SoC (system-on-chip), Northbridge is always present */
> > +	id = read_pci_config(0, 0, 0, PCI_VENDOR_ID);
> > +	vendor = id & 0xffff;
> > +	device = (id >> 16) & 0xffff;
> > +
> > +	if (vendor != PCI_VENDOR_ID_RDC || device != 
PCI_DEVICE_ID_RDC_R6020)
> > +		return;  /* not RDC */
> > +	/*
> > +	 * NB: We could go on and check other devices, e.g. r6040 NIC, but
> > +	 * that's probably overkill
> > +	 */
> > +
> > +	customer_id = read_pci_config(0, 0, 0, 0x90);
> > +
> > +	switch (customer_id) {
> > +		/* id names are from RDC */
> > +	case 0x00321000:
> > +		strcpy(c->x86_model_id, "R3210/R3211");
> > +		break;
> > +	case 0x00321001:
> > +		strcpy(c->x86_model_id, "AMITRISC20000/20010");
> > +		break;
> > +	case 0x00321002:
> > +		strcpy(c->x86_model_id, "R3210X/Edimax");
> > +		break;
> > +	case 0x00321003:
> > +		strcpy(c->x86_model_id, "R3210/Kcodes");
> > +		break;
> > +	case 0x00321004:  /* tested */
> > +		strcpy(c->x86_model_id, "S3282/CodeTek");
> > +		break;
> > +	case 0x00321007:
> > +		strcpy(c->x86_model_id, "R8610");
> > +		break;
> > +	default:
> > +		pr_info("RDC CPU: Unrecognised Customer ID (0x%x) please "
> > +			"report to: http://bugzilla.kernel.org/\n",
> > +			customer_id);
> > +		break;
> > +	}
> > +
> > +	strcpy(c->x86_vendor_id, "RDC");
> > +	c->x86_vendor = X86_VENDOR_RDC;
> > +}
> > +
> > +static const struct cpu_dev __cpuinitconst rdc_cpu_dev = {
> > +	.c_vendor	= "RDC",
> > +	.c_ident	= { "RDC" },
> > +	.c_identify	= rdc_identify,
> > +	.c_x86_vendor	= X86_VENDOR_RDC,
> > +};
> > +
> > +cpu_dev_register(rdc_cpu_dev);

Re: [PATCH] x86: CPU detection for RDC System-on-Chip

[Andi Kleen]

> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 39e8e10..21b02f2 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -419,6 +419,7 @@ config X86_RDC321X
>  	bool "RDC R-321x SoC"
>  	depends on X86_32
>  	depends on X86_EXTENDED_PLATFORM
> +	select PCI

If you don't actually need PCI in your SOC then you could easily
remove that dependency with some minor work. Early PCI really is quite 
independent from the other code and can be just used on its own. 

The only thing that would need sorting out is the command line 
interface for early_pci_enabled()

-Andi

Re: [PATCH] x86: CPU detection for RDC System-on-Chip

[Florian Fainelli]

On Monday 17 May 2010 13:23:58 Andi Kleen wrote:
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 39e8e10..21b02f2 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -419,6 +419,7 @@ config X86_RDC321X
> > 
> >  	bool "RDC R-321x SoC"
> >  	depends on X86_32
> >  	depends on X86_EXTENDED_PLATFORM
> > 
> > +	select PCI
> 
> If you don't actually need PCI in your SOC then you could easily
> remove that dependency with some minor work. Early PCI really is quite
> independent from the other code and can be just used on its own.

We actually do need PCI for the Ethernet MAC to work as well as the 
southbridge driver.

> 
> The only thing that would need sorting out is the command line
> interface for early_pci_enabled()
> 
> -Andi
> --
> 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/