Re: [PATCH 0/4] gpio: introduce descriptor-based interface
On Sun, Jan 20, 2013 at 7:07 AM, Alex Courbot wrote: > Actually the question of switching to GPIOlib is only worth being asked if > you are making use of drivers that require GENERIC_GPIO. If this is not the > case and your GPIOs are only used by your own platform code, you can always > give up using defining GENERIC_GPIO and continue implementing them your own > way. Agreed. The problem can be summed up like this: #include Considered ambiguous. #include OK with me. Yours, Linus Walleij -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Sun, Jan 20, 2013 at 7:07 AM, Alex Courbot acour...@nvidia.com wrote: Actually the question of switching to GPIOlib is only worth being asked if you are making use of drivers that require GENERIC_GPIO. If this is not the case and your GPIOs are only used by your own platform code, you can always give up using defining GENERIC_GPIO and continue implementing them your own way. Agreed. The problem can be summed up like this: #include linux/gpio.h Considered ambiguous. #include asm/foo/bar/baz-gpio.h OK with me. Yours, Linus Walleij -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
Hi Steven, On 01/18/2013 01:50 AM, Steven King wrote: Well, my concern is the small, single chip platforms with limited ram and speeds measured in MHz. My goal was that these platforms that had very basic gpio needs, no offboard gpio, just toggling a few pins for spi or whatever, could do that without pulling in a bunch of code they dont need. I realize that for x86 or arm people with their giga Hz cpus with gigabytes of ram, its no big deal, but my little 60 MHz coldfire v2s with only 16 megs of ram (and even more constraining, 2 megs of flash) need all the help they can get. Running readelf on gpiolib.o built for Tegra, here are the footprints: .text: 9412B .data: 260B .bss: 12312B .rodata: 268B Total: 22252B or 22KB. ... of which more than half is the BSS section which consists of a static array of 1024 GPIO descriptors, an arbitrary number that you can tune and is way too large even for Tegra (but we have to use these gigabytes somehow). Say you only need to use 256 GPIOs and .bss is down to ~3KB, for a total overhead of 15kB or 0.09% of your 16MB which, in perspective, suddenly seem gigantic. :) If you are concerned about the additional indirection that GPIOlib introduces and the potential slowdown for bitbanging, you can always define custom gpio_set_value() and gpio_get_value() macros to shortcut GPIOlib when the GPIO is in the range you want performance for. I haven't been keeping up with the kernel list of late, can someone point me to what''s being discussed so I can see what were talking about here? Arnd explained it already, but basically we'd like to consolidate the GPIO subsystem around GPIOlib and introduce safer interfaces (while preserving backward compatibility). Good progress in that direction would be achieved if all users of the GENERIC_GPIO interface relied on GPIOlib (making GENERIC_GPIO require GPIOLIB). Actually the question of switching to GPIOlib is only worth being asked if you are making use of drivers that require GENERIC_GPIO. If this is not the case and your GPIOs are only used by your own platform code, you can always give up using defining GENERIC_GPIO and continue implementing them your own way. Thanks, Alex. -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
Hi Steven, On 01/18/2013 01:50 AM, Steven King wrote: Well, my concern is the small, single chip platforms with limited ram and speeds measured in MHz. My goal was that these platforms that had very basic gpio needs, no offboard gpio, just toggling a few pins for spi or whatever, could do that without pulling in a bunch of code they dont need. I realize that for x86 or arm people with their giga Hz cpus with gigabytes of ram, its no big deal, but my little 60 MHz coldfire v2s with only 16 megs of ram (and even more constraining, 2 megs of flash) need all the help they can get. Running readelf on gpiolib.o built for Tegra, here are the footprints: .text: 9412B .data: 260B .bss: 12312B .rodata: 268B Total: 22252B or 22KB. ... of which more than half is the BSS section which consists of a static array of 1024 GPIO descriptors, an arbitrary number that you can tune and is way too large even for Tegra (but we have to use these gigabytes somehow). Say you only need to use 256 GPIOs and .bss is down to ~3KB, for a total overhead of 15kB or 0.09% of your 16MB which, in perspective, suddenly seem gigantic. :) If you are concerned about the additional indirection that GPIOlib introduces and the potential slowdown for bitbanging, you can always define custom gpio_set_value() and gpio_get_value() macros to shortcut GPIOlib when the GPIO is in the range you want performance for. I haven't been keeping up with the kernel list of late, can someone point me to what''s being discussed so I can see what were talking about here? Arnd explained it already, but basically we'd like to consolidate the GPIO subsystem around GPIOlib and introduce safer interfaces (while preserving backward compatibility). Good progress in that direction would be achieved if all users of the GENERIC_GPIO interface relied on GPIOlib (making GENERIC_GPIO require GPIOLIB). Actually the question of switching to GPIOlib is only worth being asked if you are making use of drivers that require GENERIC_GPIO. If this is not the case and your GPIOs are only used by your own platform code, you can always give up using defining GENERIC_GPIO and continue implementing them your own way. Thanks, Alex. -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Thursday 17 January 2013, Steven King wrote: > I haven't been keeping up with the kernel list of late, can someone point me > to what''s being discussed so I can see what were talking about here? We are discussion about changes to the GPIO API, in particular about adding a descriptor (i.e. pointer to struct) based interface to replace integers as the primary key. Any kind of change on this level is currently problematic because it is basically impossible to tell which files are implementing the current interface and would need to get changed along with changing gpiolib. If everything goes through gpiolib, it's much easier to make compatible extensions in one place. Do you have any numbers about how much of a difference for your platforms we are talking about at most? Arnd -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Thursday 17 January 2013 4:02:06 am Greg Ungerer wrote: > Hi Linus, > > (My g...@snapgear.com email no longer gets to me, g...@uclinux.org is > the best direct email for me now). > > On 01/17/2013 09:15 PM, Linus Walleij wrote: > > On Thu, Jan 10, 2013 at 11:08 AM, Arnd Bergmann wrote: > >> I've tried to find platforms that don't yet use GPIOLIB and fortunately > >> there are very few left: > >> > >> I found two that provide the generic gpio interfaces when gpiolib > >> is disabled, but use gpiolib otherwise for the same hardware, > >> arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. > >> I would assume that we can simply remove the non-gpiolib shortcut > >> here at cost of a small overhead. > > > > Geert/Greg: interested in looking into this issue? > > > > The GPIO maintainers want to get rid of non-gpiolib platforms. > > Steven King did most of the ColdFire GPIO work (CC'ed on this). > Steven: are you happy to drop the non-gpiolib support? > > Regards > Greg Well, my concern is the small, single chip platforms with limited ram and speeds measured in MHz. My goal was that these platforms that had very basic gpio needs, no offboard gpio, just toggling a few pins for spi or whatever, could do that without pulling in a bunch of code they dont need. I realize that for x86 or arm people with their giga Hz cpus with gigabytes of ram, its no big deal, but my little 60 MHz coldfire v2s with only 16 megs of ram (and even more constraining, 2 megs of flash) need all the help they can get. I haven't been keeping up with the kernel list of late, can someone point me to what''s being discussed so I can see what were talking about here? -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
Hi Linus, (My g...@snapgear.com email no longer gets to me, g...@uclinux.org is the best direct email for me now). On 01/17/2013 09:15 PM, Linus Walleij wrote: > On Thu, Jan 10, 2013 at 11:08 AM, Arnd Bergmann wrote: > >> I've tried to find platforms that don't yet use GPIOLIB and fortunately >> there are very few left: >> >> I found two that provide the generic gpio interfaces when gpiolib >> is disabled, but use gpiolib otherwise for the same hardware, >> arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. >> I would assume that we can simply remove the non-gpiolib shortcut >> here at cost of a small overhead. > > Geert/Greg: interested in looking into this issue? > > The GPIO maintainers want to get rid of non-gpiolib platforms. Steven King did most of the ColdFire GPIO work (CC'ed on this). Steven: are you happy to drop the non-gpiolib support? Regards Greg -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Thu, Jan 10, 2013 at 11:08 AM, Arnd Bergmann wrote:
> On Thursday 10 January 2013, Alex Courbot wrote:
>> > Regarding the integration of pinctrl with gpio,
>> > I was thinking in the past that we could make pinctrl provide everything
>> > that gpiolib does, and have a generic gpiolib driver on top of pinctrl
>> > so that platforms don't need to implement both interfaces but only need
>> > to provide a pure pinctrl driver. Not sure if this makes any sense.
>>
>> That would work if all GPIOs were connected to a ball, but how about GPIO
>> expanders that are external to the chip? They have no use for pinctrl AFAICT.
>> On the other hand, maybe we can have one pinctrl-gpio driver for those chips
>> where pinctrl alone can emulate all the functionality of a GPIO controller.
>> Maybe such a driver exists already?
>
> I don't think we have that yet, but it would be another option: rather
> than putting a generic gpiolib driver on top of pinctrl, we could have
> pinctrl support for all gpios that go through gpiolib, and move device
> drivers over to use pinctrl as the way to manage gpios rather than the
> classic gpio drivers. That would be a larger change though, and require
> that we pull in the pinctrl subsystem on a lot of machines that don't
> need it today.
Not quite following but have the following loose idea:
- Add API such as with struct pin_gpio_ops {}
or similar. As orthogonal to the mux and config interfaces we already
have.
- Add ops like .set_input(), .set_output(), .drive_high() and .drive_low()
(etc) to the ops struct so all functionality currently provided by
gpiolib can be implemened by a driver.
- Make global pin numbers optional in gpiolib for the next part...
- Register a generic GPIO chip on top of the pinctrl-gpio.c, preferably
only supporting Alex' descriptors.
- Provide a userspace interface to pinctrl with something like /dev/pinctrlN
with an ioctl() interface, solving also Roland Stigge's issue with
driving many pins at the same time in a smooth way.
Sounds like a plan?
I'd like to avoid the either-or-approach where you have to use
pinctrl only or only gpiolib, so a compatibility layer kindof.
I'm prepping a talk at ELC so will try to jot down something more
substantial.
Yours,
Linus Walleij
--
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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Thu, Jan 10, 2013 at 11:08 AM, Arnd Bergmann wrote: > I've tried to find platforms that don't yet use GPIOLIB and fortunately > there are very few left: > > I found two that provide the generic gpio interfaces when gpiolib > is disabled, but use gpiolib otherwise for the same hardware, > arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. > I would assume that we can simply remove the non-gpiolib shortcut > here at cost of a small overhead. Geert/Greg: interested in looking into this issue? The GPIO maintainers want to get rid of non-gpiolib platforms. Yours, Linus Walleij -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Thu, Jan 10, 2013 at 11:08 AM, Arnd Bergmann a...@arndb.de wrote: I've tried to find platforms that don't yet use GPIOLIB and fortunately there are very few left: I found two that provide the generic gpio interfaces when gpiolib is disabled, but use gpiolib otherwise for the same hardware, arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. I would assume that we can simply remove the non-gpiolib shortcut here at cost of a small overhead. Geert/Greg: interested in looking into this issue? The GPIO maintainers want to get rid of non-gpiolib platforms. Yours, Linus Walleij -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Thu, Jan 10, 2013 at 11:08 AM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 10 January 2013, Alex Courbot wrote:
Regarding the integration of pinctrl with gpio,
I was thinking in the past that we could make pinctrl provide everything
that gpiolib does, and have a generic gpiolib driver on top of pinctrl
so that platforms don't need to implement both interfaces but only need
to provide a pure pinctrl driver. Not sure if this makes any sense.
That would work if all GPIOs were connected to a ball, but how about GPIO
expanders that are external to the chip? They have no use for pinctrl AFAICT.
On the other hand, maybe we can have one pinctrl-gpio driver for those chips
where pinctrl alone can emulate all the functionality of a GPIO controller.
Maybe such a driver exists already?
I don't think we have that yet, but it would be another option: rather
than putting a generic gpiolib driver on top of pinctrl, we could have
pinctrl support for all gpios that go through gpiolib, and move device
drivers over to use pinctrl as the way to manage gpios rather than the
classic gpio drivers. That would be a larger change though, and require
that we pull in the pinctrl subsystem on a lot of machines that don't
need it today.
Not quite following but have the following loose idea:
- Add API such as linux/pinctrl/gpio.h with struct pin_gpio_ops {}
or similar. As orthogonal to the mux and config interfaces we already
have.
- Add ops like .set_input(), .set_output(), .drive_high() and .drive_low()
(etc) to the ops struct so all functionality currently provided by
gpiolib can be implemened by a driver.
- Make global pin numbers optional in gpiolib for the next part...
- Register a generic GPIO chip on top of the pinctrl-gpio.c, preferably
only supporting Alex' descriptors.
- Provide a userspace interface to pinctrl with something like /dev/pinctrlN
with an ioctl() interface, solving also Roland Stigge's issue with
driving many pins at the same time in a smooth way.
Sounds like a plan?
I'd like to avoid the either-or-approach where you have to use
pinctrl only or only gpiolib, so a compatibility layer kindof.
I'm prepping a talk at ELC so will try to jot down something more
substantial.
Yours,
Linus Walleij
--
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: [PATCH 0/4] gpio: introduce descriptor-based interface
Hi Linus, (My g...@snapgear.com email no longer gets to me, g...@uclinux.org is the best direct email for me now). On 01/17/2013 09:15 PM, Linus Walleij wrote: On Thu, Jan 10, 2013 at 11:08 AM, Arnd Bergmann a...@arndb.de wrote: I've tried to find platforms that don't yet use GPIOLIB and fortunately there are very few left: I found two that provide the generic gpio interfaces when gpiolib is disabled, but use gpiolib otherwise for the same hardware, arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. I would assume that we can simply remove the non-gpiolib shortcut here at cost of a small overhead. Geert/Greg: interested in looking into this issue? The GPIO maintainers want to get rid of non-gpiolib platforms. Steven King did most of the ColdFire GPIO work (CC'ed on this). Steven: are you happy to drop the non-gpiolib support? Regards Greg -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Thursday 17 January 2013 4:02:06 am Greg Ungerer wrote: Hi Linus, (My g...@snapgear.com email no longer gets to me, g...@uclinux.org is the best direct email for me now). On 01/17/2013 09:15 PM, Linus Walleij wrote: On Thu, Jan 10, 2013 at 11:08 AM, Arnd Bergmann a...@arndb.de wrote: I've tried to find platforms that don't yet use GPIOLIB and fortunately there are very few left: I found two that provide the generic gpio interfaces when gpiolib is disabled, but use gpiolib otherwise for the same hardware, arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. I would assume that we can simply remove the non-gpiolib shortcut here at cost of a small overhead. Geert/Greg: interested in looking into this issue? The GPIO maintainers want to get rid of non-gpiolib platforms. Steven King did most of the ColdFire GPIO work (CC'ed on this). Steven: are you happy to drop the non-gpiolib support? Regards Greg Well, my concern is the small, single chip platforms with limited ram and speeds measured in MHz. My goal was that these platforms that had very basic gpio needs, no offboard gpio, just toggling a few pins for spi or whatever, could do that without pulling in a bunch of code they dont need. I realize that for x86 or arm people with their giga Hz cpus with gigabytes of ram, its no big deal, but my little 60 MHz coldfire v2s with only 16 megs of ram (and even more constraining, 2 megs of flash) need all the help they can get. I haven't been keeping up with the kernel list of late, can someone point me to what''s being discussed so I can see what were talking about here? -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Thursday 17 January 2013, Steven King wrote: I haven't been keeping up with the kernel list of late, can someone point me to what''s being discussed so I can see what were talking about here? We are discussion about changes to the GPIO API, in particular about adding a descriptor (i.e. pointer to struct) based interface to replace integers as the primary key. Any kind of change on this level is currently problematic because it is basically impossible to tell which files are implementing the current interface and would need to get changed along with changing gpiolib. If everything goes through gpiolib, it's much easier to make compatible extensions in one place. Do you have any numbers about how much of a difference for your platforms we are talking about at most? Arnd -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Monday 14 January 2013, Alex Courbot wrote: > On 01/10/2013 07:08 PM, Arnd Bergmann wrote: > > I found two that provide the generic gpio interfaces when gpiolib > > is disabled, but use gpiolib otherwise for the same hardware, > > arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. > > I would assume that we can simply remove the non-gpiolib shortcut > > here at cost of a small overhead. > > I performed a search on my side too (checking configurations options > which select GENERIC_GPIO but not ARCH_REQUIRE_GPIOLIB) and found the > same list. This takes some time btw - many platforms use this combo to > make GPIO support optional. Can I ask how you figured out these two archs? I basically grepped for GENERIC_GPIO and looked at the individual implementations. > > Then there are a bunch that use gpiolib but have a nontrivial > > implementation of gpio_get_value and other functions. I'm not sure > > if these are a problematic with your code. > > AFAICT these all implement an inline path that bypasses GPIOlib when the > GPIO number is known at compile time, for faster bitbanging I presume. > It should be totally harmless to keep them. Unfortunately, I don't think > it would be possible to have a similar trick using handlers. Right, makes sense. Arnd -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On 01/10/2013 07:08 PM, Arnd Bergmann wrote: I've tried to find platforms that don't yet use GPIOLIB and fortunately there are very few left: I found two that provide the generic gpio interfaces when gpiolib is disabled, but use gpiolib otherwise for the same hardware, arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. I would assume that we can simply remove the non-gpiolib shortcut here at cost of a small overhead. I performed a search on my side too (checking configurations options which select GENERIC_GPIO but not ARCH_REQUIRE_GPIOLIB) and found the same list. This takes some time btw - many platforms use this combo to make GPIO support optional. Can I ask how you figured out these two archs? I'd assume the overhead induced by forcibly compiling GPIOlib is neglectable, but let's make sure this is ok indeed - Mike, Geert, would you mind if selecting GENERIC_GPIO enforced GPIOlib to be compiled in, effectively making it mandatory to implement the generic GPIO interface using GPIOlib? Both your implementations support GPIOlib already, but can also work without it, and that would make that possibility obsolete. Then there are a bunch that use gpiolib but have a nontrivial implementation of gpio_get_value and other functions. I'm not sure if these are a problematic with your code. AFAICT these all implement an inline path that bypasses GPIOlib when the GPIO number is known at compile time, for faster bitbanging I presume. It should be totally harmless to keep them. Unfortunately, I don't think it would be possible to have a similar trick using handlers. Thanks, Alex. -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On 01/10/2013 07:08 PM, Arnd Bergmann wrote: I've tried to find platforms that don't yet use GPIOLIB and fortunately there are very few left: I found two that provide the generic gpio interfaces when gpiolib is disabled, but use gpiolib otherwise for the same hardware, arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. I would assume that we can simply remove the non-gpiolib shortcut here at cost of a small overhead. I performed a search on my side too (checking configurations options which select GENERIC_GPIO but not ARCH_REQUIRE_GPIOLIB) and found the same list. This takes some time btw - many platforms use this combo to make GPIO support optional. Can I ask how you figured out these two archs? I'd assume the overhead induced by forcibly compiling GPIOlib is neglectable, but let's make sure this is ok indeed - Mike, Geert, would you mind if selecting GENERIC_GPIO enforced GPIOlib to be compiled in, effectively making it mandatory to implement the generic GPIO interface using GPIOlib? Both your implementations support GPIOlib already, but can also work without it, and that would make that possibility obsolete. Then there are a bunch that use gpiolib but have a nontrivial implementation of gpio_get_value and other functions. I'm not sure if these are a problematic with your code. AFAICT these all implement an inline path that bypasses GPIOlib when the GPIO number is known at compile time, for faster bitbanging I presume. It should be totally harmless to keep them. Unfortunately, I don't think it would be possible to have a similar trick using handlers. Thanks, Alex. -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Monday 14 January 2013, Alex Courbot wrote: On 01/10/2013 07:08 PM, Arnd Bergmann wrote: I found two that provide the generic gpio interfaces when gpiolib is disabled, but use gpiolib otherwise for the same hardware, arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. I would assume that we can simply remove the non-gpiolib shortcut here at cost of a small overhead. I performed a search on my side too (checking configurations options which select GENERIC_GPIO but not ARCH_REQUIRE_GPIOLIB) and found the same list. This takes some time btw - many platforms use this combo to make GPIO support optional. Can I ask how you figured out these two archs? I basically grepped for GENERIC_GPIO and looked at the individual implementations. Then there are a bunch that use gpiolib but have a nontrivial implementation of gpio_get_value and other functions. I'm not sure if these are a problematic with your code. AFAICT these all implement an inline path that bypasses GPIOlib when the GPIO number is known at compile time, for faster bitbanging I presume. It should be totally harmless to keep them. Unfortunately, I don't think it would be possible to have a similar trick using handlers. Right, makes sense. Arnd -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Thursday 10 January 2013, Alex Courbot wrote: > On Wednesday 09 January 2013 18:46:12 Arnd Bergmann wrote: > > > > Only legacy users did this. Initially there was only the header file, > > with the API declared but several different implementations of it. > > gpiolib was introduced later to reduce code duplication and allow having > > multiple implementations in the same kernel. > > Does the following sound reasonable? > 1) Make sure every target that uses GENERIC_GPIO also implements its drivers > using gpiolib, convert the (hopefully) few ones that don't to use gpiolib > 2) Make GENERIC_GPIO require GPIOLIB or just merge both options into a single > one > 3) Turn gpio into a full subsystem (like pinctrl) > > This should make things less blurry and easier to maintain (less header > files, > only one interface, etc.) GPIO controllers would also be better integrated > into the driver model. Yes, I think that would be good. I've tried to find platforms that don't yet use GPIOLIB and fortunately there are very few left: I found two that provide the generic gpio interfaces when gpiolib is disabled, but use gpiolib otherwise for the same hardware, arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. I would assume that we can simply remove the non-gpiolib shortcut here at cost of a small overhead. Then there are a bunch that use gpiolib but have a nontrivial implementation of gpio_get_value and other functions. I'm not sure if these are a problematic with your code. > > Regarding the integration of pinctrl with gpio, > > I was thinking in the past that we could make pinctrl provide everything > > that gpiolib does, and have a generic gpiolib driver on top of pinctrl > > so that platforms don't need to implement both interfaces but only need > > to provide a pure pinctrl driver. Not sure if this makes any sense. > > That would work if all GPIOs were connected to a ball, but how about GPIO > expanders that are external to the chip? They have no use for pinctrl AFAICT. > On the other hand, maybe we can have one pinctrl-gpio driver for those chips > where pinctrl alone can emulate all the functionality of a GPIO controller. > Maybe such a driver exists already? I don't think we have that yet, but it would be another option: rather than putting a generic gpiolib driver on top of pinctrl, we could have pinctrl support for all gpios that go through gpiolib, and move device drivers over to use pinctrl as the way to manage gpios rather than the classic gpio drivers. That would be a larger change though, and require that we pull in the pinctrl subsystem on a lot of machines that don't need it today. Arnd -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Thursday 10 January 2013, Alex Courbot wrote: On Wednesday 09 January 2013 18:46:12 Arnd Bergmann wrote: Only legacy users did this. Initially there was only the header file, with the API declared but several different implementations of it. gpiolib was introduced later to reduce code duplication and allow having multiple implementations in the same kernel. Does the following sound reasonable? 1) Make sure every target that uses GENERIC_GPIO also implements its drivers using gpiolib, convert the (hopefully) few ones that don't to use gpiolib 2) Make GENERIC_GPIO require GPIOLIB or just merge both options into a single one 3) Turn gpio into a full subsystem (like pinctrl) This should make things less blurry and easier to maintain (less header files, only one interface, etc.) GPIO controllers would also be better integrated into the driver model. Yes, I think that would be good. I've tried to find platforms that don't yet use GPIOLIB and fortunately there are very few left: I found two that provide the generic gpio interfaces when gpiolib is disabled, but use gpiolib otherwise for the same hardware, arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. I would assume that we can simply remove the non-gpiolib shortcut here at cost of a small overhead. Then there are a bunch that use gpiolib but have a nontrivial implementation of gpio_get_value and other functions. I'm not sure if these are a problematic with your code. Regarding the integration of pinctrl with gpio, I was thinking in the past that we could make pinctrl provide everything that gpiolib does, and have a generic gpiolib driver on top of pinctrl so that platforms don't need to implement both interfaces but only need to provide a pure pinctrl driver. Not sure if this makes any sense. That would work if all GPIOs were connected to a ball, but how about GPIO expanders that are external to the chip? They have no use for pinctrl AFAICT. On the other hand, maybe we can have one pinctrl-gpio driver for those chips where pinctrl alone can emulate all the functionality of a GPIO controller. Maybe such a driver exists already? I don't think we have that yet, but it would be another option: rather than putting a generic gpiolib driver on top of pinctrl, we could have pinctrl support for all gpios that go through gpiolib, and move device drivers over to use pinctrl as the way to manage gpios rather than the classic gpio drivers. That would be a larger change though, and require that we pull in the pinctrl subsystem on a lot of machines that don't need it today. Arnd -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Wednesday 09 January 2013 18:46:12 Arnd Bergmann wrote: > > The question is, do we want to totally get rid of the integer > > namespace? That would be the ultimate step, but would require another > > way to identify GPIOs (controller_device:offset might be such a way), > > and also to reorganize sysfs nodes. Wouldn't that be considered > > breaking user-space? 'cause we all know what happens to those who > > break user-space. > > > The user interface could eventually be the only part of the kernel that > uses the numbers, but you are right that we cannot change that. That's sad, as it makes it necessary to maintain the global integer namespace (assigning a base GPIO to each controller and making sure the controllers ranges do no overlap) even if it is not used internally anymore. We could make global numbers assignment transparent, but that would potentially change the GPIO numbers in user-space and cause another incompatibility. > > With the current code, a driver should depend on gpiolib being > > compiled if it uses the new interface. It is not even declared if > > gpiolib is not used. > > > > Given that both interfaces are quite close, one could imagine having a > > gpiod wrapper around the integer namespace (the "opaque descriptors" > > would then just be casted integers). This way drivers would only need > > to depend on GENERIC_GPIO. It's a little bit weird to have gpiod > > wrapping around gpio in one case and the opposite in another though - > > I'd rather have these platforms convert to GPIO descriptors internally > > (or even better, to gpiolib), but this is probably asking too much. > > > I think it would be reasonable to force everybody to use gpiolib, > that's much easier than converting everyone to the descriptor based > interface. > > > > I do not know all the details of gpiolib's history, but why would > > anyone want to implement the generic gpio interface and not use > > gpiolib anyways? > > > Only legacy users did this. Initially there was only the header file, > with the API declared but several different implementations of it. > gpiolib was introduced later to reduce code duplication and allow having > multiple implementations in the same kernel. Does the following sound reasonable? 1) Make sure every target that uses GENERIC_GPIO also implements its drivers using gpiolib, convert the (hopefully) few ones that don't to use gpiolib 2) Make GENERIC_GPIO require GPIOLIB or just merge both options into a single one 3) Turn gpio into a full subsystem (like pinctrl) This should make things less blurry and easier to maintain (less header files, only one interface, etc.) GPIO controllers would also be better integrated into the driver model. > > > If we are adding a new way to deal with GPIOs, would it make sense to > > > have that more closely integrated into pinctrl in one form or another? > > > My feeling is that there is already a significant overlap between the > > > two, and while the addition of the gpiod_* functions doesn't > > > necessarily > > > make this worse, it could be a chance to improve the current situation > > > to make the interface more consistent with pinctrl. > > > > > > That may be a chance to introduce deeper changes indeed - what do you > > have in mind exactly? > > > I don't know enough about pinctrl to have a specific idea yet, but maybe > someone else has ideas. I had a deeper look at pinctrl, and indeed I can see the connection between the two. There already interfaces to link GPIO ranges to pin ranges and have GPIO drivers switch the pin to the correct state when a GPIO is requested (this, btw, should also be updated to not use global GPIO numbers at some point). Maybe some tighter integration that I just don't see yet can be done too. > Regarding the integration of pinctrl with gpio, > I was thinking in the past that we could make pinctrl provide everything > that gpiolib does, and have a generic gpiolib driver on top of pinctrl > so that platforms don't need to implement both interfaces but only need > to provide a pure pinctrl driver. Not sure if this makes any sense. That would work if all GPIOs were connected to a ball, but how about GPIO expanders that are external to the chip? They have no use for pinctrl AFAICT. On the other hand, maybe we can have one pinctrl-gpio driver for those chips where pinctrl alone can emulate all the functionality of a GPIO controller. Maybe such a driver exists already? But in general, I agree pinctrl should be a source of inspiration for how to design GPIO. In particular, having a per-chip integer namespace instead of a single global one is definitely something to take (and that's how things work in the DT already). Alex. -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Wednesday 09 January 2013, Alexandre Courbot wrote: > On Tue, Jan 8, 2013 at 10:06 PM, Arnd Bergmann wrote: > > I like the interface, good idea! > > Great! This was initially suggested by Linus W. > > > A few questions: > > > > Is there a plan for migrating all the existing users of the current GPIO > > interface? > > Nothing specifically planned for now, as we need to make sure the new > interface covers all needs first. There would be a lot of drivers to > change if we decide to deprecate the integer interface, but Coccinelle > could probably help here. Right. > The question is, do we want to totally get rid of the integer > namespace? That would be the ultimate step, but would require another > way to identify GPIOs (controller_device:offset might be such a way), > and also to reorganize sysfs nodes. Wouldn't that be considered > breaking user-space? 'cause we all know what happens to those who > break user-space. The user interface could eventually be the only part of the kernel that uses the numbers, but you are right that we cannot change that. > > How do you want to deal with drivers that work on platforms that currently > > don't use gpiolib but have their own implementation of asm/gpio.h? Are > > we going to phase them out? > > With the current code, a driver should depend on gpiolib being > compiled if it uses the new interface. It is not even declared if > gpiolib is not used. > > Given that both interfaces are quite close, one could imagine having a > gpiod wrapper around the integer namespace (the "opaque descriptors" > would then just be casted integers). This way drivers would only need > to depend on GENERIC_GPIO. It's a little bit weird to have gpiod > wrapping around gpio in one case and the opposite in another though - > I'd rather have these platforms convert to GPIO descriptors internally > (or even better, to gpiolib), but this is probably asking too much. I think it would be reasonable to force everybody to use gpiolib, that's much easier than converting everyone to the descriptor based interface. > I do not know all the details of gpiolib's history, but why would > anyone want to implement the generic gpio interface and not use > gpiolib anyways? Only legacy users did this. Initially there was only the header file, with the API declared but several different implementations of it. gpiolib was introduced later to reduce code duplication and allow having multiple implementations in the same kernel. > Then there are platforms who do not follow generic gpios and implement > their own sauce. I don't think we need to care here, as these are not > supposed to be used with generic drivers anyway. I agree. Ideally we would convert them over as well, but there is no need to rush that, or force it on anybody. We should just make sure we don't grow any new platforms doing this. > > If we are adding a new way to deal with GPIOs, would it make sense to > > have that more closely integrated into pinctrl in one form or another? > > My feeling is that there is already a significant overlap between the > > two, and while the addition of the gpiod_* functions doesn't necessarily > > make this worse, it could be a chance to improve the current situation > > to make the interface more consistent with pinctrl. > > That may be a chance to introduce deeper changes indeed - what do you > have in mind exactly? I don't know enough about pinctrl to have a specific idea yet, but maybe someone else has ideas. Regarding the integration of pinctrl with gpio, I was thinking in the past that we could make pinctrl provide everything that gpiolib does, and have a generic gpiolib driver on top of pinctrl so that platforms don't need to implement both interfaces but only need to provide a pure pinctrl driver. Not sure if this makes any sense. Arnd -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Wednesday 09 January 2013, Alexandre Courbot wrote: On Tue, Jan 8, 2013 at 10:06 PM, Arnd Bergmann a...@arndb.de wrote: I like the interface, good idea! Great! This was initially suggested by Linus W. A few questions: Is there a plan for migrating all the existing users of the current GPIO interface? Nothing specifically planned for now, as we need to make sure the new interface covers all needs first. There would be a lot of drivers to change if we decide to deprecate the integer interface, but Coccinelle could probably help here. Right. The question is, do we want to totally get rid of the integer namespace? That would be the ultimate step, but would require another way to identify GPIOs (controller_device:offset might be such a way), and also to reorganize sysfs nodes. Wouldn't that be considered breaking user-space? 'cause we all know what happens to those who break user-space. The user interface could eventually be the only part of the kernel that uses the numbers, but you are right that we cannot change that. How do you want to deal with drivers that work on platforms that currently don't use gpiolib but have their own implementation of asm/gpio.h? Are we going to phase them out? With the current code, a driver should depend on gpiolib being compiled if it uses the new interface. It is not even declared if gpiolib is not used. Given that both interfaces are quite close, one could imagine having a gpiod wrapper around the integer namespace (the opaque descriptors would then just be casted integers). This way drivers would only need to depend on GENERIC_GPIO. It's a little bit weird to have gpiod wrapping around gpio in one case and the opposite in another though - I'd rather have these platforms convert to GPIO descriptors internally (or even better, to gpiolib), but this is probably asking too much. I think it would be reasonable to force everybody to use gpiolib, that's much easier than converting everyone to the descriptor based interface. I do not know all the details of gpiolib's history, but why would anyone want to implement the generic gpio interface and not use gpiolib anyways? Only legacy users did this. Initially there was only the header file, with the API declared but several different implementations of it. gpiolib was introduced later to reduce code duplication and allow having multiple implementations in the same kernel. Then there are platforms who do not follow generic gpios and implement their own sauce. I don't think we need to care here, as these are not supposed to be used with generic drivers anyway. I agree. Ideally we would convert them over as well, but there is no need to rush that, or force it on anybody. We should just make sure we don't grow any new platforms doing this. If we are adding a new way to deal with GPIOs, would it make sense to have that more closely integrated into pinctrl in one form or another? My feeling is that there is already a significant overlap between the two, and while the addition of the gpiod_* functions doesn't necessarily make this worse, it could be a chance to improve the current situation to make the interface more consistent with pinctrl. That may be a chance to introduce deeper changes indeed - what do you have in mind exactly? I don't know enough about pinctrl to have a specific idea yet, but maybe someone else has ideas. Regarding the integration of pinctrl with gpio, I was thinking in the past that we could make pinctrl provide everything that gpiolib does, and have a generic gpiolib driver on top of pinctrl so that platforms don't need to implement both interfaces but only need to provide a pure pinctrl driver. Not sure if this makes any sense. Arnd -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Wednesday 09 January 2013 18:46:12 Arnd Bergmann wrote: The question is, do we want to totally get rid of the integer namespace? That would be the ultimate step, but would require another way to identify GPIOs (controller_device:offset might be such a way), and also to reorganize sysfs nodes. Wouldn't that be considered breaking user-space? 'cause we all know what happens to those who break user-space. The user interface could eventually be the only part of the kernel that uses the numbers, but you are right that we cannot change that. That's sad, as it makes it necessary to maintain the global integer namespace (assigning a base GPIO to each controller and making sure the controllers ranges do no overlap) even if it is not used internally anymore. We could make global numbers assignment transparent, but that would potentially change the GPIO numbers in user-space and cause another incompatibility. With the current code, a driver should depend on gpiolib being compiled if it uses the new interface. It is not even declared if gpiolib is not used. Given that both interfaces are quite close, one could imagine having a gpiod wrapper around the integer namespace (the opaque descriptors would then just be casted integers). This way drivers would only need to depend on GENERIC_GPIO. It's a little bit weird to have gpiod wrapping around gpio in one case and the opposite in another though - I'd rather have these platforms convert to GPIO descriptors internally (or even better, to gpiolib), but this is probably asking too much. I think it would be reasonable to force everybody to use gpiolib, that's much easier than converting everyone to the descriptor based interface. I do not know all the details of gpiolib's history, but why would anyone want to implement the generic gpio interface and not use gpiolib anyways? Only legacy users did this. Initially there was only the header file, with the API declared but several different implementations of it. gpiolib was introduced later to reduce code duplication and allow having multiple implementations in the same kernel. Does the following sound reasonable? 1) Make sure every target that uses GENERIC_GPIO also implements its drivers using gpiolib, convert the (hopefully) few ones that don't to use gpiolib 2) Make GENERIC_GPIO require GPIOLIB or just merge both options into a single one 3) Turn gpio into a full subsystem (like pinctrl) This should make things less blurry and easier to maintain (less header files, only one interface, etc.) GPIO controllers would also be better integrated into the driver model. If we are adding a new way to deal with GPIOs, would it make sense to have that more closely integrated into pinctrl in one form or another? My feeling is that there is already a significant overlap between the two, and while the addition of the gpiod_* functions doesn't necessarily make this worse, it could be a chance to improve the current situation to make the interface more consistent with pinctrl. That may be a chance to introduce deeper changes indeed - what do you have in mind exactly? I don't know enough about pinctrl to have a specific idea yet, but maybe someone else has ideas. I had a deeper look at pinctrl, and indeed I can see the connection between the two. There already interfaces to link GPIO ranges to pin ranges and have GPIO drivers switch the pin to the correct state when a GPIO is requested (this, btw, should also be updated to not use global GPIO numbers at some point). Maybe some tighter integration that I just don't see yet can be done too. Regarding the integration of pinctrl with gpio, I was thinking in the past that we could make pinctrl provide everything that gpiolib does, and have a generic gpiolib driver on top of pinctrl so that platforms don't need to implement both interfaces but only need to provide a pure pinctrl driver. Not sure if this makes any sense. That would work if all GPIOs were connected to a ball, but how about GPIO expanders that are external to the chip? They have no use for pinctrl AFAICT. On the other hand, maybe we can have one pinctrl-gpio driver for those chips where pinctrl alone can emulate all the functionality of a GPIO controller. Maybe such a driver exists already? But in general, I agree pinctrl should be a source of inspiration for how to design GPIO. In particular, having a per-chip integer namespace instead of a single global one is definitely something to take (and that's how things work in the DT already). Alex. -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Tue, Jan 8, 2013 at 10:06 PM, Arnd Bergmann wrote: > I like the interface, good idea! Great! This was initially suggested by Linus W. > A few questions: > > Is there a plan for migrating all the existing users of the current GPIO > interface? Nothing specifically planned for now, as we need to make sure the new interface covers all needs first. There would be a lot of drivers to change if we decide to deprecate the integer interface, but Coccinelle could probably help here. The question is, do we want to totally get rid of the integer namespace? That would be the ultimate step, but would require another way to identify GPIOs (controller_device:offset might be such a way), and also to reorganize sysfs nodes. Wouldn't that be considered breaking user-space? 'cause we all know what happens to those who break user-space. > How do you want to deal with drivers that work on platforms that currently > don't use gpiolib but have their own implementation of asm/gpio.h? Are > we going to phase them out? With the current code, a driver should depend on gpiolib being compiled if it uses the new interface. It is not even declared if gpiolib is not used. Given that both interfaces are quite close, one could imagine having a gpiod wrapper around the integer namespace (the "opaque descriptors" would then just be casted integers). This way drivers would only need to depend on GENERIC_GPIO. It's a little bit weird to have gpiod wrapping around gpio in one case and the opposite in another though - I'd rather have these platforms convert to GPIO descriptors internally (or even better, to gpiolib), but this is probably asking too much. I do not know all the details of gpiolib's history, but why would anyone want to implement the generic gpio interface and not use gpiolib anyways? Then there are platforms who do not follow generic gpios and implement their own sauce. I don't think we need to care here, as these are not supposed to be used with generic drivers anyway. > If we are adding a new way to deal with GPIOs, would it make sense to > have that more closely integrated into pinctrl in one form or another? > My feeling is that there is already a significant overlap between the > two, and while the addition of the gpiod_* functions doesn't necessarily > make this worse, it could be a chance to improve the current situation > to make the interface more consistent with pinctrl. That may be a chance to introduce deeper changes indeed - what do you have in mind exactly? Thanks, Alex. -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Tuesday 08 January 2013, Alexandre Courbot wrote: > This series introduce a first take at implementing the RFC for the new GPIO > API > that I submitted last month. It proposes a new, opaque descriptor-based GPIO > API > that becomes available when GPIOlib is compiled, and provides a safer, more > abstract alternative to the current integer-based interface. GPIOlib internals > are also switched to use the descriptor logic, and the former integer API > becomes a lightweight wrapper around the new descriptor-based API. > > Functionally speaking the new API is identical to the integer-based API, with > only the prefix changing from gpio_ to gpiod_. However, the second patch > introduces new functions for obtaining GPIOs from a device and a consumer > name, > in a fashion similar to what is done with e.g. regulators and PWMs. I like the interface, good idea! A few questions: Is there a plan for migrating all the existing users of the current GPIO interface? How do you want to deal with drivers that work on platforms that currently don't use gpiolib but have their own implementation of asm/gpio.h? Are we going to phase them out? If we are adding a new way to deal with GPIOs, would it make sense to have that more closely integrated into pinctrl in one form or another? My feeling is that there is already a significant overlap between the two, and while the addition of the gpiod_* functions doesn't necessarily make this worse, it could be a chance to improve the current situation to make the interface more consistent with pinctrl. Arnd -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Tuesday 08 January 2013, Alexandre Courbot wrote: This series introduce a first take at implementing the RFC for the new GPIO API that I submitted last month. It proposes a new, opaque descriptor-based GPIO API that becomes available when GPIOlib is compiled, and provides a safer, more abstract alternative to the current integer-based interface. GPIOlib internals are also switched to use the descriptor logic, and the former integer API becomes a lightweight wrapper around the new descriptor-based API. Functionally speaking the new API is identical to the integer-based API, with only the prefix changing from gpio_ to gpiod_. However, the second patch introduces new functions for obtaining GPIOs from a device and a consumer name, in a fashion similar to what is done with e.g. regulators and PWMs. I like the interface, good idea! A few questions: Is there a plan for migrating all the existing users of the current GPIO interface? How do you want to deal with drivers that work on platforms that currently don't use gpiolib but have their own implementation of asm/gpio.h? Are we going to phase them out? If we are adding a new way to deal with GPIOs, would it make sense to have that more closely integrated into pinctrl in one form or another? My feeling is that there is already a significant overlap between the two, and while the addition of the gpiod_* functions doesn't necessarily make this worse, it could be a chance to improve the current situation to make the interface more consistent with pinctrl. Arnd -- 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: [PATCH 0/4] gpio: introduce descriptor-based interface
On Tue, Jan 8, 2013 at 10:06 PM, Arnd Bergmann a...@arndb.de wrote: I like the interface, good idea! Great! This was initially suggested by Linus W. A few questions: Is there a plan for migrating all the existing users of the current GPIO interface? Nothing specifically planned for now, as we need to make sure the new interface covers all needs first. There would be a lot of drivers to change if we decide to deprecate the integer interface, but Coccinelle could probably help here. The question is, do we want to totally get rid of the integer namespace? That would be the ultimate step, but would require another way to identify GPIOs (controller_device:offset might be such a way), and also to reorganize sysfs nodes. Wouldn't that be considered breaking user-space? 'cause we all know what happens to those who break user-space. How do you want to deal with drivers that work on platforms that currently don't use gpiolib but have their own implementation of asm/gpio.h? Are we going to phase them out? With the current code, a driver should depend on gpiolib being compiled if it uses the new interface. It is not even declared if gpiolib is not used. Given that both interfaces are quite close, one could imagine having a gpiod wrapper around the integer namespace (the opaque descriptors would then just be casted integers). This way drivers would only need to depend on GENERIC_GPIO. It's a little bit weird to have gpiod wrapping around gpio in one case and the opposite in another though - I'd rather have these platforms convert to GPIO descriptors internally (or even better, to gpiolib), but this is probably asking too much. I do not know all the details of gpiolib's history, but why would anyone want to implement the generic gpio interface and not use gpiolib anyways? Then there are platforms who do not follow generic gpios and implement their own sauce. I don't think we need to care here, as these are not supposed to be used with generic drivers anyway. If we are adding a new way to deal with GPIOs, would it make sense to have that more closely integrated into pinctrl in one form or another? My feeling is that there is already a significant overlap between the two, and while the addition of the gpiod_* functions doesn't necessarily make this worse, it could be a chance to improve the current situation to make the interface more consistent with pinctrl. That may be a chance to introduce deeper changes indeed - what do you have in mind exactly? Thanks, Alex. -- 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/
[PATCH 0/4] gpio: introduce descriptor-based interface
This series introduce a first take at implementing the RFC for the new GPIO API that I submitted last month. It proposes a new, opaque descriptor-based GPIO API that becomes available when GPIOlib is compiled, and provides a safer, more abstract alternative to the current integer-based interface. GPIOlib internals are also switched to use the descriptor logic, and the former integer API becomes a lightweight wrapper around the new descriptor-based API. Functionally speaking the new API is identical to the integer-based API, with only the prefix changing from gpio_ to gpiod_. However, the second patch introduces new functions for obtaining GPIOs from a device and a consumer name, in a fashion similar to what is done with e.g. regulators and PWMs. GPIOs can then be provided either by board-specific lookup tables, or through the device tree. Device tree lookup might require some attention as it does not handle properties with multiple descriptors yet. Also, there is currently no equivalent of gpio_request_array() and GPIOs can only be allocated one-by-one. Feedback about the relevancy of batch requesting GPIOs is welcome. This patch series also prepares GPIOlib for the next step, which is getting rid of ARCH_NR_GPIOS and of the static array in GPIOlib and replace the latter with per-chip arrays that are allocated when the chip is added. Some challenge may arise from the fact that gpiochip_add is potentially called before kmalloc is available. Anyway, I expect this patchset to go through several iterations in order to address the points mentioned above (and of course the ones I missed). As usual, your valuable feedback is most welcome. Alexandre Courbot (4): gpiolib: introduce descriptor-based GPIO interface gpiolib: add gpiod_get and gpiod_put functions gpiolib: of: convert OF helpers to descriptor API gpiolib: add documentation for new gpiod_ API Documentation/gpio.txt| 94 +- drivers/gpio/devres.c | 59 +++- drivers/gpio/gpiolib-of.c | 26 +- drivers/gpio/gpiolib.c| 648 -- include/asm-generic/gpio.h| 176 include/linux/gpio/consumer.h | 128 + include/linux/gpio/driver.h | 171 +++ include/linux/of_gpio.h | 73 + 8 files changed, 956 insertions(+), 419 deletions(-) create mode 100644 include/linux/gpio/consumer.h create mode 100644 include/linux/gpio/driver.h -- 1.8.1 -- 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/
[PATCH 0/4] gpio: introduce descriptor-based interface
This series introduce a first take at implementing the RFC for the new GPIO API that I submitted last month. It proposes a new, opaque descriptor-based GPIO API that becomes available when GPIOlib is compiled, and provides a safer, more abstract alternative to the current integer-based interface. GPIOlib internals are also switched to use the descriptor logic, and the former integer API becomes a lightweight wrapper around the new descriptor-based API. Functionally speaking the new API is identical to the integer-based API, with only the prefix changing from gpio_ to gpiod_. However, the second patch introduces new functions for obtaining GPIOs from a device and a consumer name, in a fashion similar to what is done with e.g. regulators and PWMs. GPIOs can then be provided either by board-specific lookup tables, or through the device tree. Device tree lookup might require some attention as it does not handle properties with multiple descriptors yet. Also, there is currently no equivalent of gpio_request_array() and GPIOs can only be allocated one-by-one. Feedback about the relevancy of batch requesting GPIOs is welcome. This patch series also prepares GPIOlib for the next step, which is getting rid of ARCH_NR_GPIOS and of the static array in GPIOlib and replace the latter with per-chip arrays that are allocated when the chip is added. Some challenge may arise from the fact that gpiochip_add is potentially called before kmalloc is available. Anyway, I expect this patchset to go through several iterations in order to address the points mentioned above (and of course the ones I missed). As usual, your valuable feedback is most welcome. Alexandre Courbot (4): gpiolib: introduce descriptor-based GPIO interface gpiolib: add gpiod_get and gpiod_put functions gpiolib: of: convert OF helpers to descriptor API gpiolib: add documentation for new gpiod_ API Documentation/gpio.txt| 94 +- drivers/gpio/devres.c | 59 +++- drivers/gpio/gpiolib-of.c | 26 +- drivers/gpio/gpiolib.c| 648 -- include/asm-generic/gpio.h| 176 include/linux/gpio/consumer.h | 128 + include/linux/gpio/driver.h | 171 +++ include/linux/of_gpio.h | 73 + 8 files changed, 956 insertions(+), 419 deletions(-) create mode 100644 include/linux/gpio/consumer.h create mode 100644 include/linux/gpio/driver.h -- 1.8.1 -- 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/
