* [PATCH v2 0/2] input: add GPIO-based charlieplex keypad @ 2026-02-13 17:14 Hugo Villeneuve 2026-02-13 17:14 ` [PATCH v2 1/2] dt-bindings: input: add GPIO " Hugo Villeneuve 2026-02-13 17:14 ` [PATCH v2 2/2] Input: charlieplex_keypad: " Hugo Villeneuve 0 siblings, 2 replies; 10+ messages in thread From: Hugo Villeneuve @ 2026-02-13 17:14 UTC (permalink / raw) To: hvilleneuve, dmitry.torokhov, robh, krzk+dt, conor+dt Cc: linux-input, devicetree, linux-kernel, hugo From: Hugo Villeneuve <hvilleneuve@dimonoff.com> Hello, this patch series add a new GPIO charlieplex keypad driver. I have tested the driver on a custom board with a Solidrun RZ/G2LC SOM with three charlieplex keyboards, all connected thru a a PCA9416 I2C GPIO expander. Link: [v1] https://lore.kernel.org/linux-serial/20250924153740.806444-1-hugo@hugovil.com/raw Changes for v2: - Fix yamllint error for example - Remove unused debug variable (nkeys) - Remove support for custom linux,no-autorepeat DT property - Remove support for custom gpio-activelow DT property Thank you. Hugo Villeneuve (2): dt-bindings: input: add GPIO charlieplex keypad Input: charlieplex_keypad: add GPIO charlieplex keypad .../input/gpio-charlieplex-keypad.yaml | 82 +++++++ MAINTAINERS | 7 + drivers/input/keyboard/Kconfig | 14 ++ drivers/input/keyboard/Makefile | 1 + drivers/input/keyboard/charlieplex_keypad.c | 213 ++++++++++++++++++ 5 files changed, 317 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml create mode 100644 drivers/input/keyboard/charlieplex_keypad.c base-commit: ed8a4ef29da3821ee3155d3b1925fa67fc92aae2 -- 2.47.3 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad 2026-02-13 17:14 [PATCH v2 0/2] input: add GPIO-based charlieplex keypad Hugo Villeneuve @ 2026-02-13 17:14 ` Hugo Villeneuve 2026-02-23 17:57 ` Rob Herring 2026-02-13 17:14 ` [PATCH v2 2/2] Input: charlieplex_keypad: " Hugo Villeneuve 1 sibling, 1 reply; 10+ messages in thread From: Hugo Villeneuve @ 2026-02-13 17:14 UTC (permalink / raw) To: hvilleneuve, dmitry.torokhov, robh, krzk+dt, conor+dt Cc: linux-input, devicetree, linux-kernel, hugo From: Hugo Villeneuve <hvilleneuve@dimonoff.com> Add DT bindings for GPIO charlieplex keypad. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> --- .../input/gpio-charlieplex-keypad.yaml | 82 +++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml new file mode 100644 index 0000000000000..1672491a75a85 --- /dev/null +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO charlieplex keypad + +maintainers: + - Hugo Villeneuve <hvilleneuve@dimonoff.com> + +description: + The charlieplex keypad supports N^2)-N different key combinations (where N is + the number of lines). Key presses and releases are detected by configuring + only one line as output at a time, and reading other line states. This process + is repeated for each line. + This mechanism doesn't allow to detect simultaneous key presses. + +allOf: + - $ref: input.yaml# + - $ref: /schemas/input/matrix-keymap.yaml# + +properties: + compatible: + const: gpio-charlieplex-keypad + + autorepeat: true + + line-scan-delay-us: + description: + Delay, measured in microseconds, that is needed + before we can scan keypad after activating one line. + default: 0 + + line-gpios: + description: + List of GPIOs used as lines. The gpio specifier for this property + depends on the gpio controller to which these lines are connected. + + linux,keymap: true + + debounce-delay-ms: + description: Debounce interval in milliseconds. + default: 5 + + poll-interval: true + + wakeup-source: true + +required: + - compatible + - line-gpios + - linux,keymap + - poll-interval + +additionalProperties: false + +examples: + - | + #include <dt-bindings/input/input.h> + + charlieplex-keypad { + compatible = "gpio-charlieplex-keypad"; + debounce-delay-ms = <20>; + poll-interval = <5>; + line-scan-delay-us = <2>; + + line-gpios = <&gpio2 25 0 + &gpio2 26 0 + &gpio2 27 0>; + + /* MATRIX_KEY(output, input, key-code) */ + linux,keymap = < + MATRIX_KEY(0, 1, KEY_F1) + MATRIX_KEY(0, 2, KEY_F2) + MATRIX_KEY(1, 0, KEY_F3) + MATRIX_KEY(1, 2, KEY_F4) + MATRIX_KEY(2, 0, KEY_F5) + MATRIX_KEY(2, 1, KEY_F6) + >; + }; -- 2.47.3 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad 2026-02-13 17:14 ` [PATCH v2 1/2] dt-bindings: input: add GPIO " Hugo Villeneuve @ 2026-02-23 17:57 ` Rob Herring 2026-02-23 18:47 ` Hugo Villeneuve 0 siblings, 1 reply; 10+ messages in thread From: Rob Herring @ 2026-02-23 17:57 UTC (permalink / raw) To: Hugo Villeneuve Cc: hvilleneuve, dmitry.torokhov, krzk+dt, conor+dt, linux-input, devicetree, linux-kernel On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote: > From: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > Add DT bindings for GPIO charlieplex keypad. > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> > --- > .../input/gpio-charlieplex-keypad.yaml | 82 +++++++++++++++++++ > 1 file changed, 82 insertions(+) > create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > new file mode 100644 > index 0000000000000..1672491a75a85 > --- /dev/null > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > @@ -0,0 +1,82 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > + > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: GPIO charlieplex keypad > + > +maintainers: > + - Hugo Villeneuve <hvilleneuve@dimonoff.com> > + > +description: > + The charlieplex keypad supports N^2)-N different key combinations (where N is > + the number of lines). Key presses and releases are detected by configuring > + only one line as output at a time, and reading other line states. This process > + is repeated for each line. > + This mechanism doesn't allow to detect simultaneous key presses. > + > +allOf: > + - $ref: input.yaml# > + - $ref: /schemas/input/matrix-keymap.yaml# > + > +properties: > + compatible: > + const: gpio-charlieplex-keypad > + > + autorepeat: true > + > + line-scan-delay-us: > + description: > + Delay, measured in microseconds, that is needed > + before we can scan keypad after activating one line. > + default: 0 Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml? If so, move it to matrix-keymap.yaml to re-use it here. If not, there's a bunch of other scan delay properties just from grepping "delay" in the input bindings. Surely we can define something common. Rob ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad 2026-02-23 17:57 ` Rob Herring @ 2026-02-23 18:47 ` Hugo Villeneuve 2026-02-23 23:23 ` Rob Herring 0 siblings, 1 reply; 10+ messages in thread From: Hugo Villeneuve @ 2026-02-23 18:47 UTC (permalink / raw) To: Rob Herring Cc: hvilleneuve, dmitry.torokhov, krzk+dt, conor+dt, linux-input, devicetree, linux-kernel Hi Rob, On Mon, 23 Feb 2026 11:57:06 -0600 Rob Herring <robh@kernel.org> wrote: > On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote: > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > Add DT bindings for GPIO charlieplex keypad. > > > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > --- > > .../input/gpio-charlieplex-keypad.yaml | 82 +++++++++++++++++++ > > 1 file changed, 82 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > new file mode 100644 > > index 0000000000000..1672491a75a85 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > @@ -0,0 +1,82 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > + > > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: GPIO charlieplex keypad > > + > > +maintainers: > > + - Hugo Villeneuve <hvilleneuve@dimonoff.com> > > + > > +description: > > + The charlieplex keypad supports N^2)-N different key combinations (where N is > > + the number of lines). Key presses and releases are detected by configuring > > + only one line as output at a time, and reading other line states. This process > > + is repeated for each line. > > + This mechanism doesn't allow to detect simultaneous key presses. > > + > > +allOf: > > + - $ref: input.yaml# > > + - $ref: /schemas/input/matrix-keymap.yaml# > > + > > +properties: > > + compatible: > > + const: gpio-charlieplex-keypad > > + > > + autorepeat: true > > + > > + line-scan-delay-us: > > + description: > > + Delay, measured in microseconds, that is needed > > + before we can scan keypad after activating one line. > > + default: 0 > > Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml? > If so, move it to matrix-keymap.yaml to re-use it here. It is used in a similar fashion, but for charlieplex keyboard, there is no concept of "rows" and "columns". There are only lines, which are all equivalent in functionality. > If not, there's a bunch of other scan delay properties just from > grepping "delay" in the input bindings. Surely we can define something > common. Most of those delays refer to something quite different than what "col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay that we wait when activating a GPIO before we can safely/reliably read other GPIOs connected thru its circuitry). Maybe "col-scan-delay-us" and "line-scan-delay-us" could be combined into a common "line-scan-delay-us" ("line" is more generic than column), and defined in matrix-keymap.yaml. Then would it be ok to remove "col-scan-delay-us" from gpio-matrix-keypad.yaml and use "line-scan-delay-us" (ABI change) ? Hugo. -- Hugo Villeneuve <hugo@hugovil.com> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad 2026-02-23 18:47 ` Hugo Villeneuve @ 2026-02-23 23:23 ` Rob Herring 2026-02-24 20:40 ` Hugo Villeneuve 0 siblings, 1 reply; 10+ messages in thread From: Rob Herring @ 2026-02-23 23:23 UTC (permalink / raw) To: Hugo Villeneuve Cc: hvilleneuve, dmitry.torokhov, krzk+dt, conor+dt, linux-input, devicetree, linux-kernel On Mon, Feb 23, 2026 at 12:47 PM Hugo Villeneuve <hugo@hugovil.com> wrote: > > Hi Rob, > > On Mon, 23 Feb 2026 11:57:06 -0600 > Rob Herring <robh@kernel.org> wrote: > > > On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote: > > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > > > Add DT bindings for GPIO charlieplex keypad. > > > > > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > --- > > > .../input/gpio-charlieplex-keypad.yaml | 82 +++++++++++++++++++ > > > 1 file changed, 82 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > new file mode 100644 > > > index 0000000000000..1672491a75a85 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > @@ -0,0 +1,82 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > + > > > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: GPIO charlieplex keypad > > > + > > > +maintainers: > > > + - Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > + > > > +description: > > > + The charlieplex keypad supports N^2)-N different key combinations (where N is > > > + the number of lines). Key presses and releases are detected by configuring > > > + only one line as output at a time, and reading other line states. This process > > > + is repeated for each line. > > > + This mechanism doesn't allow to detect simultaneous key presses. > > > + > > > +allOf: > > > + - $ref: input.yaml# > > > + - $ref: /schemas/input/matrix-keymap.yaml# > > > + > > > +properties: > > > + compatible: > > > + const: gpio-charlieplex-keypad > > > + > > > + autorepeat: true > > > + > > > + line-scan-delay-us: > > > + description: > > > + Delay, measured in microseconds, that is needed > > > + before we can scan keypad after activating one line. > > > + default: 0 > > > > Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml? > > If so, move it to matrix-keymap.yaml to re-use it here. > > It is used in a similar fashion, but for charlieplex keyboard, there is > no concept of "rows" and "columns". There are only > lines, which are all equivalent in functionality. > > > If not, there's a bunch of other scan delay properties just from > > grepping "delay" in the input bindings. Surely we can define something > > common. > > Most of those delays refer to something quite different than what > "col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay > that we wait when activating a GPIO before we can safely/reliably read > other GPIOs connected thru its circuitry). > > Maybe "col-scan-delay-us" and "line-scan-delay-us" could be > combined into a common "line-scan-delay-us" ("line" is more generic > than column), and defined in matrix-keymap.yaml. What about "scan-delay-us"? I would assume all the scan delay properties are just the delay after changing the outputs to reading the inputs. > Then would it be ok to remove "col-scan-delay-us" from > gpio-matrix-keypad.yaml and use "line-scan-delay-us" (ABI change) ? No! Rob ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad 2026-02-23 23:23 ` Rob Herring @ 2026-02-24 20:40 ` Hugo Villeneuve 2026-02-24 21:06 ` Rob Herring 0 siblings, 1 reply; 10+ messages in thread From: Hugo Villeneuve @ 2026-02-24 20:40 UTC (permalink / raw) To: Rob Herring Cc: hvilleneuve, dmitry.torokhov, krzk+dt, conor+dt, linux-input, devicetree, linux-kernel Hi Rob, On Mon, 23 Feb 2026 17:23:33 -0600 Rob Herring <robh@kernel.org> wrote: > On Mon, Feb 23, 2026 at 12:47 PM Hugo Villeneuve <hugo@hugovil.com> wrote: > > > > Hi Rob, > > > > On Mon, 23 Feb 2026 11:57:06 -0600 > > Rob Herring <robh@kernel.org> wrote: > > > > > On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote: > > > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > > > > > Add DT bindings for GPIO charlieplex keypad. > > > > > > > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > --- > > > > .../input/gpio-charlieplex-keypad.yaml | 82 +++++++++++++++++++ > > > > 1 file changed, 82 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > new file mode 100644 > > > > index 0000000000000..1672491a75a85 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > @@ -0,0 +1,82 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > + > > > > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: GPIO charlieplex keypad > > > > + > > > > +maintainers: > > > > + - Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > + > > > > +description: > > > > + The charlieplex keypad supports N^2)-N different key combinations (where N is > > > > + the number of lines). Key presses and releases are detected by configuring > > > > + only one line as output at a time, and reading other line states. This process > > > > + is repeated for each line. > > > > + This mechanism doesn't allow to detect simultaneous key presses. > > > > + > > > > +allOf: > > > > + - $ref: input.yaml# > > > > + - $ref: /schemas/input/matrix-keymap.yaml# > > > > + > > > > +properties: > > > > + compatible: > > > > + const: gpio-charlieplex-keypad > > > > + > > > > + autorepeat: true > > > > + > > > > + line-scan-delay-us: > > > > + description: > > > > + Delay, measured in microseconds, that is needed > > > > + before we can scan keypad after activating one line. > > > > + default: 0 > > > > > > Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml? > > > If so, move it to matrix-keymap.yaml to re-use it here. > > > > It is used in a similar fashion, but for charlieplex keyboard, there is > > no concept of "rows" and "columns". There are only > > lines, which are all equivalent in functionality. > > > > > If not, there's a bunch of other scan delay properties just from > > > grepping "delay" in the input bindings. Surely we can define something > > > common. > > > > Most of those delays refer to something quite different than what > > "col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay > > that we wait when activating a GPIO before we can safely/reliably read > > other GPIOs connected thru its circuitry). > > > > Maybe "col-scan-delay-us" and "line-scan-delay-us" could be > > combined into a common "line-scan-delay-us" ("line" is more generic > > than column), and defined in matrix-keymap.yaml. > > What about "scan-delay-us"? I would assume all the scan delay > properties are just the delay after changing the outputs to reading > the inputs. They are for gpio-matrix-keypad.yaml and this binding, but not for others. Most scan delay properties refer to the period or interval between successive scans. So for my binding, "settling-time-us" would be more accurate and a better property name (it is also used in adc.yaml). Looking into a common place to define this new property, I stumbled upon gpio-delay.yaml, so maybe I do not need this new property at all and simply define a gpio-delay node if needed (and add it to this binding example)? I tested this and it works, although it requires a patch to the gpio-aggregator driver, because for now it respect the delay only when changing the output value, not when switching between input and output like I do in my driver. With my patch, it works ok. > > Then would it be ok to remove "col-scan-delay-us" from > > gpio-matrix-keypad.yaml and use "line-scan-delay-us" (ABI change) ? > > No! > > Rob -- Hugo Villeneuve ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad 2026-02-24 20:40 ` Hugo Villeneuve @ 2026-02-24 21:06 ` Rob Herring 2026-02-24 22:32 ` Hugo Villeneuve 0 siblings, 1 reply; 10+ messages in thread From: Rob Herring @ 2026-02-24 21:06 UTC (permalink / raw) To: Hugo Villeneuve Cc: hvilleneuve, dmitry.torokhov, krzk+dt, conor+dt, linux-input, devicetree, linux-kernel On Tue, Feb 24, 2026 at 2:40 PM Hugo Villeneuve <hugo@hugovil.com> wrote: > > Hi Rob, > > On Mon, 23 Feb 2026 17:23:33 -0600 > Rob Herring <robh@kernel.org> wrote: > > > On Mon, Feb 23, 2026 at 12:47 PM Hugo Villeneuve <hugo@hugovil.com> wrote: > > > > > > Hi Rob, > > > > > > On Mon, 23 Feb 2026 11:57:06 -0600 > > > Rob Herring <robh@kernel.org> wrote: > > > > > > > On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote: > > > > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > > > > > > > Add DT bindings for GPIO charlieplex keypad. > > > > > > > > > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > > --- > > > > > .../input/gpio-charlieplex-keypad.yaml | 82 +++++++++++++++++++ > > > > > 1 file changed, 82 insertions(+) > > > > > create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > > new file mode 100644 > > > > > index 0000000000000..1672491a75a85 > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > > @@ -0,0 +1,82 @@ > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > +%YAML 1.2 > > > > > +--- > > > > > + > > > > > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml# > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > + > > > > > +title: GPIO charlieplex keypad > > > > > + > > > > > +maintainers: > > > > > + - Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > > + > > > > > +description: > > > > > + The charlieplex keypad supports N^2)-N different key combinations (where N is > > > > > + the number of lines). Key presses and releases are detected by configuring > > > > > + only one line as output at a time, and reading other line states. This process > > > > > + is repeated for each line. > > > > > + This mechanism doesn't allow to detect simultaneous key presses. > > > > > + > > > > > +allOf: > > > > > + - $ref: input.yaml# > > > > > + - $ref: /schemas/input/matrix-keymap.yaml# > > > > > + > > > > > +properties: > > > > > + compatible: > > > > > + const: gpio-charlieplex-keypad > > > > > + > > > > > + autorepeat: true > > > > > + > > > > > + line-scan-delay-us: > > > > > + description: > > > > > + Delay, measured in microseconds, that is needed > > > > > + before we can scan keypad after activating one line. > > > > > + default: 0 > > > > > > > > Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml? > > > > If so, move it to matrix-keymap.yaml to re-use it here. > > > > > > It is used in a similar fashion, but for charlieplex keyboard, there is > > > no concept of "rows" and "columns". There are only > > > lines, which are all equivalent in functionality. > > > > > > > If not, there's a bunch of other scan delay properties just from > > > > grepping "delay" in the input bindings. Surely we can define something > > > > common. > > > > > > Most of those delays refer to something quite different than what > > > "col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay > > > that we wait when activating a GPIO before we can safely/reliably read > > > other GPIOs connected thru its circuitry). > > > > > > Maybe "col-scan-delay-us" and "line-scan-delay-us" could be > > > combined into a common "line-scan-delay-us" ("line" is more generic > > > than column), and defined in matrix-keymap.yaml. > > > > What about "scan-delay-us"? I would assume all the scan delay > > properties are just the delay after changing the outputs to reading > > the inputs. > > They are for gpio-matrix-keypad.yaml and this binding, but not for > others. Most scan delay properties refer to the period or > interval between successive scans. > > So for my binding, "settling-time-us" would be more accurate and a > better property name (it is also used in adc.yaml). Let's go with that. > > Looking into a common place to define this new property, I stumbled > upon gpio-delay.yaml, so maybe I do not need this new property at all > and simply define a gpio-delay node if needed (and add it to this > binding example)? > > I tested this and it works, although it requires a patch to the > gpio-aggregator driver, because for now it respect the delay only > when changing the output value, not when switching between input and > output like I do in my driver. > > With my patch, it works ok. I would not use gpio-delay here. Rob ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad 2026-02-24 21:06 ` Rob Herring @ 2026-02-24 22:32 ` Hugo Villeneuve 2026-02-24 22:36 ` Rob Herring 0 siblings, 1 reply; 10+ messages in thread From: Hugo Villeneuve @ 2026-02-24 22:32 UTC (permalink / raw) To: Rob Herring Cc: hvilleneuve, dmitry.torokhov, krzk+dt, conor+dt, linux-input, devicetree, linux-kernel On Tue, 24 Feb 2026 15:06:40 -0600 Rob Herring <robh@kernel.org> wrote: > On Tue, Feb 24, 2026 at 2:40 PM Hugo Villeneuve <hugo@hugovil.com> wrote: > > > > Hi Rob, > > > > On Mon, 23 Feb 2026 17:23:33 -0600 > > Rob Herring <robh@kernel.org> wrote: > > > > > On Mon, Feb 23, 2026 at 12:47 PM Hugo Villeneuve <hugo@hugovil.com> wrote: > > > > > > > > Hi Rob, > > > > > > > > On Mon, 23 Feb 2026 11:57:06 -0600 > > > > Rob Herring <robh@kernel.org> wrote: > > > > > > > > > On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote: > > > > > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > > > > > > > > > Add DT bindings for GPIO charlieplex keypad. > > > > > > > > > > > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > > > --- > > > > > > .../input/gpio-charlieplex-keypad.yaml | 82 +++++++++++++++++++ > > > > > > 1 file changed, 82 insertions(+) > > > > > > create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > > > new file mode 100644 > > > > > > index 0000000000000..1672491a75a85 > > > > > > --- /dev/null > > > > > > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > > > @@ -0,0 +1,82 @@ > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > > +%YAML 1.2 > > > > > > +--- > > > > > > + > > > > > > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml# > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > + > > > > > > +title: GPIO charlieplex keypad > > > > > > + > > > > > > +maintainers: > > > > > > + - Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > > > + > > > > > > +description: > > > > > > + The charlieplex keypad supports N^2)-N different key combinations (where N is > > > > > > + the number of lines). Key presses and releases are detected by configuring > > > > > > + only one line as output at a time, and reading other line states. This process > > > > > > + is repeated for each line. > > > > > > + This mechanism doesn't allow to detect simultaneous key presses. > > > > > > + > > > > > > +allOf: > > > > > > + - $ref: input.yaml# > > > > > > + - $ref: /schemas/input/matrix-keymap.yaml# > > > > > > + > > > > > > +properties: > > > > > > + compatible: > > > > > > + const: gpio-charlieplex-keypad > > > > > > + > > > > > > + autorepeat: true > > > > > > + > > > > > > + line-scan-delay-us: > > > > > > + description: > > > > > > + Delay, measured in microseconds, that is needed > > > > > > + before we can scan keypad after activating one line. > > > > > > + default: 0 > > > > > > > > > > Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml? > > > > > If so, move it to matrix-keymap.yaml to re-use it here. > > > > > > > > It is used in a similar fashion, but for charlieplex keyboard, there is > > > > no concept of "rows" and "columns". There are only > > > > lines, which are all equivalent in functionality. > > > > > > > > > If not, there's a bunch of other scan delay properties just from > > > > > grepping "delay" in the input bindings. Surely we can define something > > > > > common. > > > > > > > > Most of those delays refer to something quite different than what > > > > "col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay > > > > that we wait when activating a GPIO before we can safely/reliably read > > > > other GPIOs connected thru its circuitry). > > > > > > > > Maybe "col-scan-delay-us" and "line-scan-delay-us" could be > > > > combined into a common "line-scan-delay-us" ("line" is more generic > > > > than column), and defined in matrix-keymap.yaml. > > > > > > What about "scan-delay-us"? I would assume all the scan delay > > > properties are just the delay after changing the outputs to reading > > > the inputs. > > > > They are for gpio-matrix-keypad.yaml and this binding, but not for > > others. Most scan delay properties refer to the period or > > interval between successive scans. > > > > So for my binding, "settling-time-us" would be more accurate and a > > better property name (it is also used in adc.yaml). > > Let's go with that. Ok, will do. > > > > > Looking into a common place to define this new property, I stumbled > > upon gpio-delay.yaml, so maybe I do not need this new property at all > > and simply define a gpio-delay node if needed (and add it to this > > binding example)? > > > > I tested this and it works, although it requires a patch to the > > gpio-aggregator driver, because for now it respect the delay only > > when changing the output value, not when switching between input and > > output like I do in my driver. > > > > With my patch, it works ok. > > I would not use gpio-delay here. Ok. I also observed that debounce-delay-ms is re-defined by a few bindings, including mine. I assume that I could move all these identical definitions to input.yaml and reduce duplication (in a separate patch, of course). While testing that, I found an odd situation: if I reference these four dummy (undefined anywhere) properties in the gpio-matrix-keypad binding, I am expecting four warnings when validating it. However I get just three: ================== diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml index 20b5371fa21c..733458bf4d13 100644 --- a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml +++ b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml @@ -36,7 +36,10 @@ properties: linux,keymap: true + bogus1-delay-ms: true + bogus2-delay-ms-bogus2: true + bogus3-my-property: true + bogus4: true linux,no-autorepeat: type: boolean ================== Validation result: ... SCHEMA Documentation/devicetree/bindings/processed-schema.json ... ...input/gpio-matrix-keypad.yaml: bogus2-delay-ms-bogus2: missing type definition ...input/gpio-matrix-keypad.yaml: bogus3-my-property: missing type definition ...input/gpio-matrix-keypad.yaml: bogus4: missing type definition any idea why? Thank you, Hugo. -- Hugo Villeneuve ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad 2026-02-24 22:32 ` Hugo Villeneuve @ 2026-02-24 22:36 ` Rob Herring 0 siblings, 0 replies; 10+ messages in thread From: Rob Herring @ 2026-02-24 22:36 UTC (permalink / raw) To: Hugo Villeneuve Cc: hvilleneuve, dmitry.torokhov, krzk+dt, conor+dt, linux-input, devicetree, linux-kernel On Tue, Feb 24, 2026 at 4:32 PM Hugo Villeneuve <hugo@hugovil.com> wrote: > > On Tue, 24 Feb 2026 15:06:40 -0600 > Rob Herring <robh@kernel.org> wrote: > > > On Tue, Feb 24, 2026 at 2:40 PM Hugo Villeneuve <hugo@hugovil.com> wrote: > > > > > > Hi Rob, > > > > > > On Mon, 23 Feb 2026 17:23:33 -0600 > > > Rob Herring <robh@kernel.org> wrote: > > > > > > > On Mon, Feb 23, 2026 at 12:47 PM Hugo Villeneuve <hugo@hugovil.com> wrote: > > > > > > > > > > Hi Rob, > > > > > > > > > > On Mon, 23 Feb 2026 11:57:06 -0600 > > > > > Rob Herring <robh@kernel.org> wrote: > > > > > > > > > > > On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote: > > > > > > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > > > > > > > > > > > Add DT bindings for GPIO charlieplex keypad. > > > > > > > > > > > > > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > > > > --- > > > > > > > .../input/gpio-charlieplex-keypad.yaml | 82 +++++++++++++++++++ > > > > > > > 1 file changed, 82 insertions(+) > > > > > > > create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > > > > new file mode 100644 > > > > > > > index 0000000000000..1672491a75a85 > > > > > > > --- /dev/null > > > > > > > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml > > > > > > > @@ -0,0 +1,82 @@ > > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > > > +%YAML 1.2 > > > > > > > +--- > > > > > > > + > > > > > > > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml# > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > > + > > > > > > > +title: GPIO charlieplex keypad > > > > > > > + > > > > > > > +maintainers: > > > > > > > + - Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > > > > + > > > > > > > +description: > > > > > > > + The charlieplex keypad supports N^2)-N different key combinations (where N is > > > > > > > + the number of lines). Key presses and releases are detected by configuring > > > > > > > + only one line as output at a time, and reading other line states. This process > > > > > > > + is repeated for each line. > > > > > > > + This mechanism doesn't allow to detect simultaneous key presses. > > > > > > > + > > > > > > > +allOf: > > > > > > > + - $ref: input.yaml# > > > > > > > + - $ref: /schemas/input/matrix-keymap.yaml# > > > > > > > + > > > > > > > +properties: > > > > > > > + compatible: > > > > > > > + const: gpio-charlieplex-keypad > > > > > > > + > > > > > > > + autorepeat: true > > > > > > > + > > > > > > > + line-scan-delay-us: > > > > > > > + description: > > > > > > > + Delay, measured in microseconds, that is needed > > > > > > > + before we can scan keypad after activating one line. > > > > > > > + default: 0 > > > > > > > > > > > > Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml? > > > > > > If so, move it to matrix-keymap.yaml to re-use it here. > > > > > > > > > > It is used in a similar fashion, but for charlieplex keyboard, there is > > > > > no concept of "rows" and "columns". There are only > > > > > lines, which are all equivalent in functionality. > > > > > > > > > > > If not, there's a bunch of other scan delay properties just from > > > > > > grepping "delay" in the input bindings. Surely we can define something > > > > > > common. > > > > > > > > > > Most of those delays refer to something quite different than what > > > > > "col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay > > > > > that we wait when activating a GPIO before we can safely/reliably read > > > > > other GPIOs connected thru its circuitry). > > > > > > > > > > Maybe "col-scan-delay-us" and "line-scan-delay-us" could be > > > > > combined into a common "line-scan-delay-us" ("line" is more generic > > > > > than column), and defined in matrix-keymap.yaml. > > > > > > > > What about "scan-delay-us"? I would assume all the scan delay > > > > properties are just the delay after changing the outputs to reading > > > > the inputs. > > > > > > They are for gpio-matrix-keypad.yaml and this binding, but not for > > > others. Most scan delay properties refer to the period or > > > interval between successive scans. > > > > > > So for my binding, "settling-time-us" would be more accurate and a > > > better property name (it is also used in adc.yaml). > > > > Let's go with that. > > Ok, will do. > > > > > > > > > Looking into a common place to define this new property, I stumbled > > > upon gpio-delay.yaml, so maybe I do not need this new property at all > > > and simply define a gpio-delay node if needed (and add it to this > > > binding example)? > > > > > > I tested this and it works, although it requires a patch to the > > > gpio-aggregator driver, because for now it respect the delay only > > > when changing the output value, not when switching between input and > > > output like I do in my driver. > > > > > > With my patch, it works ok. > > > > I would not use gpio-delay here. > > Ok. > > I also observed that debounce-delay-ms is re-defined by a few bindings, > including mine. I assume that I could move all these identical > definitions to input.yaml and reduce duplication (in a separate patch, > of course). Yes, that would be good. > While testing that, I found an odd situation: if I reference these four > dummy (undefined anywhere) properties in the gpio-matrix-keypad > binding, I am expecting four warnings when validating it. However I get > just three: > > ================== > diff --git > a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml > b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml index > 20b5371fa21c..733458bf4d13 100644 > --- a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml > +++ b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml > @@ -36,7 +36,10 @@ properties: > > linux,keymap: true > > + bogus1-delay-ms: true > + bogus2-delay-ms-bogus2: true > + bogus3-my-property: true > + bogus4: true > > linux,no-autorepeat: > type: boolean > ================== > > Validation result: > > ... > SCHEMA Documentation/devicetree/bindings/processed-schema.json > ... > ...input/gpio-matrix-keypad.yaml: > bogus2-delay-ms-bogus2: missing type definition > ...input/gpio-matrix-keypad.yaml: > bogus3-my-property: missing type definition > ...input/gpio-matrix-keypad.yaml: > bogus4: missing type definition > > any idea why? Properties with a unit suffix like "-ms" always have a type hence why they don't ever define a type. Rob ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2 2/2] Input: charlieplex_keypad: add GPIO charlieplex keypad 2026-02-13 17:14 [PATCH v2 0/2] input: add GPIO-based charlieplex keypad Hugo Villeneuve 2026-02-13 17:14 ` [PATCH v2 1/2] dt-bindings: input: add GPIO " Hugo Villeneuve @ 2026-02-13 17:14 ` Hugo Villeneuve 1 sibling, 0 replies; 10+ messages in thread From: Hugo Villeneuve @ 2026-02-13 17:14 UTC (permalink / raw) To: hvilleneuve, dmitry.torokhov, robh, krzk+dt, conor+dt Cc: linux-input, devicetree, linux-kernel, hugo From: Hugo Villeneuve <hvilleneuve@dimonoff.com> Add support for GPIO-based charlieplex keypad, allowing to control N^2-N keys using N GPIO lines. Reuse matrix keypad keymap to simplify, even if there is no concept of rows and columns in this type of keyboard. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> --- MAINTAINERS | 7 + drivers/input/keyboard/Kconfig | 14 ++ drivers/input/keyboard/Makefile | 1 + drivers/input/keyboard/charlieplex_keypad.c | 213 ++++++++++++++++++++ 4 files changed, 235 insertions(+) create mode 100644 drivers/input/keyboard/charlieplex_keypad.c diff --git a/MAINTAINERS b/MAINTAINERS index 9ed6d11a77466..0b2d71f32b400 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5765,6 +5765,13 @@ S: Maintained F: Documentation/hwmon/powerz.rst F: drivers/hwmon/powerz.c +CHARLIEPLEX KEYPAD DRIVER +M: Hugo Villeneuve <hvilleneuve@dimonoff.com> +S: Supported +W: http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/electronic-circuits/matrix-keypad-scan-decode +F: Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml +F: drivers/input/keyboard/charlieplex_keypad.c + CHECKPATCH M: Andy Whitcroft <apw@canonical.com> M: Joe Perches <joe@perches.com> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig index 2ff4fef322c24..ae54b4b7e2d8a 100644 --- a/drivers/input/keyboard/Kconfig +++ b/drivers/input/keyboard/Kconfig @@ -289,6 +289,20 @@ config KEYBOARD_MATRIX To compile this driver as a module, choose M here: the module will be called matrix_keypad. +config KEYBOARD_CHARLIEPLEX + tristate "GPIO driven chearlieplex keypad support" + depends on GPIOLIB || COMPILE_TEST + select INPUT_MATRIXKMAP + help + Enable support for GPIO driven charlieplex keypad. A charlieplex + keypad allows to use fewer GPIO lines to interface to key switches. + For example, an N lines charlieplex keypad can be used to interface + to N^2-N different key switches. However, this type of keypad + cannot detect more than one key press at a time. + + To compile this driver as a module, choose M here: the + module will be called charlieplex_keypad. + config KEYBOARD_HIL_OLD tristate "HP HIL keyboard support (simple driver)" depends on GSC || HP300 diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile index 2d906e14f3e27..40b5cf5d374d2 100644 --- a/drivers/input/keyboard/Makefile +++ b/drivers/input/keyboard/Makefile @@ -40,6 +40,7 @@ obj-$(CONFIG_KEYBOARD_LOCOMO) += locomokbd.o obj-$(CONFIG_KEYBOARD_LPC32XX) += lpc32xx-keys.o obj-$(CONFIG_KEYBOARD_MAPLE) += maple_keyb.o obj-$(CONFIG_KEYBOARD_MATRIX) += matrix_keypad.o +obj-$(CONFIG_KEYBOARD_CHARLIEPLEX) += charlieplex_keypad.o obj-$(CONFIG_KEYBOARD_MAX7359) += max7359_keypad.o obj-$(CONFIG_KEYBOARD_MAX7360) += max7360-keypad.o obj-$(CONFIG_KEYBOARD_MPR121) += mpr121_touchkey.o diff --git a/drivers/input/keyboard/charlieplex_keypad.c b/drivers/input/keyboard/charlieplex_keypad.c new file mode 100644 index 0000000000000..81e8b6b96dab1 --- /dev/null +++ b/drivers/input/keyboard/charlieplex_keypad.c @@ -0,0 +1,213 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * GPIO driven charlieplex keypad driver + * + * Copyright (c) 2025 Hugo Villeneuve <hvilleneuve@dimonoff.com> + * + * Based on matrix_keyboard.c + */ + +#include <linux/delay.h> +#include <linux/gpio/consumer.h> +#include <linux/input.h> +#include <linux/input/matrix_keypad.h> +#include <linux/module.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/property.h> +#include <linux/types.h> + +struct charlieplex_keypad { + struct input_dev *input_dev; + struct gpio_descs *line_gpios; + unsigned int nlines; + unsigned int line_scan_delay_us; + unsigned int debounce_threshold; + unsigned int debounce_count; + int debounce_code; + int current_code; +}; + +static void charlieplex_keypad_report_key(struct input_dev *input) +{ + struct charlieplex_keypad *keypad = input_get_drvdata(input); + const unsigned short *keycodes = input->keycode; + + if (keypad->current_code > 0) { + input_event(input, EV_MSC, MSC_SCAN, keypad->current_code); + input_report_key(input, keycodes[keypad->current_code], 0); + } + + if (keypad->debounce_code) { + input_event(input, EV_MSC, MSC_SCAN, keypad->debounce_code); + input_report_key(input, keycodes[keypad->debounce_code], 1); + } + + input_sync(input); + keypad->current_code = keypad->debounce_code; +} + +static void charlieplex_keypad_check_switch_change(struct input_dev *input, + int code) +{ + struct charlieplex_keypad *keypad = input_get_drvdata(input); + + if (code != keypad->debounce_code) { + keypad->debounce_count = 0; + keypad->debounce_code = code; + } else if (keypad->debounce_count < keypad->debounce_threshold) { + keypad->debounce_count++; + + if (keypad->debounce_count >= keypad->debounce_threshold && + keypad->debounce_code != keypad->current_code) + charlieplex_keypad_report_key(input); + } +} + +static void charlieplex_keypad_poll(struct input_dev *input) +{ + struct charlieplex_keypad *keypad = input_get_drvdata(input); + int oline; + int code; + + for (code = 0, oline = 0; oline < keypad->nlines; oline++) { + DECLARE_BITMAP(values, MATRIX_MAX_ROWS); + int iline; + int rc; + + /* Activate only one line as output at a time. */ + gpiod_direction_output(keypad->line_gpios->desc[oline], 1); + + if (keypad->line_scan_delay_us) + fsleep(keypad->line_scan_delay_us); + + /* Read input on all other lines. */ + rc = gpiod_get_array_value_cansleep(keypad->line_gpios->ndescs, + keypad->line_gpios->desc, + keypad->line_gpios->info, values); + if (rc) + return; + + for (iline = 0; iline < keypad->nlines; iline++) { + if (iline == oline) + continue; /* Do not read active output line. */ + + /* Check if GPIO is asserted. */ + if (test_bit(iline, values)) { + code = MATRIX_SCAN_CODE(oline, iline, + get_count_order(keypad->nlines)); + /* + * Exit loop immediately since we cannot detect + * more than one key press at a time. + */ + break; + } + } + + gpiod_direction_input(keypad->line_gpios->desc[oline]); + + if (code) + break; + } + + charlieplex_keypad_check_switch_change(input, code); +} + +static int charlieplex_keypad_init_gpio(struct platform_device *pdev, + struct charlieplex_keypad *keypad) +{ + int i; + + keypad->line_gpios = devm_gpiod_get_array(&pdev->dev, "line", GPIOD_IN); + if (IS_ERR(keypad->line_gpios)) + return PTR_ERR(keypad->line_gpios); + + keypad->nlines = keypad->line_gpios->ndescs; + + if (keypad->nlines > MATRIX_MAX_ROWS) + return -EINVAL; + + for (i = 0; i < keypad->nlines; i++) + gpiod_set_consumer_name(keypad->line_gpios->desc[i], "charlieplex_kbd_line"); + + return 0; +} + +static int charlieplex_keypad_probe(struct platform_device *pdev) +{ + struct charlieplex_keypad *keypad; + unsigned int debounce_interval_ms; + unsigned int poll_interval_ms; + struct input_dev *input_dev; + int err; + + keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL); + if (!keypad) + return -ENOMEM; + + input_dev = devm_input_allocate_device(&pdev->dev); + if (!input_dev) + return -ENOMEM; + + keypad->input_dev = input_dev; + + device_property_read_u32(&pdev->dev, "poll-interval", &poll_interval_ms); + device_property_read_u32(&pdev->dev, "debounce-delay-ms", &debounce_interval_ms); + device_property_read_u32(&pdev->dev, "line-scan-delay-us", &keypad->line_scan_delay_us); + + keypad->current_code = -1; + keypad->debounce_code = -1; + keypad->debounce_threshold = DIV_ROUND_UP(debounce_interval_ms, poll_interval_ms); + + err = charlieplex_keypad_init_gpio(pdev, keypad); + if (err) + return err; + + input_dev->name = pdev->name; + input_dev->id.bustype = BUS_HOST; + + err = matrix_keypad_build_keymap(NULL, NULL, keypad->nlines, + keypad->nlines, NULL, input_dev); + if (err) + dev_err_probe(&pdev->dev, -ENOMEM, "failed to build keymap\n"); + + if (device_property_read_bool(&pdev->dev, "autorepeat")) + __set_bit(EV_REP, input_dev->evbit); + + input_set_capability(input_dev, EV_MSC, MSC_SCAN); + + err = input_setup_polling(input_dev, charlieplex_keypad_poll); + if (err) + dev_err_probe(&pdev->dev, err, "unable to set up polling\n"); + + input_set_poll_interval(input_dev, poll_interval_ms); + + input_set_drvdata(input_dev, keypad); + + err = input_register_device(keypad->input_dev); + if (err) + return err; + + platform_set_drvdata(pdev, keypad); + + return 0; +} + +static const struct of_device_id charlieplex_keypad_dt_match[] = { + { .compatible = "gpio-charlieplex-keypad" }, + { } +}; +MODULE_DEVICE_TABLE(of, charlieplex_keypad_dt_match); + +static struct platform_driver charlieplex_keypad_driver = { + .probe = charlieplex_keypad_probe, + .driver = { + .name = "charlieplex-keypad", + .of_match_table = of_match_ptr(charlieplex_keypad_dt_match), + }, +}; +module_platform_driver(charlieplex_keypad_driver); + +MODULE_AUTHOR("Hugo Villeneuve <hvilleneuve@dimonoff.com>"); +MODULE_DESCRIPTION("GPIO driven charlieplex keypad driver"); +MODULE_LICENSE("GPL"); -- 2.47.3 ^ permalink raw reply related [flat|nested] 10+ messages in thread
end of thread, other threads:[~2026-02-24 22:37 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-02-13 17:14 [PATCH v2 0/2] input: add GPIO-based charlieplex keypad Hugo Villeneuve 2026-02-13 17:14 ` [PATCH v2 1/2] dt-bindings: input: add GPIO " Hugo Villeneuve 2026-02-23 17:57 ` Rob Herring 2026-02-23 18:47 ` Hugo Villeneuve 2026-02-23 23:23 ` Rob Herring 2026-02-24 20:40 ` Hugo Villeneuve 2026-02-24 21:06 ` Rob Herring 2026-02-24 22:32 ` Hugo Villeneuve 2026-02-24 22:36 ` Rob Herring 2026-02-13 17:14 ` [PATCH v2 2/2] Input: charlieplex_keypad: " Hugo Villeneuve
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox