From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Date: Fri, 08 May 2015 20:26:06 +0000 Subject: Re: [PATCH/RFC 00/03] irqchip: renesas-irqc: Fine grained Runtime PM support Message-Id: <7hmw1ehl41.fsf@deeprootsystems.com> List-Id: References: In-Reply-To: (Geert Uytterhoeven's message of "Thu, 23 Apr 2015 19:49:59 +0200") MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Geert Uytterhoeven Cc: Alan Stern , Magnus Damm , Linux-sh list , Jason Cooper , Geert Uytterhoeven , Linux PM list , "linux-kernel@vger.kernel.org" , Simon Horman , Thomas Gleixner Geert Uytterhoeven writes: > On Thu, Apr 23, 2015 at 4:44 PM, Alan Stern wrote: >> On Thu, 23 Apr 2015, Geert Uytterhoeven wrote: >>> >> I'm afraid you can't call pm_runtime_get_sync() from these methods, as >>> >> they may be called from interrupt context. >>> > >>> > Ouch. I know the clock framework has prepare/enable separated with >>> > context, but with the irqchip callbacks I suppose no such separation >>> >>> It's not the clock operations, but the pm_runtime operations that cannot be >>> called from interrupt context. >> >> In fact the pm_runtime operations _can_ be called from interrupt >> context, provided the driver has first invoked pm_runtime_irq_safe(). >> Of course, this requires that none of the runtime-PM callback routines >> ever sleep or perform a blocking operation. >> >> This is all explained in Documentation/power/runtime_pm.txt (search for >> "irq_safe"). > > Perhaps that can help. We'll have to give it a try... > > I've always found this a bit strange when PM Domains are involved: > pm_runtime_irq_safe(dev) applies to device dev, while the actual callbacks > belong to the PM Domain code (the device's driver doesn't have any). Currently PM domains don't support IRQ-safe devices very well. Any irq_safe devices will prevent the entire PM domain from ever powering off. There is some on-going work for this but it requires reworking the genpd locking a bit. Kevin