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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).