On Tue, Jan 03, 2017 at 03:44:28PM -0800, Florian Fainelli wrote: > 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@xxxxxxxxx> > > > > 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. Ok, fair enough then. > > 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. Right. The point is I used this workaround to avoid inventing something like interrupts-extended nearly 10 years ago (for the Bamboo 440EP board I think). Admittedly the workaround is pretty ugly. > 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). I've wondered about something like that for some time (my working name was 'bus-reg'). The use cases I encountered were on PPC4xx machines which had lots of things controlled (at least partially) by the sideband "DCR" (Device Control Register) bus. We did invent a 'dcr-reg' property to cover that specific case, and I think something similar has been done for some other sideband busses. Something like 'bus-reg' would be a more general solution to the problem. I believe the "classic" IEEE1275 way of solving this is to have separate nodes on each of the relevant busses, with phandle pointers linking them together. The relevant driver would claim all the related nodes. Again, it gets pretty messy, though. > >> --- > >> 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 > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> > > > > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
