[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180801223635.GO30024@minitux>
Date: Wed, 1 Aug 2018 15:36:35 -0700
From: Bjorn Andersson <bjorn.andersson@...aro.org>
To: Lina Iyer <ilina@...eaurora.org>
Cc: Marc Zyngier <marc.zyngier@....com>, swboyd@...omium.org,
evgreen@...omium.org, linus.walleij@...aro.org,
rplsssn@...eaurora.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, rnayak@...eaurora.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH RESEND RFC 1/4] drivers: pinctrl: qcom: add wakeup
capability to GPIO
On Wed 01 Aug 12:45 PDT 2018, Lina Iyer wrote:
> Thanks for the feedback, Marc.
>
> On Wed, Aug 01 2018 at 00:31 -0600, Marc Zyngier wrote:
> > On Wed, 01 Aug 2018 03:00:18 +0100,
> > Lina Iyer <ilina@...eaurora.org> wrote:
[..]
> > Why isn't that the case? And if that's because the HW is broken and
> > doesn't buffer edge interrupts, why can't you use the resend mechanism
> > instead?
> >
> The PDC hardware can replay the interrupts accurately. However, it will
> replay only the pin and its not the TLMM summary IRQ. The handler here,
> needs to notify the driver that the wakeup interrupt happened and needs
> to take action. If I could trip the summary IRQ in this handler that
> would work too. Can it be done?
>
Does this means that the intr_status_reg will not hold the information
about the interrupt events that occurred before we powered on the TLMM
again? Or is the problem limited to it not triggering the TLMM IRQ?
Can the PDC (and MPM) be used in the non-sleep use cases as well?
Regards,
Bjorn
Powered by blists - more mailing lists