On Thu, 09 Aug 2018 18:30:53 +0100, Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote: > > Quoting Marc Zyngier (2018-08-07 23:26:32) > > On Tue, 07 Aug 2018 23:05:07 -0700 > > Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote: > > > > > Quoting Lina Iyer (2018-08-02 05:58:27) > > > > On Thu, Aug 02 2018 at 01:27 -0600, Marc Zyngier wrote: > > > > > > > > > >Sure. But once woken up (GIC *and* TLMM), the gpio line (which I > > > > >assume is level) is still high at the TLMM input. So why isn't it > > > > >registering that state once it has been woken up? > > > > > > > > > >I can understand that it would be missing an edge. But that doesn't > > > > >hold for level signalling. > > > > > > > > > Sure, yes. Sorry for not registering your point in my response. > > > > Once woken up we should see the level interrupt in TLMM. > > > > > > And the level type gpio interrupt will trigger the TLMM summary > > > interrupt line after the wakeup? So then the only thing that needs to be > > > replayed is edge interrupts? How are edge interrupts going to be > > > replayed? > > > > Level interrupts should be taken care of without doing anything, by the > > very nature of being a level signal. > > Right. I suspect we'll still need to configure the PDC to actually wake > up on the level triggered signal though so PDC needs to be told to > unmask the line. Surely this can be done at suspend time with the PDC driver tracking the interrupts that are configured as a wake-up source (although it needs to track an interrupt that is logically connected to the TLMM, which sucks). > > Edge interrupts should be replayed using check_irq_resend() after > > taking the right locks and making the interrupt pending. Or, if there > > is a way for SW to make the interrupt pending at the TLMM level, to use > > that as a way to reinject the interrupt (which would be the preferred > > way, as it avoids all kind of ugly locking considerations). > > > > Ok. Looking at the hardware it seems that I can write the interrupt > status bit directly for an edge type interrupt and that causes the > interrupt handler to run. So that's good news, we can use that ability > to directly inject interrupts here. That's pretty good news. It means that if TLMM implements the irq_set_irqchip_state() API, there isn't muc that needs doing, and most of the original ugliness can go. At least I hope. M. -- Jazz is not dead, it just smell funny.
