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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
