On Wednesday, November 27, 2013 12:44:35 AM Ulf Hansson wrote: > On 26 November 2013 22:09, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 26 Nov 2013, Rafael J. Wysocki wrote: > > > >> On Tuesday, November 26, 2013 10:48:56 AM Ulf Hansson wrote: > >> > On 26 November 2013 00:10, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > >> > > On Monday, November 25, 2013 01:40:21 PM Ulf Hansson wrote: > >> > >> To put devices into low power state during sleep, it sometimes makes > >> > >> sense at subsystem-level to re-use device's runtime PM callbacks. > > > > Ulf, please be more careful about the distinction between "device" and > > "driver". Devices don't have callbacks; drivers do. You made this > > mistake a few times in the patch description. > > Sorry, my bad. > > > > >> > >> The PM core will at device_suspend_late disable runtime PM, after that > >> > >> we can safely operate on these callbacks. At suspend_late the device > >> > >> will be put into low power state by invoking the device's > >> > >> runtime_suspend callback, unless the runtime status is already > >> > >> suspended. At resume_early the state is restored by invoking the > >> > >> device's runtime_resume callback. Soon after the PM core will re-enable > >> > >> runtime PM before returning from device_resume_early. > >> > >> > >> > >> The new pm_generic functions are named pm_generic_suspend_late_runtime > >> > >> and pm_generic_resume_early_runtime, they are supposed to be used in > >> > >> pairs. > >> > > > >> > > What happens if the subsystem uses the new functions as its late suspend/ > >> > > early resume callbacks, but some of its drivers implement .suspend_late() > >> > > and .resume_early()? > > > > The same thing that happens whenever any PM-related callback is defined > > by both the subsystem and the driver: The PM core uses the subsystem's > > callback. (Or the pm_domain's callback, or the type's callback, or the > > class's callback.) > > > > Besides, Ulf specifically assumed at the top of this message that > > re-using the runtime-suspend callback makes sense at the subsystem > > level. This must mean it is appropriate for all drivers in the > > subsystem. So why would a driver want to override the subsystem's > > behavior? > > > >> > Good point. Normally, I think the decision of using these callbacks > >> > should be taken at the lowest level, in other words in the driver. > >> > Otherwise the lowest layer of .suspend_late will be by-passed. > >> > >> I'm not sure what's the point to add them, then. If the driver has to decide > >> anyway, it may simply populate its .suspend_late and .resume_early pointers > >> I think. > > > > Another possibility is to have the pm_generic_suspend_late_runtime > > routine check to see if the driver has defined a suspend_late callback. > > If the driver has its own callback, we could invoke it instead of > > invoking the runtime_suspend callback. > > There are already a generic callbacks that does this. Normally the > generic callbacks is used from buses and power domains. > > My new callbacks are intended to be used from the driver, so those are > kind of different from the others in that sense. Hmm. I see. For that to work, the subsystem's .suspend() and .resume() callbacks will have to be implemented in a special way, because of the unknown runtime PM status of devices while those callbacks are being executed. Presumably you think about subsystems that don't implement those callbacks at all? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
