PPC32: New OCP core support

New OCP infrastructure ported from 2.4 along with several enhancements. Please apply.

-Matt

diff -Nru a/arch/ppc/Kconfig b/arch/ppc/Kconfig
@@ -1238,7 +1238,7 @@
 	bool "Support for early boot texts over serial port"
 	depends on 4xx || GT64260 || LOPEC || PPLUS || PRPMC800 || PPC_GEN550
 
-config OCP
+config PPC_OCP
 	bool
 	depends on IBM_OCP
 	default y

diff -Nru a/arch/ppc/Makefile b/arch/ppc/Makefile
@@ -43,7 +43,6 @@
 drivers-$(CONFIG_8xx)		+= arch/ppc/8xx_io/
 drivers-$(CONFIG_4xx)		+= arch/ppc/4xx_io/
 drivers-$(CONFIG_8260)		+= arch/ppc/8260_io/
-drivers-$(CONFIG_OCP)		+= arch/ppc/ocp/
 
 BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
 

diff -Nru a/arch/ppc/kernel/setup.c b/arch/ppc/kernel/setup.c
@@ -37,6 +37,7 @@
 #include <asm/sections.h>
 #include <asm/nvram.h>
 #include <asm/xmon.h>
+#include <asm/ocp.h>
 
 #if defined CONFIG_KGDB
 #include <asm/kgdb.h>

@@ -682,6 +683,12 @@
 	/* set up the bootmem stuff with available memory */
 	do_init_bootmem();
 	if ( ppc_md.progress ) ppc_md.progress("setup_arch: bootmem", 0x3eab);
+
+#ifdef CONFIG_PPC_OCP
+	/* Initialize OCP device list */
+	ocp_early_init();
+	if ( ppc_md.progress ) ppc_md.progress("ocp: exit", 0x3eab);
+#endif
 
 	ppc_md.setup_arch();
 	if ( ppc_md.progress ) ppc_md.progress("arch: exit", 0x3eab);

diff -Nru a/arch/ppc/ocp/Makefile b/arch/ppc/ocp/Makefile
@@ -1,6 +0,0 @@
-#
-# Makefile for the linux kernel.
-#
-
-obj-y   	:= ocp.o ocp-driver.o ocp-probe.o
-

diff -Nru a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
@@ -13,6 +13,7 @@
 CFLAGS_btext.o          += -mrelocatable-lib
 
 obj-$(CONFIG_PPCBUG_NVRAM)	+= prep_nvram.o
+obj-$(CONFIG_PPC_OCP)		+= ocp.o
 obj-$(CONFIG_44x)		+= ibm44x_common.o
 obj-$(CONFIG_440GP)		+= ibm440gp_common.o
 ifeq ($(CONFIG_4xx),y)

Big honking patch. Wholesale removal of old code. Wholesale addition of new code.

And this is the closest to a hint of what an OCP in the old code:

- * @device: OCP device such as PCI, GPT, UART, OPB, IIC, GPIO, EMAC, ZMII
- * @dev_num: ocp device number whos paddr you want

And in the new:

+extern struct ocp_def core_ocp[]; /* Static list of devices, provided by
+ CPU core */

And some vendor IDs that say that IBM and FreeScale make them, and Motorola apparently rebadges/clones Freescale's (or vice versa)..

I'm *guessing* that this is some all-in-one integrated north/south/PCI/east bridge with an APIC or similar and some I/O controllers.... Or maybe it's a board-level designator like 'ebony' seems to be.. or something..

It's a UART... or a Bus-level board.. or both.. ;)

arch/ppc/Kconfig says this:
config OCP
bool
depends on IBM_OCP
default y
that leads to arch/ppc/platforms/4xx/Kconfig:
config IBM_OCP

        bool
        depends on ASH || CPCI405 || EBONY || EP405 || OCOTEA || REDWOOD_5 || REDWOOD_6 || SYCAMOR

E || WALNUT
default y

Grepping for OCP in arch/ppc/platforms/4xx/* isn't informative either..

Color me mystified.. ;)

(Actually, other than the apparent lack of any comment that says what an OCP in fact is, I didn't see any really big style problems while scrolling through it..)

Yep.

<snip>

Actually, OCP stands for On-Chip Peripheral and is the basic system we've used in ppc32 for some time now to abstract dumb peripherals behind a standard API. BenH did yet another rewrite of OCP in 2.4 sometime ago and I picked up that work to port to 2.6 and the new device model. It is a software abstraction, and easily allows us to plug in SoC descriptors when new chips come out and use standard apis to modify device entries on a per-board basis during "setup_arch() time". It used to be PPC4xx-specific, but now is being used by PPC85xx, MV64xxx, and MPC52xx based PPC systems. "Now", meaning that the respective developers for those parts are using the OCP working tree to base their 2.6 ports off of.

Ahh, good.

-Matt

Wrap a /* */ around that paragraph and add it to the top of ppc/syslib/ocp.c :)

Wrap a /* */ around that paragraph and add it to the top of ppc/syslib/ocp.c :)

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

I incorporated a more polished version into the updated patch I just sent.

Thanks.

-Matt

Wrap a /* */ around that paragraph and add it to the top of ppc/syslib/ocp.c :)

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

Yep.

<snip>

Actually, OCP stands for On-Chip Peripheral and is the basic system we've used in ppc32 for some time now to abstract dumb peripherals behind a standard API. BenH did yet another rewrite of OCP in 2.4 sometime ago and I picked up that work to port to 2.6 and the new device model. It is a software abstraction, and easily allows us to plug in SoC descriptors when new chips come out and use standard apis to modify device entries on a per-board basis during "setup_arch() time". It used to be PPC4xx-specific, but now is being used by PPC85xx, MV64xxx, and MPC52xx based PPC systems. "Now", meaning that the respective developers for those parts are using the OCP working tree to base their 2.6 ports off of.

Ahh, good.

-Matt

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

Yep.

<snip>

Actually, OCP stands for On-Chip Peripheral and is the basic system we've used in ppc32 for some time now to abstract dumb peripherals behind a standard API. BenH did yet another rewrite of OCP in 2.4 sometime ago and I picked up that work to port to 2.6 and the new device model. It is a software abstraction, and easily allows us to plug in SoC descriptors when new chips come out and use standard apis to modify device entries on a per-board basis during "setup_arch() time". It used to be PPC4xx-specific, but now is being used by PPC85xx, MV64xxx, and MPC52xx based PPC systems. "Now", meaning that the respective developers for those parts are using the OCP working tree to base their 2.6 ports off of.

Ahh, good.

-Matt

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

I only received patch 1/2.

Could you please avoid using the same Subject: for different patches? It confuses my auto-subject-to-patch-filename-munger and it's nice to more specifically identify each patch anwyay.

Oddly I sent unique subjects:

Subject: [PATCH 1/2] PPC32: New OCP core support
Subject: [PATCH 2/2] PPC32: PPC4xx updates for new OCP

It appears 2/2 at least made it off my system to the remote mailer, will doublecheck.

-Matt

Oddly I sent unique subjects:

Subject: [PATCH 1/2] PPC32: New OCP core support
Subject: [PATCH 2/2] PPC32: PPC4xx updates for new OCP

It appears 2/2 at least made it off my system to the remote mailer, will doublecheck.

-Matt

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

Your mail is being duplicated by what looks like a broken news gateway, or something similar, on linuxppc-dev:

Received: from host213-123-250-229.in-addr.btopenworld.com ([213.123.250.229]:15149

        "EHLO 2003SERVER.sbs2003.local") by vger.kernel.org with ESMTP                                  
        id S264904AbUELBme (ORCPT <rfc822;[email protected]>);                               
        Tue, 11 May 2004 21:42:34 -0400                                                                 
Received: from mail pickup service by 2003SERVER.sbs2003.local with Microsoft SMTPSVC;                  
         Wed, 12 May 2004 02:45:44 +0100                                                                

Daniel Jacobowitz

Your mail is being duplicated by what looks like a broken news gateway, or something similar, on linuxppc-dev:

Received: from host213-123-250-229.in-addr.btopenworld.com ([213.123.250.229]:15149

        "EHLO 2003SERVER.sbs2003.local") by vger.kernel.org with ESMTP
        id S264904AbUELBme (ORCPT <rfc822;[email protected]>);
        Tue, 11 May 2004 21:42:34 -0400
Received: from mail pickup service by 2003SERVER.sbs2003.local with Microsoft SMTPSVC;
         Wed, 12 May 2004 02:45:44 +0100

--
Daniel Jacobowitz

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

I only received patch 1/2.

Could you please avoid using the same Subject: for different patches? It confuses my auto-subject-to-patch-filename-munger and it's nice to more specifically identify each patch anwyay.

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

Big honking patch. Wholesale removal of old code. Wholesale addition of new code.

And this is the closest to a hint of what an OCP in the old code:

- * @device: OCP device such as PCI, GPT, UART, OPB, IIC, GPIO, EMAC, ZMII
- * @dev_num: ocp device number whos paddr you want

And in the new:

+extern struct ocp_def core_ocp[]; /* Static list of devices, provided by
+ CPU core */

And some vendor IDs that say that IBM and FreeScale make them, and Motorola apparently rebadges/clones Freescale's (or vice versa)..

I'm *guessing* that this is some all-in-one integrated north/south/PCI/east bridge with an APIC or similar and some I/O controllers.... Or maybe it's a board-level designator like 'ebony' seems to be.. or something..

It's a UART... or a Bus-level board.. or both.. ;)

arch/ppc/Kconfig says this:
config OCP
bool
depends on IBM_OCP
default y
that leads to arch/ppc/platforms/4xx/Kconfig:
config IBM_OCP

        bool
        depends on ASH || CPCI405 || EBONY || EP405 || OCOTEA || REDWOOD_5 || REDWOOD_6 || SYCAMOR

E || WALNUT
default y

Grepping for OCP in arch/ppc/platforms/4xx/* isn't informative either..

Color me mystified.. ;)

(Actually, other than the apparent lack of any comment that says what an OCP in fact is, I didn't see any really big style problems while scrolling through it..)

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

Big honking patch. Wholesale removal of old code. Wholesale addition of new code.

And this is the closest to a hint of what an OCP in the old code:

- * @device: OCP device such as PCI, GPT, UART, OPB, IIC, GPIO, EMAC, ZMII
- * @dev_num: ocp device number whos paddr you want

And in the new:

+extern struct ocp_def core_ocp[]; /* Static list of devices, provided by
+ CPU core */

And some vendor IDs that say that IBM and FreeScale make them, and Motorola apparently rebadges/clones Freescale's (or vice versa)..

I'm *guessing* that this is some all-in-one integrated north/south/PCI/east bridge with an APIC or similar and some I/O controllers.... Or maybe it's a board-level designator like 'ebony' seems to be.. or something..

It's a UART... or a Bus-level board.. or both.. ;)

arch/ppc/Kconfig says this:
config OCP
bool
depends on IBM_OCP
default y
that leads to arch/ppc/platforms/4xx/Kconfig:
config IBM_OCP

        bool
        depends on ASH || CPCI405 || EBONY || EP405 || OCOTEA || REDWOOD_5 || REDWOOD_6 || SYCAMOR

E || WALNUT
default y

Grepping for OCP in arch/ppc/platforms/4xx/* isn't informative either..

Color me mystified.. ;)

(Actually, other than the apparent lack of any comment that says what an OCP in fact is, I didn't see any really big style problems while scrolling through it..)

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

The old-style PM callback (using struct pm_dev) is bogus, please kill that part.

The old-style PM callback (using struct pm_dev) is bogus, please kill that part.

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

Thanks. I killed off the deprecated PM stuff in the updated patch I just sent out.

-Matt

The old-style PM callback (using struct pm_dev) is bogus, please kill that part.

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