Re: [PATCH 3/3] input: gpio-keys: Use hrtimer for software debounce

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dmitry,

Le ven. 5 mars 2021 à 10:35, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> 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





[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux