Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754464AbbKMJBu (ORCPT ); Fri, 13 Nov 2015 04:01:50 -0500 Received: from hqemgate14.nvidia.com ([216.228.121.143]:10990 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752717AbbKMJBs (ORCPT ); Fri, 13 Nov 2015 04:01:48 -0500 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Fri, 13 Nov 2015 00:59:28 -0800 Subject: Re: [RFC PATCH 1/2] genirq: Add runtime resume/suspend support for IRQ chips To: Kevin Hilman References: <1447166377-19707-1-git-send-email-jonathanh@nvidia.com> <1447166377-19707-2-git-send-email-jonathanh@nvidia.com> <7hio56dctz.fsf@deeprootsystems.com> CC: Thomas Gleixner , Jason Cooper , Marc Zyngier , Stephen Warren , Thierry Reding , Geert Uytterhoeven , , From: Jon Hunter Message-ID: <5645A6F6.6020202@nvidia.com> Date: Fri, 13 Nov 2015 09:01:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7hio56dctz.fsf@deeprootsystems.com> X-Originating-IP: [10.21.132.159] X-ClientProxiedBy: UKMAIL101.nvidia.com (10.26.138.13) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2687 Lines: 56 On 12/11/15 23:20, Kevin Hilman wrote: > Jon Hunter writes: > >> Some IRQ chips may be located in a power domain outside of the CPU subsystem >> and hence will require device specific runtime power management. Ideally, >> rather than adding more functions to the irq_chip_ops function table, using >> existing chip functions such as irq_startup/shutdown or >> irq_request/release_resources() would be best. However, these existing chip >> functions are called in the context of a spinlock which is not ideal for >> power management operations that may take some time to power up a domain. >> >> Two possible solutions are: >> 1. Move existing chip operators such as irq_request/release_resources() >> outside of the spinlock and use these helpers. >> 2. Add new chip operators that are called outside of any spinlocks while >> setting up and freeing an IRQ. > >> Not knowing whether we can safely move irq_request/release_resources() to >> outside the spinlock (but hopefully this will solicit some feedback), add >> new chip operators for runtime resuming and suspending of an IRQ chip. > > I'm not quite seeing how this would connect to the actual hardware > power domain (presumabaly managed by genpd) and any other devices in > that domain (presumably managed by runtime PM.) So this patch is just providing some hooks that an irqchip can use to perform any PM related operations. If you look at the 2nd patch in the series you will see for the GIC that these helpers are used to call pm_runtime_get/put() which would handle the power-domain. > If all the RPM devices in the domain go idle, it will be powered off > independently of the status of the irqchip because the irqchip isn't > using RPM. That's dependent on how the irqchip uses these helpers. If these helpers invoke RPM then that will not be the case. > Is there a longer-term plan to handle the irqchips as a "normal" device > and use RPM? IMO, that approach would be helpful even for irqchips that > share power domains with CPUs, since there are efforts working towards > using genpd/RPM to manage CPUs/clusters. That would ideal. However, the majority of irqchips today create/register them with IRQCHIP_DECLARE() and not as "normal" devices. Therefore, I was reluctant to add "struct device" to the irqchip structure. However, if this is what you would prefer and Thomas is ok with it, then that would be fine with me. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/