On Mon, Jul 7, 2014 at 8:12 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Sat, Jun 21, 2014 at 9:22 AM, Alexandre Courbot <gnurou@xxxxxxxxx> wrote: > >>> I have added Linus Walleij and Alexandre Courbot, the maintainers of >>> gpio. Let's see if they can point us in a direction. >> >> I agree it would be nice if the debounce value could be handled by the >> GPIO framework. > > I agree too. > >> I just wonder what would be the correct way of doing >> it? Contrary to ACTIVE_LOW and other flags which can be specified with >> the GPIO phandle, debounce is a numeric value. Maybe using a different >> property, e.g.: >> >> cd-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; >> cd-gpios-debounce = <10>; >> >> When looking up a GPIO through gpiod_get(), the GPIO framework could >> then check for -debounce property and set the debounce time >> accordingly. At first sight I'd say that would work and could be used >> for MMC and all other subsystems that need something similar. > > Yes, but we also need to write generic debounce handling into > the gpiolib, so it doesn't matter if the GPIO driver can or cannot > handle this itself. Some hardware has the capability to debounce > lines in *hardware*. > > Right now a call to gpiod_set_debounce() will fail unless the > hardware has a debounce option. > > What we should really do is make gpiod_set_debounce() always > work, put the debounce value into the gpio_desc, and move some > logic similar to what exists in drivers/input/keyboard/gpio_keys.c > into the gpiolib, then get rid of any local implementations like > in gpio_keys. > > Then we can rely on the gpiolib handling this at all times, and also > to get the debounce config from DT. > > Dmitry, opinions on this? I am always happy to hear when common functionality is moved into appropriate layer. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
