First steps to OCP device model integration
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 at 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/
First steps to OCP device model integration
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 at 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/
First steps to OCP device model integration
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 at 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/
First steps to OCP device model integration
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/
First steps to OCP device model integration
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/
First steps to OCP device model integration
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.0 +1000
+++ linux-bluefish/drivers/ocp/ocp.c2002-08-09 13:55:08.0 +1000
@@ -69,6 +69,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -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.0 +1000
+++ linux-bluefish/include/asm-ppc/ocp.h2002-08-09 14:00:46.0
+1000
@@ -51,6 +51,7 @@
#include
#include
+#include
#include/* 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;
+};
+
+#defineto_ocp_dev(n) container_of(n, struct ocp_device, dev)
+#defineto_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 at 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/
First steps to OCP device model integration
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/
