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

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.

quoted

+- #interrupt-cells: <2>
+  This controller supports level and edge triggered interrupts. The
+  first cell is the interrupt number, the second is a 1:1 mapping to
+  the linux interrupt flags.

The DT documentation should be self-contained, and not reference
anything OS-specific. In this case, you could reference
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
for the interrupt flags.

Good Idea, I'll do that for the next iteration.

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.


Jonas