linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <swboyd@chromium.org>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Lina Iyer <ilina@codeaurora.org>,
	evgreen@chromium.org, linus.walleij@linaro.org,
	bjorn.andersson@linaro.org, rplsssn@codeaurora.org,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	rnayak@codeaurora.org, devicetree@vger.kernel.org
Subject: Re: [PATCH RESEND RFC 1/4] drivers: pinctrl: qcom: add wakeup capability to GPIO
Date: Thu, 09 Aug 2018 10:30:53 -0700	[thread overview]
Message-ID: <153383585322.220756.9422019201626837843@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20180808072632.21f076b6@why.wild-wind.fr.eu.org>

Quoting Marc Zyngier (2018-08-07 23:26:32)
> On Tue, 07 Aug 2018 23:05:07 -0700
> Stephen Boyd <swboyd@chromium.org> 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.

> 
> 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.


  reply	other threads:[~2018-08-09 17:30 UTC|newest]

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 [this message]
2018-08-10  7:45                     ` Marc Zyngier
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 publicly 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 \
    --in-reply-to=153383585322.220756.9422019201626837843@swboyd.mtv.corp.google.com \
    --to=swboyd@chromium.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=evgreen@chromium.org \
    --cc=ilina@codeaurora.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=rnayak@codeaurora.org \
    --cc=rplsssn@codeaurora.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).