Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
On Mon, Dec 10, 2012 at 11:37:35AM -0800, anish singh wrote: > On Mon, Dec 10, 2012 at 10:48 AM, Guenter Roeck > wrote: > > On Mon, Dec 10, 2012 at 11:04:09AM +0100, Linus Walleij wrote: > >> On Fri, Dec 7, 2012 at 5:49 PM, Alan Cox wrote: > >> > >> >> I could imagine declaring the activity request buttons to be "input", > >> >> but for > >> >> presence detects it is a bit far fetched and would add too much > >> >> complexity. > >> > > >> > Android tries to address this with its switch class driver, but I'm not > >> > sure its actually got anything over making them input devices. > >> > >> This has actually been merged into the kernel proper as drivers/extcon. > >> > >> So another poke on Günther if this fulfills the needs? > >> > > I'll look into it. Currently I am hampered by a cold which seems to mug my > > brain, and technically by the need to backport extcon to 3.0 (if that is > > even > > possible) since our chip vendor does not yet support a more recent kernel. > It is very much possible.I have already tried that and it works. Confirmed. Looks like this is going to work for me, so I won't need the gpio patch. Please ignore it. Thanks, Guenter -- 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] gpio: export 'debounce' attribute if supported by the gpio chip
On Mon, Dec 10, 2012 at 10:48 AM, Guenter Roeck wrote: > On Mon, Dec 10, 2012 at 11:04:09AM +0100, Linus Walleij wrote: >> On Fri, Dec 7, 2012 at 5:49 PM, Alan Cox wrote: >> >> >> I could imagine declaring the activity request buttons to be "input", but >> >> for >> >> presence detects it is a bit far fetched and would add too much >> >> complexity. >> > >> > Android tries to address this with its switch class driver, but I'm not >> > sure its actually got anything over making them input devices. >> >> This has actually been merged into the kernel proper as drivers/extcon. >> >> So another poke on Günther if this fulfills the needs? >> > I'll look into it. Currently I am hampered by a cold which seems to mug my > brain, and technically by the need to backport extcon to 3.0 (if that is even > possible) since our chip vendor does not yet support a more recent kernel. It is very much possible.I have already tried that and it works. > > Thanks, > Guenter > -- > 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/
Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
On Mon, Dec 10, 2012 at 11:04:09AM +0100, Linus Walleij wrote: > On Fri, Dec 7, 2012 at 5:49 PM, Alan Cox wrote: > > >> I could imagine declaring the activity request buttons to be "input", but > >> for > >> presence detects it is a bit far fetched and would add too much complexity. > > > > Android tries to address this with its switch class driver, but I'm not > > sure its actually got anything over making them input devices. > > This has actually been merged into the kernel proper as drivers/extcon. > > So another poke on Günther if this fulfills the needs? > I'll look into it. Currently I am hampered by a cold which seems to mug my brain, and technically by the need to backport extcon to 3.0 (if that is even possible) since our chip vendor does not yet support a more recent kernel. Thanks, Guenter -- 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] gpio: export 'debounce' attribute if supported by the gpio chip
On Sun, Dec 9, 2012 at 6:07 PM, Guenter Roeck wrote: > The gpio pins I am dealing with are provided by an FPGA which is used on > various > boards. While the gpio access registers are always the same, the actual usage > is > board specific. This means I either need to write ugly code, or use the gpio > subsystem to provide access to the gpio pins. Ugly code is out of the > question, > which means I'll need gpio support. > > Anyway, I want to keep things simple, not add unnecessary complexity. Having > to > go through the input subsystem just to be able to support debounce on a couple > of input pins doesn't really sound simple. Guess I'll have to find another > solution if the patch is not accepted. Maybe I'll add a "debounce" property to > the gpio driver's of properties. I would like you to seriously consider both gpio-input and the new drivers/extcon/extcon-gpio.c driver (maybe adding debounce into that driver). The latter also has a sysfs interface. Your usecases seem to be EXTCON_MECHANICAL. If not, new classes can surely be added. There is some risk that sysfs makes everything that is a GPIO line appear as GPIO instead of what it really is, which is not helpful for userspace which will have to keep track of all the routing of the electronics. The latter might be comfortable if you're designing and maintaining the whole system with firmware and so on, but from a newcomer examining the system in sysfs it's not helpful, and we're designing that ABI for a purpose. (And I share Grant's hesitant stance on extending the GPIO sysfs.) 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] gpio: export 'debounce' attribute if supported by the gpio chip
On Fri, Dec 7, 2012 at 5:49 PM, Alan Cox wrote: >> I could imagine declaring the activity request buttons to be "input", but for >> presence detects it is a bit far fetched and would add too much complexity. > > Android tries to address this with its switch class driver, but I'm not > sure its actually got anything over making them input devices. This has actually been merged into the kernel proper as drivers/extcon. So another poke on Günther if this fulfills the needs? 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] gpio: export 'debounce' attribute if supported by the gpio chip
On Sun, Dec 9, 2012 at 5:07 PM, Guenter Roeck wrote: > On Sun, Dec 09, 2012 at 11:03:19AM +, Alan Cox wrote: >> On Sun, 09 Dec 2012 01:58:19 -0800 >> anish kumar wrote: >> >> > On Fri, 2012-12-07 at 16:49 +, Alan Cox wrote: >> > > > I could imagine declaring the activity request buttons to be "input", >> > > > but for >> > > > presence detects it is a bit far fetched and would add too much >> > > > complexity. >> > > >> > > Android tries to address this with its switch class driver, but I'm not >> > > sure its actually got anything over making them input devices. >> > >> > Sorry for not understanding the context here.How the debounce sysfs >> > added by Guenter has anything to do with switch driver in android? >> >> The other more general option is to make the input layer do the debounce >> and make them all inputs rather than just relying on any gpio layer >> support. >> > The gpio pins I am dealing with are provided by an FPGA which is used on > various > boards. While the gpio access registers are always the same, the actual usage > is > board specific. This means I either need to write ugly code, or use the gpio > subsystem to provide access to the gpio pins. Ugly code is out of the > question, > which means I'll need gpio support. > > Anyway, I want to keep things simple, not add unnecessary complexity. Having > to > go through the input subsystem just to be able to support debounce on a couple > of input pins doesn't really sound simple. Guess I'll have to find another > solution if the patch is not accepted. Maybe I'll add a "debounce" property to > the gpio driver's of properties. I haven't looked deeply at the patch to give you an answer yet, but I'd recommend you go with the DT property approach anyway. The gpio sysfs interface is horribly designed and I'm not keen on adding new features to it. g. -- 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] gpio: export 'debounce' attribute if supported by the gpio chip
On Sun, Dec 09, 2012 at 11:03:19AM +, Alan Cox wrote: > On Sun, 09 Dec 2012 01:58:19 -0800 > anish kumar wrote: > > > On Fri, 2012-12-07 at 16:49 +, Alan Cox wrote: > > > > I could imagine declaring the activity request buttons to be "input", > > > > but for > > > > presence detects it is a bit far fetched and would add too much > > > > complexity. > > > > > > Android tries to address this with its switch class driver, but I'm not > > > sure its actually got anything over making them input devices. > > > > Sorry for not understanding the context here.How the debounce sysfs > > added by Guenter has anything to do with switch driver in android? > > The other more general option is to make the input layer do the debounce > and make them all inputs rather than just relying on any gpio layer > support. > The gpio pins I am dealing with are provided by an FPGA which is used on various boards. While the gpio access registers are always the same, the actual usage is board specific. This means I either need to write ugly code, or use the gpio subsystem to provide access to the gpio pins. Ugly code is out of the question, which means I'll need gpio support. Anyway, I want to keep things simple, not add unnecessary complexity. Having to go through the input subsystem just to be able to support debounce on a couple of input pins doesn't really sound simple. Guess I'll have to find another solution if the patch is not accepted. Maybe I'll add a "debounce" property to the gpio driver's of properties. Thanks, Guenter -- 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] gpio: export 'debounce' attribute if supported by the gpio chip
On Sun, 09 Dec 2012 01:58:19 -0800 anish kumar wrote: > On Fri, 2012-12-07 at 16:49 +, Alan Cox wrote: > > > I could imagine declaring the activity request buttons to be "input", but > > > for > > > presence detects it is a bit far fetched and would add too much > > > complexity. > > > > Android tries to address this with its switch class driver, but I'm not > > sure its actually got anything over making them input devices. > > Sorry for not understanding the context here.How the debounce sysfs > added by Guenter has anything to do with switch driver in android? The other more general option is to make the input layer do the debounce and make them all inputs rather than just relying on any gpio layer support. -- 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] gpio: export 'debounce' attribute if supported by the gpio chip
On Fri, 2012-12-07 at 16:49 +, Alan Cox wrote: > > I could imagine declaring the activity request buttons to be "input", but > > for > > presence detects it is a bit far fetched and would add too much complexity. > > Android tries to address this with its switch class driver, but I'm not > sure its actually got anything over making them input devices. Sorry for not understanding the context here.How the debounce sysfs added by Guenter has anything to do with switch driver in android? AFAIK android just uses switch driver api to talk to driver to get the status of the headset and the status of the keys if headset has any.This API in turn updates the sysfs to let userspace know the status change using kobject uevent. Switch driver is replaced by extcon in the mainline. > > Alan > -- > 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/
Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
> I could imagine declaring the activity request buttons to be "input", but for > presence detects it is a bit far fetched and would add too much complexity. Android tries to address this with its switch class driver, but I'm not sure its actually got anything over making them input devices. Alan -- 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] gpio: export 'debounce' attribute if supported by the gpio chip
On Fri, Dec 07, 2012 at 06:59:55AM -0800, Guenter Roeck wrote: > On Fri, Dec 07, 2012 at 09:07:28AM +0100, Linus Walleij wrote: > > On Thu, Dec 6, 2012 at 7:32 AM, Guenter Roeck wrote: > > > > > Create a 'debounce' attribute if debounce is supported by the gpio > > > chip and a gpio pin is exported. > > > > > > Signed-off-by: Guenter Roeck > > > > Can you describe the usecase for this? > > > > I have this problem when working as a back-up GPIO maintainer that > > I don't really understand the userspace apps doing this. > > > > I would guess something like a userspace app reading a GPIO switch > > and needing to set this to avoid key bounces, but it'd be nice to know > > if this is really the case. > > > Yes, that is one if the use cases. Button pressed on the chassis/board > requesting user space action. Another is board presence detect pins which > require rebounce support and are handled in user space. Yes, the later should > be > handled in the kernel, and most of them are, but there are some which don't > need > immediate kernel activity and are handled completely by applications. > > There may be other use cases - there are hundreds of gpio pins in the system I > am working on, and I have not looked into all of them. > There are three use cases, all related to each other. - board present (connector pin) - board removal request (button) - board voltage good (connector pin) Guenter > > If this is the usecase I am slightly concerned why these are not used: > > drivers/input/keyboard/gpio_keys_polled.c > > drivers/input/keyboard/gpio_keys.c > > > > The latter even uses the in-kernel debounce interface. > > > > I'd agree if this is not user input at all but something like a switch > > in a factory production line. > > > I could imagine declaring the activity request buttons to be "input", but for > presence detects it is a bit far fetched and would add too much complexity. > > Thanks, > Guenter > -- 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] gpio: export 'debounce' attribute if supported by the gpio chip
On Fri, Dec 07, 2012 at 09:07:28AM +0100, Linus Walleij wrote: > On Thu, Dec 6, 2012 at 7:32 AM, Guenter Roeck wrote: > > > Create a 'debounce' attribute if debounce is supported by the gpio > > chip and a gpio pin is exported. > > > > Signed-off-by: Guenter Roeck > > Can you describe the usecase for this? > > I have this problem when working as a back-up GPIO maintainer that > I don't really understand the userspace apps doing this. > > I would guess something like a userspace app reading a GPIO switch > and needing to set this to avoid key bounces, but it'd be nice to know > if this is really the case. > Yes, that is one if the use cases. Button pressed on the chassis/board requesting user space action. Another is board presence detect pins which require rebounce support and are handled in user space. Yes, the later should be handled in the kernel, and most of them are, but there are some which don't need immediate kernel activity and are handled completely by applications. There may be other use cases - there are hundreds of gpio pins in the system I am working on, and I have not looked into all of them. > If this is the usecase I am slightly concerned why these are not used: > drivers/input/keyboard/gpio_keys_polled.c > drivers/input/keyboard/gpio_keys.c > > The latter even uses the in-kernel debounce interface. > > I'd agree if this is not user input at all but something like a switch > in a factory production line. > I could imagine declaring the activity request buttons to be "input", but for presence detects it is a bit far fetched and would add too much complexity. Thanks, Guenter -- 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] gpio: export 'debounce' attribute if supported by the gpio chip
On Thu, Dec 6, 2012 at 7:32 AM, Guenter Roeck wrote: > Create a 'debounce' attribute if debounce is supported by the gpio > chip and a gpio pin is exported. > > Signed-off-by: Guenter Roeck Can you describe the usecase for this? I have this problem when working as a back-up GPIO maintainer that I don't really understand the userspace apps doing this. I would guess something like a userspace app reading a GPIO switch and needing to set this to avoid key bounces, but it'd be nice to know if this is really the case. If this is the usecase I am slightly concerned why these are not used: drivers/input/keyboard/gpio_keys_polled.c drivers/input/keyboard/gpio_keys.c The latter even uses the in-kernel debounce interface. I'd agree if this is not user input at all but something like a switch in a factory production line. So please help me understand this. 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/
