Hi List,
I have a design question concerning a device driver. The device in question is
somewhere in between drivers/mfd/timberdale and drivers/ssb. It is mapped
connected via PCI and on PCI Bar 0 there is a table describing which
"sub-devices" are contained in the FPGA as well as where their Memory and IRQ
resources are.
Unlike the timberdale driver, there is no static configuration of the FPGA's
sub-devices, but their number and kind is variable. But luckily we have unique
device-ids for every sub-device, so it is possible to do a PCI/USB like
enumeration.
In my understanding the MFD API, which timberdale uses, isn't tailored to this
Plug'n'Play like behavior. Whereas the I think (virtual) bus concept used by
SSB is much more suited for this kind of devices. But would it be wise to add a
bus only suited to devices manufactured by one vendor, when there is already a
API for such kinds of multi function devices?
Long story short, which would be the preferred way to implement such a driver? At
the point I currently reached I could go in both directions.
I'd appreciate any advice I can get on this topic.
Thanks in advance,
Johannes
P.S.: MFD and SSB maintainers are on CC as I'd really like to hear their opinion
On 10/22/2013 12:02 AM, Johannes Thumshirn wrote:
> Hi List,
>
> I have a design question concerning a device driver. The device in question is
> somewhere in between drivers/mfd/timberdale and drivers/ssb. It is mapped
> connected via PCI and on PCI Bar 0 there is a table describing which
> "sub-devices" are contained in the FPGA as well as where their Memory and IRQ
> resources are.
>
> Unlike the timberdale driver, there is no static configuration of the FPGA's
> sub-devices, but their number and kind is variable. But luckily we have unique
> device-ids for every sub-device, so it is possible to do a PCI/USB like
> enumeration.
>
> In my understanding the MFD API, which timberdale uses, isn't tailored to this
> Plug'n'Play like behavior. Whereas the I think (virtual) bus concept used by
Not sure if that is true. There is no requirement to declare mfd cells
statically. As long as the devices don't change after mfd probe, an mfd based
solution would at least be implementable.
However, adding support for new sub-devices might be an issue, as you would
have to update the mfd driver to add support for each new device (to create its
mfd cell and platform data), in addition to writing the actual driver.
> SSB is much more suited for this kind of devices. But would it be wise to add a
> bus only suited to devices manufactured by one vendor, when there is already a
> API for such kinds of multi function devices?
>
Assuming you refer to mfd, isn't that a contradiction ? You just stated that mfd
doesn't exactly meet your requirements. There is also an API for adding a new bus,
and it is used quite widely.
Question for me would be if the additional overhead for adding a bus outweighs its
benefits.
> Long story short, which would be the preferred way to implement such a driver? At
> the point I currently reached I could go in both directions.
>
> I'd appreciate any advice I can get on this topic.
>
I'm adding Greg KH to the thread. Maybe he has some useful advice as the driver core
maintainer. I have struggled with the question if to add a bus myself, so maybe I can
get something useful out of it ;).
Thanks,
Guenter
> Thanks in advance,
>
> Johannes
>
> P.S.: MFD and SSB maintainers are on CC as I'd really like to hear their opinion
> --
> 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/
>
>
>
>
On Tue, Oct 22, 2013 at 08:10:00PM -0700, Guenter Roeck wrote:
> On 10/22/2013 12:02 AM, Johannes Thumshirn wrote:
> >Hi List,
> >
> >I have a design question concerning a device driver. The device in question is
> >somewhere in between drivers/mfd/timberdale and drivers/ssb. It is mapped
> >connected via PCI and on PCI Bar 0 there is a table describing which
> >"sub-devices" are contained in the FPGA as well as where their Memory and IRQ
> >resources are.
> >
> >Unlike the timberdale driver, there is no static configuration of the FPGA's
> >sub-devices, but their number and kind is variable. But luckily we have unique
> >device-ids for every sub-device, so it is possible to do a PCI/USB like
> >enumeration.
> >
> >In my understanding the MFD API, which timberdale uses, isn't tailored to this
> >Plug'n'Play like behavior. Whereas the I think (virtual) bus concept used by
>
> Not sure if that is true. There is no requirement to declare mfd cells
> statically. As long as the devices don't change after mfd probe, an mfd based
> solution would at least be implementable.
Yes it would be implementable, but would it be a good idea to do so?
>
> However, adding support for new sub-devices might be an issue, as you would
> have to update the mfd driver to add support for each new device (to create its
> mfd cell and platform data), in addition to writing the actual driver.
>
Adding sub-devices could probably be done without changing th mfd driver, as I
have a device-id, which is part o the article number, so I could generate the
string for the modalias in a generic way.
> >SSB is much more suited for this kind of devices. But would it be wise to add a
> >bus only suited to devices manufactured by one vendor, when there is already a
> >API for such kinds of multi function devices?
> >
> Assuming you refer to mfd, isn't that a contradiction ? You just stated that mfd
> doesn't exactly meet your requirements. There is also an API for adding a new bus,
> and it is used quite widely.
Well my requirements probably can be met using the mfd framework, but I'm not
shure if it would be a good design decission then. Or maybe adding a bus would
be a better decission. The thing is, I don't want to make me a maintainence
hell, but have something I ideally don't need to touch a 2nd time once it is
done right.
>
> Question for me would be if the additional overhead for adding a bus outweighs its
> benefits.
>
> >Long story short, which would be the preferred way to implement such a driver? At
> >the point I currently reached I could go in both directions.
> >
> >I'd appreciate any advice I can get on this topic.
> >
>
> I'm adding Greg KH to the thread. Maybe he has some useful advice as the driver core
> maintainer. I have struggled with the question if to add a bus myself, so maybe I can
> get something useful out of it ;).
This really would be great. If you can get an answer as well, we'd have a win
win situation ;).
Thanks a lot for your comments.
Johannes