devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Thierry Reding
	<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	Linus Walleij
	<linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v2] gpio: Add Avionic Design N-bit GPIO expander support
Date: Tue, 31 Jul 2012 17:03:05 -0500	[thread overview]
Message-ID: <50185619.5090706@gmail.com> (raw)
In-Reply-To: <20120730074714.GC15245-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>

On 07/30/2012 02:47 AM, Thierry Reding wrote:
> On Sun, Jul 29, 2012 at 07:13:57PM +0200, Linus Walleij wrote:
>> On Mon, Jul 23, 2012 at 1:59 PM, Thierry Reding
>> <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
>>
>>> This commit adds a driver for the Avionic Design N-bit GPIO expander.
>>> The expander provides a variable number of GPIO pins with interrupt
>>> support.
>> (...)
>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-adnp.txt b/Documentation/devicetree/bindings/gpio/gpio-adnp.txt
>>> new file mode 100644
>>> index 0000000..513a18e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/gpio/gpio-adnp.txt
>>> @@ -0,0 +1,38 @@
>>> +Avionic Design N-bit GPIO expander bindings
>>> +
>>> +Required properties:
>>> +- compatible: should be "ad,gpio-adnp"
>>> +- reg: The I2C slave address for this device.
>>> +- interrupt-parent: phandle of the parent interrupt controller.
>>> +- interrupts: Interrupt specifier for the controllers interrupt.
>>> +- #gpio-cells: Should be 2. The first cell is the GPIO number and the
>>> +  second cell is used to specify optional parameters:
>>> +  - bit 0: polarity (0: normal, 1: inverted)
>>> +- gpio-controller: Marks the device as a GPIO controller
>>> +- #interrupt-cells: Should be 2. The first cell contains the GPIO number,
>>> +  whereas the second cell is used to specify flags:
>>> +    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
>>
>> Why on earth would a bunch of flags be an "interrupt cell"?
>>
>> Maybe there is something about DT bindings I don't get so
>> please educate me.
>>
>> I can see that OMAP is doing this, but is it a good idea?
>> I really need Rob/Grant to comment on this.
>>
>>> +- interrupt-controller: Marks the device as an interrupt controller.
>>> +- nr-gpios: The number of pins supported by the controller.
>>
>> These two last things look very generic, like something every GPIO
>> driver could want to expose.
> 
> As Arnd mentioned, interrupt-controller is a generic property required
> by all interrupt controller nodes. Perhaps it shouldn't be listed in the
> DT binding for this driver.
> 
> As to the nr-gpios property, this is actually not only for informational
> purposes, but it also allows the driver to be configured to handle any
> number of bits (powers of two). However since this is also a description
> of the hardware it may be useful to make this into a generic property
> for GPIO controllers.
> 
>> I'd really like to have Grant's word on GPIO DT bindings and how these
>> should look, I had some discussion with Wolfram (the I2C maintainer)
>> about bindings turning out less generic than they ought to be, so we
>> need some discussion on this.
>>
>> Arnd recently consolidated some MMC props, maybe we need to do
>> the same for GPIO drivers.

For nr-gpios, I think it is typically not needed. Generally, you will
know how many gpio lines the h/w has based on the compatible string. If
this part really is the same part but different packages with different
numbers of gpio, then this property makes sense. Otherwise, I would say
drop it.

If your goal is how many gpios are you using, you really need a bitmap
instead if you want it to be generic.

IIRC, Tegra also needed this in that they N instances of some number of
bits and the registers are interleaved so they can't have separate nodes.

Rob

  parent reply	other threads:[~2012-07-31 22:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-23 11:59 [PATCH v2] gpio: Add Avionic Design N-bit GPIO expander support Thierry Reding
     [not found] ` <1343044770-6591-1-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
2012-07-29 17:13   ` Linus Walleij
2012-07-29 20:27     ` Arnd Bergmann
     [not found]     ` <CACRpkdaZcUvcJMUZTqCEU5FQYhE3EvSSfUEnEx0dYRt-6x5Nig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-07-30  7:47       ` Thierry Reding
     [not found]         ` <20120730074714.GC15245-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-07-31 22:03           ` Rob Herring [this message]
2012-07-31 23:22             ` Stephen Warren
     [not found]             ` <50185619.5090706-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-08-02  6:18               ` Thierry Reding
2012-08-05 10:50           ` Linus Walleij
     [not found]             ` <CACRpkdbrdWw_HR91r72aB_S2+vxiaSBKHwW+Tsmi8pKk9VsgFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-08-06  5:11               ` Thierry Reding
     [not found]                 ` <20120806051144.GA12642-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-08-06  6:39                   ` Linus Walleij
2012-08-09  6:27             ` Thierry Reding
2012-08-09 20:20     ` Thierry Reding
     [not found]       ` <20120809202054.GA24503-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-08-10  8:19         ` Linus Walleij
2012-08-10  8:35           ` Thierry Reding
     [not found]             ` <20120810083508.GA16251-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-08-10  8:41               ` Linus Walleij
2012-08-10  8:48                 ` Thierry Reding
2012-08-10  9:15                 ` Russell King - ARM Linux

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=50185619.5090706@gmail.com \
    --to=robherring2-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org \
    --cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.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).