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 01/12] input: matrix-keypad: update devicetree binding doc
Date: Fri, 21 Jun 2013 15:31:39 -0600 [thread overview]
Message-ID: <51C4C63B.3030300@wwwdotorg.org> (raw)
In-Reply-To: <1371838198-7327-2-git-send-email-gsi@denx.de>
On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
> update the device tree binding documentation for the GPIO matrix keypad
> driver: mention the driver's selecting all columns at once, reword the
> delay descriptions, add the missing active low GPIO pin level property
> diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
Presumably the changes to this file simply seek to precisely document
the HW that this binding supports, and do not intend to change the
semantics of the binding at all. If that's the case, then they seem fine
to me.
Have you checked that all users of this binding do assume that the
column GPIOs are output, and rows inputs, rather than the other way
around for example? I suppose if the Linux driver is already implemented
to assume that, then nobody can be successfully using this binding for
HW where that isn't the case, so this change is fine.
This change assumes it's OK to activate all columns at once, and
presumably that drivers can request the GPIOs as IRQs. This need not be
true on all HW. Should an additional property be added to describe
whether it's legal to activate all columns at once? For the IRQ case,
presumably the driver can simply try to request an IRQ for each GPIO,
and fall back to not doing so if that doesn't work.
> +Simple keypad matrix layouts just connect GPIO lines to mechanical
> +switches, with no other active components involved. Although due to the
I don't think that's always true. On some Tegra boards for example,
multiple processes can "press" certain switches, so we actually have a
wired-OR feed into a transistor which then connects a particular
(column, row) combination. We do this e.g. for remote-control USB over
the power button for example. I believe the effect is the same, but it
does mean that statement above isn't quite true.
> +driver's operation of activating all columns at the same time for most
Saying "driver" in a DT binding is a slight red flag. The binding should
really purely describe HW, rather than SW's use of it. Here, the use is
probably generic enough not to be an issue, although it there's some way
to reword it to avoid that word it might be good.
> +- gpio-activelow: row pins as well as column pins are active low
That one change is definitely wrong. Each entry in row-gpios and
col-gpios should include GPIO flags (in a format defined by the binding
for the DT node providing the GPIO). Those flags include an active-high
vs. active-low bit. In Linux, you can use of_get_gpio_flags() to
retrieve a standardized representation of the flags.
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 01/12] input: matrix-keypad: update devicetree binding doc
Date: Fri, 21 Jun 2013 15:31:39 -0600 [thread overview]
Message-ID: <51C4C63B.3030300@wwwdotorg.org> (raw)
In-Reply-To: <1371838198-7327-2-git-send-email-gsi@denx.de>
On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
> update the device tree binding documentation for the GPIO matrix keypad
> driver: mention the driver's selecting all columns at once, reword the
> delay descriptions, add the missing active low GPIO pin level property
> diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
Presumably the changes to this file simply seek to precisely document
the HW that this binding supports, and do not intend to change the
semantics of the binding at all. If that's the case, then they seem fine
to me.
Have you checked that all users of this binding do assume that the
column GPIOs are output, and rows inputs, rather than the other way
around for example? I suppose if the Linux driver is already implemented
to assume that, then nobody can be successfully using this binding for
HW where that isn't the case, so this change is fine.
This change assumes it's OK to activate all columns at once, and
presumably that drivers can request the GPIOs as IRQs. This need not be
true on all HW. Should an additional property be added to describe
whether it's legal to activate all columns at once? For the IRQ case,
presumably the driver can simply try to request an IRQ for each GPIO,
and fall back to not doing so if that doesn't work.
> +Simple keypad matrix layouts just connect GPIO lines to mechanical
> +switches, with no other active components involved. Although due to the
I don't think that's always true. On some Tegra boards for example,
multiple processes can "press" certain switches, so we actually have a
wired-OR feed into a transistor which then connects a particular
(column, row) combination. We do this e.g. for remote-control USB over
the power button for example. I believe the effect is the same, but it
does mean that statement above isn't quite true.
> +driver's operation of activating all columns at the same time for most
Saying "driver" in a DT binding is a slight red flag. The binding should
really purely describe HW, rather than SW's use of it. Here, the use is
probably generic enough not to be an issue, although it there's some way
to reword it to avoid that word it might be good.
> +- gpio-activelow: row pins as well as column pins are active low
That one change is definitely wrong. Each entry in row-gpios and
col-gpios should include GPIO flags (in a format defined by the binding
for the DT node providing the GPIO). Those flags include an active-high
vs. active-low bit. In Linux, you can use of_get_gpio_flags() to
retrieve a standardized representation of the flags.
next prev parent reply other threads:[~2013-06-21 21:31 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 [this message]
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
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=51C4C63B.3030300@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: link
Be 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.