lkml.org 
[lkml]   [2021]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] input: gpio-keys: Use hrtimer for software debounce
Hi Dmitry,

Le ven. 5 mars 2021 à 10:35, Dmitry Torokhov
<dmitry.torokhov@gmail.com> a écrit :
> Hi Paul,
>
> On Fri, Mar 05, 2021 at 05:01:11PM +0000, Paul Cercueil wrote:
>> -static void gpio_keys_gpio_work_func(struct work_struct *work)
>> +static enum hrtimer_restart gpio_keys_debounce_timer(struct
>> hrtimer *t)
>> {
>> - struct gpio_button_data *bdata =
>> - container_of(work, struct gpio_button_data, work.work);
>> + struct gpio_button_data *bdata = container_of(t,
>> + struct gpio_button_data,
>> + debounce_timer);
>>
>> gpio_keys_gpio_report_event(bdata);
>
> I am not sure how this works. As far as I know, even
> HRTIMER_MODE_REL_SOFT do not allow sleeping in the timer handlers, and
> gpio_keys_gpio_report_event() use sleeping variant of GPIOD API (and
> that is not going to change).

Quoting <linux/hrtimers.h>, the "timer callback will be executed in
soft irq context", so sleeping should be possible.

But I guess in this case I can use HRTIMER_MODE_REL.

> It seems to me that if you want to use software debounce in gpio keys
> driver you need to set up sufficiently high HZ for your system. Maybe
> we
> could thrown a warning when we see low debounce delay and low HZ to
> alert system developer.

This is exactly what we should not do. I certainly don't want to have
250+ timer interrupts per second just so that input events aren't lost,
to work around a sucky debounce implementation. Besides, if you
consider the hrtimers doc (Documentation/timers/hrtimers.rst), hrtimers
really are what should be used here.

-Paul


\
 
 \ /
  Last update: 2021-03-05 21:03    [W:0.091 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site