Hi Rob,
Many thanks for a quick review!
On 30 October 2018 23:04, Rob Herring wrote:
> On Tue, Oct 30, 2018 at 10:44:37AM +0000, Phil Edworthy wrote:
> > Add device binding documentation for the Renesas RZ/N1 GPIO interrupt
> > multiplexer.
> >
<snip>
> This looks a bit strange...
>
> > +
> > + gpioirqmux: gpioirqmux@51000480 {
> > + compatible = "renesas,r9a06g032-gpioirqmux",
> > + "renesas,rzn1-gpioirqmux";
> > + reg = <0x51000480 0x20>;
> > +
>
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + interrupt-parent = <&gpioirqmux_map>;
> > + interrupts =
> > + <0 1 17>, /* gpio1a 17 */
> > + <1 1 24>, /* gpio1a 24 */
> > + <2 1 26>; /* gpio1a 26 */
>
> Remove all these and...
>
> > +
> > + gpioirqmux_map: gpioirqmux-map {
>
> Move everything in this node up a level.
>
> > + #interrupt-cells = <3>;
>
> This should be 1.
>
> Or perhaps 2 cells if you need the GPIO controller index (cell 2 above).
> But is that numbering really meaningful to the GPIO irq mux or does it just
> have Nx32 inputs? #interrupt-cells should be defined based on the GPIO irq
> mux, not what it is connected to. You could always have a single linear
> number space and mask out bits to get banks if you need to.
You are absolutely correct, the irq mux should not concern itself with where
interrupts came from, all it sees is 96 inputs.
> > + #address-cells = <0>;
> > + interrupt-map-mask = <7 0 0>;
>
> Then 1 cell here, but the mask should be 31.
>
> > + interrupt-map =
> > + <0 0 0 &gic GIC_SPI 103
> IRQ_TYPE_LEVEL_HIGH>,
>
> Then this should be:
>
> <17 &gic GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>
>
> > + <1 0 0 &gic GIC_SPI 104
> IRQ_TYPE_LEVEL_HIGH>,
>
> <24 &gic GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>
>
> If I understand what you are trying to do. :)
I think you do!
>
> If the 0-7 numbering and mapping to the downstream numbering was
> important (i.e. the 1 combined with 1 and 24 in the interrupts property), then
> you can use the index of the interrupt-map entries for that.
Yes, the 0-7 numbering and mapping are important as we need to pin the input
interrupt to a specific output interrupt due to firmware running on another core.
Using the index makes complete sense.
> > + <2 0 0 &gic GIC_SPI 105
> IRQ_TYPE_LEVEL_HIGH>,
> > + <3 0 0 &gic GIC_SPI 106
> IRQ_TYPE_LEVEL_HIGH>,
> > + <4 0 0 &gic GIC_SPI 107
> IRQ_TYPE_LEVEL_HIGH>,
> > + <5 0 0 &gic GIC_SPI 108
> IRQ_TYPE_LEVEL_HIGH>,
> > + <6 0 0 &gic GIC_SPI 109
> IRQ_TYPE_LEVEL_HIGH>,
> > + <7 0 0 &gic GIC_SPI 110
> IRQ_TYPE_LEVEL_HIGH>;
>
> These all seem to be unused?
I think that's just an artefact of the way I abused interrupt-map!
Thanks
Phil
> > + };
> > + };
> > +
> > + gpio1: gpio@5000c000 {
> > + compatible = "snps,dw-apb-gpio";
> > + reg = <0x5000c000 0x80>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + clock-names = "bus";
> > + clocks = <&sysctrl R9A06G032_HCLK_GPIO1>;
> > +
> > + gpio1a: gpio-controller@0 {
> > + compatible = "snps,dw-apb-gpio-port";
> > + bank-name = "gpio1a";
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + snps,nr-gpios = <32>;
> > + reg = <0>;
> > +
> > + interrupt-controller;
> > + interrupt-parent = <&gpioirqmux>;
> > + interrupts = < 0 1 2 3 4 5 6 7
> > + 8 9 10 11 12 13 14 15
> > + 16 17 18 19 20 21 22 23
> > + 24 25 26 27 28 29 30 31 >;
> > + #interrupt-cells = <2>;
> > + };
> > + };
> > --
> > 2.17.1
>
