OCP support for MPC107 and relatives

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.

# This is a BitKeeper generated diff -Nru style patch. #
# ChangeSet
# 2004/06/14 10:15:20+01:00 [email protected]
# Add OCP support for MPC10x peripherals, and tidy up OpenPic initialisation.
#

# include/asm-ppc/mpc10x.h
#   2004/06/14 10:14:53+01:00 [email protected] +3 -0
#   Add a new MPC10x OpenPIC setup function
#
# arch/ppc/syslib/mpc10x_common.c
#   2004/06/14 10:14:53+01:00 [email protected] +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 [email protected] +4 -4
#   Use new config entry for the MPC10x internal OpenPIC.
#
# arch/ppc/platforms/sandpoint.c
#   2004/06/14 10:14:53+01:00 [email protected] +1 -11
#   Use new standardised mpc10x_set_openpic().
#
# arch/ppc/platforms/powerpmc250.c
#   2004/06/14 10:14:53+01:00 [email protected] +1 -1
#   Use new standardised mpc10x_set_openpic().
#
# arch/ppc/platforms/lopec_setup.c
#   2004/06/14 10:14:53+01:00 [email protected] +1 -14
#   Use new standardised mpc10x_set_openpic().
#
# arch/ppc/Kconfig
#   2004/06/14 10:14:53+01:00 [email protected] +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
@@ -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
@@ -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
@@ -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
@@ -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/include/asm-ppc/mpc10x.h b/include/asm-ppc/mpc10x.h
@@ -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 */

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.

# This is a BitKeeper generated diff -Nru style patch. #
# ChangeSet
# 2004/06/14 10:54:08+01:00 [email protected]
# Add MPC107 I2C interface
#

# drivers/i2c/busses/i2c-mpc107.c
#   2004/06/14 10:53:50+01:00 [email protected] +402 -0
#
# drivers/i2c/busses/i2c-mpc107.c
#   2004/06/14 10:53:50+01:00 [email protected] +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 [email protected] +1 -0
#   Add MPC107 I2C interface
#
# drivers/i2c/busses/Kconfig
#   2004/06/14 10:53:50+01:00 [email protected] +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
@@ -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

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/

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/

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/

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/

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

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

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/

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/

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.

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/

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

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.

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/

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/

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/

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/

FWIW, that's fine with me.

Mark

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