Re: [PATCH] mmc: core: Add DT bindings for card detect debounce time

[Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>]

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-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html