From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend Date: Tue, 19 Nov 2013 08:45:13 -0800 Message-ID: <87r4acmjc6.fsf@linaro.org> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: (Alan Stern's message of "Tue, 19 Nov 2013 10:35:46 -0500 (EST)") Sender: linux-pci-owner@vger.kernel.org To: Alan Stern Cc: Ulf Hansson , "Rafael J. Wysocki" , Len Brown , Pavel Machek , "linux-pm@vger.kernel.org" , Greg Kroah-Hartman , Linux PCI , linux-usb@vger.kernel.org List-Id: linux-pm@vger.kernel.org Alan Stern writes: > On Tue, 19 Nov 2013, Ulf Hansson wrote: > >> At the moment, system PM is already affecting behaviour of runtime PM >> since it is preventing runtime suspend during system suspend. > > Sure. And that behavior is documented. In any case, it's a bug for > drivers to depend on runtime suspend for carrying out a system suspend. As Rafael mentioned, there is bus/pm_domain code that comes into play here, so I'm not sure it's always a bug. IMO, it's not a bug for the driver to depend on runtime PM if the bus/pm_domain is handling the details. On OMAP, we handle all the SoC on-chip devices with a pm_domain since the low-level PM operations that need to happen are bus-level things not device-level things. Therefore, drivers for these devices can rely entirely on runtime PM, even for system suspend. The late/early callbacks in the pm_domain can see if the device is runtime suspended already or not and behave accordingly. So, this all *can* work by handling it at the bus/pm_domain level, but as Ulf has mentioned (and I agree) it seems like a clunky workaround because the PM core is preventing it from happening as one might expect. Kevin