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/
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/
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/
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/
On Fri, Aug 09, 2002 at 12:41:29PM -0700, akuster wrote:
David Gibson wrote:
quoted
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/