[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <56EC0937.9080702@ti.com>
Date: Fri, 18 Mar 2016 15:57:11 +0200
From: Grygorii Strashko <grygorii.strashko@...com>
To: Linus Walleij <linus.walleij@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Marc Zyngier <marc.zyngier@....com>
CC: Ulf Hansson <ulf.hansson@...aro.org>,
Jon Hunter <jonathanh@...dia.com>,
Jason Cooper <jason@...edaemon.net>,
Jiang Liu <jiang.liu@...ux.intel.com>,
Stephen Warren <swarren@...dotorg.org>,
Thierry Reding <thierry.reding@...il.com>,
Kevin Hilman <khilman@...nel.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Lars-Peter Clausen <lars@...afoo.de>,
Soren Brinkmann <soren.brinkmann@...inx.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [RFC PATCH V2 3/8] genirq: Add runtime power management support
for IRQ chips
On 02/05/2016 04:37 PM, Linus Walleij wrote:
> On Thu, Jan 21, 2016 at 8:51 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
>
>> So as long as an interrupt handler is installed, there is no sane way that we
>> can decide to power down the irq chip, unless that chip has the magic ability
>> to relay incoming interrupts while powered down :)
>
> Actually isn't that exactly what almost every SoC that supports
> deepsleep does?
>
> They power off the primary interrupt controller and arm the padring
> of the SoC with an asynchronous edge detector to wake up as soon
> as something happens on a few select lines, like a keypad button
> or whatnot.
>
> The asynchronous edge detector is handled by the ROM or some
> power-management microcontroller, which wakes up the system
> and restores power to the CPU and primary interrupt controller.
> That is the magic ability right there.
>
> Of course as the wakeup signal may be deasserted at the
> point the system actually comes back up, so the magic ROM
> power management unit then needs to latch
> any latent IRQs from some shadow register to the primary interrupt
> controller, which as far as I've seen is done by out-of-tree hacks
> similar to the irq_[get/set]_irqchip_state() implemented
> by Marc Zyngier, albeit for virtualization.
>
> I've not seen it on any non-primary interrupt controller though.
>
OMAP gpio can lose context(Power) even if there
GPIO IRQs configured as wakeup sources (wakeup happen through the SoC specific HW
responsible for wakeup in this case) - pcs.
It also injects IRQs if their triggering type is not fully compatible with PM HW.
--
regards,
-grygorii
Powered by blists - more mailing lists