Subject: [PATCH v3 1/8] ARM/dts: omap2: Add McBSP entries for OMAP2420 and OMAP2430 SoC

From: [email-masked] (Benoit Cousson)
Date: Mon, 10 Sep 2012 10:07:24 +0200

Hi Tony,

On 09/08/2012 12:29 AM, Tony Lindgren wrote:
> * Peter Ujfalusi <[email-masked]> [120905 04:59]:
>> +
>> +	ocp {
>> +		mcbsp1: mcbsp at 48074000 {
>> +			compatible = "ti,omap2420-mcbsp";
>> +			reg = <0x48074000 0xff>;
>> +			reg-names = "mpu";
>> +			interrupts = <59>, /* TX interrupt */
>> +				     <60>; /* RX interrupt */
>> +			interrupt-names = "tx", "rx";
>> +			interrupt-parent = <&intc>;
>> +			ti,hwmods = "mcbsp1";
>> +		};
>> +
>> +		mcbsp2: mcbsp at 48076000 {
>> +			compatible = "ti,omap2420-mcbsp";
>> +			reg = <0x48076000 0xff>;
>> +			reg-names = "mpu";
>> +			interrupts = <62>, /* TX interrupt */
>> +				     <63>; /* RX interrupt */
>> +			interrupt-names = "tx", "rx";
>> +			interrupt-parent = <&intc>;
>> +			ti,hwmods = "mcbsp2";
>> +		};
>> +	};
> 
> Hmm don't you need to specify the interrupt chip and offset for
> the interrupts here?

Mmm, I'm not sure to get your question, there is the link to the
interrupt-parent.

The interrupt number is relative to the parent interrupt domain. So even
if the INTC IRQ offset start at 32 instead of 0, DT IRQ mechanism will
convert that to the proper hwirq thanks to irqdomain.
In that case we should always provide interrupt number relative to the
interrupt controller HW number and not assuming any Linux IRQ number
offset like before.

And in fact the interrupt-parent is not even needed, by default if will
look to the parent to get the interrupt-controller.

Extract from [1]

interrupt-parent:
"Because the hierarchy of the nodes in the interrupt tree might not
match the device tree, the interrupt-parent property is available to
make the definition of an interrupt parent explicit.
The value is the phandle to the interrupt parent. If this property is
missing from a device, its interrupt parent is assumed to be its device
tree parent."

[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

Regards,
Benoit