From: Lina Iyer <email@example.com>
To: Stephen Boyd <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org,
Subject: Re: [PATCH RESEND v1 2/5] drivers: pinctrl: msm: enable PDC interrupt only during suspend
Date: Tue, 4 Sep 2018 15:09:34 -0600 [thread overview]
Message-ID: <20180904210934.GA23990@codeaurora.org> (raw)
On Mon, Aug 27 2018 at 14:01 -0600, Stephen Boyd wrote:
>Quoting Lina Iyer (2018-08-24 10:14:32)
>> On Fri, Aug 24 2018 at 02:22 -0600, Stephen Boyd wrote:
>> >Quoting Lina Iyer (2018-08-17 12:10:23)
>> >> During suspend the system may power down some of the system rails. As a
>> >> result, the TLMM hw block may not be operational anymore and wakeup
>> >> capable GPIOs will not be detected. The PDC however will be operational
>> >> and the GPIOs that are routed to the PDC as IRQs can wake the system up.
>> >> To avoid being interrupted twice (for TLMM and once for PDC IRQ) when a
>> >> GPIO trips, use TLMM for active and switch to PDC for suspend. When
>> >> entering suspend, disable the TLMM wakeup interrupt and instead enable
>> >> the PDC IRQ and revert upon resume.
>> >What about idle paths? Don't we want to disable the TLMM interrupt and
>> >enable the PDC interrupt when the whole cluster goes idle so we get
>> >wakeup interrupts?
>> We would need to do this from the idle paths. When we have that support
>> (a patch for cluster power down is in the works), we would need to hook
>> up to TLMM and do the same.
>Ok so then this approach doesn't really seem to work for the CPU idle
>> >Because of this complicated dance, it may make sense to always get the
>> >interrupt at the PDC and then replay it into the TLMM chip "manually"
>> >with the irq_set_irqchip_state() APIs. This way the duplicate interrupt
>> >can't happen. The only way for the interrupt handler to run would be by
>> >PDC poking the TLMM hardware to inject the irq into the status register.
>> If the PDC interrupt was always enabled and the interrupt at TLMM was
>> always disabled, all we would need to set the action handler of the PDC
>> interrupt to that of the TLMM. I couldn't find a way to retrieve that
>Can't we just configure a different chained IRQ handler with
>irq_set_chained_handler_and_data() for each of the GPIO IRQs that are
>handled by PDC to be the interrupts provide by the PDC irq controller
>that match the GPIOs? And then set their parent irq with
>irq_set_parent() for completeness? And also move those GPIOs from the
>existing msm_gpio irqchip to a different PDC gpio irqchip that does
>nothing besides push irqchip calls up to the PDC irqchip? Then we don't
>even have to think about resending anything and we can rely on PDC to do
>all the interrupt sensing all the time but still provide the irqs from
>the GPIO controller.
Seems like the irqchips need to be in hierarchy for this to work, which
is not the case with TLMM and the PDC, currently.
next prev parent reply other threads:[~2018-09-04 21:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-17 19:10 [PATCH RESEND v1 0/5] Wakeup GPIO support for SDM845 SoC Lina Iyer
2018-08-17 19:10 ` [PATCH RESEND v1 1/5] dt-bindings: pinctrl: add wakeup capable GPIOs for SDM845 Lina Iyer
2018-08-20 22:16 ` Rob Herring
2018-08-20 23:19 ` Bjorn Andersson
2018-08-21 8:37 ` Marc Zyngier
2018-08-17 19:10 ` [PATCH RESEND v1 2/5] drivers: pinctrl: msm: enable PDC interrupt only during suspend Lina Iyer
2018-08-18 13:13 ` Marc Zyngier
2018-08-20 15:26 ` Lina Iyer
2018-08-20 15:34 ` Marc Zyngier
2018-08-20 15:49 ` Lina Iyer
2018-08-21 7:11 ` Marc Zyngier
2018-08-24 8:22 ` Stephen Boyd
2018-08-24 17:14 ` Lina Iyer
2018-08-27 20:00 ` Stephen Boyd
2018-09-04 21:09 ` Lina Iyer [this message]
2018-09-04 22:00 ` Stephen Boyd
2018-09-06 16:36 ` Lina Iyer
2018-08-17 19:10 ` [PATCH RESEND v1 3/5] drivers: pinctrl: qcom: sdm845: support GPIO wakeup from suspend Lina Iyer
2018-08-17 19:10 ` [PATCH RESEND v1 4/5] arm64: dts: qcom: add wake up interrupts for GPIOs for SDM845 Lina Iyer
2018-08-17 19:10 ` [PATCH RESEND v1 5/5] irqchip/gic-v3: Allow interrupt to be configured as wake-up sources Lina Iyer
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).