I just responded to the latest in the thread, and then decided to look
backwards... This will be a bit of a rambling post as I jump around in
Google looking for stuff.
On Fri, 10 Feb 2017 00:57:59 -0800 (PST), Gurpartap Singh
<
gurparta...@gmail.com> declaimed the
following:
>compatible = "gpio-matrix-keypad";
>debounce-delay-ms = <0x5>;
>col-scan-delay-us = <0x2>;
>row-gpios = <0x5a 0x19 0x0 0x5a 0x1a 0x0 0x5a 0x1b 0x0>;
>col-gpios = <0x5a 0x15 0x0 0x5a 0x16 0x0>;
Where did the 0x5A come from? Based on
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
where your x5A field is shown with &gpio2; though the documentation does
state the precise form per gpio depends on the system) -- see
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/gpio/gpio.txt
Regretably, I've not found a reference for what the BBB uses...
http://www.jumpnowtek.com/beaglebone/BeagleBone-Black-pinmuxing-and-other-device-tree-notes.html
appears to show a definition for gpio banks, but doesn't show anything
later to referencing them... I'm guessing it would be something like
<&gpio0 xx yy> (the yy based on the LED control in another file using a
third field for some mode control){I've found one PDF from two years ago
using 0x5, not 0x5A for the LED definition... I suspect using a hard-coded
integer is not safe as the node may change as the device tree changes --
integers may be the result of running a decompile on the device tree}
All the references I've found seem to focus on the pinmux in the device
tree, and not on defining a pseudo-device using GPIO pin assignments.
>linux,keymap = <0x8b 0x100009e 0x2000069 0x1006a 0x101001c 0x201006c>;
Well, that much is the same as the first link -- a 3x2 matrix
0 1
0 8b 6a
1 9e 1c
2 69 6c