From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759448AbcAUMlE (ORCPT ); Thu, 21 Jan 2016 07:41:04 -0500 Received: from mail-yk0-f169.google.com ([209.85.160.169]:33798 "EHLO mail-yk0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759316AbcAUMlA (ORCPT ); Thu, 21 Jan 2016 07:41:00 -0500 MIME-Version: 1.0 In-Reply-To: References: <1450349309-8107-1-git-send-email-jonathanh@nvidia.com> <1450349309-8107-4-git-send-email-jonathanh@nvidia.com> <569E1366.8070005@nvidia.com> Date: Thu, 21 Jan 2016 13:40:58 +0100 Message-ID: Subject: Re: [RFC PATCH V2 3/8] genirq: Add runtime power management support for IRQ chips From: Ulf Hansson To: Thomas Gleixner Cc: Jon Hunter , Jason Cooper , Marc Zyngier , Jiang Liu , Stephen Warren , Thierry Reding , Kevin Hilman , Geert Uytterhoeven , Grygorii Strashko , Lars-Peter Clausen , Linus Walleij , Soren Brinkmann , "linux-kernel@vger.kernel.org" , "linux-tegra@vger.kernel.org" , "linux-pm@vger.kernel.org" , "Rafael J. Wysocki" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [...] >> > I don't think using __free_irq() is the correct place to decrease the >> > runtime PM usage count. It will keep the irqchip runtime resumed even >> > if there are no irqs enabled for it. >> > >> > Instead I would rather allow the irqchip to be runtime suspended, when >> > there are no irqs enabled on it. > > Which is a no no, as you might lose interrupts that way. We disable interrupts > lazy, i.e. we do not mask them. So no, you cannot do that from > enable/disable_irq(). Thanks for the input! My main point around the approach suggested in $subject patch, is that I don't think it's *enough* fine grained. >>From a runtime PM perspective, we should allow the irqchip to enter a low power state when there are no IRQs enabled for it. As enable|disable_irq() isn't the place to do runtime PM reference counting from, perhaps there is another option? Maybe the irqchip driver itself is better suited to take these decisions? [...] Kind regards Uffe