Re: [PATCH] of/irq: lookup 'interrupts-extended' property first

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 08/06/2014 02:50 PM, Tim Bird wrote:
> On Wed, Aug 6, 2014 at 1:12 PM, Brian Norris
> <computersforpeace@xxxxxxxxx> wrote:
>> On Wed, Aug 06, 2014 at 01:42:08PM -0500, Rob Herring wrote:
>>> On Wed, Aug 6, 2014 at 11:54 AM, Brian Norris <computersforpeace@xxxxxxxxx> wrote:
>>>> On Thu, Jul 31, 2014 at 11:00:01AM -0700, Florian Fainelli wrote:
>>>> I think it is important that a device tree provide some flexibility on
>>>> kernel versions. We only invented 'interrupts-extended' in Linux 3.13,
>>>> so it's easy to have device trees that could work only on 3.13+.
>>>>
>>>> Typically, we might say that new features require new kernels, but this
>>>> is a very basic piece of the DT infrastructure. In our case, we have
>>>> hardware whose basic features can be supported by a single interrupt
>>>> parent, and so we used the 'interrupts' property pre-3.13. But when we
>>>> want to add some power management features, there's an additional
>>>> interrupt parent. Under the current DT binding, we have to switch over
>>>> to using 'interrupts-extended' exclusively, and thus we must have a
>>>> completely new DTB for >=3.13, and this DTB no longer works with the old
>>>> kernels.
>>>
>>> "Must have" to enable the new features?
>>
>> Yes. The new feature requires an additional interrupt parent, and so it
>> requires interrupts-extended.
> 
> Hold on there.  What about interrupt-map?  That was the traditional DT
> feature for
> supporting multi-parented interrupts.  Why couldn't the feature have been added
> using that instead of interrupts-extended?

As far as I read it from the ePAPR specification, you have a good point
here, it looks like 'interrupt-map' could have been used as-is instead
of 'interrupts-extended'. In fact it is a little more general than
'interrupts-extended' since it allows any sort of "child unit address",
whether that is an actual interrupt number, or something else, is
dependent on the type of node being used.

> 
> I know interrupts-extended is preferred, but has interrupt-map support been
> removed from recent kernels?  I'm a bit confused.

'interrupt-map' support has not been removed since that is heavily used
to cross interrupt domains, e.g: PCI relies heavily on it, other buses
as well most likely.

> 
>  -- Tim Bird
> Senior Software Engineer, Sony Mobile
> Architecture Group Chair, CE Workgroup, Linux Foundation
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux