[PATCH V3 5/5] input: pxa27x-keypad: add device tree support

[Gerhard Sittig]

On Wed, Jun 19, 2013 at 16:38 +0800, Chao Xie wrote:
> 
> On Wed, Jun 19, 2013 at 4:22 PM, Marek Vasut <marex at denx.de> wrote:
> >
> >> Signed-off-by: Chao Xie <chao.xie at marvell.com>
> >> [ ... ]
> >> +++ b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
> >> @@ -0,0 +1,60 @@
> >> +* Marvell PXA Keypad controller
> >> +
> >> +Required Properties
> >> +- compatible : should be "marvell,pxa27x-keypad"
> >> +- reg : Address and length of the register set for the device
> >> +- interrupts : The interrupt for the keypad controller
> >> +- marvell,debounce-interval : How long time the key will be
> >
> > Is there no generic prop name for this debounce interval?
> >
> I searched at drivers/input and Documents.
> Two drivers use "debounce-interval", gpio-keys.c and stmpe-keypad.c.
> They describe the meanings of "debounce-interval" at its own document file.
> Some other drivers uses "xxx,debounce-delay-ms" or "debounce-delay-ms"
> So it seems that there is no generic prop name for this debounce interval.

Actually there is, but under a different (more user friendly)
name:  See the 'debounce-delay-ms' property in
Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
which gets referenced in the matrix_keypad_parse_dt() routine in
the drivers/input/keyboard/matrix_keypad.c source file.  Ah, your
last sentence mentions that fact.

But when you introduce DT support into an existing driver which
previously used platform data, then there is no problem with
backwards compatibility in .dts files.  So I suggest to go with
the "debounce-delay-ms" name since it better reflects to the .dts
author (hardware engineer) which unit the number is supposed to
be specified in.


Note that I've recently worked on extending the matrix keypad
input driver (doc improvements, software polling, binary encoded
column selection), but haven't submitted the patch series yet
since it's perfectly operational on the target which motivated
the extension but wasn't tested yet on any other platform or
matrix setup -- I currently lack access to an ARM based board
with either lots of accessible GPIOs to connect a matrix to, or
some matrix already built into the board, but more importantly
lack free resources for this very driver extension.

Alternatively I might send an RFC series since the current state
isn't good enough for v1.  Just ask if you'd like to test or
review what I have come up with so far (it builds but wasn't
run-tested).


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de