Re: [PATCH 4/7] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO

[Stephen Boyd]

Quoting Rob Herring (2019-01-09 11:36:56)
> 
> > >However, my main concern is documenting something genericish in a
> > >device specific binding. It looks like Tegra is trying to add the same
> > >thing, so this needs to be documented in a common place. One question
> > >is whether wakeup is the only use or if this should be more generally
> > >a secondary interrupt parent?
> > >
> > Yes, wakeup is the only use of this interrupt parent.
> 
> Maybe for you, but I was wondering about this more generally. Should
> we encode what the function (e.g. wakeup) is in the property name or
> have something like aux-interrupt-controller? Maybe some platforms
> have some need for a secondary interrupt-controller which is not
> wakeup. Routing interrupts to other cores perhaps?
> 

I'd say it's not the interrupt-parent, but a secondary-interrupt-parent,
because it's another path that some GPIO interrupts will go through vs.
the "normal" summary irq line that uses the interrupt-parent. Maybe
that's similar to the interrupt partitioning that ARM is doing for PPIs
that only go to some CPUs?

We don't really specify that some GPIO is corresponding to the secondary
or primary interrupt controller for the GPIO controller in DT. If we
did, then we could do something like the interrupt-map binding and have
the index of that property be the gpio number and the interrupt parent
that it maps to (either summary from the GIC or MPM pin number).

 interrupt-map = <0 0 &gic GIC_SPI 208 0>,
                 <1 0 &pdc 3 0>;
 interrupt-map-mask = <0xfffffff 0>;

And then we would pass the 2-cell GPIO interrupt specifier (gpio# and
flags) through the table and remap it to arbitrary domain parents. We
could use this same design for the SSBI and SPMI gpio interrupt
controller where we're currently looking at hardcoding the base
interrupt number in the driver (0xc0) and then adding the GPIO number to
that to get the parent interrupt specifier.

It's sort of an abuse of interrupt-map, but I don't know if it really
matters because there isn't a child of the gpio controller that is going
to go through this table.