First steps to OCP device model integration

First steps to OCP device model integration

[David Gibson]

THe patch below implements the first steps in transitioning the
handling of 4xx OCP devices to the unfied device model (in 2.5).  So
far the code just registers an ocp bus and registers each device
described in core_ocp on that bus.  The next step is to convert the
actual device drivers so that that they register with the unified
driver tree rather than through the old ocp_register() mechanism.

I will commit this shortly unless there are serious objections.

diff -urN /home/dgibson/kernel/linuxppc-2.5/drivers/ocp/ocp.c linux-bluefish/drivers/ocp/ocp.c
--- /home/dgibson/kernel/linuxppc-2.5/drivers/ocp/ocp.c	2002-08-09 11:28:27.000000000 +1000
+++ linux-bluefish/drivers/ocp/ocp.c	2002-08-09 13:55:08.000000000 +1000
@@ -69,6 +69,8 @@
 #include <linux/miscdevice.h>
 #include <linux/slab.h>
 #include <linux/types.h>
+#include <linux/device.h>
+#include <linux/init.h>
 #include <asm/io.h>
 #include <asm/ocp.h>
 #include <asm/errno.h>
@@ -388,3 +390,58 @@
 EXPORT_SYMBOL(ocp_free_dev);
 EXPORT_SYMBOL(ocp_register);
 EXPORT_SYMBOL(ocp_unregister);
+
+/* Unified device model OCP interface */
+
+static int ocp_bus_match(struct device * dev, struct device_driver * drv)
+{
+	struct ocp_device *odev = to_ocp_dev(dev);
+	struct ocp_driver *odrv = to_ocp_driver(drv);
+
+	return (odrv->type == odev->def.type);
+}
+
+struct bus_type ocp_bus_type = {
+	name:	"ocp",
+	match:	ocp_bus_match,
+};
+
+static struct device ocp_bus = {
+       name:           "IBM4xx On-Chip Peripheral Bus",
+       bus_id:         "ocp",
+};
+
+static int __init ocp_bus_init(void)
+{
+	int i;
+
+	printk(KERN_DEBUG "OCP: Registering OCP bus and devices\n");
+
+	if (bus_register(&ocp_bus_type) != 0)
+		panic("Couldn't register OCP bus type\n");
+	if (device_register(&ocp_bus) != 0)
+		panic("Couldn't register OCP bus\n");
+
+	for (i = 0; core_ocp[i].type != OCP_NULL_TYPE; i++) {
+		enum ocp_type type = core_ocp[i].type;
+		struct ocp_device *odev;
+
+		odev = kmalloc(sizeof(*odev), GFP_KERNEL);
+		if (! odev)
+			panic("unable to allocate memory for ocp_device\n");
+		memset(odev, 0, sizeof(*odev));
+
+		memcpy(&odev->def, &core_ocp[i], sizeof(struct ocp_def));
+
+		odev->dev.bus = &ocp_bus_type;
+		odev->dev.parent = &ocp_bus;
+		strcpy(odev->dev.name, ocp_type_info[type].desc);
+		sprintf(odev->dev.bus_id, "%d:%s", i, ocp_type_info[type].name);
+
+		device_register(&odev->dev);
+	}
+
+	return 0;
+}
+
+postcore_initcall(ocp_bus_init);
diff -urN /home/dgibson/kernel/linuxppc-2.5/include/asm-ppc/ocp.h linux-bluefish/include/asm-ppc/ocp.h
--- /home/dgibson/kernel/linuxppc-2.5/include/asm-ppc/ocp.h	2002-08-08 11:20:50.000000000 +1000
+++ linux-bluefish/include/asm-ppc/ocp.h	2002-08-09 14:00:46.000000000 +1000
@@ -51,6 +51,7 @@

 #include <linux/list.h>
 #include <linux/config.h>
+#include <linux/device.h>

 #include <asm/mmu.h>		/* For phys_addr_t */

@@ -158,5 +159,21 @@
 extern int ocp_get_irq(int type, int dev_num);
 extern int ocp_get_pm(int type, int dev_num);

+/* Unified device model OCP interface */
+
+struct ocp_device {
+	struct ocp_def def;
+	struct device dev;
+};
+
+struct ocp_driver {
+	enum ocp_type type;
+	struct device_driver driver;
+};
+
+#define	to_ocp_dev(n) container_of(n, struct ocp_device, dev)
+#define	to_ocp_driver(n) container_of(n, struct ocp_driver, driver)
+
+
 #endif				/* __OCP_H__ */
 #endif				/* __KERNEL__ */


--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

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

Re: First steps to OCP device model integration

[akuster]

David Gibson wrote:
> THe patch below implements the first steps in transitioning the
> handling of 4xx OCP devices to the unfied device model (in 2.5).  So
> far the code just registers an ocp bus and registers each device
> described in core_ocp on that bus.  The next step is to convert the
> actual device drivers so that that they register with the unified
> driver tree rather than through the old ocp_register() mechanism.
>
> I will commit this shortly unless there are serious objections.
>

I object seriously.

  Some of what you have might be useful.:) OCP is not just for 4xx.  In
fact the name may need to change.  I have been working on overhalling
this interface and testing the ideas before having a review of the
changes.  I am on the hook to Paul and others to get this out in the
open to discuss and am not ready.  So if you could just relax and wait I
would appriciate it.  I would rather see the 2.5 kernel boot on a few
4xx boards

Armin


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

Re: First steps to OCP device model integration

[Paul Mackerras]

akuster writes:

> I object seriously.
>
>   Some of what you have might be useful.:) OCP is not just for 4xx.  In
> fact the name may need to change.  I have been working on overhalling
> this interface and testing the ideas before having a review of the
> changes.  I am on the hook to Paul and others to get this out in the
> open to discuss and am not ready.  So if you could just relax and wait I
> would appriciate it.  I would rather see the 2.5 kernel boot on a few
> 4xx boards

Two points:

- Integrating the OCP stuff into the unified device model (driverfs
  etc.) in 2.5 is essential.

- I really want to have some open discussions about ideas, structures
  etc. for OCP support *before* you have everything fully worked out. :)

Regards,
Paul.

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

Re: First steps to OCP device model integration

[akuster]

Paul Mackerras wrote:
 > akuster writes:
 >
 >
 >>I object seriously.
 >>
 >>  Some of what you have might be useful.:) OCP is not just for 4xx.  In
 >>fact the name may need to change.  I have been working on overhalling
 >>this interface and testing the ideas before having a review of the
 >>changes.  I am on the hook to Paul and others to get this out in the
 >>open to discuss and am not ready.  So if you could just relax and wait I
 >>would appriciate it.  I would rather see the 2.5 kernel boot on a few
 >>4xx boards
 >>
 >
 > Two points:
 >
 > - Integrating the OCP stuff into the unified device model (driverfs
 >   etc.) in 2.5 is essential.

completely agree

 >
 > - I really want to have some open discussions about ideas, structures
 >   etc. for OCP support *before* you have everything fully worked out. :)
 >

The discussions will start soon ;)  I never have a complete
implimentation done before I present but I do tinker with code and
validate my hypothisis to weed out the lame stuff. I am sure you would
rather see a bit more meat to my ideas than if my only statement was one
such are your #1 point above. :)  You will just need to wait even though
my employer is gracious and allows me to work in the community during
work hours.

 > Regards,
 > Paul.


Armin


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

Re: First steps to OCP device model integration

[David Gibson]

On Fri, Aug 09, 2002 at 12:41:29PM -0700, akuster wrote:
>
> David Gibson wrote:
> >THe patch below implements the first steps in transitioning the
> >handling of 4xx OCP devices to the unfied device model (in 2.5).  So
> >far the code just registers an ocp bus and registers each device
> >described in core_ocp on that bus.  The next step is to convert the
> >actual device drivers so that that they register with the unified
> >driver tree rather than through the old ocp_register() mechanism.
> >
> >I will commit this shortly unless there are serious objections.
>
> I object seriously.
>
>  Some of what you have might be useful.:) OCP is not just for 4xx.
In

Sure, details, changing names is easy.  At the moment 4xx is the only
thing using OCP so we might as well get it working for that before
worrying too much about anything else.

> fact the name may need to change.  I have been working on overhalling
> this interface and testing the ideas before having a review of the
> changes.  I am on the hook to Paul and others to get this out in the
> open to discuss and am not ready.  So if you could just relax and
> wait I

So how about you tell us about this new scheme of yours.  This is not
a difficult problem, and you've been making intermittent mutterings
for months.

> would appriciate it.  I would rather see the 2.5 kernel boot on a few
> 4xx boards

OCP support is currently the main thing lacking for that.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

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

Re: First steps to OCP device model integration

[Matt Porter]

On Fri, Aug 09, 2002 at 02:26:05PM +1000, David Gibson wrote:
>
> THe patch below implements the first steps in transitioning the
> handling of 4xx OCP devices to the unfied device model (in 2.5).  So
> far the code just registers an ocp bus and registers each device
> described in core_ocp on that bus.  The next step is to convert the
> actual device drivers so that that they register with the unified
> driver tree rather than through the old ocp_register() mechanism.

Hi David,

I don't have any concerns about your patch as a starting point,
but I'd like to talk about where we are going with driverfs
integration of proprietary on-chip buses (4xx and other SoCs).
This "first steps" patch shows you registering OCP as a bus
with a name of "Onchip Peripheral Bus".  This seems to trivialize
the bus hierarchy on 4xx and part of the point of driverfs is
to see where devices are located in the physical bus structure
(since management of them may vary based on their location).
I would expect to see "PLB", "OPB", and "ExtBus" registered
for 4xx for correctness.  They may all use the same bus ops
in a reference board implementation (not making use of the EBC
in most cases), but somebody could have some FPGA-based peripherals
hanging from the EBC which require board-specific PM ops and thus
it would be desirable to see and manage at least the External Bus
separately in driverfs.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

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

440 PCI adapter card DMA question

[Khai Trinh]

Matt,

Welcome back to the ppc mailing list. I would like
your answer to my question really bad on the topic of
mapping the PCI bus DMA address to the PLB address
space for setting up the 440GP DMA. I don't have the
email I sent you anymore.

On one of your response email to me, you said the
440GP maps PCI<->PLB 1:1 and I can use the PCI bus
address directly as a PLB address to program the 440GP
DMA controller.

The thing is that the DMA high and low register only
allows 36-bit programming whereas the PCI bus address
given to me by the Host is 64-bit.

Don't I have to manually setup the PCI-PLB mapping
before I can program the DMA controller? OR the 440
kernel has already handle that?

Your comment and response are very important and
appreciated...

Thanks again,
--Khai


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

Re: First steps to OCP device model integration

[David Gibson]

On Tue, Aug 13, 2002 at 08:34:03AM -0700, Matt Porter wrote:
>
> On Fri, Aug 09, 2002 at 02:26:05PM +1000, David Gibson wrote:
> >
> > THe patch below implements the first steps in transitioning the
> > handling of 4xx OCP devices to the unfied device model (in 2.5).  So
> > far the code just registers an ocp bus and registers each device
> > described in core_ocp on that bus.  The next step is to convert the
> > actual device drivers so that that they register with the unified
> > driver tree rather than through the old ocp_register() mechanism.
>
> Hi David,
>
> I don't have any concerns about your patch as a starting point,
> but I'd like to talk about where we are going with driverfs
> integration of proprietary on-chip buses (4xx and other SoCs).
> This "first steps" patch shows you registering OCP as a bus
> with a name of "Onchip Peripheral Bus".  This seems to trivialize
> the bus hierarchy on 4xx and part of the point of driverfs is
> to see where devices are located in the physical bus structure
> (since management of them may vary based on their location).
> I would expect to see "PLB", "OPB", and "ExtBus" registered
> for 4xx for correctness.  They may all use the same bus ops
> in a reference board implementation (not making use of the EBC
> in most cases), but somebody could have some FPGA-based peripherals
> hanging from the EBC which require board-specific PM ops and thus
> it would be desirable to see and manage at least the External Bus
> separately in driverfs.

Agreed.  I see the use of a single "ocp" bus as a transitional step.
My first concern was toget something working - as a proof of concept,
and so that we can have working support for ocp devices with an
interface that is less broken that the current ocp code.

Using a single bus makes it easier to import the devices from the
existing core_ocp structure while we port the drivers to the driverfs
way of thinking.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

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