From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH 1/4] PM / Wakeirq: Add minimal device wakeirq helper functions Date: Mon, 9 Mar 2015 09:41:25 -0700 Message-ID: <20150309164125.GG5264@atomide.com> References: <20150309150908.GC5264@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-omap-owner@vger.kernel.org To: Alan Stern Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Andreas Fenkart , Greg Kroah-Hartman , Felipe Balbi , Huiquan Zhong , Kevin Hilman , NeilBrown , Mika Westerberg , Nishanth Menon , Peter Hurley , Sebastian Andrzej Siewior , Ulf Hansson , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, linux-omap@vger.kernel.org, Linux PM list List-Id: linux-serial@vger.kernel.org * Alan Stern [150309 08:42]: > On Mon, 9 Mar 2015, Tony Lindgren wrote: > > > > > > > Considering the above, should we add a new function something like > > > > > > pm_resume_complete() that does not need irq_safe set but does > > > > > > not return until the device has completed resume? > > > > > > > > > > That doesn't make sense. You're asking for a routine that is allowed > > > > > to sleep but can safely be called in interrupt context. > > > > > > > > Oh it naturally would not work in irq context, it's for the bottom > > > > half again. > > > > > > In other words, you're suggesting we add a function that runs in > > > process context and doesn't return until the device is fully resumed? > > > That's exactly what pm_runtime_resume does right now. > > > > But doesn't it only wait for completion if the driver is marked with > > pm_runtime_irq_safe()? > > Put it this way: pm_runtime_resume invokes a ->runtime_resume > callback routine (the subsystem's or the driver's or whichever), and it > assumes that if the routine returns 0 then the device has been resumed. > It doesn't really _wait_ for anything; it just calls the callback > routine. > > It behaves this way whether or not the irq_safe flag is set. The only > difference is that if irq_safe is set then the callback routine is > invoked with interrupts disabled (and in this case pm_runtime_resume > may be called in interrupt context -- normally it can be called only in > process context). Oh right you are. Looking at rpm_resume() again, it's the RPM_ASYNC that was causing problems to me earlier, not the irq_safe. Sorry it seems I was a bit confused. And yes, pm_runtime_resume() does not set RPM_ASYNC like you pointed out earlier so no need to do anything there. Regards, Tony