On 11/14/2012 05:09 AM, Jonas Gorski wrote:

On 13 November 2012 06:00, Stephen Warren [off-list ref] wrote:

quoted

On 11/11/2012 05:50 AM, Jonas Gorski wrote:

quoted

Register IRQ domains through Device Tree for the internal and external
interrupt controllers. Register the same IRQ ranges as previously to
provide backward compatibility for non-DT drivers.

quoted

diff --git a/Documentation/devicetree/bindings/mips/bcm63xx/epic.txt b/Documentation/devicetree/bindings/mips/bcm63xx/epic.txt

Rather than putting binding docs in an arch-specific directory, perhaps
put them into a device-type-specific directory, such as
bindings/interrupt-controller/brcm,bcm63xx-epic.txt?

Almost everyone has their interrupt-controller bindings in
$arch/$platform, but if interrupt-controller is the preferred
location, I can certainly move it there; I have no hard preference for
any location.

Yes, people have been putting them in arch/platform, but I think there's
a move to more type-based locations.

quoted

quoted

diff --git a/arch/mips/bcm63xx/dts/bcm6328.dtsi b/arch/mips/bcm63xx/dts/bcm6328.dtsi

quoted

              ranges = <0 0x10000000 0x20000>;
              compatible = "simple-bus";
+
+             interrupt-parent = <&ipic>;
+
+             perf@0 {
+                     epic: interrupt-controller@18 {

Don't you need some reg properties in the perf and interrupt-controller
nodes so that the register address can be determined?

Since there is no support code for that property yet I did not add it.
I haven't quite finished yet how the final bindings will be (since
there are/were a few things I haven't finished researching yet, e.g.
how this controller works in SMP context, and how interrupt
controllers are supposed to work).

I can add all expected properties now and add support for them later,
but I feel that this might add properties that will then never
supported, and nobody updates the documentation for that, so I'd
rather like to keep the documentation/dts(i) in sync with what the
actual code expects/supports.

The DT bindings and DT content are supposed to be fully defined the
first time around, such that even if the kernel doesn't use the reg
property yet, if you were to use the DT created now with a future kernel
that does use the reg property, it's already there.