Thread (32 messages) 32 messages, 4 authors, 2025-02-26

Re: [PATCH v5 7/7] Input: matrix_keypad - detect change during scan

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2025-02-25 17:46:27
Also in: linux-devicetree, lkml

On Tue, Feb 25, 2025 at 09:51:22AM +0100, Markus Burri wrote:
On Mon, Feb 24, 2025 at 10:58:27PM -0800, Dmitry Torokhov wrote:
quoted
On Wed, Feb 19, 2025 at 05:56:10PM +0100, Manuel Traut wrote:
quoted
On Fri, Jan 10, 2025 at 06:49:06AM +0100, Markus Burri wrote:
quoted
For a setup where the matrix keypad is connected over a slow interface
(e.g. a gpio-expansion over i2c), the scan can take a longer time to read.

Interrupts need to be disabled during scan. And therefore changes in this
period are not detected.
To improve this situation, scan the matrix again if the row state changed
during interrupts disabled.
The rescan is repeated until no change is detected anymore.
This is a quirk for a bad hardware design. For 'good' hardware it adds
an additional read_row_state for no need. For even slower connected
GPIOs this will also not help much. However it is obvious that it will
be an improvement for some designs. 

Dmitry, would it make sense to make this configurable?
What if we do not disable interrupts after the first one, but record
the last interrupt time and rescan if it arrived after work handler
started executing?

Thanks.
I was also thinking about that.
If we do not disable interrupts we will get a lot of interrupts during scan.
The scanning process itself generate interrupts because of selecting the columns
and read row state. Therefore after scan we will not know if the interrupts are
caused by scanning or a change.
OK, then maybe we should keep re-submitting the work until we get to
stable state? My objection is repeating the scan once does not really
solve the issue....

Thanks.

-- 
Dmitry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help