Re: [PATCH V3 5/5] input: pxa27x-keypad: add device tree support
From: Chao Xie
Date: Wed Jun 19 2013 - 22:01:33 EST
On Wed, Jun 19, 2013 at 7:13 PM, Gerhard Sittig <gsi@xxxxxxx> wrote:
> On Wed, Jun 19, 2013 at 16:38 +0800, Chao Xie wrote:
>> On Wed, Jun 19, 2013 at 4:22 PM, Marek Vasut <marex@xxxxxxx> wrote:
>> >> Signed-off-by: Chao Xie <chao.xie@xxxxxxxxxxx>
>> >> [ ... ]
>> >> +++ 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
> 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.
What do you think? I am fine with either one.
> 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
Sure, i can help you to test at PXA platform which is ARM based.
> 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@xxxxxxx
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/