Re: Driver Design Question
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Driver Design Question
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Driver Design Question
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Driver Design Question
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Driver Design Question
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Driver Design Question
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
