Guys,
I was hoping to get your opinion on a question I had. The question comes
down to what we think a "platform device" is.
The situation I have is an FPGA connected over PCI. The FPGA implements
various device functionality (serial ports, I2C controller, IR, etc.) as a
single PCI device/function. The FPGA breaks any notion of a true PCI
device, it uses PCI as a device interconnect more than anything else.
In talking to Greg about this, he suggested I just create a new bus_type
for this similar to what is being done for usb-serial. As I started to
think about what I wanted ended up being a platform_device plus a sysfs
entry for the MMIO region.
So, it seems that a "platform device" is a pretty generic concept now. Do
you guys thing its acceptable to use a platform device for my needs or
should I create some new bus_type? Do we have a better definition of what
a platform device is or might be?
If we're ok with my use of platform device for this, I assume no one has
an issue with adding a sysfs attribute to platform devices to expose the
MMIO regions similar to what we do for PCI today.
thanks
- kumar
On Wed, Feb 22, 2006 at 03:47:40PM -0600, Kumar Gala wrote:
> Guys,
>
> I was hoping to get your opinion on a question I had. The question comes
> down to what we think a "platform device" is.
>
> The situation I have is an FPGA connected over PCI. The FPGA implements
> various device functionality (serial ports, I2C controller, IR, etc.) as a
> single PCI device/function. The FPGA breaks any notion of a true PCI
> device, it uses PCI as a device interconnect more than anything else.
>
> In talking to Greg about this, he suggested I just create a new bus_type
> for this similar to what is being done for usb-serial. As I started to
> think about what I wanted ended up being a platform_device plus a sysfs
> entry for the MMIO region.
>
> So, it seems that a "platform device" is a pretty generic concept now. Do
> you guys thing its acceptable to use a platform device for my needs or
> should I create some new bus_type? Do we have a better definition of what
> a platform device is or might be?
Well, your FPGA is a pci device, right? It's only the devices that hang
off of it that you are concerned about. I really think you should make
your own bus type, as it's not much work, and it would not disturb the
existing platform devices, which do not know about mmio regions like
PCI.
thanks,
greg k-h
On Feb 22, 2006, at 10:39 PM, Greg KH wrote:
> On Wed, Feb 22, 2006 at 03:47:40PM -0600, Kumar Gala wrote:
>> Guys,
>>
>> I was hoping to get your opinion on a question I had. The
>> question comes
>> down to what we think a "platform device" is.
>>
>> The situation I have is an FPGA connected over PCI. The FPGA
>> implements
>> various device functionality (serial ports, I2C controller, IR,
>> etc.) as a
>> single PCI device/function. The FPGA breaks any notion of a true PCI
>> device, it uses PCI as a device interconnect more than anything else.
>>
>> In talking to Greg about this, he suggested I just create a new
>> bus_type
>> for this similar to what is being done for usb-serial. As I
>> started to
>> think about what I wanted ended up being a platform_device plus a
>> sysfs
>> entry for the MMIO region.
>>
>> So, it seems that a "platform device" is a pretty generic concept
>> now. Do
>> you guys thing its acceptable to use a platform device for my
>> needs or
>> should I create some new bus_type? Do we have a better definition
>> of what
>> a platform device is or might be?
>
> Well, your FPGA is a pci device, right? It's only the devices that
> hang
> off of it that you are concerned about. I really think you should
> make
> your own bus type, as it's not much work, and it would not disturb the
> existing platform devices, which do not know about mmio regions like
> PCI.
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.
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 :)
- kumar
On Wed, Feb 22, 2006 at 10:55:16PM -0600, Kumar Gala wrote:
>
> On Feb 22, 2006, at 10:39 PM, Greg KH wrote:
>
> >On Wed, Feb 22, 2006 at 03:47:40PM -0600, Kumar Gala wrote:
> >>Guys,
> >>
> >>I was hoping to get your opinion on a question I had. The
> >>question comes
> >>down to what we think a "platform device" is.
> >>
> >>The situation I have is an FPGA connected over PCI. The FPGA
> >>implements
> >>various device functionality (serial ports, I2C controller, IR,
> >>etc.) as a
> >>single PCI device/function. The FPGA breaks any notion of a true PCI
> >>device, it uses PCI as a device interconnect more than anything else.
> >>
> >>In talking to Greg about this, he suggested I just create a new
> >>bus_type
> >>for this similar to what is being done for usb-serial. As I
> >>started to
> >>think about what I wanted ended up being a platform_device plus a
> >>sysfs
> >>entry for the MMIO region.
> >>
> >>So, it seems that a "platform device" is a pretty generic concept
> >>now. Do
> >>you guys thing its acceptable to use a platform device for my
> >>needs or
> >>should I create some new bus_type? Do we have a better definition
> >>of what
> >>a platform device is or might be?
> >
> >Well, your FPGA is a pci device, right? It's only the devices that
> >hang
> >off of it that you are concerned about. I really think you should
> >make
> >your own bus type, as it's not much work, and it would not disturb the
> >existing platform devices, which do not know about mmio regions like
> >PCI.
>
> 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 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?
Russell probably has other thoughts about this.
thanks,
greg k-h
>> 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.
> Russell probably has other thoughts about this.
Hopefully he'll provide his thoughts :)
- kumar
On Wed, Feb 22, 2006 at 03:47:40PM -0600, Kumar Gala wrote:
> The situation I have is an FPGA connected over PCI. The FPGA implements
> various device functionality (serial ports, I2C controller, IR, etc.) as a
> single PCI device/function. The FPGA breaks any notion of a true PCI
> device, it uses PCI as a device interconnect more than anything else.
We have at least one example where we have a single PCI function
containing more than one type of functionality which are the parallel
port and serial cards [*]. Normally, the different types of
functionality are accessible via different BARs which at least gives
some logical separation.
It's not really a good model because you have to have a special PCI
probe driver to register the various functionalities with the subsystems
rather than using the generic 8250_pci and parport_pci drivers directly.
Also it can have problems if you want to have (eg) serial built-in and
i2c as a module.
The alternative as Greg points out is to implement a pseudo bus_type, but
I start to worry about the overhead associated with doing so.
Given the choice between a small PCI "probe" driver for a small number
of functionalities and a complete driver model infrastructure, I'd
prefer the former over the latter.
* - I'm slightly biased here because it seems I've ended up "owning" the
serial parts of parport_serial, though I don't want to admit that in
public. (damn, I just did!) I think that, provided the subsystems
are sanely written such that there is very little or no code
duplication, this method is as good as any other method.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Feb 23, 2006, at 3:33 AM, Russell King wrote:
> On Wed, Feb 22, 2006 at 03:47:40PM -0600, Kumar Gala wrote:
>> The situation I have is an FPGA connected over PCI. The FPGA
>> implements
>> various device functionality (serial ports, I2C controller, IR,
>> etc.) as a
>> single PCI device/function. The FPGA breaks any notion of a true PCI
>> device, it uses PCI as a device interconnect more than anything else.
>
> We have at least one example where we have a single PCI function
> containing more than one type of functionality which are the parallel
> port and serial cards [*]. Normally, the different types of
> functionality are accessible via different BARs which at least gives
> some logical separation.
>
> It's not really a good model because you have to have a special PCI
> probe driver to register the various functionalities with the
> subsystems
> rather than using the generic 8250_pci and parport_pci drivers
> directly.
> Also it can have problems if you want to have (eg) serial built-in and
> i2c as a module.
>
> The alternative as Greg points out is to implement a pseudo
> bus_type, but
> I start to worry about the overhead associated with doing so.
>
> Given the choice between a small PCI "probe" driver for a small number
> of functionalities and a complete driver model infrastructure, I'd
> prefer the former over the latter.
I might not have been clear before. The number of functions that are
implemented in the FPGA is not a small hand full. I think Greg's
idea of creating a bus is appropriate for the scale.
- kumar
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
- kumar
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 461554a..fb320e9 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -242,7 +242,8 @@ int platform_device_add(struct platform_
if (!pdev->dev.parent)
pdev->dev.parent = &platform_bus;
- pdev->dev.bus = &platform_bus_type;
+ if (!pdev->dev.bus)
+ pdev->dev.bus = &platform_bus_type;
if (pdev->id != -1)
snprintf(pdev->dev.bus_id, BUS_ID_SIZE, "%s.%u", pdev->name, pdev->id);
@@ -426,7 +427,8 @@ static int platform_drv_resume(struct de
*/
int platform_driver_register(struct platform_driver *drv)
{
- drv->driver.bus = &platform_bus_type;
+ if (!drv->driver.bus)
+ drv->driver.bus = &platform_bus_type;
if (drv->probe)
drv->driver.probe = platform_drv_probe;
if (drv->remove)
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
>>> 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?
http://marc.theaimsgroup.com/?l=linux-kernel&m=114072367307531&w=2
Russell, comments?
- kumar
On Mon, Feb 27, 2006 at 04:25:52PM -0600, Kumar Gala wrote:
> >>>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?
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114072367307531&w=2
>
> Russell, comments?
No particular opinion on this, other than maybe we want to move the
dev.bus/driver.bus initialisation out of these functions and inline
or something like that - just so there's some distinction between
real platform devices and these other types.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core