From: Stephen Warren <swarren@wwwdotorg.org> To: Gerhard Sittig <gsi@denx.de> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>, linux-input@vger.kernel.org, devicetree-discuss@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, Chao Xie <xiechao.mail@gmail.com>, Eric Miao <eric.y.miao@gmail.com>, Detlev Zundel <dzu@denx.de>, Sekhar Nori <nsekhar@ti.com>, Marek Vasut <marek.vasut@gmail.com>, Ralf Baechle <ralf@linux-mips.org> Subject: Re: [PATCH v1 09/12] input: matrix-keypad: add binary column encoding Date: Fri, 21 Jun 2013 15:58:14 -0600 [thread overview] Message-ID: <51C4CC76.70501@wwwdotorg.org> (raw) In-Reply-To: <1371838198-7327-10-git-send-email-gsi@denx.de> On 06/21/2013 12:09 PM, Gerhard Sittig wrote: > introduce support to optionally run a binary column address bit pattern > on column GPIO pins in contrast to the formerly assumed one-out-of-N approach > diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt > +The driver assumes that each row and column line of the keypad matrix is Here, I would definitely: s/The driver/This binding/. > +connected to a specific GPIO pin. Alternatively column addresses can get > +encoded in binary form to reduce the number of GPIO pins involved, at the > +cost of adding an external decoder which translates the binary pattern of N > +GPIO coloumn pins into one of 2**N column lines of the matrix. A mere s/coloumn/column/ > +circuit of two inverting open collector drivers in series connected to one > +output pin is a special case of this generic decoder approach. Such a > +decoder may be desirable since it's cheap and protects the SoC from damage > +by unwanted interaction of signals when any combination of multiple keys > +gets pressed, regardless of the software's operating the column GPIO pins. > +The row GPIO pins won't interfere either since they all are inputs. I'm not sure it's worth mentioning that; it presumably makes no semantic difference to how SW interfaces to the HW this binding describes. > +- col-gpios-binary: boolean, switches from the 'one GPIO pin for each > + column' approach to the 'n GPIO pins to address > + 2**n columns' approach (binary encoding of column > + addresses in contrast to a one-out-of-many pattern > + for the column GPIO pins) Thinking about the keypad,num-rows/keypad,num-columns properties from the previous patch, "num" might not be enough to describe all HW. "num" assumes that the decoder outputs 0..num-1 are used and that num..N-1 are not. What if the unused decoder outputs are 0..(N-num-1)? Instead, it may be better to define a property col-values-mask, with one bit set for each valid/useful integer value to be output on the column GPIOs? BTW, I think some of the new properties in either/both these patches and the original matrix-keypad binding doc are prefixed with "keypad," and some not. It would be best to be consistent. Given these properties are specific to this one binding, rather than some kind of generic infra-structure, having the prefix on as many properties as possible seems correct to me.
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v1 09/12] input: matrix-keypad: add binary column encoding Date: Fri, 21 Jun 2013 15:58:14 -0600 [thread overview] Message-ID: <51C4CC76.70501@wwwdotorg.org> (raw) In-Reply-To: <1371838198-7327-10-git-send-email-gsi@denx.de> On 06/21/2013 12:09 PM, Gerhard Sittig wrote: > introduce support to optionally run a binary column address bit pattern > on column GPIO pins in contrast to the formerly assumed one-out-of-N approach > diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt > +The driver assumes that each row and column line of the keypad matrix is Here, I would definitely: s/The driver/This binding/. > +connected to a specific GPIO pin. Alternatively column addresses can get > +encoded in binary form to reduce the number of GPIO pins involved, at the > +cost of adding an external decoder which translates the binary pattern of N > +GPIO coloumn pins into one of 2**N column lines of the matrix. A mere s/coloumn/column/ > +circuit of two inverting open collector drivers in series connected to one > +output pin is a special case of this generic decoder approach. Such a > +decoder may be desirable since it's cheap and protects the SoC from damage > +by unwanted interaction of signals when any combination of multiple keys > +gets pressed, regardless of the software's operating the column GPIO pins. > +The row GPIO pins won't interfere either since they all are inputs. I'm not sure it's worth mentioning that; it presumably makes no semantic difference to how SW interfaces to the HW this binding describes. > +- col-gpios-binary: boolean, switches from the 'one GPIO pin for each > + column' approach to the 'n GPIO pins to address > + 2**n columns' approach (binary encoding of column > + addresses in contrast to a one-out-of-many pattern > + for the column GPIO pins) Thinking about the keypad,num-rows/keypad,num-columns properties from the previous patch, "num" might not be enough to describe all HW. "num" assumes that the decoder outputs 0..num-1 are used and that num..N-1 are not. What if the unused decoder outputs are 0..(N-num-1)? Instead, it may be better to define a property col-values-mask, with one bit set for each valid/useful integer value to be output on the column GPIOs? BTW, I think some of the new properties in either/both these patches and the original matrix-keypad binding doc are prefixed with "keypad," and some not. It would be best to be consistent. Given these properties are specific to this one binding, rather than some kind of generic infra-structure, having the prefix on as many properties as possible seems correct to me.
next prev parent reply other threads:[~2013-06-21 21:58 UTC|newest] Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-06-21 18:09 [PATCH v1 00/12] input: keypad-matrix: doc update, hw separation, polling, binary columns Gerhard Sittig 2013-06-21 18:09 ` Gerhard Sittig 2013-06-21 18:09 ` [PATCH v1 01/12] input: matrix-keypad: update devicetree binding doc Gerhard Sittig 2013-06-21 18:09 ` Gerhard Sittig 2013-06-21 21:31 ` Stephen Warren 2013-06-21 21:31 ` Stephen Warren 2013-06-22 9:23 ` Gerhard Sittig 2013-06-22 9:23 ` Gerhard Sittig 2013-06-24 22:00 ` Stephen Warren 2013-06-24 22:00 ` Stephen Warren 2013-06-28 8:24 ` Gerhard Sittig 2013-06-28 8:24 ` Gerhard Sittig 2013-06-28 14:50 ` Stephen Warren 2013-06-28 14:50 ` Stephen Warren 2013-06-30 11:04 ` Gerhard Sittig 2013-06-30 11:04 ` Gerhard Sittig 2013-06-21 18:09 ` [PATCH v1 02/12] input: matrix-keymap: func call coding style nit Gerhard Sittig 2013-06-21 18:09 ` Gerhard Sittig 2013-06-22 2:18 ` Marek Vasut 2013-06-22 2:18 ` Marek Vasut 2013-06-22 8:22 ` Gerhard Sittig 2013-06-22 8:22 ` Gerhard Sittig 2013-06-22 13:23 ` Marek Vasut 2013-06-22 13:23 ` Marek Vasut 2013-06-21 18:09 ` [PATCH v1 03/12] input: matrix-keypad: rename variables and funcs Gerhard Sittig 2013-06-21 18:09 ` Gerhard Sittig 2013-06-21 18:09 ` [PATCH v1 04/12] input: matrix-keypad: push/pull, separate polarity Gerhard Sittig 2013-06-21 18:09 ` Gerhard Sittig 2013-06-21 21:34 ` Stephen Warren 2013-06-21 21:34 ` Stephen Warren 2013-06-22 9:36 ` Gerhard Sittig 2013-06-22 9:36 ` Gerhard Sittig 2013-06-24 23:14 ` Stephen Warren 2013-06-24 23:14 ` Stephen Warren 2013-06-28 8:33 ` Gerhard Sittig 2013-06-28 8:33 ` Gerhard Sittig 2013-06-28 15:01 ` Stephen Warren 2013-06-28 15:01 ` Stephen Warren 2013-06-30 11:43 ` Gerhard Sittig 2013-06-30 11:43 ` Gerhard Sittig 2013-06-21 18:09 ` [PATCH v1 05/12] input: matrix-keypad: update comments, diagnostics Gerhard Sittig 2013-06-21 18:09 ` Gerhard Sittig 2013-06-22 2:23 ` Marek Vasut 2013-06-22 2:23 ` Marek Vasut 2013-06-21 18:09 ` [PATCH v1 06/12] input: keypad-matrix: refactor matrix scan logic Gerhard Sittig 2013-06-21 18:09 ` Gerhard Sittig 2013-06-21 18:09 ` [PATCH v1 07/12] input: keypad-matrix: introduce polling support Gerhard Sittig 2013-06-21 18:09 ` Gerhard Sittig 2013-06-21 21:38 ` Stephen Warren 2013-06-21 21:38 ` Stephen Warren 2013-06-22 9:50 ` Gerhard Sittig 2013-06-22 9:50 ` Gerhard Sittig 2013-06-24 23:18 ` Stephen Warren 2013-06-24 23:18 ` Stephen Warren 2013-06-21 18:09 ` [PATCH v1 08/12] input: keypad-matrix: tell GPIO pins from matrix lines Gerhard Sittig 2013-06-21 18:09 ` Gerhard Sittig 2013-06-21 21:41 ` Stephen Warren 2013-06-21 21:41 ` Stephen Warren 2013-06-22 10:00 ` Gerhard Sittig 2013-06-22 10:00 ` Gerhard Sittig 2013-06-24 23:26 ` Stephen Warren 2013-06-24 23:26 ` Stephen Warren 2013-06-28 7:52 ` Gerhard Sittig 2013-06-28 7:52 ` Gerhard Sittig 2013-06-28 14:35 ` Stephen Warren 2013-06-28 14:35 ` Stephen Warren 2013-06-28 18:25 ` Dmitry Torokhov 2013-06-28 18:25 ` Dmitry Torokhov 2013-06-30 12:03 ` Gerhard Sittig 2013-06-30 12:03 ` Gerhard Sittig 2013-06-21 18:09 ` [PATCH v1 09/12] input: matrix-keypad: add binary column encoding Gerhard Sittig 2013-06-21 18:09 ` Gerhard Sittig 2013-06-21 21:58 ` Stephen Warren [this message] 2013-06-21 21:58 ` Stephen Warren 2013-06-21 18:09 ` [PATCH v1 10/12] input: keypad_matrix: use usleep_range() for scan delay Gerhard Sittig 2013-06-21 18:09 ` Gerhard Sittig 2013-06-21 22:00 ` Stephen Warren 2013-06-21 22:00 ` Stephen Warren 2013-06-22 10:17 ` Gerhard Sittig 2013-06-22 10:17 ` Gerhard Sittig 2013-06-24 23:27 ` Stephen Warren 2013-06-24 23:27 ` Stephen Warren 2013-06-21 18:09 ` [PATCH v1 11/12] input: keypad-matrix: AC14xx device tree update Gerhard Sittig 2013-06-21 18:09 ` Gerhard Sittig 2013-06-21 18:09 ` [PATCH v1 12/12] input: matrix-keypad: add diagnostics in probe() Gerhard Sittig 2013-06-21 18:09 ` Gerhard Sittig 2013-06-22 2:28 ` Marek Vasut 2013-06-22 2:28 ` Marek Vasut 2013-06-22 8:30 ` Gerhard Sittig 2013-06-22 8:30 ` Gerhard Sittig
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=51C4CC76.70501@wwwdotorg.org \ --to=swarren@wwwdotorg.org \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=dmitry.torokhov@gmail.com \ --cc=dzu@denx.de \ --cc=eric.y.miao@gmail.com \ --cc=gsi@denx.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-input@vger.kernel.org \ --cc=marek.vasut@gmail.com \ --cc=nsekhar@ti.com \ --cc=ralf@linux-mips.org \ --cc=xiechao.mail@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.