Olof Johansson wrote at Wednesday, December 28, 2011 11:34 PM:

On Wed, Dec 28, 2011 at 10:16 PM, Stephen Warren [off-list ref] wrote:

quoted

Olof Johansson wrote at Wednesday, December 28, 2011 3:53 PM:

quoted

From: Dmitry Torokhov <redacted>

This adds a basic device tree binding for simple key matrix data.

Signed-off-by: Olof Johansson <redacted>
---

Based on email exchange this morning, this is a first cut at a shared
definition and helper function to parse and fill in the keymap data.

Instead of doing the direct parsing into the final keymap format, I
chose to fill in the pdata-equivalent since that is how the OF pdata
fillers work right now if code is to be kept common with the legacy
platform_device probe interface.

This is a prerequisite for a revised version of the tegra-kbc device
tree support that I will repost separately once this interface is stable.

...

quoted

diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt

...

quoted

+For simple keyboards with just a few buttons, you can specify each key
+as a subnode of the keyboard controller, with the following
+properties:
+
+- keypad,row: the row number to which the key is connected.
+- keypad,column: the column number to which the key is connected.
+- linux,code: the key-code to be reported when the key is pressed
+  and released.
+
+Example:
+
+     key_1 {
+             keypad,row = <0>;
+             keypad,column = <3>;
+             linux,code = <2>;
+     };
+
+
+For a more complex keyboard, such as a full laptop, a more compact
+binding can be used instead, with the following property directly in
+the keyboard controller node:
+
+- linux,keymap: an array of 3-cell entries containing the equivalent
+  of the three separate properties above: row, column and linux
+  key-code.

Why allow two completely different bindings? Is there some deficiency
to the compact binding that means it isn't suitable for all cases?

The main reason is that the samsung keyboard driver already implements
the more verbose one, and allowing that binding to coexist while also
providing a more compact one seems like the right thing to do.

Can we deprecate the Samsung format, and only allow it for that Samsung
device (and allow both there), and require a single format for any other
keyboard?

The issue here is that U-Boot wants to stay small, and having to allow
two alternative methods to specify a keyboard is going to bloat the code;
I expect some pushback adding DT support for just one binding by the time
they see all the DT parsing code that's needed to do it all right.

-- 
nvpublic