RFC: cpm2_devices.c

RFC: cpm2_devices.c

[Allen Curtis]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

Please review and comment on the following.

My comments regarding the implementation:
1. This implementation uses the cpm_map_t structure definition to derive
the IORESOURCE_MEM regions. This seems to be more adaptible to CPM
address differences but it assumes that there are unique structures for
each processor type.

2. ppc_sys_spec appears to identify the CPM elements which are
applicable to a particular processor. So this structure, not the
cpm_map_t structure identifies the CPM resources. This implementation
addresses the the CPU differences but assumes that a CPM resource is
always at the same IMMAP address. The FCC, DPRAM usage is an example of
an exception to this rule.

Note: The attachment was generated via cg-diff, please let me know if
there is a preferred format.

Thanks


[-- Attachment #2: cpm2_devices.patch --]
[-- Type: text/x-patch, Size: 12562 bytes --]

diff --git a/arch/ppc/syslib/cpm2_devices.c b/arch/ppc/syslib/cpm2_devices.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/syslib/cpm2_devices.c
@@ -0,0 +1,460 @@
+/*
+ * arch/ppc/platforms/cpm2_devices.c
+ *
+ * General CPM2 Device descriptions
+ *
+ * Maintainer: Allen Curtis <acurtis@onz.com>
+ * Derived from mpc83xx_devices.c by Kumar Gala
+ *
+ * Copyright 2005 Ones and Zeros Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/fsl_devices.h>
+#include <asm/cpm2.h>
+#include <asm/irq.h>
+#include <asm/ppc_sys.h>
+
+/* We use offsets for IORESOURCE_MEM since we do not know at compile time
+ * what IMMRBAR is, will get fixed up by mach_mpc83xx_fixup
+ */
+
+#define CPM2_STARTOF(m)		(offsetof(cpm2_map_t,(m)))
+#define CCPM2_ENDOF(m)		(CPM_STARTOF(m)+sizeof(m)-1)
+
+/* Define the CPM2 platform devices
+ */
+struct platform_device ppc_sys_platform_devices[] = {
+	[CPM2_FCC1] = {
+		.name = "fsl-cpm-fcc",
+		.id	= 1,
+		.dev.platform_data = ,
+		.num_resources	 = 5,
+		.resource = (struct resource[]) {
+			{
+				.name	= "fcc_regs",
+				.start	= CPM2_STARTOF(im_fcc[0]),
+				.end	= CPM2_ENDOF(im_fcc[0]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "fcc_regs_c",
+				.start	= CPM2_STARTOF(im_fcc_c[0]),
+				.end	= CPM2_ENDOF(im_fcc_c[0]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "fcc_pram",
+				.start	= PROFF_FCC1,
+				.end	= PROFF_FCC1 + PROFF_FCC_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			/* fcc_mem
+			 * This should be allocated from DPRAM, not part
+			 * of this structure definition.
+			 */
+			{
+				.name	= "fcc_mem",
+				.start	= PROFF_FCC1_MEM_BASE,
+				.end	= PROFF_FCC1_MEM_BASE + PROFF_FCC_MEM_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= SIU_INT_FCC1,
+				.end	= SIU_INT_FCC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[CPM2_FCC2] = {
+		.name = "fsl-cpm-fcc",
+		.id	= 2,
+		.dev.platform_data = ,
+		.num_resources	 = 5,
+		.resource = (struct resource[]) {
+			{
+				.name	= "fcc_regs",
+				.start	= CPM2_STARTOF(im_fcc[1]),
+				.end	= CPM2_ENDOF(im_fcc[1]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "fcc_regs_c",
+				.start	= CPM2_STARTOF(im_fcc_c[1]),
+				.end	= CPM2_ENDOF(im_fcc_c[1]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "fcc_pram",
+				.start	= PROFF_FCC2,
+				.end	= PROFF_FCC2 + PROFF_FCC_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			/* fcc_mem
+			 * This should be allocated from DPRAM, not part
+			 * of this structure definition.
+			 */
+			{
+				.name	= "fcc_mem",
+				.start	= PROFF_FCC2_MEM_BASE,
+				.end	= PROFF_FCC2_MEM_BASE + PROFF_FCC_MEM_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= SIU_INT_FCC2,
+				.end	= SIU_INT_FCC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[CPM2_FCC3] = {
+		.name = "fsl-cpm-fcc",
+		.id	= 3,
+		.dev.platform_data = ,
+		.num_resources	 = 5,
+		.resource = (struct resource[]) {
+			{
+				.name	= "fcc_regs",
+				.start	= CPM2_STARTOF(im_fcc[2]),
+				.end	= CPM2_ENDOF(im_fcc[2]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "fcc_regs_c",
+				.start	= CPM2_STARTOF(im_fcc_c[2]),
+				.end	= CPM2_ENDOF(im_fcc_c[2]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "fcc_pram",
+				.start	= PROFF_FCC3,
+				.end	= PROFF_FCC3 + PROFF_FCC_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			/* fcc_mem
+			 * This should be allocated from DPRAM, not part
+			 * of this structure definition.
+			 */
+			{
+				.name	= "fcc_mem",
+				.start	= PROFF_FCC3_MEM_BASE,
+				.end	= PROFF_FCC3_MEM_BASE + PROFF_FCC_MEM_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= SIU_INT_FCC3,
+				.end	= SIU_INT_FCC3,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[CPM2_SCC1] = {
+		.name = "fsl-cpm-scc",
+		.id	= 1,
+		.dev.platform_data = ,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "scc_regs",
+				.start	= CPM2_STARTOF(im_scc[0]),
+				.end	= CPM2_ENDOF(im_scc[0]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "scc_pram",
+				.start	= PROFF_SCC1,
+				.end	= PROFF_SCC1 + PROFF_SCC_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= SIU_INT_SCC1,
+				.end	= SIU_INT_SCC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[CPM2_SCC2] = {
+		.name = "fsl-cpm-scc",
+		.id	= 2,
+		.dev.platform_data = ,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "scc_regs",
+				.start	= CPM2_STARTOF(im_scc[1]),
+				.end	= CPM2_ENDOF(im_scc[1]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "scc_pram",
+				.start	= PROFF_SCC2,
+				.end	= PROFF_SCC2 + PROFF_SCC_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= SIU_INT_SCC2,
+				.end	= SIU_INT_SCC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[CPM2_SCC3] = {
+		.name = "fsl-cpm-scc",
+		.id	= 3,
+		.dev.platform_data = ,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "scc_regs",
+				.start	= CPM2_STARTOF(im_scc[2]),
+				.end	= CPM2_ENDOF(im_scc[2]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "scc_pram",
+				.start	= PROFF_SCC3,
+				.end	= PROFF_SCC3 + PROFF_SCC_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= SIU_INT_SCC3,
+				.end	= SIU_INT_SCC3,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[CPM2_SCC4] = {
+		.name = "fsl-cpm-scc",
+		.id	= 4,
+		.dev.platform_data = ,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "scc_regs",
+				.start	= CPM2_STARTOF(im_scc[3]),
+				.end	= CPM2_ENDOF(im_scc[3]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "scc_pram",
+				.start	= PROFF_SCC4,
+				.end	= PROFF_SCC4 + PROFF_SCC_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= SIU_INT_SCC4,
+				.end	= SIU_INT_SCC4,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[CPM2_SMC1] = {
+		.name = "fsl-cpm-smc",
+		.id	= 1,
+		.dev.platform_data = ,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "smc_regs",
+				.start	= CPM2_STARTOF(im_smc[0]),
+				.end	= CPM2_ENDOF(im_smc[0]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "smc_pram",
+				.start	= PROFF_SMC1_BASE,
+				.end	= PROFF_SMC1_BASE + PROFF_SMC_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= SIU_INT_SMC1,
+				.end	= SIU_INT_SMC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[CPM2_SMC2] = {
+		.name = "fsl-cpm-smc",
+		.id	= 2,
+		.dev.platform_data = ,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "smc_regs",
+				.start	= CPM2_STARTOF(im_smc[1]),
+				.end	= CPM2_ENDOF(im_smc[1]),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "smc_pram",
+				.start	= PROFF_SMC2_BASE,
+				.end	= PROFF_SMC2_BASE + PROFF_SMC_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= SIU_INT_SMC2,
+				.end	= SIU_INT_SMC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[CPM2_I2C] = {
+		.name = "fsl-cpm-i2c",
+		.id	= 1,
+		.dev.platform_data = ,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "i2c_regs",
+				.start	= CPM2_STARTOF(im_i2c),
+				.end	= CPM2_ENDOF(im_i2c),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "i2c_pram",
+				.start	= PROFF_I2C_BASE,
+				.end	= PROFF_I2C_BASE + PROFF_I2C_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= SIU_INT_I2C,
+				.end	= SIU_INT_I2C,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[CPM2_SPI] = {
+		.name = "fsl-cpm-spi",
+		.id	= 1,
+		.dev.platform_data = ,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "spi_regs",
+				.start	= CPM2_STARTOF(im_spi),
+				.end	= CPM2_ENDOF(im_spi),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "spi_pram",
+				.start	= PROFF_SPI_BASE,
+				.end	= PROFF_SPI_BASE + PROFF_SPI_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= SIU_INT_SPI,
+				.end	= SIU_INT_SPI,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[CPM2_CPM] = {
+		.name = "fsl-cpm-cpm",
+		.id	= 1,
+		.dev.platform_data = ,
+		.num_resources	 = 2,
+		.resource = (struct resource[]) {
+			{
+				.name	= "cpm_regs",
+				.start	= CPM2_STARTOF(im_cpm),
+				.end	= CPM2_ENDOF(im_cpm),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "cpm_mux",
+				.start	= CPM2_STARTOF(im_cpmux),
+				.end	= CPM2_ENDOF(im_cpmux),
+				.flags	= IORESOURCE_MEM,
+			},
+		},
+	},
+#if !defined(CONFIG_8272) && !defined(CONFIG_MPC8555)
+	[CPM2_MMC1] = {
+		.name = "fsl-cpm-mmc",
+		.id	= 1,
+		.dev.platform_data = ,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "mmc_regs",
+				.start	= CPM2_STARTOF(im_mmc1),
+				.end	= CPM2_ENDOF(im_mmc1),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "mmc_pram",
+				.start	= PROFF_MMC1,
+				.end	= PROFF_MMC1 + PROFF_MMC_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= SIU_INT_MMC1,
+				.end	= SIU_INT_MMC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[CPM2_MMC2] = {
+		.name = "fsl-cpm-mmc",
+		.id	= 2,
+		.dev.platform_data = ,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "mmc_regs",
+				.start	= CPM2_STARTOF(im_mmc2),
+				.end	= CPM2_ENDOF(im_mmc2),
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "mmc_pram",
+				.start	= PROFF_MMC2,
+				.end	= PROFF_MMC2 + PROFF_MMC_SIZE - 1,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "interrupt",
+				.start	= SIU_INT_MMC2,
+				.end	= SIU_INT_MMC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+#endif
+
+	
+static int __init mach_cpm2_fixup(struct platform_device *pdev)
+{
+	ppc_sys_fixup_mem_resource(pdev, CPM_MAP_ADDR);
+	return 0;
+}
+
+static int __init mach_cpm2_init(void)
+{
+	if (ppc_md.progress)
+		ppc_md.progress("mach_cpm2_init:enter", 0);
+	ppc_sys_device_fixup = mach_cpm2_fixup;
+	return 0;
+}
+
+postcore_initcall(mach_cpm2_init);
+	
\ No newline at end of file
diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
--- a/include/asm-ppc/cpm2.h
+++ b/include/asm-ppc/cpm2.h
@@ -170,6 +170,20 @@ typedef struct cpm_buf_desc {
 #define PROFF_I2C_BASE		((uint)0x8afc)
 #define PROFF_IDMA4_BASE	((uint)0x8afe)
 
+#define PROFF_FCC_SIZE		((uint))256)
+#define PROFF_SCC_SIZE		((uint))256)
+#define PROFF_SMC_SIZE		((uint)2)
+#define PROFF_IDMA_SIZE		((uint)2)
+#define PROFF_SPI_SIZE		((uint)2)
+#define PROFF_I2C_SIZE		((uint)2)
+#define PROFF_MMC_SIZE		((uint)124)
+#define PROFF_USB_SIZE		((uint)256)
+
+#define PROFF_FCC_MEM_SIZE	((uint)128)
+#define PROFF_FCC1_MEM_BASE	(CPM_FCC_SPECIAL_BASE+(PROFF_FCC_MEM_SIZE*0))
+#define PROFF_FCC2_MEM_BASE	(CPM_FCC_SPECIAL_BASE+(PROFF_FCC_MEM_SIZE*1))
+#define PROFF_FCC3_MEM_BASE	(CPM_FCC_SPECIAL_BASE+(PROFF_FCC_MEM_SIZE*2))
+
 /* The SMCs are relocated to any of the first eight DPRAM pages.
  * We will fix these at the first locations of DPRAM, until we
  * get some microcode patches :-).
@@ -1084,6 +1098,40 @@ typedef struct im_idma {
 #define SCCR_PCIDF_MSK	0x00000078	/* PCI division factor	*/
 #define SCCR_PCIDF_SHIFT 3
 
+/*-----------------------------------------------------------------------
+ * Enumeration of PPC/CPM2 devices for platform initialization
+ */
+
+/* It says this should be an enumeration. If it was #defines then the
+ * cpm2_devices array definition could be conditionally compiled.
+ *
+ * Another approach would be to add all devices and have a flags field
+ * for the different CPM configuration options.
+ */
+enum ppc_sys_devices {
+	CPM2_FCC1,
+	CPM2_FCC2,
+	CPM2_FCC3,
+	CPM2_SCC1,
+	CPM2_SCC2,
+	CPM2_SCC3,
+	CPM2_SCC4,
+	CPM2_SMC1,
+	CPM2_SMC2,
+	CPM2_I2C,
+	CPM2_SPI,
+/*	CPM2_DMA,	think about this more, separate SDMA and IDMA? */
+	CPM2_CPM,
+/*	CPM2_SI2,	*/
+#if !defined(CONFIG_8272) && !defined(CONFIG_MPC8555)
+	CPM2_SI1,
+	CPM2_MMC1,
+	CPM2_MMC2,
+#else
+	CPM2_USB,
+#endf	
+};
+
 
 #endif /* __CPM2__ */
 #endif /* __KERNEL__ */

Re: RFC: cpm2_devices.c

[Kumar Gala]

Allen,

I've also included our version of this patch for commentary. Did you see a 
need for the following to actually be devices? (DMA, CPM, SI1, SIC2).

I can provide feedback on all the issues I had with you patch, but would 
prefer to start with ours (let me know).

- kumar


diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -80,7 +80,8 @@ obj-$(CONFIG_SANDPOINT)		+= i8259.o pci_
 obj-$(CONFIG_SBC82xx)		+= todc_time.o
 obj-$(CONFIG_SPRUCE)		+= cpc700_pic.o indirect_pci.o pci_auto.o \
 				   todc_time.o
-obj-$(CONFIG_8260)		+= m8260_setup.o
+obj-$(CONFIG_8260)		+= m8260_setup.o mpc82xx_devices.o mpc82xx_sys.o \
+				   ppc_sys.o
 obj-$(CONFIG_PCI_8260)		+= m82xx_pci.o indirect_pci.o pci_auto.o
 obj-$(CONFIG_8260_PCI9)		+= m8260_pci_erratum9.o
 obj-$(CONFIG_CPM2)		+= cpm2_common.o cpm2_pic.o
diff --git a/arch/ppc/syslib/mpc82xx_devices.c b/arch/ppc/syslib/mpc82xx_devices.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/syslib/mpc82xx_devices.c
@@ -0,0 +1,389 @@
+/*
+ * arch/ppc/syslib/mpc82xx_devices.c
+ *
+ * MPC82xx Device descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License 
+ * version 2. This program is licensed "as is" without any warranty of any 
+ * kind, whether express or implied.
+ */
+
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/ioport.h>
+#include <asm/cpm2.h>
+#include <asm/irq.h>
+#include <asm/ppc_sys.h>
+
+struct platform_device ppc_sys_platform_devices[] = {
+	[MPC82xx_CPM_FCC1] = {
+		.name = "fsl-cpm-fcc",
+		.id	= 1,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "fcc_regs",
+				.start	= 0x11300,
+				.end	= 0x1131f,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "fcc_pram",
+				.start	= 0x8400,
+				.end	= 0x84ff,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= SIU_INT_FCC1,
+				.end	= SIU_INT_FCC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC82xx_CPM_FCC2] = {
+		.name = "fsl-cpm-fcc",
+		.id	= 2,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "fcc_regs",
+				.start	= 0x11320,
+				.end	= 0x1133f,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "fcc_pram",
+				.start	= 0x8500,
+				.end	= 0x85ff,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= SIU_INT_FCC2,
+				.end	= SIU_INT_FCC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC82xx_CPM_FCC3] = {
+		.name = "fsl-cpm-fcc",
+		.id	= 3,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "fcc_regs",
+				.start	= 0x11340,
+				.end	= 0x1135f,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "fcc_pram",
+				.start	= 0x8600,
+				.end	= 0x86ff,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= SIU_INT_FCC3,
+				.end	= SIU_INT_FCC3,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC82xx_CPM_I2C] = {
+		.name = "fsl-cpm-i2c",
+		.id	= 1,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "i2c_mem",
+				.start	= 0x11860,
+				.end	= 0x118BF,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "i2c_pram",
+				.start 	= 0x8afc,
+				.end	= 0x8afd,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= SIU_INT_I2C,
+				.end	= SIU_INT_I2C,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC82xx_CPM_SCC1] = {
+		.name = "fsl-cpm-scc",
+		.id	= 1,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "scc_mem",
+				.start	= 0x11A00,
+				.end	= 0x11A1F,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "scc_pram",
+				.start	= 0x8000,
+				.end	= 0x80ff,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= SIU_INT_SCC1,
+				.end	= SIU_INT_SCC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC82xx_CPM_SCC2] = {
+		.name = "fsl-cpm-scc",
+		.id	= 2,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "scc_mem",
+				.start	= 0x11A20,
+				.end	= 0x11A3F,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "scc_pram",
+				.start	= 0x8100,
+				.end	= 0x81ff,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= SIU_INT_SCC2,
+				.end	= SIU_INT_SCC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC82xx_CPM_SCC3] = {
+		.name = "fsl-cpm-scc",
+		.id	= 3,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name 	= "scc_mem",
+				.start	= 0x11A40,
+				.end	= 0x11A5F,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "scc_pram",
+				.start	= 0x8200,
+				.end	= 0x82ff,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= SIU_INT_SCC3,
+				.end	= SIU_INT_SCC3,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC82xx_CPM_SCC4] = {
+		.name = "fsl-cpm-scc",
+		.id	= 4,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "scc_mem",
+				.start	= 0x11A60,
+				.end	= 0x11A7F,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "scc_pram",
+				.start	= 0x8300,
+				.end	= 0x83ff,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= SIU_INT_SCC4,
+				.end	= SIU_INT_SCC4,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC82xx_CPM_SPI] = {
+		.name = "fsl-cpm-spi",
+		.id	= 1,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "spi_mem",
+				.start	= 0x11AA0,
+				.end	= 0x11AFF,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "spi_pram",
+				.start	= 0x89fc,
+				.end	= 0x89fd,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= SIU_INT_SPI,
+				.end	= SIU_INT_SPI,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC82xx_CPM_MCC1] = {
+		.name = "fsl-cpm-mcc",
+		.id	= 1,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "mcc_mem",
+				.start	= 0x11B30,
+				.end	= 0x11B3F,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "mcc_pram",
+				.start	= 0x8700,
+				.end	= 0x877f,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= SIU_INT_MCC1,
+				.end	= SIU_INT_MCC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC82xx_CPM_MCC2] = {
+		.name = "fsl-cpm-mcc",
+		.id	= 2,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "mcc_mem",
+				.start	= 0x11B50,
+				.end	= 0x11B5F,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "mcc_pram",
+				.start	= 0x8800,
+				.end	= 0x887f,
+				.flags	= IORESOURCE_MEM,
+			},		
+			{
+				.start	= SIU_INT_MCC2,
+				.end	= SIU_INT_MCC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC82xx_CPM_SMC1] = {
+		.name = "fsl-cpm-smc",
+		.id	= 1,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "smc_mem",
+				.start	= 0x11A80,
+				.end	= 0x11A8F,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "smc_pram",
+				.start	= 0x87fc,
+				.end	= 0x87fd,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= SIU_INT_SMC1,
+				.end	= SIU_INT_SMC1,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC82xx_CPM_SMC2] = {
+		.name = "fsl-cpm-smc",
+		.id	= 2,
+		.num_resources	 = 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "smc_mem",
+				.start	= 0x11A90,
+				.end	= 0x11A9F,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "smc_pram",
+				.start	= 0x88fc,
+				.end	= 0x88fd,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.start	= SIU_INT_SMC2,
+				.end	= SIU_INT_SMC2,
+				.flags	= IORESOURCE_IRQ,
+			},
+		},
+	},
+	[MPC82xx_CPM_USB] = {
+		.name = "fsl-cpm-usb",
+		.id	= 1,
+		.num_resources	= 3,
+		.resource = (struct resource[]) {
+			{
+				.name	= "usb_mem",
+				.start	= 0x11b60,
+				.end	= 0x11b78,
+				.flags	= IORESOURCE_MEM,
+			},
+			{
+				.name	= "usb_pram",
+				.start	= 0x8b00,
+				.end	= 0x8bff,
+				.flags 	= IORESOURCE_MEM,
+			},
+			{
+				.start	= SIU_INT_USB,
+				.end	= SIU_INT_USB,
+				.flags	= IORESOURCE_IRQ,
+			},
+
+		},
+	},
+	[MPC82xx_SEC1] = {
+		.name = "fsl-sec",
+		.id = 1,
+		.num_resources = 1,
+		.resource = (struct resource[]) {
+			{
+				.name	= "sec_mem",
+				.start	= 0x40000,
+				.end	= 0x52fff,
+				.flags	= IORESOURCE_MEM,
+			},
+		},
+	},
+};
+
+static int __init mach_mpc82xx_fixup(struct platform_device *pdev)
+{
+	ppc_sys_fixup_mem_resource(pdev, CPM_MAP_ADDR);
+	return 0;
+}
+
+static int __init mach_mpc82xx_init(void)
+{
+	if (ppc_md.progress)
+		ppc_md.progress("mach_mpc82xx_init:enter", 0);
+	ppc_sys_device_fixup = mach_mpc82xx_fixup;
+	return 0;
+}
+
+postcore_initcall(mach_mpc82xx_init);
diff --git a/arch/ppc/syslib/mpc82xx_sys.c b/arch/ppc/syslib/mpc82xx_sys.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/syslib/mpc82xx_sys.c
@@ -0,0 +1,200 @@
+/*
+ * arch/ppc/syslib/mpc82xx_devices.c
+ *
+ * MPC82xx System descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License 
+ * version 2. This program is licensed "as is" without any warranty of any 
+ * kind, whether express or implied.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+
+#include <asm/ppc_sys.h>
+
+struct ppc_sys_spec *cur_ppc_sys_spec;
+struct ppc_sys_spec ppc_sys_specs[] = {
+	/* below is a list of the 8260 family of processors */
+	{
+		.ppc_sys_name	= "8250",
+		.mask		= 0x0000ff00,
+		.value		= 0x00000000,
+		.num_devices	= 12,
+		.device_list = (enum ppc_sys_devices[])
+		{
+			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+		}
+	},
+	{
+		.ppc_sys_name	= "8255",
+		.mask		= 0x0000ff00,
+		.value		= 0x00000000,
+		.num_devices	= 11,
+		.device_list = (enum ppc_sys_devices[])
+		{
+			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
+			MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SCC4,
+			MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1, MPC82xx_CPM_SMC2,
+			MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+		}
+	},
+	{
+		.ppc_sys_name	= "8260",
+		.mask		= 0x0000ff00,
+		.value		= 0x00000000,
+		.num_devices	= 12,
+		.device_list = (enum ppc_sys_devices[])
+		{
+			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+		}
+	},
+	{
+		.ppc_sys_name	= "8264",
+		.mask		= 0x0000ff00,
+		.value		= 0x00000000,
+		.num_devices	= 12,
+		.device_list = (enum ppc_sys_devices[])
+		{
+			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+		}
+	},
+	{
+		.ppc_sys_name	= "8265",
+		.mask		= 0x0000ff00,
+		.value		= 0x00000000,
+		.num_devices	= 12,
+		.device_list = (enum ppc_sys_devices[])
+		{
+			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+		}
+	},
+	{
+		.ppc_sys_name	= "8266",
+		.mask		= 0x0000ff00,
+		.value		= 0x00000000,
+		.num_devices	= 12,
+		.device_list = (enum ppc_sys_devices[])
+		{
+			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+		}
+	},
+	/* below is a list of the 8272 family of processors */
+	{
+		.ppc_sys_name	= "8247",
+		.mask		= 0x000fe000,
+		.value		= 0x0000c000,
+		.num_devices	= 10,
+		.device_list = (enum ppc_sys_devices[])
+		{
+			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
+			MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
+			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+			MPC82xx_CPM_USB,
+		},
+	},
+	{
+		.ppc_sys_name	= "8248",
+		.mask		= 0x000fe000,
+		.value		= 0x0000c000,
+		.num_devices	= 11,
+		.device_list = (enum ppc_sys_devices[])
+		{
+			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
+			MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
+			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+			MPC82xx_CPM_USB, MPC82xx_SEC1,
+		},
+	},
+	{
+		.ppc_sys_name	= "8271",
+		.mask		= 0x000fe000,
+		.value		= 0x0000c000,
+		.num_devices	= 10,
+		.device_list = (enum ppc_sys_devices[])
+		{
+			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
+			MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
+			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+			MPC82xx_CPM_USB,
+		},
+	},
+	{
+		.ppc_sys_name	= "8272",
+		.mask		= 0x000fe000,
+		.value		= 0x0000c000,
+		.num_devices	= 11,
+		.device_list = (enum ppc_sys_devices[])
+		{
+			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
+			MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
+			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+			MPC82xx_CPM_USB, MPC82xx_SEC1,
+		},
+	},
+	/* below is a list of the 8280 family of processors */
+	{	
+		.ppc_sys_name	= "8270",
+		.mask 		= 0x0000ff00,
+		.value 		= 0x00000a00,
+		.num_devices 	= 12,
+		.device_list = (enum ppc_sys_devices[])
+		{
+			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+		},
+	},
+	{	
+		.ppc_sys_name	= "8275",
+		.mask 		= 0x0000ff00,
+		.value 		= 0x00000a00,
+		.num_devices 	= 12,
+		.device_list = (enum ppc_sys_devices[])
+		{
+			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+		},
+	},
+	{	
+		.ppc_sys_name	= "8280",
+		.mask 		= 0x0000ff00,
+		.value 		= 0x00000a00,
+		.num_devices 	= 13,
+		.device_list = (enum ppc_sys_devices[])
+		{
+			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_MCC2,
+			MPC82xx_CPM_SMC1, MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI,
+			MPC82xx_CPM_I2C,
+		},
+	},
+	{
+		/* default match */
+		.ppc_sys_name	= "",
+		.mask 		= 0x00000000,
+		.value 		= 0x00000000,
+	},
+};
diff --git a/include/asm-ppc/irq.h b/include/asm-ppc/irq.h
--- a/include/asm-ppc/irq.h
+++ b/include/asm-ppc/irq.h
@@ -331,6 +331,7 @@ static __inline__ int irq_canonicalize(i
 #define	SIU_INT_IDMA3		((uint)0x08 + CPM_IRQ_OFFSET)
 #define	SIU_INT_IDMA4		((uint)0x09 + CPM_IRQ_OFFSET)
 #define	SIU_INT_SDMA		((uint)0x0a + CPM_IRQ_OFFSET)
+#define	SIU_INT_USB		((uint)0x0b + CPM_IRQ_OFFSET)
 #define	SIU_INT_TIMER1		((uint)0x0c + CPM_IRQ_OFFSET)
 #define	SIU_INT_TIMER2		((uint)0x0d + CPM_IRQ_OFFSET)
 #define	SIU_INT_TIMER3		((uint)0x0e + CPM_IRQ_OFFSET)
diff --git a/include/asm-ppc/mpc8260.h b/include/asm-ppc/mpc8260.h
--- a/include/asm-ppc/mpc8260.h
+++ b/include/asm-ppc/mpc8260.h
@@ -34,8 +34,7 @@
 
 #ifdef CONFIG_TQM8260
 #include <platforms/tqm8260.h>
-#endif
-
+#endif 
 #if defined(CONFIG_PQ2ADS) || defined (CONFIG_PQ2FADS)
 #include <platforms/pq2ads.h>
 #endif
@@ -66,6 +65,24 @@
 #ifndef IO_VIRT_ADDR
 #define IO_VIRT_ADDR	IO_PHYS_ADDR
 #endif
+
+enum ppc_sys_devices {
+	MPC82xx_CPM_FCC1,
+	MPC82xx_CPM_FCC2,
+	MPC82xx_CPM_FCC3,
+	MPC82xx_CPM_I2C,
+	MPC82xx_CPM_SCC1,
+	MPC82xx_CPM_SCC2,
+	MPC82xx_CPM_SCC3,
+	MPC82xx_CPM_SCC4,
+	MPC82xx_CPM_SPI,
+	MPC82xx_CPM_MCC1,
+	MPC82xx_CPM_MCC2,
+	MPC82xx_CPM_SMC1,
+	MPC82xx_CPM_SMC2,
+	MPC82xx_CPM_USB,
+	MPC82xx_SEC1,
+};
 
 #ifndef __ASSEMBLY__
 /* The "residual" data board information structure the boot loader
diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
--- a/include/asm-ppc/ppc_sys.h
+++ b/include/asm-ppc/ppc_sys.h
@@ -21,7 +21,9 @@
 #include <linux/device.h>
 #include <linux/types.h>
 
-#if defined(CONFIG_83xx)
+#if defined(CONFIG_8260)
+#include <asm/mpc8260.h>
+#elif defined(CONFIG_83xx)
 #include <asm/mpc83xx.h>
 #elif defined(CONFIG_85xx)
 #include <asm/mpc85xx.h>

Re: RFC: cpm2_devices.c

[Allen Curtis]

> I've also included our version of this patch for commentary. Did you 
> see a
> need for the following to actually be devices? (DMA, CPM, SI1, SIC2).
>
The good thing about them actually being devices is that you can find 
them and the IO resources had already been remapped. You don't need a 
device driver for them but they are resources used by other device 
drivers.

> I can provide feedback on all the issues I had with you patch, but 
> would
> prefer to start with ours (let me know).
>
Comments:
1. You removed the other PRAM definition from this FCC definition, this 
is good.

2. I am torn about using numeric IMMR offsets vs. the structure member 
approach. The good thing is that you can create all the devices in a 
single table even if they overlay depending on processor. The question 
is, will the IMMAP structure become obsolete? If not, then you will 
still need the conditional compiles in immap_cpm2.h.

3. Naming convention, are all these devices just in the MPC82xx family? 
If the CPM is a general FSL co-processor, used across many processor 
families, then I like the CPM2 naming convention.

4. What about PCI?

5. This patch does not address the platform specific device structures. 
How do you want to handle these?

Thanks for the patch, this helps.


> - kumar
>
>
> diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
> --- a/arch/ppc/syslib/Makefile
> +++ b/arch/ppc/syslib/Makefile
> @@ -80,7 +80,8 @@ obj-$(CONFIG_SANDPOINT)		+= i8259.o pci_
>  obj-$(CONFIG_SBC82xx)		+= todc_time.o
>  obj-$(CONFIG_SPRUCE)		+= cpc700_pic.o indirect_pci.o pci_auto.o \
>  				   todc_time.o
> -obj-$(CONFIG_8260)		+= m8260_setup.o
> +obj-$(CONFIG_8260)		+= m8260_setup.o mpc82xx_devices.o mpc82xx_sys.o \
> +				   ppc_sys.o
>  obj-$(CONFIG_PCI_8260)		+= m82xx_pci.o indirect_pci.o pci_auto.o
>  obj-$(CONFIG_8260_PCI9)		+= m8260_pci_erratum9.o
>  obj-$(CONFIG_CPM2)		+= cpm2_common.o cpm2_pic.o
> diff --git a/arch/ppc/syslib/mpc82xx_devices.c 
> b/arch/ppc/syslib/mpc82xx_devices.c
> new file mode 100644
> --- /dev/null
> +++ b/arch/ppc/syslib/mpc82xx_devices.c
> @@ -0,0 +1,389 @@
> +/*
> + * arch/ppc/syslib/mpc82xx_devices.c
> + *
> + * MPC82xx Device descriptions
> + *
> + * Maintainer: Kumar Gala <kumar.gala@freescale.com>
> + *
> + * This file is licensed under the terms of the GNU General Public 
> License
> + * version 2. This program is licensed "as is" without any warranty 
> of any
> + * kind, whether express or implied.
> + */
> +
> +
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/ioport.h>
> +#include <asm/cpm2.h>
> +#include <asm/irq.h>
> +#include <asm/ppc_sys.h>
> +
> +struct platform_device ppc_sys_platform_devices[] = {
> +	[MPC82xx_CPM_FCC1] = {
> +		.name = "fsl-cpm-fcc",
> +		.id	= 1,
> +		.num_resources	 = 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "fcc_regs",
> +				.start	= 0x11300,
> +				.end	= 0x1131f,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "fcc_pram",
> +				.start	= 0x8400,
> +				.end	= 0x84ff,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.start	= SIU_INT_FCC1,
> +				.end	= SIU_INT_FCC1,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +		},
> +	},
> +	[MPC82xx_CPM_FCC2] = {
> +		.name = "fsl-cpm-fcc",
> +		.id	= 2,
> +		.num_resources	 = 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "fcc_regs",
> +				.start	= 0x11320,
> +				.end	= 0x1133f,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "fcc_pram",
> +				.start	= 0x8500,
> +				.end	= 0x85ff,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.start	= SIU_INT_FCC2,
> +				.end	= SIU_INT_FCC2,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +		},
> +	},
> +	[MPC82xx_CPM_FCC3] = {
> +		.name = "fsl-cpm-fcc",
> +		.id	= 3,
> +		.num_resources	 = 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "fcc_regs",
> +				.start	= 0x11340,
> +				.end	= 0x1135f,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "fcc_pram",
> +				.start	= 0x8600,
> +				.end	= 0x86ff,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.start	= SIU_INT_FCC3,
> +				.end	= SIU_INT_FCC3,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +		},
> +	},
> +	[MPC82xx_CPM_I2C] = {
> +		.name = "fsl-cpm-i2c",
> +		.id	= 1,
> +		.num_resources	 = 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "i2c_mem",
> +				.start	= 0x11860,
> +				.end	= 0x118BF,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "i2c_pram",
> +				.start 	= 0x8afc,
> +				.end	= 0x8afd,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.start	= SIU_INT_I2C,
> +				.end	= SIU_INT_I2C,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +		},
> +	},
> +	[MPC82xx_CPM_SCC1] = {
> +		.name = "fsl-cpm-scc",
> +		.id	= 1,
> +		.num_resources	 = 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "scc_mem",
> +				.start	= 0x11A00,
> +				.end	= 0x11A1F,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "scc_pram",
> +				.start	= 0x8000,
> +				.end	= 0x80ff,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.start	= SIU_INT_SCC1,
> +				.end	= SIU_INT_SCC1,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +		},
> +	},
> +	[MPC82xx_CPM_SCC2] = {
> +		.name = "fsl-cpm-scc",
> +		.id	= 2,
> +		.num_resources	 = 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "scc_mem",
> +				.start	= 0x11A20,
> +				.end	= 0x11A3F,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "scc_pram",
> +				.start	= 0x8100,
> +				.end	= 0x81ff,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.start	= SIU_INT_SCC2,
> +				.end	= SIU_INT_SCC2,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +		},
> +	},
> +	[MPC82xx_CPM_SCC3] = {
> +		.name = "fsl-cpm-scc",
> +		.id	= 3,
> +		.num_resources	 = 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name 	= "scc_mem",
> +				.start	= 0x11A40,
> +				.end	= 0x11A5F,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "scc_pram",
> +				.start	= 0x8200,
> +				.end	= 0x82ff,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.start	= SIU_INT_SCC3,
> +				.end	= SIU_INT_SCC3,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +		},
> +	},
> +	[MPC82xx_CPM_SCC4] = {
> +		.name = "fsl-cpm-scc",
> +		.id	= 4,
> +		.num_resources	 = 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "scc_mem",
> +				.start	= 0x11A60,
> +				.end	= 0x11A7F,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "scc_pram",
> +				.start	= 0x8300,
> +				.end	= 0x83ff,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.start	= SIU_INT_SCC4,
> +				.end	= SIU_INT_SCC4,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +		},
> +	},
> +	[MPC82xx_CPM_SPI] = {
> +		.name = "fsl-cpm-spi",
> +		.id	= 1,
> +		.num_resources	 = 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "spi_mem",
> +				.start	= 0x11AA0,
> +				.end	= 0x11AFF,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "spi_pram",
> +				.start	= 0x89fc,
> +				.end	= 0x89fd,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.start	= SIU_INT_SPI,
> +				.end	= SIU_INT_SPI,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +		},
> +	},
> +	[MPC82xx_CPM_MCC1] = {
> +		.name = "fsl-cpm-mcc",
> +		.id	= 1,
> +		.num_resources	 = 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "mcc_mem",
> +				.start	= 0x11B30,
> +				.end	= 0x11B3F,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "mcc_pram",
> +				.start	= 0x8700,
> +				.end	= 0x877f,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.start	= SIU_INT_MCC1,
> +				.end	= SIU_INT_MCC1,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +		},
> +	},
> +	[MPC82xx_CPM_MCC2] = {
> +		.name = "fsl-cpm-mcc",
> +		.id	= 2,
> +		.num_resources	 = 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "mcc_mem",
> +				.start	= 0x11B50,
> +				.end	= 0x11B5F,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "mcc_pram",
> +				.start	= 0x8800,
> +				.end	= 0x887f,
> +				.flags	= IORESOURCE_MEM,
> +			},		
> +			{
> +				.start	= SIU_INT_MCC2,
> +				.end	= SIU_INT_MCC2,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +		},
> +	},
> +	[MPC82xx_CPM_SMC1] = {
> +		.name = "fsl-cpm-smc",
> +		.id	= 1,
> +		.num_resources	 = 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "smc_mem",
> +				.start	= 0x11A80,
> +				.end	= 0x11A8F,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "smc_pram",
> +				.start	= 0x87fc,
> +				.end	= 0x87fd,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.start	= SIU_INT_SMC1,
> +				.end	= SIU_INT_SMC1,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +		},
> +	},
> +	[MPC82xx_CPM_SMC2] = {
> +		.name = "fsl-cpm-smc",
> +		.id	= 2,
> +		.num_resources	 = 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "smc_mem",
> +				.start	= 0x11A90,
> +				.end	= 0x11A9F,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "smc_pram",
> +				.start	= 0x88fc,
> +				.end	= 0x88fd,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.start	= SIU_INT_SMC2,
> +				.end	= SIU_INT_SMC2,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +		},
> +	},
> +	[MPC82xx_CPM_USB] = {
> +		.name = "fsl-cpm-usb",
> +		.id	= 1,
> +		.num_resources	= 3,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "usb_mem",
> +				.start	= 0x11b60,
> +				.end	= 0x11b78,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +			{
> +				.name	= "usb_pram",
> +				.start	= 0x8b00,
> +				.end	= 0x8bff,
> +				.flags 	= IORESOURCE_MEM,
> +			},
> +			{
> +				.start	= SIU_INT_USB,
> +				.end	= SIU_INT_USB,
> +				.flags	= IORESOURCE_IRQ,
> +			},
> +
> +		},
> +	},
> +	[MPC82xx_SEC1] = {
> +		.name = "fsl-sec",
> +		.id = 1,
> +		.num_resources = 1,
> +		.resource = (struct resource[]) {
> +			{
> +				.name	= "sec_mem",
> +				.start	= 0x40000,
> +				.end	= 0x52fff,
> +				.flags	= IORESOURCE_MEM,
> +			},
> +		},
> +	},
> +};
> +
> +static int __init mach_mpc82xx_fixup(struct platform_device *pdev)
> +{
> +	ppc_sys_fixup_mem_resource(pdev, CPM_MAP_ADDR);
> +	return 0;
> +}
> +
> +static int __init mach_mpc82xx_init(void)
> +{
> +	if (ppc_md.progress)
> +		ppc_md.progress("mach_mpc82xx_init:enter", 0);
> +	ppc_sys_device_fixup = mach_mpc82xx_fixup;
> +	return 0;
> +}
> +
> +postcore_initcall(mach_mpc82xx_init);
> diff --git a/arch/ppc/syslib/mpc82xx_sys.c 
> b/arch/ppc/syslib/mpc82xx_sys.c
> new file mode 100644
> --- /dev/null
> +++ b/arch/ppc/syslib/mpc82xx_sys.c
> @@ -0,0 +1,200 @@
> +/*
> + * arch/ppc/syslib/mpc82xx_devices.c
> + *
> + * MPC82xx System descriptions
> + *
> + * Maintainer: Kumar Gala <kumar.gala@freescale.com>
> + *
> + * This file is licensed under the terms of the GNU General Public 
> License
> + * version 2. This program is licensed "as is" without any warranty 
> of any
> + * kind, whether express or implied.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/device.h>
> +
> +#include <asm/ppc_sys.h>
> +
> +struct ppc_sys_spec *cur_ppc_sys_spec;
> +struct ppc_sys_spec ppc_sys_specs[] = {
> +	/* below is a list of the 8260 family of processors */
> +	{
> +		.ppc_sys_name	= "8250",
> +		.mask		= 0x0000ff00,
> +		.value		= 0x00000000,
> +		.num_devices	= 12,
> +		.device_list = (enum ppc_sys_devices[])
> +		{
> +			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> +			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> +			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> +			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> +		}
> +	},
> +	{
> +		.ppc_sys_name	= "8255",
> +		.mask		= 0x0000ff00,
> +		.value		= 0x00000000,
> +		.num_devices	= 11,
> +		.device_list = (enum ppc_sys_devices[])
> +		{
> +			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
> +			MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SCC4,
> +			MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1, MPC82xx_CPM_SMC2,
> +			MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> +		}
> +	},
> +	{
> +		.ppc_sys_name	= "8260",
> +		.mask		= 0x0000ff00,
> +		.value		= 0x00000000,
> +		.num_devices	= 12,
> +		.device_list = (enum ppc_sys_devices[])
> +		{
> +			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> +			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> +			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> +			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> +		}
> +	},
> +	{
> +		.ppc_sys_name	= "8264",
> +		.mask		= 0x0000ff00,
> +		.value		= 0x00000000,
> +		.num_devices	= 12,
> +		.device_list = (enum ppc_sys_devices[])
> +		{
> +			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> +			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> +			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> +			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> +		}
> +	},
> +	{
> +		.ppc_sys_name	= "8265",
> +		.mask		= 0x0000ff00,
> +		.value		= 0x00000000,
> +		.num_devices	= 12,
> +		.device_list = (enum ppc_sys_devices[])
> +		{
> +			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> +			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> +			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> +			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> +		}
> +	},
> +	{
> +		.ppc_sys_name	= "8266",
> +		.mask		= 0x0000ff00,
> +		.value		= 0x00000000,
> +		.num_devices	= 12,
> +		.device_list = (enum ppc_sys_devices[])
> +		{
> +			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> +			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> +			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> +			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> +		}
> +	},
> +	/* below is a list of the 8272 family of processors */
> +	{
> +		.ppc_sys_name	= "8247",
> +		.mask		= 0x000fe000,
> +		.value		= 0x0000c000,
> +		.num_devices	= 10,
> +		.device_list = (enum ppc_sys_devices[])
> +		{
> +			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
> +			MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
> +			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> +			MPC82xx_CPM_USB,
> +		},
> +	},
> +	{
> +		.ppc_sys_name	= "8248",
> +		.mask		= 0x000fe000,
> +		.value		= 0x0000c000,
> +		.num_devices	= 11,
> +		.device_list = (enum ppc_sys_devices[])
> +		{
> +			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
> +			MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
> +			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> +			MPC82xx_CPM_USB, MPC82xx_SEC1,
> +		},
> +	},
> +	{
> +		.ppc_sys_name	= "8271",
> +		.mask		= 0x000fe000,
> +		.value		= 0x0000c000,
> +		.num_devices	= 10,
> +		.device_list = (enum ppc_sys_devices[])
> +		{
> +			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
> +			MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
> +			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> +			MPC82xx_CPM_USB,
> +		},
> +	},
> +	{
> +		.ppc_sys_name	= "8272",
> +		.mask		= 0x000fe000,
> +		.value		= 0x0000c000,
> +		.num_devices	= 11,
> +		.device_list = (enum ppc_sys_devices[])
> +		{
> +			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
> +			MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
> +			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> +			MPC82xx_CPM_USB, MPC82xx_SEC1,
> +		},
> +	},
> +	/* below is a list of the 8280 family of processors */
> +	{	
> +		.ppc_sys_name	= "8270",
> +		.mask 		= 0x0000ff00,
> +		.value 		= 0x00000a00,
> +		.num_devices 	= 12,
> +		.device_list = (enum ppc_sys_devices[])
> +		{
> +			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> +			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> +			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> +			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> +		},
> +	},
> +	{	
> +		.ppc_sys_name	= "8275",
> +		.mask 		= 0x0000ff00,
> +		.value 		= 0x00000a00,
> +		.num_devices 	= 12,
> +		.device_list = (enum ppc_sys_devices[])
> +		{
> +			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> +			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> +			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
> +			MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
> +		},
> +	},
> +	{	
> +		.ppc_sys_name	= "8280",
> +		.mask 		= 0x0000ff00,
> +		.value 		= 0x00000a00,
> +		.num_devices 	= 13,
> +		.device_list = (enum ppc_sys_devices[])
> +		{
> +			MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
> +			MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
> +			MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_MCC2,
> +			MPC82xx_CPM_SMC1, MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI,
> +			MPC82xx_CPM_I2C,
> +		},
> +	},
> +	{
> +		/* default match */
> +		.ppc_sys_name	= "",
> +		.mask 		= 0x00000000,
> +		.value 		= 0x00000000,
> +	},
> +};
> diff --git a/include/asm-ppc/irq.h b/include/asm-ppc/irq.h
> --- a/include/asm-ppc/irq.h
> +++ b/include/asm-ppc/irq.h
> @@ -331,6 +331,7 @@ static __inline__ int irq_canonicalize(i
>  #define	SIU_INT_IDMA3		((uint)0x08 + CPM_IRQ_OFFSET)
>  #define	SIU_INT_IDMA4		((uint)0x09 + CPM_IRQ_OFFSET)
>  #define	SIU_INT_SDMA		((uint)0x0a + CPM_IRQ_OFFSET)
> +#define	SIU_INT_USB		((uint)0x0b + CPM_IRQ_OFFSET)
>  #define	SIU_INT_TIMER1		((uint)0x0c + CPM_IRQ_OFFSET)
>  #define	SIU_INT_TIMER2		((uint)0x0d + CPM_IRQ_OFFSET)
>  #define	SIU_INT_TIMER3		((uint)0x0e + CPM_IRQ_OFFSET)
> diff --git a/include/asm-ppc/mpc8260.h b/include/asm-ppc/mpc8260.h
> --- a/include/asm-ppc/mpc8260.h
> +++ b/include/asm-ppc/mpc8260.h
> @@ -34,8 +34,7 @@
>
>  #ifdef CONFIG_TQM8260
>  #include <platforms/tqm8260.h>
> -#endif
> -
> +#endif
>  #if defined(CONFIG_PQ2ADS) || defined (CONFIG_PQ2FADS)
>  #include <platforms/pq2ads.h>
>  #endif
> @@ -66,6 +65,24 @@
>  #ifndef IO_VIRT_ADDR
>  #define IO_VIRT_ADDR	IO_PHYS_ADDR
>  #endif
> +
> +enum ppc_sys_devices {
> +	MPC82xx_CPM_FCC1,
> +	MPC82xx_CPM_FCC2,
> +	MPC82xx_CPM_FCC3,
> +	MPC82xx_CPM_I2C,
> +	MPC82xx_CPM_SCC1,
> +	MPC82xx_CPM_SCC2,
> +	MPC82xx_CPM_SCC3,
> +	MPC82xx_CPM_SCC4,
> +	MPC82xx_CPM_SPI,
> +	MPC82xx_CPM_MCC1,
> +	MPC82xx_CPM_MCC2,
> +	MPC82xx_CPM_SMC1,
> +	MPC82xx_CPM_SMC2,
> +	MPC82xx_CPM_USB,
> +	MPC82xx_SEC1,
> +};
>
>  #ifndef __ASSEMBLY__
>  /* The "residual" data board information structure the boot loader
> diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
> --- a/include/asm-ppc/ppc_sys.h
> +++ b/include/asm-ppc/ppc_sys.h
> @@ -21,7 +21,9 @@
>  #include <linux/device.h>
>  #include <linux/types.h>
>
> -#if defined(CONFIG_83xx)
> +#if defined(CONFIG_8260)
> +#include <asm/mpc8260.h>
> +#elif defined(CONFIG_83xx)
>  #include <asm/mpc83xx.h>
>  #elif defined(CONFIG_85xx)
>  #include <asm/mpc85xx.h>
>

Re: RFC: cpm2_devices.c

[Kumar Gala]

On Jun 14, 2005, at 10:57 PM, Allen Curtis wrote:

>> I've also included our version of this patch for commentary. Did you
>> see a
>> need for the following to actually be devices? (DMA, CPM, SI1, SIC2).
>>
> The good thing about them actually being devices is that you can find
> them and the IO resources had already been remapped. You don't need a
> device driver for them but they are resources used by other device
> drivers.

Not sure I follow.  The IO resources are not mapped by anything until 
some piece of code does an explicit ioremap().  How do you plan on 
finding them?  I've got now issue adding them, I just want to 
understand how you see us using them.  A simple code example might be 
helpful.

>> I can provide feedback on all the issues I had with you patch, but
>> would
>> prefer to start with ours (let me know).
>>
> Comments:
> 1. You removed the other PRAM definition from this FCC definition, this
> is good.
>
> 2. I am torn about using numeric IMMR offsets vs. the structure member
> approach. The good thing is that you can create all the devices in a
> single table even if they overlay depending on processor. The question
> is, will the IMMAP structure become obsolete? If not, then you will
> still need the conditional compiles in immap_cpm2.h.

I'm trying to stay away from basing things on the structure.  Since the 
offsets are truly fixed I see not reason to try to make sure that the 
immap structure is always correct for all cases.  Hopefully this will 
end up removing the need to ifdef the immap structure as we go forward.

> 3. Naming convention, are all these devices just in the MPC82xx family?
> If the CPM is a general FSL co-processor, used across many processor
> families, then I like the CPM2 naming convention.

The key there is the driver name not the enum name.  If you look the 
driver name field matches 85xx.  These files might be better of called 
pq2_* instead of mpc82xx_ (8240/1/5 is not handled here) or cpm2_ (85xx 
has cpm2).

> 4. What about PCI?

What about it, none of the busses have specific drivers at this point 
so they haven't been added.

> 5. This patch does not address the platform specific device structures.
> How do you want to handle these?

I want to do that as a second pass every we close on this.  Since the 
platform specific device structs are going to be based on what is 
needed for the drivers.

- kumar

Re: RFC: cpm2_devices.c

[Allen Curtis]

>>> I've also included our version of this patch for commentary. Did you
>>> see a
>>> need for the following to actually be devices? (DMA, CPM, SI1, SIC2).
>>>
>> The good thing about them actually being devices is that you can find
>> them and the IO resources had already been remapped. You don't need a
>> device driver for them but they are resources used by other device
>> drivers.
>
> Not sure I follow.  The IO resources are not mapped by anything until 
> some piece of code does an explicit ioremap().  How do you plan on 
> finding them?  I've got now issue adding them, I just want to 
> understand how you see us using them.  A simple code example might be 
> helpful.
>

See below...

>>> I can provide feedback on all the issues I had with you patch, but
>>> would
>>> prefer to start with ours (let me know).
>>>
>> Comments:
>> 1. You removed the other PRAM definition from this FCC definition, 
>> this
>> is good.
>>
>> 2. I am torn about using numeric IMMR offsets vs. the structure member
>> approach. The good thing is that you can create all the devices in a
>> single table even if they overlay depending on processor. The question
>> is, will the IMMAP structure become obsolete? If not, then you will
>> still need the conditional compiles in immap_cpm2.h.
>
> I'm trying to stay away from basing things on the structure.  Since 
> the offsets are truly fixed I see not reason to try to make sure that 
> the immap structure is always correct for all cases.  Hopefully this 
> will end up removing the need to ifdef the immap structure as we go 
> forward.
>

I am not sure I understand the purpose of each access method. How is 
the immap structure used vs. the platform resources list? Going half 
way without a clear distinction of purpose will just confuse the 
matter. (my opinion)

>> 3. Naming convention, are all these devices just in the MPC82xx 
>> family?
>> If the CPM is a general FSL co-processor, used across many processor
>> families, then I like the CPM2 naming convention.
>
> The key there is the driver name not the enum name.  If you look the 
> driver name field matches 85xx.  These files might be better of called 
> pq2_* instead of mpc82xx_ (8240/1/5 is not handled here) or cpm2_ 
> (85xx has cpm2).
>

I used the name CPM2 because that is how all the files are now renamed. 
Based on the #ifdef in your patch, you can see that 82xx and 83xx use 
the same device definitions. Lets change the name.

>> 4. What about PCI?
>
> What about it, none of the busses have specific drivers at this point 
> so they haven't been added.
>
>> 5. This patch does not address the platform specific device 
>> structures.
>> How do you want to handle these?
>
> I want to do that as a second pass every we close on this.  Since the 
> platform specific device structs are going to be based on what is 
> needed for the drivers.
>
That is true but a good example is the FCC definition. You removed one 
IORESOURCE from the sample you provided earlier because it changed 
based on processor. (8260 vs 8272) It would have been beneficial to see 
this in your patch as an example.

-- Allen

Re: RFC: cpm2_devices.c

[Vitaly Bordug]

Kumar,
I assume this as a IMMR enumerating you promised to help with. Is it in 
the final state? And what was the reason of fcc_regs_c removal?
I'm also going to change the files name to cpm2_.. .
Allen,
I'll provide a patch containing these platform stuff together with 
platform-specific device structures which is utilized in the fs_enet 
driver. As now it's clear that fcc_mem dpram offset should be passed 
over platform_info, these structures at least regarding fs_enet probably 
will not change.

--
Sincerely, Vitaly

Re: RFC: cpm2_devices.c

[Jason McMullan]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

My personal opinions:

	* Use macro-offsets into a cpm2_map_t struct
	* Put fcc_c regs back in
	* dpram[PROFF_*] should be in the resources list
	* cpm2_* is a better name than MPC82xx_* or MPC85xx_*
	* Keep CPM2_DMA, etc, as these *should* be showing up in
	  /proc/iomem, since, IIRC, the platform layer does
	  reserve them upon registration. (And I *do* have a DMA
	  layer then uses CPM2_DMA as a driver-ish thing)

-- 
Jason McMullan <jason.mcmullan@gmail.com>
"Sure, send me the latest Knoppix DVD as an attachment..."

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: RFC: cpm2_devices.c

[Kumar Gala]

On Jun 15, 2005, at 2:55 AM, Vitaly Bordug wrote:

> Kumar,
> I assume this as a IMMR enumerating you promised to help with. Is it in
> the final state? And what was the reason of fcc_regs_c removal?
> I'm also going to change the files name to cpm2_.. .

Yes, I removed the fcc_regs_c since its not always true.  Please don't 
rename the file to cpm2_.  I think I'm going to end up renaming them to 
pq2_ since that is the most appropriate name.  I'd say we are about 80% 
the way to a final patch.

- kumar

Re: RFC: cpm2_devices.c

[Kumar Gala]

>> I'm trying to stay away from basing things on the structure.  Since
>> the offsets are truly fixed I see not reason to try to make sure that
>> the immap structure is always correct for all cases.  Hopefully this
>> will end up removing the need to ifdef the immap structure as we go
>> forward.
>>
>
> I am not sure I understand the purpose of each access method. How is
> the immap structure used vs. the platform resources list? Going half
> way without a clear distinction of purpose will just confuse the
> matter. (my opinion)

Agreed, I guess what I mean is going forward drivers should contain 
their own structure defn.

>> pq2_* instead of mpc82xx_ (8240/1/5 is not handled here) or cpm2_
>> (85xx has cpm2).
>
> I used the name CPM2 because that is how all the files are now renamed.
> Based on the #ifdef in your patch, you can see that 82xx and 83xx use
> the same device definitions. Lets change the name.

Sure but...  I'll change the file names to pq2_ which is what makes the 
most sense at the end of they.

- kumar

Re: RFC: cpm2_devices.c

[Kumar Gala]

On Jun 14, 2005, at 11:41 PM, Allen Curtis wrote:

>>>> I've also included our version of this patch for commentary. Did you
>>>> see a
>>>> need for the following to actually be devices? (DMA, CPM, SI1,
> SIC2).
>>>>
>>> The good thing about them actually being devices is that you can find
>>> them and the IO resources had already been remapped. You don't need a
>>> device driver for them but they are resources used by other device
>>> drivers.
>>
>> Not sure I follow.  The IO resources are not mapped by anything until
>> some piece of code does an explicit ioremap().  How do you plan on
>> finding them?  I've got now issue adding them, I just want to
>> understand how you see us using them.  A simple code example might be
>> helpful.

Allen, you haven't addressed my question.

- kumar

Re: RFC: cpm2_devices.c

[Jason McMullan]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

On Wed, 2005-06-15 at 09:25 -0500, Kumar Gala wrote:
> Yes, I removed the fcc_regs_c since its not always true.  Please don't 
> rename the file to cpm2_.  I think I'm going to end up renaming them to 
> pq2_ since that is the most appropriate name.  I'd say we are about 80% 

 PQ2_? But all these devices are on PQ3 also!

-- 
Jason McMullan <jason.mcmullan@gmail.com>
"Sure, send me the latest Knoppix DVD as an attachment..."

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: RFC: cpm2_devices.c

[Kumar Gala]

On Jun 15, 2005, at 9:33 AM, Jason McMullan wrote:

> On Wed, 2005-06-15 at 09:25 -0500, Kumar Gala wrote:
>> Yes, I removed the fcc_regs_c since its not always true.  Please don't
>> rename the file to cpm2_.  I think I'm going to end up renaming them 
>> to
>> pq2_ since that is the most appropriate name.  I'd say we are about 
>> 80%
>
>  PQ2_? But all these devices are on PQ3 also!

Sure and they are in the mpc85xx_* files.  Maybe I'm missing some 
concern people have here.  It dont see what the issue is.  This is just 
like how TSEC/gianfar show up in both mpc85xx_* and mpc83xx_*.  These 
files are intended to represent the devices found on a product family 
(PQ2, PQ3, PQ2 Pro, etc.).  There is going to be overlap.

Also, its not 100% true that all of the devices on a PQ2 exist in PQ3.  
For example (and this isn't a great one) the security block on 
8248/8272 is different than the security block on PQ3 devices.

- kumar

Re: RFC: cpm2_devices.c

[Kumar Gala]

On Jun 15, 2005, at 9:24 AM, Jason McMullan wrote:

> My personal opinions:
>
> 	* Use macro-offsets into a cpm2_map_t struct

Not going to happen.  Sorry.

> 	* Put fcc_c regs back in

Can you explain this.  I'm not 100% sure what regs you are referring to.

> 	* dpram[PROFF_*] should be in the resources list

The patch I posted seems to do that.  I'm guessing these comments may 
be against Allen's initial patch.

> 	* cpm2_* is a better name than MPC82xx_* or MPC85xx_*
> 	* Keep CPM2_DMA, etc, as these *should* be showing up in
> 	  /proc/iomem, since, IIRC, the platform layer does
> 	  reserve them upon registration. (And I *do* have a DMA
> 	  layer then uses CPM2_DMA as a driver-ish thing)

I'll agree on DMA, do you see value in CPM, SI1 and SI2 being here?  
And if so for what?

- kumar

Re: RFC: cpm2_devices.c

[Vitaly Bordug]

Kumar Gala wrote:

>
> On Jun 15, 2005, at 2:55 AM, Vitaly Bordug wrote:
>
>> Kumar,
>> I assume this as a IMMR enumerating you promised to help with. Is it in
>> the final state? And what was the reason of fcc_regs_c removal?
>> I'm also going to change the files name to cpm2_.. .
>
>
> Yes, I removed the fcc_regs_c since its not always true.  Please don't 
> rename the file to cpm2_.  I think I'm going to end up renaming them 
> to pq2_ since that is the most appropriate name.  I'd say we are about 
> 80% the way to a final patch.
>
Great. Apart of naming issue - what else remaining to do?
I mean how can I contribute to speed-up this?

-- 
Sincerely, 
Vitaly

Re: RFC: cpm2_devices.c

[Kumar Gala]

On Jun 15, 2005, at 10:31 AM, Vitaly Bordug wrote:

> Kumar Gala wrote:
>
>>
>> On Jun 15, 2005, at 2:55 AM, Vitaly Bordug wrote:
>>
>>> Kumar,
>>> I assume this as a IMMR enumerating you promised to help with. Is it 
>>> in
>>> the final state? And what was the reason of fcc_regs_c removal?
>>> I'm also going to change the files name to cpm2_.. .
>>
>>
>> Yes, I removed the fcc_regs_c since its not always true.  Please don't
>> rename the file to cpm2_.  I think I'm going to end up renaming them
>> to pq2_ since that is the most appropriate name.  I'd say we are about
>> 80% the way to a final patch.
>>
> Great. Apart of naming issue - what else remaining to do?
> I mean how can I contribute to speed-up this?

At this point, I think a bit more discussion is going to be needed on 
if SI1, SI2, and CPM are "devices" or not.

Also, does the proposed FCC defn. sufficient or do we need the extended 
registers that exist on some of the newer PQ2/PQ3 devices?  I wasn't 
sure if the drivers used them or not.

- kumar

Re: RFC: cpm2_devices.c

[Vitaly Bordug]

Kumar Gala wrote:

>
> On Jun 15, 2005, at 10:31 AM, Vitaly Bordug wrote:
>
>> Kumar Gala wrote:
>>
>>>
>>> On Jun 15, 2005, at 2:55 AM, Vitaly Bordug wrote:
>>>
>>>> Kumar,
>>>> I assume this as a IMMR enumerating you promised to help with. Is 
>>>> it in
>>>> the final state? And what was the reason of fcc_regs_c removal?
>>>> I'm also going to change the files name to cpm2_.. .
>>>
>>>
>>>
>>> Yes, I removed the fcc_regs_c since its not always true.  Please don't
>>> rename the file to cpm2_.  I think I'm going to end up renaming them
>>> to pq2_ since that is the most appropriate name.  I'd say we are about
>>> 80% the way to a final patch.
>>>
>> Great. Apart of naming issue - what else remaining to do?
>> I mean how can I contribute to speed-up this?
>
>
> At this point, I think a bit more discussion is going to be needed on 
> if SI1, SI2, and CPM are "devices" or not.
>
> Also, does the proposed FCC defn. sufficient or do we need the 
> extended registers that exist on some of the newer PQ2/PQ3 devices?  I 
> wasn't sure if the drivers used them or not.
>
fs_enet uses fcc_regs_c but only as a pass to the generic ethtool stuff 
but I'm not currently aware if it's compulsory. I guess FCC's mem(used 
to be IORESORCE) will be passed through platform_info but... Well, we 
have tiptridx etc. stuff that wants DPRAM offsets but pad area has to be 
real address. I'm still not sure how to handle this correct...

> - kumar
>
>


-- 
Sincerely, 
Vitaly

Re: RFC: cpm2_devices.c

[Allen Curtis]

> On Jun 15, 2005, at 9:24 AM, Jason McMullan wrote:
>
>> My personal opinions:
>>
>> 	* Use macro-offsets into a cpm2_map_t struct
>
> Not going to happen.  Sorry.
>

Interesting... So are you thinking of eliminating the cpm_map_t 
structure all together?

>> 	* Put fcc_c regs back in
>
> Can you explain this.  I'm not 100% sure what regs you are referring 
> to.
>

The registers that he is referring to are in my patch with a comment 
about moving them to the device driver specific structure. The base 
address changed depending on processor.

>> 	* dpram[PROFF_*] should be in the resources list
>
> The patch I posted seems to do that.  I'm guessing these comments may 
> be against Allen's initial patch.
>
My patch did you the #defines from cpm2.h to specify the PROFF 
locations. It did not use dpram[PROFF] since that would be an address 
not an offset from the base.

>> 	* cpm2_* is a better name than MPC82xx_* or MPC85xx_*
>> 	* Keep CPM2_DMA, etc, as these *should* be showing up in
>> 	  /proc/iomem, since, IIRC, the platform layer does
>> 	  reserve them upon registration. (And I *do* have a DMA
>> 	  layer then uses CPM2_DMA as a driver-ish thing)
>
> I'll agree on DMA, do you see value in CPM, SI1 and SI2 being here?  
> And if so for what?
>
I really do not want to belabor this point about naming conventions but 
I believe it will become more of a problem in the future. The problem 
as I see it is the PQ2 is a multi-core processor composed of a PPC 603 
and a CPM. So the question is, is it more efficient to describe the 
multi-core permutations or the pieces that are put together to create 
the processor. As industry uses more IP blocks to create SoCs I can see 
the "describe the chip" approach to be a exponential problem.

DMA and CPM should be in the device list. They represent a shared 
resource or a management function shared by the "real" devices. Putting 
them in the list has the advantage that their resources are mapped with 
the device is registered. (as mentioned by Jason M.) Perhaps there will 
be a need for a DMA manager.

Re: RFC: cpm2_devices.c

[Vitaly Bordug]

Allen Curtis wrote:

>> On Jun 15, 2005, at 9:24 AM, Jason McMullan wrote:
>>
>>> My personal opinions:
>>>
>>>     * Use macro-offsets into a cpm2_map_t struct
>>
>>
>> Not going to happen.  Sorry.
>>
>
> Interesting... So are you thinking of eliminating the cpm_map_t 
> structure all together?

I guess not that tough. I used to have really disappointing problem when 
on of the patches added a small error to immr structure. Whole day of 
ghost hust while the problem wasn't even mine. So the hardcoded offsets 
are intended to prevent such cases. I don't think cpm_map_t will be 
eliminated as structure is much more comfortable and understandable than 
pure offsets.  Bus I agree that structure-dependence within platform 
definitions is not very good idea. IMHO.

>
>>>     * Put fcc_c regs back in
>>
>>
>> Can you explain this.  I'm not 100% sure what regs you are referring to.
>>
>
> The registers that he is referring to are in my patch with a comment 
> about moving them to the device driver specific structure. The base 
> address changed depending on processor.
>
>>>     * dpram[PROFF_*] should be in the resources list
>>
>>
>> The patch I posted seems to do that.  I'm guessing these comments may 
>> be against Allen's initial patch.
>>
> My patch did you the #defines from cpm2.h to specify the PROFF 
> locations. It did not use dpram[PROFF] since that would be an address 
> not an offset from the base.
>
>>>     * cpm2_* is a better name than MPC82xx_* or MPC85xx_*
>>>     * Keep CPM2_DMA, etc, as these *should* be showing up in
>>>       /proc/iomem, since, IIRC, the platform layer does
>>>       reserve them upon registration. (And I *do* have a DMA
>>>       layer then uses CPM2_DMA as a driver-ish thing)
>>
>>
>> I'll agree on DMA, do you see value in CPM, SI1 and SI2 being here?  
>> And if so for what?
>>
> I really do not want to belabor this point about naming conventions 
> but I believe it will become more of a problem in the future. The 
> problem as I see it is the PQ2 is a multi-core processor composed of a 
> PPC 603 and a CPM. So the question is, is it more efficient to 
> describe the multi-core permutations or the pieces that are put 
> together to create the processor. As industry uses more IP blocks to 
> create SoCs I can see the "describe the chip" approach to be a 
> exponential problem.
>
Definitely.And there isn't only one issue. For example, I think 8xx will 
never get such device/sys files because the fact that the board has 8xx 
chip means nearly nothing in term of what devices it has. The best 
decision this case to manually call platform_device_register on 
structures created within board-specific code.

> DMA and CPM should be in the device list. They represent a shared 
> resource or a management function shared by the "real" devices. 
> Putting them in the list has the advantage that their resources are 
> mapped with the device is registered. (as mentioned by Jason M.) 
> Perhaps there will be a need for a DMA manager.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>


-- 
Sincerely, 
Vitaly

Re: RFC: cpm2_devices.c

[Pantelis Antoniou]

Let me hop in here...

Have you thought about breaking up the structures per
cpm peripheral?

Some registers are unique for each processor family, but
others are (almost) common to all.

For example SCC parameters & stuff are the same on 8xx/82xx ...

IMHO keeping one definition in the tree for these will make
keeping them in sync easier.

Then the main header file will be the definitions of the
unique registers, a number of defines for the structures offsets
and a list of included files for the common peripherals...

Regards

Pantelis

Re: RFC: cpm2_devices.c

[Wolfgang Denk]

In message <42B11F5B.2050706@intracom.gr> you wrote:
> Let me hop in here...
> 
> Have you thought about breaking up the structures per
> cpm peripheral?

I complained about this a long time ago (when  Kumar's  patches  were
checked  in for 2.4.26 which broke compatibility between 8xx and 8260
systems).

> Some registers are unique for each processor family, but
> others are (almost) common to all.

It would indeed be beneficial if common parts used common definitions
and names.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
When you die, the first thing you lose is your life. The  next  thing
is the illusions.                       - Terry Pratchett, _Pyramids_

Re: RFC: cpm2_devices.c

[Kumar Gala]

I'm not sure I follow on what you want done.  I done see the 
pq2_device.c file changing much once we put it in place.  If there is a 
little duplication between pq1_device.c, pq2_device.c and 
mpc85xx_device.c I'm not to concerned about it since the only 
information in there is memory offsets and IRQs.

If the structures for an SCC uart driver are the same for PQ1 and PQ2 
then I would expect the SCC uart driver to handle that fact going 
forward.

- kumar

On Jun 16, 2005, at 1:42 AM, Pantelis Antoniou wrote:

> Let me hop in here...
>
> Have you thought about breaking up the structures per
> cpm peripheral?
>
> Some registers are unique for each processor family, but
> others are (almost) common to all.
>
> For example SCC parameters & stuff are the same on 8xx/82xx ...
>
> IMHO keeping one definition in the tree for these will make
> keeping them in sync easier.
>
> Then the main header file will be the definitions of the
> unique registers, a number of defines for the structures offsets
> and a list of included files for the common peripherals...
>
> Regards
>
> Pantelis

Re: RFC: cpm2_devices.c

[Dan Malek]

On Jun 15, 2005, at 12:13 AM, Kumar Gala wrote:

>> 2. I am torn about using numeric IMMR offsets vs. the structure member
>> approach. The good thing is that you can create all the devices in a
>> single table even if they overlay depending on processor. The question
>> is, will the IMMAP structure become obsolete? If not, then you will
>> still need the conditional compiles in immap_cpm2.h.
>
> I'm trying to stay away from basing things on the structure.  Since 
> the offsets are truly fixed I see not reason to try to make sure that 
> the immap structure is always correct for all cases.

Having just converted an different SoC part from using offsets to data
structures, I have to say that tables/defines of offsets are more of a 
mess
than a data structure.  We don't have to define the whole of the IMMAP, 
but
using the data structures for the individual device spaces is quite 
effective.
The advantage of using the data structure is it also conveys the data 
type
size, adding a level error checking.  I also dislike io accessor 
functions/macros,
especially on these processor specific devices.


Thanks.

	-- Dan

Re: RFC: cpm2_devices.c

[Kumar Gala]

Dan,

If I understand you correctly this is not any different than how we 
handle the TSEC (gianfar) on 85xx.  The platform device structure just 
gives us physical address (start & end) and IRQs and we use a structure 
in the driver that maps to the start address.

- kumar

> Having just converted an different SoC part from using offsets to data
> structures, I have to say that tables/defines of offsets are more of a
> mess
> than a data structure.  We don't have to define the whole of the IMMAP,
> but
> using the data structures for the individual device spaces is quite
> effective.
> The advantage of using the data structure is it also conveys the data
> type
> size, adding a level error checking.  I also dislike io accessor
> functions/macros,
> especially on these processor specific devices.
>
>
> Thanks.
>
> 	-- Dan

Re: RFC: cpm2_devices.c

[Allen Curtis]

> If I understand you correctly this is not any different than how we 
> handle the TSEC (gianfar) on 85xx.  The platform device structure just 
> gives us physical address (start & end) and IRQs and we use a 
> structure in the driver that maps to the start address.
>
> - kumar
>

So have we answered your question regarding the inclusion of DMA and 
CPM in the platform_device array? If I am reading this correctly, all 
the individual CPM "objects" should be defined in the device structure 
with their physical address location defined. The complete IMMAP 
structure can then be constructed from these objects if required.

Is it possible to add some flags to the IORESOURCE information to 
address the differences in SCC structures between processor types? 
Perhaps something like this could be used to apply the correct 
structure cast in the device driver. Just a thought...

-- Allen

>> Having just converted an different SoC part from using offsets to data
>> structures, I have to say that tables/defines of offsets are more of a
>> mess
>> than a data structure.  We don't have to define the whole of the 
>> IMMAP,
>> but
>> using the data structures for the individual device spaces is quite
>> effective.
>> The advantage of using the data structure is it also conveys the data
>> type
>> size, adding a level error checking.  I also dislike io accessor
>> functions/macros,
>> especially on these processor specific devices.
>>
>>
>> Thanks.
>>
>> 	-- Dan
>
>

Re: RFC: cpm2_devices.c

[Kumar Gala]

> So have we answered your question regarding the inclusion of DMA and
> CPM in the platform_device array? If I am reading this correctly, all
> the individual CPM "objects" should be defined in the device structure
> with their physical address location defined. The complete IMMAP
> structure can then be constructed from these objects if required.

Actually, I dont feel that anyone has given a reason why or how they 
would use CPM, DMA, SI1, SI2 if they were platform devices.

> Is it possible to add some flags to the IORESOURCE information to
> address the differences in SCC structures between processor types?
> Perhaps something like this could be used to apply the correct
> structure cast in the device driver. Just a thought...

I envisioned this being a field in the platform_data structures for the 
devices.

- kumar

Re: RFC: cpm2_devices.c

[Allen Curtis]

>> So have we answered your question regarding the inclusion of DMA and
>> CPM in the platform_device array? If I am reading this correctly, all
>> the individual CPM "objects" should be defined in the device structure
>> with their physical address location defined. The complete IMMAP
>> structure can then be constructed from these objects if required.
>
> Actually, I dont feel that anyone has given a reason why or how they 
> would use CPM, DMA, SI1, SI2 if they were platform devices.
>

Think about the breaking up of the immap structure into little pieces 
with offsets defined in platform_devices....  This is how I read the 
previous conversation.

>> Is it possible to add some flags to the IORESOURCE information to
>> address the differences in SCC structures between processor types?
>> Perhaps something like this could be used to apply the correct
>> structure cast in the device driver. Just a thought...
>
> I envisioned this being a field in the platform_data structures for 
> the devices.
>
Then you envision a device specific structure for each platform_device, 
even if the sole purpose is to convey version information? Ok...

- Allen

Re: RFC: cpm2_devices.c

[Dan Malek]

On Jun 16, 2005, at 11:33 AM, Kumar Gala wrote:

> If I understand you correctly this is not any different than how we 
> handle the TSEC (gianfar) on 85xx.  The platform device structure just 
> gives us physical address (start & end) and IRQs and we use a 
> structure in the driver that maps to the start address.

Yes, that's correct.  However, some of the other devices may be more
challenging, since the set up SCC ports involves accessing multiple
areas of the CPM (parameter ram, device control, BRGs, serial mux,
TDM, etc), for example.  This is why I created the whole immap structure
in the first place.  With a single pointer to it, plus knowing the usage
of the device, I could easily get to all of the necessary spaces.
Using the resource reservation isn't always appropriate either, because
there are lots of shared registers or device spaces in the CPM.  It
may keep you from multiply using a specific SCC, but there are many
other places requiring configuration that are more likely to be
improperly configured by other drivers.

Also, I'm not a fan of the gfar_read/write functions because I never
know their implementation :-)  They use the in/out macros which I
never know if they are for PCI IO or not.  We aren't using any
pipeline synchronization, which we may need.  By the way, I do like
using separate synchronization, not hidden in the in/out functions.

Thanks.


	-- Dan