From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings
Date: Fri, 11 May 2012 13:12:05 -0600 [thread overview]
Message-ID: <20120511191205.9BD0E3E0791@localhost> (raw)
In-Reply-To: <4F83E041.7040108@linaro.org>
On Tue, 10 Apr 2012 08:24:49 +0100, Lee Jones <lee.jones@linaro.org> wrote:
> On 06/04/12 05:20, Grant Likely wrote:
> > On Thu, 5 Apr 2012 10:55:45 +0100, Lee Jones<lee.jones@linaro.org> wrote:
> >> Add required documentation for specific gpio-nomadik DT bindings.
> >>
> >> Signed-off-by: Lee Jones<lee.jones@linaro.org>
> >> ---
> >> .../devicetree/bindings/gpio/gpio-nmk.txt | 29 ++++++++++++++++++++
> >> 1 files changed, 29 insertions(+), 0 deletions(-)
> >> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> >> new file mode 100644
> >> index 0000000..1555029
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> >> @@ -0,0 +1,29 @@
> >> +Nomadik GPIO controller
> >> +
> >> +Required properties:
> >> +- compatible : Should be "stmicroelectronics,nomadik-gpio".
> >
> > "stmicroelectronics," is a really long prefix. You can use simply
> > "st," here since it has already been defined and documented in
> > Documentation/devicetree/bindings/vendor-prefixes.txt
>
> Absolutely.
>
> >> +- reg : Physical base address and length of the controller's registers.
> >> +- interrupts : The interrupt outputs from the controller.
> >> +- #gpio-cells : Should be two:
> >> + The first cell is the pin number.
> >> + The second cell is used to specify optional parameters:
> >> + - bits[3:0] trigger type and level flags:
> >> + 1 = low-to-high edge triggered.
> >> + 2 = high-to-low edge triggered.
> >> + 4 = active high level-sensitive.
> >> + 8 = active low level-sensitive.
> >
> > Those look like interrupt flags, not gpio flags. If the gpio lines
> > can be used as generic irq input lines, then this node should also
> > declare itself as an interrupt controller.
>
> They can and it will do in an up-coming patch.
>
> >> +- gpio-controller : Marks the device node as a GPIO controller.
> >> +- supports-sleepmode : Specifies whether controller can sleep or not
> >
> > Typically, custom properites that are for a specific device should be
> > prefixed with the manufacturer name. So, something like:
> > "st,has-sleepmode".
>
> No problem.
>
> >> +- gpio-bank : Specifies which bank a controller owns.
> >
> > What is this for (how is it used)? It shouldn't be needed to specify
> > a bank number.
>
> Briefly, it is used like this:
>
> of_property_read_u32(np, "gpio-bank", &bank);
> chip->base = bank * NMK_GPIO_PER_CHIP;
> nmk_chip->bank = bank;
>
> Is that wrong? If so, is there a better way to do it?
(sorry for the late reply on this, I've been tied up with other stuff.
I know you've posted updated patches, but I haven't looked at them
yet. This answer may be obsolete by now, but I'm sending it anyway
for background).
It's not strictly wrong, but it looks a lot like the "cell-index"
pattern which is appropriate sometimes, but always comes under
scrutiny first. It makes me wonder what the driver needs it for. ie.
Are the banks all part of a single GPIO device? If they are really
independent, the the bank number should be irrelevant because the base
address identifies how to control the device. Or, is there a shared
resource that needs the bank number to access correctly?
If they a single device then a better binding might be a single node
with #gpio-cells = <3> with the first cell specifying a bank and the
second specifying the gpio number. Or if the GPIOs appear in a flat
number space, then you could use the exact same numbering as found in
the user-manual for the chip.
g.
next prev parent reply other threads:[~2012-05-11 19:12 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-05 9:55 [0/7] Next round of DT enablement for ux500/Snowball Lee Jones
2012-04-05 9:55 ` [PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement Lee Jones
2012-04-10 9:03 ` Linus Walleij
2012-04-10 9:26 ` Lee Jones
2012-04-10 11:02 ` Linus Walleij
2012-04-10 11:15 ` Lee Jones
2012-04-05 9:55 ` [PATCH 2/7] ARM: ux500: New DT:ed u8500_init_devices " Lee Jones
2012-04-10 9:05 ` Linus Walleij
2012-04-05 9:55 ` [PATCH 3/7] drivers/gpio: gpio-nomadik: Apply Device Tree bindings Lee Jones
2012-04-10 9:14 ` Linus Walleij
2012-04-10 9:19 ` Linus Walleij
2012-04-05 9:55 ` [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for " Lee Jones
2012-04-06 4:20 ` Grant Likely
2012-04-10 7:24 ` Lee Jones
2012-05-11 19:12 ` Grant Likely [this message]
2012-05-11 22:18 ` Linus Walleij
2012-05-11 22:24 ` Grant Likely
2012-05-14 8:33 ` Lee Jones
2012-04-05 9:55 ` [PATCH 5/7] ARM: ux500: Rename gpio_keys in the Device Tree file Lee Jones
2012-04-10 9:16 ` Linus Walleij
2012-04-05 9:55 ` [PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants Lee Jones
2012-04-05 12:36 ` Russell King - ARM Linux
2012-04-05 13:45 ` Lee Jones
2012-04-06 4:14 ` Grant Likely
2012-04-09 14:27 ` Arnd Bergmann
2012-04-09 14:41 ` Chris Ball
2012-04-05 9:55 ` [PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings Lee Jones
2012-04-18 13:04 ` Arnd Bergmann
2012-04-18 14:25 ` Pawel Moll
2012-04-18 14:29 ` Lee Jones
2012-04-18 16:32 ` Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2012-04-05 10:25 [PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement Lee Jones
2012-04-05 10:25 ` [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings Lee Jones
2012-04-13 14:05 [PATCH 0/7 v2] Next round of DT enablement for ux500/Snowball Lee Jones
2012-04-13 14:05 ` [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings Lee Jones
2012-04-13 14:59 ` Lee Jones
2012-04-16 8:43 ` Linus Walleij
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=20120511191205.9BD0E3E0791@localhost \
--to=grant.likely@secretlab.ca \
--cc=linux-arm-kernel@lists.infradead.org \
/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.