On Fri, 4 May 2007, Paul Mackerras wrote: > > What happens without preemption enabled when a device driver's suspend() > > method calls schedule()? > > That would be bad; don't do that. :) > > In the context of the original powermac sleep code, drivers registered > a notifier for sleep which got called twice - the first time before > doing the sync, and the second time after it, with an argument to the > notifier to indicate which call this is. Drivers are allowed to call > schedule on the first call but not on the second. But the generic non-PPC core merely calls a suspend() method with interrupts enabled. And drivers may use the same code for runtime power management as well. As such it cannot afford to spin during a delay; it must sleep. > > With or without preemption enabled, what happens when a user process tries > > to do I/O to a suspended device? > > If we have two calls to the driver, then the second one should happen > with only one cpu still active and preemption disabled, and that's the > call where the device hardware should actually be put into its suspend > state. > > I'm not saying the original powermac code was perfect, but it does > work well for many users using powerbooks (which are all single-cpu > machines), without freezing processes. If you think in terms of suspend-to-RAM as just being one super-big runtime suspend of every device, you may find it an appealing point of view. (From some of the things he has said, this seems to be how Linus thinks of it.) Since runtime PM doesn't involve freezing processes, you can conclude that neither should STR. On the other hand, runtime suspend generally involves wake-on-demand, including demands for I/O from userspace. Should STR behave the same way? Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
