devicetree-spec.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
Cc: devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH] Describe interrupts-extended property
Date: Tue, 3 Jan 2017 15:44:28 -0800	[thread overview]
Message-ID: <f04c76d4-996b-6ffd-d59e-eb992d0a912d@gmail.com> (raw)
In-Reply-To: <20170103230436.GS12761-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>

On 01/03/2017 03:04 PM, David Gibson wrote:
> On Tue, Jan 03, 2017 at 11:24:23AM -0800, Florian Fainelli wrote:
>> The interrupts-extended property is a common property used when
>> interrupt generating devices having interrupt lines in several interrupt
>> controllers with possibly distinct interrupt specifiers.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> Hmm.  Is this actually used in the wild already?

Yes, we have been using this for nearly 3 years now, primarily with
devices that have a "main" interrupt and a "wake-up" interrupt in
separate interrupt controllers. There are existing in kernel tree users
of this as well.

> 
> I'm just wondering if it's really needed, since you can work around
> the limitations with the ordinary interrupts property by setting
> interrupt-parent to the node itself putting an interrupt nexus
> (interrupt-map and interrupt-map-mask properties) in there to redirect
> those to different interrupt controllers.

Well, sure you could do that, and this actually serves a similar, if not
identical purpose, it just appeared that interrupts-extended got
introduced to solve that problem, is supported by Linux, and therefore
may deserve a documentation in the Device Tree spec. I'd have to double
check, but it does not appear to me that the solution you are proposing
is supported by Linux for instance.

Digression: I was actually wondering if we may not have a need to do the
same thing for "reg" properties, where a given device may have memory
mapped I/O registers in one place, and another address in another bus,
with a different address space, this is actually pretty common for e.g:
PHY (Ethernet, PCIe, SATA or USB).

Thanks!

> 
>> ---
>>  source/devicetree-basics.rst | 34 ++++++++++++++++++++++++++++++++++
>>  1 file changed, 34 insertions(+)
>>
>> diff --git a/source/devicetree-basics.rst b/source/devicetree-basics.rst
>> index be80af3d825b..1bda0fa54e7a 100644
>> --- a/source/devicetree-basics.rst
>> +++ b/source/devicetree-basics.rst
>> @@ -955,6 +955,40 @@ Description:
>>     to the interrupt parent. If this property is missing from a device, its
>>     interrupt parent is assumed to be its devicetree parent.
>>  
>> +interrupts-extended
>> +^^^^^^^^^^^^^^^^^^^
>> +
>> +Property: ``interrupts-extended``
>> +
>> +Value type: ``<phandle> <prop-encoded-array>``
>> +
>> +Description:
>> +
>> +   The *interrupts-extended* property of a device node defines the interrupt or
>> +   the interrupts that are generated by the device. In case where an interrupt
>> +   generating devices has several interrupt lines, some of them having distinct
>> +   interrupt parents, the *interrupts-extended* property should be used to
>> +   fully describe the interrupts of this device, relative to the interrupt
>> +   controller(s), which is encoded by the phandle part of the property. The non
>> +   phandle part of the property encodes the interrupt specifiers and obeys to
>> +   the *interrupts* property description.
>> +
>> +   If both *interrupts-extended* and *interrupts* properties are present, the
>> +   *interrupts-extended* properties takes precedence, and the *interrupts*
>> +   property may be provided to a client program for compatibility purposes.
>> +
>> +Example:
>> +
>> +   A device with several interrupt lines in distinct interrupt controllers,
>> +   having different interrupt specifiers is illustrated below. In this example
>> +   ``pic`` is an interrupt controller with an *#interrupt-cells* specifier
>> +   of 2, while ``gic`` is an interrupt controller with an *#interrupts-cells*
>> +   specifier of 1.
>> +
>> +
>> +      ``interrupts-extended = <&pic 0xA 8>, <&gic 0xda>;``
>> +
>> +
>>  Properties for Interrupt Controllers
>>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>  
> 


-- 
Florian

  parent reply	other threads:[~2017-01-03 23:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-03 19:24 [PATCH] Describe interrupts-extended property Florian Fainelli
     [not found] ` <20170103192423.5838-1-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-03 22:24   ` Rob Herring
     [not found]     ` <CAL_Jsq+2TVHGS2onm50rG_AxesJEBUhEGLZNEJN8XAGo4CbMgA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-01-03 22:29       ` Florian Fainelli
2017-01-13  8:51       ` Grant Likely
2017-01-03 23:04   ` David Gibson
     [not found]     ` <20170103230436.GS12761-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
2017-01-03 23:44       ` Florian Fainelli [this message]
     [not found]         ` <f04c76d4-996b-6ffd-d59e-eb992d0a912d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-04  0:31           ` David Gibson
     [not found]             ` <20170104003147.GW12761-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
2017-01-04  0:47               ` Florian Fainelli
     [not found]                 ` <0d9b43f1-147c-5761-9fdd-8ba28c690df9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-04  1:03                   ` Laurent Pinchart
2017-01-04  1:19                     ` Florian Fainelli
     [not found]                       ` <663f501c-4646-8f15-cb90-0477ceff3daf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-04  1:28                         ` Laurent Pinchart

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=f04c76d4-996b-6ffd-d59e-eb992d0a912d@gmail.com \
    --to=f.fainelli-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
    --cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@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).