lkml.org 
[lkml]   [2019]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 4/7] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO
    From
    Date
    Quoting Stephen Boyd (2019-01-11 15:20:48)
    > 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.
    >

    Rob, can you please respond?

    \
     
     \ /
      Last update: 2019-01-23 21:53    [W:3.845 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site