From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grygorii Strashko Subject: Re: [RFC PATCH V2 3/8] genirq: Add runtime power management support for IRQ chips Date: Fri, 18 Mar 2016 15:57:11 +0200 Message-ID: <56EC0937.9080702@ti.com> References: <1450349309-8107-1-git-send-email-jonathanh@nvidia.com> <1450349309-8107-4-git-send-email-jonathanh@nvidia.com> <569E1366.8070005@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Linus Walleij , Thomas Gleixner , Marc Zyngier Cc: Ulf Hansson , Jon Hunter , Jason Cooper , Jiang Liu , Stephen Warren , Thierry Reding , Kevin Hilman , Geert Uytterhoeven , Lars-Peter Clausen , Soren Brinkmann , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "Rafael J. Wysocki" List-Id: linux-tegra@vger.kernel.org On 02/05/2016 04:37 PM, Linus Walleij wrote: > On Thu, Jan 21, 2016 at 8:51 PM, Thomas Gleixner 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933008AbcCRN5w (ORCPT ); Fri, 18 Mar 2016 09:57:52 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:40269 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932916AbcCRN5u (ORCPT ); Fri, 18 Mar 2016 09:57:50 -0400 Subject: Re: [RFC PATCH V2 3/8] genirq: Add runtime power management support for IRQ chips To: Linus Walleij , Thomas Gleixner , Marc Zyngier References: <1450349309-8107-1-git-send-email-jonathanh@nvidia.com> <1450349309-8107-4-git-send-email-jonathanh@nvidia.com> <569E1366.8070005@nvidia.com> CC: Ulf Hansson , Jon Hunter , Jason Cooper , Jiang Liu , Stephen Warren , Thierry Reding , Kevin Hilman , Geert Uytterhoeven , Lars-Peter Clausen , Soren Brinkmann , "linux-kernel@vger.kernel.org" , "linux-tegra@vger.kernel.org" , "linux-pm@vger.kernel.org" , "Rafael J. Wysocki" From: Grygorii Strashko Message-ID: <56EC0937.9080702@ti.com> Date: Fri, 18 Mar 2016 15:57:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/05/2016 04:37 PM, Linus Walleij wrote: > On Thu, Jan 21, 2016 at 8:51 PM, Thomas Gleixner 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