From: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Linus Walleij
<linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
Subject: Re: [PATCH] gpio: Describe interrupt-controller binding
Date: Tue, 18 Sep 2012 14:00:45 -0500 [thread overview]
Message-ID: <5058C4DD.5010608@gmail.com> (raw)
In-Reply-To: <20120918184552.GD29360-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
On 09/18/2012 01:45 PM, Thierry Reding wrote:
> On Tue, Sep 18, 2012 at 12:15:02PM -0600, Stephen Warren wrote:
>> On 09/18/2012 12:06 PM, Thierry Reding wrote:
>>> On Tue, Sep 18, 2012 at 08:55:40AM -0600, Stephen Warren wrote:
>>>> On 09/18/2012 07:28 AM, Rob Herring wrote:
>>>>> On 09/18/2012 03:51 AM, Thierry Reding wrote:
>>>>>> In order to use GPIO controllers as interrupt controllers,
>>>>>> they need to be marked with the DT interrupt-controller
>>>>>> property. This commit adds some documentation about this to
>>>>>> the general GPIO binding document.
>>>>>>
>>>>>> Cc: Linus Walleij <linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org> Cc: Grant
>>>>>> Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> Cc: Rob Herring
>>>>>> <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org> Cc:
>>>>>> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Cc:
>>>>>> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Signed-off-by: Thierry Reding
>>>>>> <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
>>>>>
>>>>> Applied for 3.7.
>>>>>
>>>>> Rob
>>>>>
>>>>>> --- Documentation/devicetree/bindings/gpio/gpio.txt | 33
>>>>>> +++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt
>>>>>> b/Documentation/devicetree/bindings/gpio/gpio.txt index
>>>>>> 4e16ba4..8d125b0 100644 ---
>>>>>> a/Documentation/devicetree/bindings/gpio/gpio.txt +++
>>>>>> b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -75,4
>>>>>> +75,37 @@ Example of two SOC GPIO banks defined as
>>>>>> gpio-controller nodes: gpio-controller; };
>>>>>>
>>>>>> +If the GPIO controller supports the generation of
>>>>>> interrupts, it should +also contain an empty
>>>>>> "interrupt-controller" property as well as an
>>>>>> +"#interrupt-cells" property. This is required in order for
>>>>>> other nodes +to use the GPIO controller as their interrupt
>>>>>> parent.
>>>>
>>>> Surely this is generic information for any interrupt controller,
>>>> and hence doesn't belong in the GPIO binding?
>>>
>>> LinusW requested this in order to avoid having to list these
>>> properties in every GPIO controller.
>>
>> There's no need to list this property in an individual GPIO
>> controller's binding either; it's a standard property for any
>> interrupt controller of any type.
>>
>>> I suppose that having it in an extra binding for interrupt
>>> controllers might make sense as well, but in that case we should
>>> probably provide a reference because the GPIO binding is where
>>> people are most likely to look for this information.
>>
>> Yes, we probably should have a centralized .txt for the base interrupt
>> controller properties. I guess we don't today because it's probably so
>> old everyone assumes it.
>
> Since each driver binding still needs to document it and in order to
> avoid needless duplication I think having a central location for this
> makes a lot of sense.
>
>> For some other patches I sent, I created
>> Documentation/devicetree/bindings/interrupt-controller/ - a file in
>> that directory would make sense (bike-shedding: irq.txt, interrupts.txt?)
>>
>> Yes, each individual GPIO binding (that actually is an interrupt
>> controller; some may not be) should probably mention this and refer to
>> whatever documents the interrupt controller properties.
>
> Okay. So how about I add a file interrupts.txt in that directory and put
> something like what this patch contains into it? Then I can just add a
> reference to the driver binding that the controller can be used as an
> interrupt-controller and that a description can be find in this new
> document.
>
>>> There is Documentation/devicetree/bindings/open-pic.txt, which
>>> already lists most of this information, so maybe a reference to
>>> that document will do just as well?
>>
>> I think that's just one random interrupt controller. The common/core
>> properties probably should be separated out.
>>
>>>>>> +If #interrupt-cells is 1, the single cell is used to specify
>>>>>> the number +of the GPIO that is to be used as an interrupt.
>>>>>> + +If #interrupt-cells is 2, the first cell is used to
>>>>>> specify the number +of the GPIO that is to be used as an
>>>>>> interrupt, whereas the second cell +is used to specify any of
>>>>>> the following 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
>>>>
>>>> That certainly shouldn't be in the generic GPIO binding; the
>>>> format of the interrupt specifier is determined by the binding
>>>> for the individual device that is the interrupt controller. Just
>>>> because a device is also a GPIO controller doesn't mean that it
>>>> has to conform to a specific format for the interrupt specifier.
>>>
>>> I think it does make sense to provide a description of the most
>>> commonly used variants. The above certainly is what the majority is
>>> using and many of those that do not use one of the predefined
>>> irq_domain_xlate_*() functions reimplement them with some
>>> additional checks or conversions.
>>
>> OK, but the document can't say "this is how the IRQ specifier is
>> formatted", when it clearly isn't generally true.
>>
>> The document should say that the format of the IRQ specifier is
>> entirely determined by the individual binding, but that bindings may
>> often choose to re-use the following common format. Each individual
>> binding would then need to document whether it did choose to use that
>> common format, or whether it instead chose something custom.
>
> Yes, that makes sense.
>
> Rob, given the above discussion I think it'd be better if I followed up
> with a patch that moves this description into a more generic location
> and we removed this patch.
Yes, agreed.
Rob
next prev parent reply other threads:[~2012-09-18 19:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-18 8:51 [PATCH] gpio: Describe interrupt-controller binding Thierry Reding
[not found] ` <1347958274-19425-1-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
2012-09-18 13:28 ` Rob Herring
2012-09-18 14:55 ` Stephen Warren
2012-09-18 18:06 ` Thierry Reding
2012-09-18 18:15 ` Stephen Warren
2012-09-18 18:45 ` Thierry Reding
[not found] ` <20120918184552.GD29360-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-09-18 19:00 ` Rob Herring [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-09-18 8:35 Thierry Reding
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=5058C4DD.5010608@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 \
/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).