Is delayed work's precision good enough for input-poller?

Is delayed work's precision good enough for input-poller?

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

Hi everyone,
I just found about an issue in the downstream Raspberry Pi[1] kernel that I
wonder if it'd be worth fixing generally. The official RPi DSI display
touchscreen uses the polled input interface. The ts chip works at around 60Hz,
and that's the period the driver is configured to use (17ms). This doesn't play
too good on systems with low HZ (100/250). Users complain that in practice they
experience, at worst, half the event rate. This is due to the rounding error
when converting milliseconds to jiffies, general system delays, and what not.

We could somewhat fix this in the driver (raspberrypi-ts.c) by playing with the
poll rate. But it seems pretty hacky and would ultimately stress the CPU
unnecessarily. I wonder to what extent it makes sense to move the
implementation to using hrtimers whenever the poll period is in the same order
of magnitude as HZ's delta.

Any ideas/comments?

Regards,
Nicolas

[1] https://github.com/raspberrypi/linux/issues/3777#issuecomment-698346991


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Is delayed work's precision good enough for input-poller?

[Dmitry Torokhov]

Hi Nicolas,

On Thu, Nov 12, 2020 at 04:30:49PM +0100, Nicolas Saenz Julienne wrote:
> Hi everyone,
> I just found about an issue in the downstream Raspberry Pi[1] kernel that I
> wonder if it'd be worth fixing generally. The official RPi DSI display
> touchscreen uses the polled input interface. The ts chip works at around 60Hz,
> and that's the period the driver is configured to use (17ms). This doesn't play
> too good on systems with low HZ (100/250). Users complain that in practice they
> experience, at worst, half the event rate. This is due to the rounding error
> when converting milliseconds to jiffies, general system delays, and what not.
> 
> We could somewhat fix this in the driver (raspberrypi-ts.c) by playing with the
> poll rate. But it seems pretty hacky and would ultimately stress the CPU
> unnecessarily. I wonder to what extent it makes sense to move the
> implementation to using hrtimers whenever the poll period is in the same order
> of magnitude as HZ's delta.
> 
> Any ideas/comments?

The polling function in the poller is supposed to be able to sleep, so
you will still have to schedule work which will introduce additional
delay.

If that works for you then I'd be OK with switching to hrtimers for
small poll intervals.

Thanks.

-- 
Dmitry