On 08/13/2012 09:40 PM, Wang Dongsheng-B40534 wrote:
quoted
quoted
quoted
+Example 2:
quoted
+
+ timer: timer@010f0 {
+ compatible = "open-pic,global-timer";
+ device_type = "open-pic";
+ reg = <0x010f0 4 0x01100 0x100>;
+ interrupts = <0 0 3 0
+ 1 0 3 0
+ 2 0 3 0
+ 3 0 3 0>;
+ };
4-cell interrupt specifiers are specific to Freescale MPICs. This
means there's no way to describe the timer interrupt on a non-
Freescale openpic.
quoted
quoted
Again, I suggest we not bother with this in the absence of an actual
need to support the timer on non-Freescale openpic in partitioned
scenarios.
quoted
quoted
The existing openpic node is sufficient to describe the
hardware in the absence of partitioning. We could have an
"openpic-no-timer" property to indicate that we're describing it
separately, so that the absence of a timer node isn't ambiguous as to
whether it's an old tree or a partitioned scenario. An fsl,mpic
compatible would imply openpic-no-timer.
Note that I believe many of the non-Freescale openpic nodes are going
to be found on systems with real Open Firmware, so we can't go
changing the device tree for them.
[Wang Dongsheng] In the Open-PIC specification, there are four timer.
interrupts = <0 0 3 0
1 0 3 0
2 0 3 0
3 0 3 0>;
The "interrupts" just let user know there are four timers. Usage based
"interrupts"
quoted
binding to change dts.
I can't understand the above or how it's a response to what I wrote.
[Wang Dongsheng] I mean this just to tell how many timers to support in Open-PIC
specification. If someone needs to write "interrupts" into dts, this must comply
with the specification of the interrupt to write. this is based on the pic driver
should be changed in different platforms.
My point (beyond that examples provided should be valid for *some*
system) is there is no valid thing to put in the interrupts property
here when the interrupt controller is not "fsl,mpic", so this doesn't work.
-Scott