From: Marc Zyngier <email@example.com> To: Stephen Boyd <firstname.lastname@example.org> Cc: Lina Iyer <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH RESEND RFC 1/4] drivers: pinctrl: qcom: add wakeup capability to GPIO Date: Fri, 10 Aug 2018 08:45:12 +0100 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On Thu, 09 Aug 2018 18:30:53 +0100, Stephen Boyd <firstname.lastname@example.org> wrote: > > Quoting Marc Zyngier (2018-08-07 23:26:32) > > On Tue, 07 Aug 2018 23:05:07 -0700 > > Stephen Boyd <email@example.com> 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.
next prev parent reply index Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-01 2:00 [PATCH RESEND RFC 0/4] Wakeup GPIO support for SDM845 SoC Lina Iyer 2018-08-01 2:00 ` [PATCH RESEND RFC 1/4] drivers: pinctrl: qcom: add wakeup capability to GPIO Lina Iyer 2018-08-01 6:31 ` Marc Zyngier 2018-08-01 19:45 ` Lina Iyer 2018-08-01 22:36 ` Bjorn Andersson 2018-08-02 2:10 ` Lina Iyer 2018-08-02 6:08 ` Marc Zyngier 2018-08-02 6:51 ` Lina Iyer 2018-08-02 7:27 ` Marc Zyngier 2018-08-02 12:58 ` Lina Iyer 2018-08-08 6:05 ` Stephen Boyd 2018-08-08 6:26 ` Marc Zyngier 2018-08-09 17:30 ` Stephen Boyd 2018-08-10 7:45 ` Marc Zyngier [this message] 2018-08-10 15:06 ` Stephen Boyd 2018-08-10 16:15 ` Lina Iyer 2018-08-01 2:00 ` [PATCH RESEND RFC 2/4] drivers: pinctrl: qcom: add wakeup gpio map for sdm845 Lina Iyer 2018-08-01 8:42 ` Marc Zyngier 2018-08-01 20:04 ` Lina Iyer 2018-08-13 19:41 ` Lina Iyer 2018-08-14 9:26 ` Marc Zyngier 2018-08-01 2:00 ` [PATCH RESEND RFC 3/4] arm64: dts: msm: add PDC device bindings " Lina Iyer 2018-08-01 2:00 ` [PATCH RESEND RFC 4/4] arm64: dts: qcom: add wake up interrupts for GPIOs Lina Iyer
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ firstname.lastname@example.org email@example.com public-inbox-index lkml Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/ public-inbox