Messages in this thread | | | Date | Thu, 23 Feb 2006 17:42:51 -0800 | From | Greg KH <> | Subject | Re: what's a platform device? |
| |
On Thu, Feb 23, 2006 at 01:30:39PM -0600, Kumar Gala wrote: > On Thu, 23 Feb 2006, Kumar Gala wrote: > > > >> Yes, the FPGA is a pci device. > > >> > > >> Not sure I follow exactly what you mean by the fact that platform > > >> devices dont know about mmio regions. They know about struct > > >> resource and iomem_resource & ioport_resource. > > > > > > Yes, as they have no "bus" to attach too. That's why they are there, > > > they are for devices with no bus, but are merely "raw" memory mapped > > > devices. > > > > I'm not sure I follow this. How is PCI different? How would "kumar" > > bus be different? > > > > >> I think I might be missing something fundamental here. In > > >> implementing my own bus_type, I'll end up introducing my own struct > > >> foobar_device which looked pretty much like struct platform_device. > > >> Then I'll need a set of functions to assign resources, etc. > > >> > > >> I got no issue implementing my own bus_type, but I clearly feel like > > >> I'm missing something here (just not sure what it is :) > > > > > > I guess I look at your FPGA as a PCI "bridge" chip, that bridges > > > between > > > the PCI bus, and your "kumar" bus (for lack of a better name). Your > > > devices hang off of that bus, which is attached to the FPGA, which is > > > attached to the pci bridge, and so on. If you use the platform > > > bus, you > > > break that link. > > > > > > Does that make sense? > > > > This makes sense, but you seem to be talking about hierarchy more the > > functionality. I agree in your description of hierarchy. > > > > I was looking at it from a functional point of view, maybe more from > > the device view then from the bus. I need a struct device type that > > contains resources, a name, an id. I'll do matching based on name. > > From a functional point of view platform does all this. > > > > Based on your description would you say that a platform_device's > > parent device should always be platform_bus? [I'm getting at the fact > > that we allow pdev->dev.parent to be set by the caller of > > platform_device_add]. > > > > Hmm, as I think about this further, I think that its more coincidence > > that the functionality for the "kumar" bus is equivalent to that of > > the "platform" bus. > > > > What about a new bus_type that uses all the sematics of the platform_bus. > Doing someting like the following which would allow the caller to specify > their own bus_type. > > I'm just trying to avoid duplicating alot of code that already exists in > base/platform.c
I'm ok with this patch, Russell?
thanks,
greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |