[PATCH][RFC] OCP support for MPC107 and relatives

[PATCH][RFC] OCP support for MPC107 and relatives

[Adrian Cox]

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

The attached patch is a start at adding the internal peripherals of the
MPC107/MPC8240/MPC8245 to the OCP bus. I've used thus in the 2.6 port of
my MPC107 I2C driver, which follows shortly. I intend to use this for
the DMA controller later, once I decide what device ID to give it.

I'm a little uncertain about OCP device IDs. Should there be a separate
I2C device ID for each different I2C programming interface from the same
vendor? Motorola have already given us two separate implementations on
PowerPC.

This is a little bit different from the PPC40x use of OCP, because it's
hard to calculate everything at compile time. This is particularly
caused by the pcore boards, which use the MPC107 but don't use the
interrupt controller.

I've compiled for pcore, lopec, sandpoint, and an in-house board without
errors. PowerPMC250 was broken before, and I have probably not repaired
it.

Any comments? (I'm away from email midweek, so I may not answer until
Friday.)

- Adrian Cox
Humboldt Solutions Ltd.


[-- Attachment #2: Type: text/x-patch, Size: 8931 bytes --]

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/06/14 10:15:20+01:00 adrian@humboldt.co.uk
#   Add OCP support for MPC10x peripherals, and tidy up OpenPic initialisation.
#
# include/asm-ppc/mpc10x.h
#   2004/06/14 10:14:53+01:00 adrian@humboldt.co.uk +3 -0
#   Add a new MPC10x OpenPIC setup function
#
# arch/ppc/syslib/mpc10x_common.c
#   2004/06/14 10:14:53+01:00 adrian@humboldt.co.uk +50 -3
#   Setup core_ocp structure based on the calls into the MPC10x setup routines.
#
# arch/ppc/syslib/Makefile
#   2004/06/14 10:14:53+01:00 adrian@humboldt.co.uk +4 -4
#   Use new config entry for the MPC10x internal OpenPIC.
#
# arch/ppc/platforms/sandpoint.c
#   2004/06/14 10:14:53+01:00 adrian@humboldt.co.uk +1 -11
#   Use new standardised mpc10x_set_openpic().
#
# arch/ppc/platforms/powerpmc250.c
#   2004/06/14 10:14:53+01:00 adrian@humboldt.co.uk +1 -1
#   Use new standardised mpc10x_set_openpic().
#
# arch/ppc/platforms/lopec_setup.c
#   2004/06/14 10:14:53+01:00 adrian@humboldt.co.uk +1 -14
#   Use new standardised mpc10x_set_openpic().
#
# arch/ppc/Kconfig
#   2004/06/14 10:14:53+01:00 adrian@humboldt.co.uk +6 -1
#   Add OCP support to MPC10x/EPIC combination.
#
diff -Nru a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig	Mon Jun 14 10:18:30 2004
+++ b/arch/ppc/Kconfig	Mon Jun 14 10:18:30 2004
@@ -656,6 +656,11 @@
 	depends on PCORE || POWERPMC250 || LOPEC || SANDPOINT
 	default y

+config MPC10X_OPENPIC
+	bool
+	depends on POWERPMC250 || LOPEC || SANDPOINT
+	default y
+
 config MPC10X_STORE_GATHERING
 	bool "Enable MPC10x store gathering"
 	depends on MPC10X_BRIDGE
@@ -1279,7 +1284,7 @@

 config PPC_OCP
 	bool
-	depends on IBM_OCP
+	depends on IBM_OCP || MPC10X_BRIDGE
 	default y

 endmenu
diff -Nru a/arch/ppc/platforms/lopec_setup.c b/arch/ppc/platforms/lopec_setup.c
--- a/arch/ppc/platforms/lopec_setup.c	Mon Jun 14 10:18:30 2004
+++ b/arch/ppc/platforms/lopec_setup.c	Mon Jun 14 10:18:30 2004
@@ -193,21 +193,8 @@
 	OpenPIC_InitSenses = lopec_openpic_initsenses;
 	OpenPIC_NumInitSenses = sizeof(lopec_openpic_initsenses);

-	/*
-	 * We need to tell openpic_set_sources where things actually are.
-	 * mpc10x_common will setup OpenPIC_Addr at ioremap(EUMB phys base +
-	 * EPIC offset (0x40000));  The EPIC IRQ Register Address Map -
-	 * Interrupt Source Configuration Registers gives these numbers
-	 * as offsets starting at 0x50200, we need to adjust occordinly.
-	 */
-	/* Map serial interrupts 0-15 */
-	openpic_set_sources(0, 16, OpenPIC_Addr + 0x10200);
-	/* Skip reserved space and map i2c and DMA Ch[01] */
-	openpic_set_sources(16, 3, OpenPIC_Addr + 0x11020);
-	/* Skip reserved space and map Message Unit Interrupt (I2O) */
-	openpic_set_sources(19, 1, OpenPIC_Addr + 0x110C0);
+	mpc10x_set_openpic();

-	openpic_init(NUM_8259_INTERRUPTS);
 	/* We have a cascade on OpenPIC IRQ 0, Linux IRQ 16 */
 	openpic_hookup_cascade(NUM_8259_INTERRUPTS, "82c59 cascade",
 			&i8259_irq);
diff -Nru a/arch/ppc/platforms/powerpmc250.c b/arch/ppc/platforms/powerpmc250.c
--- a/arch/ppc/platforms/powerpmc250.c	Mon Jun 14 10:18:30 2004
+++ b/arch/ppc/platforms/powerpmc250.c	Mon Jun 14 10:18:30 2004
@@ -197,7 +197,7 @@

 	OpenPIC_InitSenses = powerpmc250_openpic_initsenses;
 	OpenPIC_NumInitSenses = sizeof(powerpmc250_openpic_initsenses);
-	openpic_init(1, 0, 0, -1);
+	mpc10x_set_openpic();
 }

 /*
diff -Nru a/arch/ppc/platforms/sandpoint.c b/arch/ppc/platforms/sandpoint.c
--- a/arch/ppc/platforms/sandpoint.c	Mon Jun 14 10:18:30 2004
+++ b/arch/ppc/platforms/sandpoint.c	Mon Jun 14 10:18:30 2004
@@ -433,17 +433,7 @@
 	OpenPIC_InitSenses = sandpoint_openpic_initsenses;
 	OpenPIC_NumInitSenses = sizeof(sandpoint_openpic_initsenses);

-	/*
-	 * We need to tell openpic_set_sources where things actually are.
-	 * mpc10x_common will setup OpenPIC_Addr at ioremap(EUMB phys base +
-	 * EPIC offset (0x40000));  The EPIC IRQ Register Address Map -
-	 * Interrupt Source Configuration Registers gives these numbers
-	 * as offsets starting at 0x50200, we need to adjust occordinly.
-	 */
-	/* Map serial interrupts 0-15 */
-	openpic_set_sources(0, 16, OpenPIC_Addr + 0x10200);
-
-	openpic_init(NUM_8259_INTERRUPTS);
+	mpc10x_set_openpic();
 	openpic_hookup_cascade(NUM_8259_INTERRUPTS, "82c59 cascade",
 			i8259_irq);

diff -Nru a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile	Mon Jun 14 10:18:30 2004
+++ b/arch/ppc/syslib/Makefile	Mon Jun 14 10:18:30 2004
@@ -45,7 +45,7 @@
 obj-$(CONFIG_GEMINI)		+= open_pic.o indirect_pci.o
 obj-$(CONFIG_K2)		+= i8259.o indirect_pci.o todc_time.o \
 					pci_auto.o
-obj-$(CONFIG_LOPEC)		+= pci_auto.o open_pic.o i8259.o todc_time.o
+obj-$(CONFIG_LOPEC)		+= i8259.o pci_auto.o todc_time.o
 obj-$(CONFIG_MCPN765)		+= todc_time.o indirect_pci.o pci_auto.o \
 					open_pic.o i8259.o hawk_common.o
 obj-$(CONFIG_MENF1)		+= todc_time.o i8259.o mpc10x_common.o \
@@ -55,15 +55,14 @@
 obj-$(CONFIG_OCOTEA)		+= indirect_pci.o pci_auto.o todc_time.o
 obj-$(CONFIG_PAL4)		+= cpc700_pic.o
 obj-$(CONFIG_PCORE)		+= todc_time.o i8259.o pci_auto.o
-obj-$(CONFIG_POWERPMC250)	+= open_pic.o pci_auto.o
+obj-$(CONFIG_POWERPMC250)	+= pci_auto.o
 obj-$(CONFIG_PPLUS)		+= hawk_common.o open_pic.o i8259.o \
 				   indirect_pci.o todc_time.o pci_auto.o
 obj-$(CONFIG_PRPMC750)		+= open_pic.o indirect_pci.o pci_auto.o \
 					hawk_common.o
 obj-$(CONFIG_HARRIER)		+= harrier.o
 obj-$(CONFIG_PRPMC800)		+= open_pic.o indirect_pci.o pci_auto.o
-obj-$(CONFIG_SANDPOINT)		+= i8259.o open_pic.o pci_auto.o todc_time.o
-obj-$(CONFIG_SA107)		+= i8259.o open_pic.o
+obj-$(CONFIG_SANDPOINT)		+= i8259.o pci_auto.o todc_time.o
 obj-$(CONFIG_SBC82xx)		+= todc_time.o
 obj-$(CONFIG_SPRUCE)		+= cpc700_pic.o indirect_pci.o pci_auto.o \
 				   todc_time.o
@@ -74,5 +73,6 @@
 endif
 obj-$(CONFIG_BOOTX_TEXT)	+= btext.o
 obj-$(CONFIG_MPC10X_BRIDGE)     += mpc10x_common.o indirect_pci.o
+obj-$(CONFIG_MPC10X_OPENPIC)	+= open_pic.o
 obj-$(CONFIG_40x)		+= dcr.o
 obj-$(CONFIG_BOOKE)		+= dcr.o
diff -Nru a/arch/ppc/syslib/mpc10x_common.c b/arch/ppc/syslib/mpc10x_common.c
--- a/arch/ppc/syslib/mpc10x_common.c	Mon Jun 14 10:18:30 2004
+++ b/arch/ppc/syslib/mpc10x_common.c	Mon Jun 14 10:18:30 2004
@@ -30,7 +30,25 @@
 #include <asm/pci-bridge.h>
 #include <asm/open_pic.h>
 #include <asm/mpc10x.h>
+#include <asm/ocp.h>

+/* The OCP structure is fixed by code below, before OCP initialises.
+   paddr depends on where the board places the EUMB.
+    - fixed in mpc10x_bridge_init().
+   irq depends on two things:
+    > does the board use the EPIC at all? (PCORE does not).
+    > is the EPIC in serial or parallel mode?
+    - fixed in mpc10x_set_openpic().
+*/
+struct ocp_def core_ocp[] = {
+	{ .vendor	= OCP_VENDOR_MOTOROLA,
+	  .function	= OCP_FUNC_IIC,
+	  .index	= 0,
+	  .irq		= OCP_IRQ_NA
+	},
+	{ .vendor	= OCP_VENDOR_INVALID
+	}
+};

 /* Set resources to match bridge memory map */
 void __init
@@ -213,7 +231,10 @@
 					byte);
 	}

-	if (host_bridge != MPC10X_BRIDGE_106) {
+	if (host_bridge == MPC10X_BRIDGE_106) {
+		/* On-chip peripherals were introduced with the MPC107/MPC8240 */
+		core_ocp[0].vendor = OCP_VENDOR_INVALID;
+	} else {
 		early_read_config_byte(hose,
 				       0,
 				       PCI_DEVFN(0,0),
@@ -231,11 +252,14 @@
 					 PCI_DEVFN(0,0),
 					 MPC10X_CFG_EUMBBAR,
 					 phys_eumb_base);
-
-		/* Map EPIC register part of EUMB into vitual memory */
+#ifdef CONFIG_MPC10X_OPENPIC
+		/* Map EPIC register part of EUMB into vitual memory  - PCORE
+		   uses an i8259 instead of EPIC. */
 		OpenPIC_Addr =
 			ioremap(phys_eumb_base + MPC10X_EUMB_EPIC_OFFSET,
 				MPC10X_EUMB_EPIC_SIZE);
+#endif
+		core_ocp[0].paddr = phys_eumb_base + MPC10X_EUMB_I2C_OFFSET;
 	}

 #ifdef CONFIG_MPC10X_STORE_GATHERING
@@ -397,3 +421,26 @@

 	return 0;
 }
+
+#ifdef CONFIG_MPC10X_OPENPIC
+void __init mpc10x_set_openpic(void)
+{
+#ifdef CONFIG_EPIC_SERIAL_MODE
+#define EPIC_IRQ_BASE 16
+	/* Map 16 serial IRQs */
+	openpic_set_sources(0, 16, OpenPIC_Addr + 0x10200);
+#else
+#define EPIC_IRQ_BASE 5
+	/* Map EPIC IRQs 0-4 */
+	openpic_set_sources(0, 5, OpenPIC_Addr + 0x10200);
+#endif
+	/* Skip reserved space and map i2c and DMA Ch[01] */
+	openpic_set_sources(EPIC_IRQ_BASE, 3, OpenPIC_Addr + 0x11020);
+	/* Skip reserved space and map Message Unit Interrupt (I2O) */
+	openpic_set_sources(EPIC_IRQ_BASE + 3, 1, OpenPIC_Addr + 0x110C0);
+
+	core_ocp[0].irq = NUM_8259_INTERRUPTS + EPIC_IRQ_BASE;
+
+	openpic_init(NUM_8259_INTERRUPTS);
+}
+#endif
diff -Nru a/include/asm-ppc/mpc10x.h b/include/asm-ppc/mpc10x.h
--- a/include/asm-ppc/mpc10x.h	Mon Jun 14 10:18:30 2004
+++ b/include/asm-ppc/mpc10x.h	Mon Jun 14 10:18:30 2004
@@ -164,4 +164,7 @@
 int mpc10x_enable_store_gathering(struct pci_controller *hose);
 int mpc10x_disable_store_gathering(struct pci_controller *hose);

+/* For MPC107 boards that use the built-in openpic */
+void mpc10x_set_openpic(void);
+
 #endif	/* __PPC_KERNEL_MPC10X_H */

[PATCH][RFC] I2C support for MPC107 and relatives

[Adrian Cox]

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

The attached patch is a 2.6 port of my I2C driver for the MPC107 and
relatives. It uses my OCP patch to find the address and IRQ information,
which replaces the direct reading of EPIC registers used in the 2.4
version.

Both of these are against the linux-2.5 tree.

Again, any comments? (I'm away from email midweek, so I may not answer
until Friday.)

- Adrian Cox
Humboldt Solutions Ltd.


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

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/06/14 10:54:08+01:00 adrian@humboldt.co.uk
#   Add MPC107 I2C interface
#
# drivers/i2c/busses/i2c-mpc107.c
#   2004/06/14 10:53:50+01:00 adrian@humboldt.co.uk +402 -0
#
# drivers/i2c/busses/i2c-mpc107.c
#   2004/06/14 10:53:50+01:00 adrian@humboldt.co.uk +0 -0
#   BitKeeper file /home/adrian/kernels/sa107-2.6/sa107-2/drivers/i2c/busses/i2c-mpc107.c
#
# drivers/i2c/busses/Makefile
#   2004/06/14 10:53:50+01:00 adrian@humboldt.co.uk +1 -0
#   Add MPC107 I2C interface
#
# drivers/i2c/busses/Kconfig
#   2004/06/14 10:53:50+01:00 adrian@humboldt.co.uk +10 -0
#   Add MPC107 I2C interface
#
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig	Mon Jun 14 10:55:04 2004
+++ b/drivers/i2c/busses/Kconfig	Mon Jun 14 10:55:04 2004
@@ -396,4 +396,14 @@
 	  This driver can also be built as a module.  If so, the module
 	  will be called i2c-voodoo3.

+config I2C_MPC107
+	tristate "MPC107/824x"
+	depends on I2C && MPC10X_BRIDGE
+	help
+	  If you say yes to this option, support will be included for the
+	  built-in I2C interface on the MPC107/Tsi107/MPC8240/MPC8245.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called i2c-mpc107.
+
 endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile	Mon Jun 14 10:55:04 2004
+++ b/drivers/i2c/busses/Makefile	Mon Jun 14 10:55:04 2004
@@ -32,6 +32,7 @@
 obj-$(CONFIG_I2C_VOODOO3)	+= i2c-voodoo3.o
 obj-$(CONFIG_SCx200_ACB)	+= scx200_acb.o
 obj-$(CONFIG_SCx200_I2C)	+= scx200_i2c.o
+obj-$(CONFIG_I2C_MPC107)	+= i2c-mpc107.o

 ifeq ($(CONFIG_I2C_DEBUG_BUS),y)
 EXTRA_CFLAGS += -DDEBUG
diff -Nru a/drivers/i2c/busses/i2c-mpc107.c b/drivers/i2c/busses/i2c-mpc107.c
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ b/drivers/i2c/busses/i2c-mpc107.c	Mon Jun 14 10:55:04 2004
@@ -0,0 +1,402 @@
+/*
+ * (C) Copyright 2003-2004
+ * Humboldt Solutions Ltd, adrian@humboldt.co.uk.
+
+ * This is a combined i2c adapter and algorithm driver for Motorola's
+ * MPC107 PowerPC northbridge and related silicon (8240, 8245).
+ *
+ * Release 0.4
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/sched.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <asm/io.h>
+#include <asm/mpc10x.h>
+#include <asm/ocp.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+
+#ifdef CONFIG_I2C_DEBUG_BUS
+#define DPRINTK(args...) printk(KERN_DEBUG __FILE__": " args)
+#else
+#define DPRINTK(args...)
+#endif
+
+
+#define MPC107_I2CADDR  0x00
+#define MPC107_I2CFDR 	0x04
+#define MPC107_I2CCR	0x08
+#define MPC107_I2CSR	0x0c
+#define MPC107_I2CDR	0x10
+
+#define MPC107_CCR_MEN  0x80
+#define MPC107_CCR_MIEN 0x40
+#define MPC107_CCR_MSTA 0x20
+#define MPC107_CCR_MTX  0x10
+#define MPC107_CCR_TXAK 0x08
+#define MPC107_CCR_RSTA 0x04
+
+#define MPC107_CSR_MCF  0x80
+#define MPC107_CSR_MAAS 0x40
+#define MPC107_CSR_MBB  0x20
+#define MPC107_CSR_MAL  0x10
+#define MPC107_CSR_SRW  0x04
+#define MPC107_CSR_MIF  0x02
+#define MPC107_CSR_RXAK 0x01
+
+struct mpc107_i2c {
+	char *base;
+	struct ocp_def *ocpdef;
+	u32 interrupt;
+	wait_queue_head_t queue;
+	struct i2c_adapter adap;
+};
+
+static __inline__ void writeccr(struct mpc107_i2c *i2c, u32 x)
+{
+	writel(x, i2c->base + MPC107_I2CCR);
+}
+
+static irqreturn_t mpc107_i2c_isr(int irq, void *dev_id, struct pt_regs * regs)
+{
+	struct mpc107_i2c *i2c = dev_id;
+	if (readl(i2c->base + MPC107_I2CSR) & MPC107_CSR_MIF) {
+		/* Read again to allow register to stabilise */
+		i2c->interrupt = readl(i2c->base + MPC107_I2CSR);
+		writel(0, i2c->base + MPC107_I2CSR);
+		wake_up_interruptible(&i2c->queue);
+	}
+	return IRQ_HANDLED;
+}
+
+static int i2c_wait(struct mpc107_i2c *i2c, unsigned timeout, int writing)
+{
+	DECLARE_WAITQUEUE(wait, current);
+        unsigned long orig_jiffies = jiffies;
+        u32 x;
+	int result = 0;
+
+	if (i2c->ocpdef->irq == OCP_IRQ_NA) {
+		while(! (readl(i2c->base + MPC107_I2CSR) & MPC107_CSR_MIF)) {
+			schedule();
+			if (orig_jiffies + timeout < jiffies) {
+				DPRINTK("I2C: timeout\n");
+				result = -EIO;
+				break;
+			}
+		}
+		x = readl(i2c->base + MPC107_I2CSR);
+		writel(0, i2c->base + MPC107_I2CSR);
+	} else {
+		add_wait_queue(&i2c->queue, &wait);
+		while ( ! (i2c->interrupt & MPC107_CSR_MIF)) {
+			set_current_state(TASK_INTERRUPTIBLE);
+			if (signal_pending(current)) {
+				DPRINTK("I2C: Interrupted\n");
+				result = -EINTR;
+				break;
+			}
+			if (orig_jiffies + timeout < jiffies) {
+				DPRINTK("I2C: timeout\n");
+				result = -EIO;
+				break;
+			}
+			schedule_timeout(timeout);
+		}
+		current->state = TASK_RUNNING;
+		remove_wait_queue(&i2c->queue, &wait);
+		x = i2c->interrupt;
+		i2c->interrupt = 0;
+	}
+
+	if (result < -0)
+	    return result;
+
+	if (! (x & MPC107_CSR_MCF))
+	{
+	    DPRINTK("I2C: unfinished\n");
+	    return -EIO;
+	}
+
+        if (x & MPC107_CSR_MAL)
+	{
+	    	DPRINTK("I2C: MAL\n");
+                return -EIO;
+	}
+
+        if (writing && (x & MPC107_CSR_RXAK)) {
+                DPRINTK("I2C: No RXAK\n");
+                /* generate stop */
+                writeccr(i2c, MPC107_CCR_MEN);
+                return -EIO;
+        }
+        return 0;
+}
+
+static void mpc107_i2c_start(struct mpc107_i2c *i2c)
+{
+        /* Set clock */
+        writel(0x1031, i2c->base + MPC107_I2CFDR);
+        /* Clear arbitration */
+        writel(0, i2c->base + MPC107_I2CSR);
+       	/* Start with MEN */
+	writeccr(i2c, MPC107_CCR_MEN);
+}
+
+static void mpc107_i2c_stop(struct mpc107_i2c *i2c)
+{
+	writeccr(i2c, MPC107_CCR_MEN);
+}
+
+static int mpc107_write(struct mpc107_i2c *i2c, int target,
+			const u8 *data, int length, int restart)
+{
+        int i;
+        unsigned timeout = HZ;
+    	u32 flags = restart ? MPC107_CCR_RSTA : 0;
+
+	/* Start with MEN */
+	if (! restart)
+		writeccr(i2c, MPC107_CCR_MEN);
+	/* Start as master */
+	writeccr(i2c, MPC107_CCR_MIEN | MPC107_CCR_MEN |
+		      MPC107_CCR_MSTA | MPC107_CCR_MTX | flags);
+	/* Write target byte */
+	writel((target << 1), i2c->base + MPC107_I2CDR);
+
+	if (i2c_wait(i2c, timeout, 1) < 0)
+	    return -1;
+
+        for(i = 0; i < length; i++) {
+	        /* Write data byte */
+	        writel(data[i], i2c->base + MPC107_I2CDR);
+
+	        if (i2c_wait(i2c, timeout, 1) < 0)
+	            return -1;
+        }
+
+        return 0;
+}
+
+static int mpc107_read(struct mpc107_i2c *i2c, int target,
+		       u8 *data, int length, int restart)
+{
+    	unsigned timeout = HZ;
+    	int i;
+    	u32 flags = restart ? MPC107_CCR_RSTA : 0;
+
+	/* Start with MEN */
+	if (! restart)
+		writeccr(i2c, MPC107_CCR_MEN);
+	/* Switch to read - restart */
+	writeccr(i2c, MPC107_CCR_MIEN | MPC107_CCR_MEN | MPC107_CCR_MSTA |
+		      MPC107_CCR_MTX | flags);
+	/* Write target address byte - this time with the read flag set */
+	writel((target << 1) | 1, i2c->base + MPC107_I2CDR);
+
+	if (i2c_wait(i2c, timeout, 0) < 0)
+	    return -1;
+
+	if (length == 1)
+	    writeccr(i2c, MPC107_CCR_MIEN| MPC107_CCR_MEN |
+			  MPC107_CCR_MSTA | MPC107_CCR_TXAK);
+	else
+	    writeccr(i2c, MPC107_CCR_MIEN| MPC107_CCR_MEN | MPC107_CCR_MSTA);
+    	/* Dummy read */
+	readl(i2c->base + MPC107_I2CDR);
+
+	for(i = 0; i < length; i++) {
+		if (i2c_wait(i2c, timeout, 0) < 0)
+			return -1;
+
+		/* Generate txack on next to last byte */
+		if (i == length - 2)
+			writeccr(i2c, MPC107_CCR_MIEN | MPC107_CCR_MEN |
+				      MPC107_CCR_MSTA | MPC107_CCR_TXAK);
+		/* Generate stop on last byte */
+		if (i == length - 1)
+			writeccr(i2c, MPC107_CCR_MIEN | MPC107_CCR_MEN |
+				      MPC107_CCR_TXAK);
+		data[i] = readl(i2c->base + MPC107_I2CDR);
+	}
+
+	return length;
+}
+
+static int mpc107_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
+	                   int num)
+{
+	struct i2c_msg *pmsg;
+	int i;
+	int ret=0;
+        unsigned long orig_jiffies = jiffies;
+	struct mpc107_i2c *i2c = i2c_get_adapdata(adap);
+
+        mpc107_i2c_start(i2c);
+
+	/* Allow bus up to 1s to become not busy */
+	while(readl(i2c->base + MPC107_I2CSR) & MPC107_CSR_MBB) {
+                if (signal_pending(current))
+		{
+			DPRINTK("I2C: Interrupted\n");
+                        return -EINTR;
+		}
+                if (orig_jiffies + HZ < jiffies)
+		{
+		    	printk("I2C: timeout\n");
+                        return -EIO;
+		}
+                schedule();
+        }
+
+	for (i = 0;ret >= 0 && i < num; i++) {
+		pmsg = &msgs[i];
+		DPRINTK("Doing %s %d bytes to 0x%02x - %d of %d messages\n",
+		     pmsg->flags & I2C_M_RD ? "read" : "write",
+                     pmsg->len, pmsg->addr, i + 1, num);
+		if (pmsg->flags & I2C_M_RD)
+                        ret = mpc107_read(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+                else
+                        ret = mpc107_write(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+        }
+        mpc107_i2c_stop(i2c);
+        return (ret < 0) ? ret : num;
+}
+
+static u32 mpc107_functionality(struct i2c_adapter *adap)
+{
+        return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+}
+
+static struct i2c_algorithm mpc107_algo = {
+	.name = "MPC107 algorithm",
+	.id = I2C_ALGO_MPC107,
+	.master_xfer = mpc107_xfer,
+	.functionality = mpc107_functionality,
+};
+
+static struct i2c_adapter mpc107_ops = {
+	.name = "MPC107 adapter",
+	.id = I2C_ALGO_MPC107 | I2C_HW_MPC107,
+	.algo = &mpc107_algo,
+	.class = I2C_CLASS_HWMON,
+	.timeout = 1,
+	.retries = 1
+};
+
+static int __devinit mpc107_i2c_probe(struct ocp_device *ocp)
+{
+	int result = 0;
+	struct mpc107_i2c *i2c;
+
+	if (!(i2c = kmalloc(sizeof(*i2c), GFP_KERNEL))){
+		return -ENOMEM;
+	}
+	i2c->ocpdef = ocp->def;
+	init_waitqueue_head(&i2c->queue);
+
+	if (! request_mem_region(ocp->def->paddr, MPC10X_EUMB_I2C_SIZE,
+		                 "Motorola MPC107 I2C Controller")) {
+		printk(KERN_ERR "MPC107 I2C - resource unavailable\n");
+		return -ENODEV;
+	}
+
+	i2c->base = ioremap(ocp->def->paddr, MPC10X_EUMB_I2C_SIZE);
+
+	if (! i2c->base) {
+		printk(KERN_ERR "MPC107 I2C - failed to map controller\n");
+		result = -ENOMEM;
+		goto fail_map;
+	}
+
+	if (ocp->def->irq != OCP_IRQ_NA)
+		if ((result = request_irq(ocp->def->irq, mpc107_i2c_isr,
+					  0, "mpc107_i2c", i2c)) < 0) {
+			printk(KERN_ERR "MPC107 I2C - failed to attach interrupt\n");
+			goto fail_irq;
+		}
+
+	i2c->adap = mpc107_ops;
+	i2c_set_adapdata(&i2c->adap, i2c);
+	if ((result = i2c_add_adapter(&i2c->adap)) < 0) {
+		printk(KERN_ERR "MPC107 I2C - failed to add adapter\n");
+		goto fail_add;
+	}
+	ocp_set_drvdata(ocp, i2c);
+	return result;
+
+fail_add:
+	if (ocp->def->irq != OCP_IRQ_NA)
+		free_irq(ocp->def->irq, 0);
+fail_irq:
+	iounmap(i2c->base);
+fail_map:
+	release_mem_region(ocp->def->paddr, MPC10X_EUMB_I2C_SIZE);
+	kfree(i2c);
+	return result;
+}
+static void __devexit mpc107_i2c_remove(struct ocp_device *ocp)
+{
+	struct mpc107_i2c *i2c = ocp_get_drvdata(ocp);
+	ocp_set_drvdata(ocp, NULL);
+	i2c_del_adapter(&i2c->adap);
+
+	if (ocp->def->irq != OCP_IRQ_NA)
+		free_irq(i2c->ocpdef->irq, i2c);
+	iounmap(i2c->base);
+	release_mem_region(i2c->ocpdef->paddr, MPC10X_EUMB_I2C_SIZE);
+	kfree(i2c);
+}
+
+static struct ocp_device_id mpc107_iic_ids[] __devinitdata =
+{
+	{ .vendor = OCP_VENDOR_MOTOROLA, .function = OCP_FUNC_IIC },
+	{ .vendor = OCP_VENDOR_INVALID }
+};
+
+MODULE_DEVICE_TABLE(ocp, mpc107_iic_ids);
+
+static struct ocp_driver mpc107_iic_driver =
+{
+	.name 		= "iic",
+	.id_table	= mpc107_iic_ids,
+	.probe		= mpc107_i2c_probe,
+	.remove		= __devexit_p(mpc107_i2c_remove)
+};
+
+static int __init iic_init(void)
+{
+	return ocp_register_driver(&mpc107_iic_driver);
+}
+
+static void __exit iic_exit(void)
+{
+	ocp_unregister_driver(&mpc107_iic_driver);
+}
+
+module_init(iic_init);
+module_exit(iic_exit);
+
+
+MODULE_AUTHOR("Adrian Cox <adrian@humboldt.co.uk>");
+MODULE_DESCRIPTION("I2C-Bus adapter for Motorola MPC107 and related bridges");
+MODULE_LICENSE("GPL");

Re: [PATCH][RFC] I2C support for MPC107 and relatives

[Stefan Nickl]

On Mon, 2004-06-14 at 12:23, Adrian Cox wrote:
> The attached patch is a 2.6 port of my I2C driver for the MPC107 and
> relatives. It uses my OCP patch to find the address and IRQ information,
> which replaces the direct reading of EPIC registers used in the 2.4
> version.

FYI: The Motorola folks recently pushed a I2C driver called i2c-mpc.c
into the 2.4 tree, it seems to be fully OCP'ed, save it seems the
platform hooks are only present for 8540 yet.

It claims to be:
"non-CPM I2C driver for the Motorola MPC85xx, MPC824x, and MPC107"

It works fine on 8540 (except when the PCB has passed the 74°C-mark
and you reboot it ...)

--
Stefan Nickl
Kontron Modular Computers


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH][RFC] I2C support for MPC107 and relatives

[Adrian Cox]

On Mon, 2004-06-14 at 12:01, Stefan Nickl wrote:
> FYI: The Motorola folks recently pushed a I2C driver called i2c-mpc.c
> into the 2.4 tree, it seems to be fully OCP'ed, save it seems the
> platform hooks are only present for 8540 yet.

Do you know which 2.4 tree? It's not in linuxppc_2_4_devel or in the
main 2.4 kernel. If their driver works with my OCP patch, it would save
a whole lot of effort.

- Adrian Cox
Humboldt Solutions Ltd.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH][RFC] I2C support for MPC107 and relatives

[Stefan Nickl]

On Mon, 2004-06-14 at 13:37, Adrian Cox wrote:
> On Mon, 2004-06-14 at 12:01, Stefan Nickl wrote:
> > FYI: The Motorola folks recently pushed a I2C driver called i2c-mpc.c
> > into the 2.4 tree, it seems to be fully OCP'ed, save it seems the
> > platform hooks are only present for 8540 yet.
>
> Do you know which 2.4 tree? It's not in linuxppc_2_4_devel or in the
> main 2.4 kernel. If their driver works with my OCP patch, it would save
> a whole lot of effort.

Sorry, I was talking about
bk://ppc.bkbits.net/linuxppc-2.4

--
Stefan Nickl
Project Engineering
Kontron Modular Computers
Sudetenstr. 7
D-87600 Kaufbeuren
Phone ++49/8341/803-294


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH][RFC] I2C support for MPC107 and relatives

[Adrian Cox]

On Mon, 2004-06-14 at 14:01, Stefan Nickl wrote:
> On Mon, 2004-06-14 at 13:37, Adrian Cox wrote:
> > On Mon, 2004-06-14 at 12:01, Stefan Nickl wrote:
> > > FYI: The Motorola folks recently pushed a I2C driver called i2c-mpc.c
> > > into the 2.4 tree, it seems to be fully OCP'ed, save it seems the
> > > platform hooks are only present for 8540 yet.
> >
> > Do you know which 2.4 tree? It's not in linuxppc_2_4_devel or in the
> > main 2.4 kernel. If their driver works with my OCP patch, it would save
> > a whole lot of effort.
>
> Sorry, I was talking about
> bk://ppc.bkbits.net/linuxppc-2.4

It does similar things to mine, but it can support the controller on 8
as well as 32 bit busses.  I may try putting it into my 2.6 tree and
using it on the MPC107.

- Adrian Cox
Humboldt Solutions Ltd.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH][RFC] I2C support for MPC107 and relatives

[Kumar Gala]

Adrian,

It would be really helpful if you could take a look at getting the
driver working on a MPC107 based systems.  We have not had time to look
at that fully.  However, are intent has always to get the same driver
working for MPC10x, 824x, 85xx systems since the block is very similar.

- kumar

On Jun 14, 2004, at 8:24 AM, Adrian Cox wrote:

> On Mon, 2004-06-14 at 14:01, Stefan Nickl wrote:
>> On Mon, 2004-06-14 at 13:37, Adrian Cox wrote:
>>> On Mon, 2004-06-14 at 12:01, Stefan Nickl wrote:
>>>> FYI: The Motorola folks recently pushed a I2C driver called
>>>> i2c-mpc.c
>>>> into the 2.4 tree, it seems to be fully OCP'ed, save it seems the
>>>> platform hooks are only present for 8540 yet.
>>>
>>> Do you know which 2.4 tree? It's not in linuxppc_2_4_devel or in the
>>> main 2.4 kernel. If their driver works with my OCP patch, it would
>>> save
>>> a whole lot of effort.
>>
>> Sorry, I was talking about
>> bk://ppc.bkbits.net/linuxppc-2.4
>
> It does similar things to mine, but it can support the controller on 8
> as well as 32 bit busses.  I may try putting it into my 2.6 tree and
> using it on the MPC107.
>
> - Adrian Cox
> Humboldt Solutions Ltd.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH][RFC] I2C support for MPC107 and relatives

[Pantelis Antoniou]

Kumar Gala wrote:

>
> Adrian,
>
> It would be really helpful if you could take a look at getting the
> driver working on a MPC107 based systems.  We have not had time to look
> at that fully.  However, are intent has always to get the same driver
> working for MPC10x, 824x, 85xx systems since the block is very similar.
>
> - kumar
>
> On Jun 14, 2004, at 8:24 AM, Adrian Cox wrote:
>
>> On Mon, 2004-06-14 at 14:01, Stefan Nickl wrote:
>>
>>> On Mon, 2004-06-14 at 13:37, Adrian Cox wrote:
>>>
>>>> On Mon, 2004-06-14 at 12:01, Stefan Nickl wrote:
>>>>
>>>>> FYI: The Motorola folks recently pushed a I2C driver called
>>>>> i2c-mpc.c
>>>>> into the 2.4 tree, it seems to be fully OCP'ed, save it seems the
>>>>> platform hooks are only present for 8540 yet.
>>>>
>>>>
>>>> Do you know which 2.4 tree? It's not in linuxppc_2_4_devel or in the
>>>> main 2.4 kernel. If their driver works with my OCP patch, it would
>>>> save
>>>> a whole lot of effort.
>>>
>>>
>>> Sorry, I was talking about
>>> bk://ppc.bkbits.net/linuxppc-2.4
>>
>>
>> It does similar things to mine, but it can support the controller on 8
>> as well as 32 bit busses.  I may try putting it into my 2.6 tree and
>> using it on the MPC107.
>>
>> - Adrian Cox
>> Humboldt Solutions Ltd.
>
>
>
>
>
>
I'm thinking about taking the plunge and OCPfying 8xx so perhaps we
can get this thing organized.

I'd like to have a hierarhy of the peripherals like so:


                  ______- CPM -______  ___________  ___
                 /        /          \            \     \
                /        /            \            \     \
            Timers     SCC1..n _       SMC__      IDMA   DSP-f  etc.
                      /  |  \   \      |    \
                     /   |   \   \      \    \
                 UART  HDLC Enet QMC     UART Transp.
                                 /   \
                         HDLC0..63  Transp0..63

Of course with only one protocol active per SCC/SMC.

Is something like this supported with the OCP code, and if not
how could I get around in making it work?

IMO, we could share alot of the stuff between the CPM1/CPM2/CPM3...

Regards

Pantelis

P.S. I suck at ASCII art


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH][RFC] OCP support for MPC107 and relatives

[Kumar Gala]

On Jun 14, 2004, at 5:10 AM, Adrian Cox wrote:

> The attached patch is a start at adding the internal peripherals of the
> MPC107/MPC8240/MPC8245 to the OCP bus. I've used thus in the 2.6 port
> of
> my MPC107 I2C driver, which follows shortly. I intend to use this for
> the DMA controller later, once I decide what device ID to give it.
> I'm a little uncertain about OCP device IDs. Should there be a separate
> I2C device ID for each different I2C programming interface from the
> same
> vendor? Motorola have already given us two separate implementations on
> PowerPC.

Take a look at the driver i2c-mpc.c in
bk://ppc.bkbits.net/linuxppc-2.4.  We have been trying to write a
single driver to handle as many variations of one device as possible.
Our expectation is that one driver should hopefully be able to handle
10x, 824x, 85xx.  (and some future device families 83xx & 86xx).

I've also pushed support for 85xx infrastructure into linuxppc-2.5
which includes support for some config options for Motorola/Freescale
OCP.  These changes are expected to make it into linux-2.5 after 2.6.7
is released.

We are looking at adding OCP support for 824x as well for the I2C
driver.

I will make sure to look over the code and provide any feedback I've
got.

- kumar


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH][RFC] OCP support for MPC107 and relatives

[Kumar Gala]

> diff -Nru a/arch/ppc/syslib/mpc10x_common.c
> b/arch/ppc/syslib/mpc10x_common.c
> --- a/arch/ppc/syslib/mpc10x_common.c	Mon Jun 14 10:18:30 2004
> +++ b/arch/ppc/syslib/mpc10x_common.c	Mon Jun 14 10:18:30 2004
> @@ -30,7 +30,25 @@
>  #include <asm/pci-bridge.h>
>  #include <asm/open_pic.h>
>  #include <asm/mpc10x.h>
> +#include <asm/ocp.h>
> +/* The OCP structure is fixed by code below, before OCP initialises.
> +   paddr depends on where the board places the EUMB.
> +    - fixed in mpc10x_bridge_init().
> +   irq depends on two things:
> +    > does the board use the EPIC at all? (PCORE does not).
> +    > is the EPIC in serial or parallel mode?
> +    - fixed in mpc10x_set_openpic().
> +*/
> +struct ocp_def core_ocp[] = {
> +	{ .vendor	= OCP_VENDOR_MOTOROLA,
> +	  .function	= OCP_FUNC_IIC,
> +	  .index	= 0,
> +	  .irq		= OCP_IRQ_NA
> +	},
> +	{ .vendor	= OCP_VENDOR_INVALID
> +	}
> +};
>  /* Set resources to match bridge memory map */
>  void __init
> @@ -213,7 +231,10 @@
>  					byte);
>  	}

Is there a reason why we dont support the 106 as well for OCP?  Do you
know if this will match for the 8241 and/or 824x?

> -	if (host_bridge != MPC10X_BRIDGE_106) {
> +	if (host_bridge == MPC10X_BRIDGE_106) {
> +		/* On-chip peripherals were introduced with the MPC107/MPC8240 */
> +		core_ocp[0].vendor = OCP_VENDOR_INVALID;
> +	} else {
>  		early_read_config_byte(hose,
>  				       0,
>  				       PCI_DEVFN(0,0),

My only other comments relate to consistency with how we are doing
things for 85xx with regards to OCP.  For example, how the config
options are handled (added a FSL_OCP) and how we update the paddr field
based on eumbar.  Also, I believe we have an ocp interface to delete an
OCP entry [which may or may not apply].

- kumar


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH][RFC] OCP support for MPC107 and relatives

[Adrian Cox]

On Mon, 2004-06-14 at 14:59, Kumar Gala wrote:
> Is there a reason why we dont support the 106 as well for OCP?  Do you
> know if this will match for the 8241 and/or 824x?

According to my 106 user manual it's a pure northbridge, without I2C
unit, DMA, or interrupt controller. The code should work for the 824x
family, but I don't have any of them.

> > -	if (host_bridge != MPC10X_BRIDGE_106) {
> > +	if (host_bridge == MPC10X_BRIDGE_106) {
> > +		/* On-chip peripherals were introduced with the MPC107/MPC8240 */
> > +		core_ocp[0].vendor = OCP_VENDOR_INVALID;
> > +	} else {
> >  		early_read_config_byte(hose,
> >  				       0,
> >  				       PCI_DEVFN(0,0),
>
> My only other comments relate to consistency with how we are doing
> things for 85xx with regards to OCP.  For example, how the config
> options are handled (added a FSL_OCP) and how we update the paddr field
> based on eumbar.  Also, I believe we have an ocp interface to delete an
> OCP entry [which may or may not apply].

I've just done a bk pull which has fetched your 85xx ocp code. I can
copy your config approach and make MPC10X_BRIDGE set FSL_OCP.

As for the updates based on EUMBAR, we do them at the same time. I've
done them in syslib code rather than platform code, because I'm trying
to minimise the board specific code. My goal is for the platform
directory to contain the minimum amount of code necessary to describe
how the board vendor connected the chip. I have the added complication
that the board vendor may not have wired the MPC107 OpenPIC to the IRQ
line of the PowerPC. With the 824x and 85xx they don't have the ability
to make that mistake.

- Adrian Cox
Humboldt Solutions Ltd


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH][RFC] OCP support for MPC107 and relatives

[Matt Porter]

On Mon, Jun 14, 2004 at 11:10:04AM +0100, Adrian Cox wrote:
> The attached patch is a start at adding the internal peripherals of the
> MPC107/MPC8240/MPC8245 to the OCP bus. I've used thus in the 2.6 port of
> my MPC107 I2C driver, which follows shortly. I intend to use this for
> the DMA controller later, once I decide what device ID to give it.

Excellent...I was hoping someone would take care of this for MPC10x-ish
on-chip devices.

> I'm a little uncertain about OCP device IDs. Should there be a separate
> I2C device ID for each different I2C programming interface from the same
> vendor? Motorola have already given us two separate implementations on
> PowerPC.

Well, I've been asked this question a few times in similar contexts,
but I haven't had a solid answer to give yet.  Basically, the question
boils down to, "What are the rules for assigning new OCP IDs?". Right
now, there are no written rules.  However, we have a software "bus"
abstraction with a massive amount (32-bit) of IDs available for our
use per vendor.

My current suggestion is to use this space to assign unique IDs
per device even though devices don't show up between architectures
(normally).  I can actually see cases where two different OCP systems might
share a device, but it would be rare if anybody ever implements such
a thing at all. Please assign unique IDs per device and per vendor
for now.  If it gets out of hand in the future, we can revisit the
situation.

> This is a little bit different from the PPC40x use of OCP, because it's
> hard to calculate everything at compile time. This is particularly
> caused by the pcore boards, which use the MPC107 but don't use the
> interrupt controller.

Mark Greer and Kumar Gala each have platforms doing runtime mods, so the
Marvell and 85xx ports are good examples to follow.

-Matt

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH][RFC] OCP support for MPC107 and relatives

[Kumar Gala]

Matt,

We know have several systems which have the same issue of updating a
paddr based on some offset.

I'm wondering if we should add something like the following code into
ocp.c (obviously, removing the 85xx specific aspects).

Called w/in board code:

         ocp_for_each_device(mpc85xx_update_paddr_ocp,
&(binfo->bi_immr_base));

Or should we have a more explicit ocp_update_paddr(phys_addr_t x);

/*
************************************************************************
  */
/* Update the 85xx OCP tables paddr field */
void
mpc85xx_update_paddr_ocp(struct ocp_device *dev, void *arg)
{
         phys_addr_t ccsrbar;
         if (arg) {
                 ccsrbar = *(phys_addr_t *)arg;
                 dev->def->paddr += ccsrbar;
         }
}

- kumar


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH][RFC] OCP support for MPC107 and relatives

[Mark A. Greer]

Adrian Cox wrote:

> <snip>
>
>-	if (host_bridge != MPC10X_BRIDGE_106) {
>+	if (host_bridge == MPC10X_BRIDGE_106) {
>+		/* On-chip peripherals were introduced with the MPC107/MPC8240 */
>+		core_ocp[0].vendor = OCP_VENDOR_INVALID;
>

><snip>
>

> 		OpenPIC_Addr =
> 			ioremap(phys_eumb_base + MPC10X_EUMB_EPIC_OFFSET,
> 				MPC10X_EUMB_EPIC_SIZE);
>+#endif
>+		core_ocp[0].paddr = phys_eumb_base + MPC10X_EUMB_I2C_OFFSET;
> 	}
>
>

That's great that you're OCP-ifying the mpc10x code!  My only comment is
thatI don't like hardcoding the position of an entry in the OCP (e.g.,
core_ocp[0].vedor/paddr).  I don't think its safe to assume that any
particular piece of code will always know all of the entries in the OCP
and therefore what an entry's position will be.  You can use
'ocp_for_each_device()' and a routine that checks for the fields that
you want to accomplish the same thing.

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH][RFC] OCP support for MPC107 and relatives

[Adrian Cox]

On Mon, 2004-06-14 at 18:05, Mark A. Greer wrote:

> That's great that you're OCP-ifying the mpc10x code!  My only comment is
> thatI don't like hardcoding the position of an entry in the OCP (e.g.,
> core_ocp[0].vedor/paddr).  I don't think its safe to assume that any
> particular piece of code will always know all of the entries in the OCP
> and therefore what an entry's position will be.  You can use
> 'ocp_for_each_device()' and a routine that checks for the fields that
> you want to accomplish the same thing.

I'll try to do a new version of the patch at the end of the week.

Would it work to have an empty core_ocp[] array, and then call
ocp_add_one_device() to insert the entries? That would deal with these
issues, as the code would look like:
mpc10x_i2c_ocp.paddr = phys_eumb_base + MPC10X_EUMB_I2C_OFFSET;
ocp_add_one_device(&mpc10x_i2c_ocp);

Then the MPC106 path would simply not add any entries, rather than
having to go through and mark them as invalid.

- Adrian Cox
Humboldt Solutions Ltd.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH][RFC] OCP support for MPC107 and relatives

[Mark A. Greer]

Adrian Cox wrote:

>On Mon, 2004-06-14 at 18:05, Mark A. Greer wrote:
>
>
>
>>That's great that you're OCP-ifying the mpc10x code!  My only comment is
>>thatI don't like hardcoding the position of an entry in the OCP (e.g.,
>>core_ocp[0].vedor/paddr).  I don't think its safe to assume that any
>>particular piece of code will always know all of the entries in the OCP
>>and therefore what an entry's position will be.  You can use
>>'ocp_for_each_device()' and a routine that checks for the fields that
>>you want to accomplish the same thing.
>>
>>
>
>I'll try to do a new version of the patch at the end of the week.
>
>Would it work to have an empty core_ocp[] array, and then call
>ocp_add_one_device() to insert the entries? That would deal with these
>issues, as the code would look like:
>mpc10x_i2c_ocp.paddr = phys_eumb_base + MPC10X_EUMB_I2C_OFFSET;
>ocp_add_one_device(&mpc10x_i2c_ocp);
>
>Then the MPC106 path would simply not add any entries, rather than
>having to go through and mark them as invalid.
>
>
FWIW, that's fine with me.

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/