Just to prove that all generalizations have exceptions: On the OLPC system, we want the wireless (which, unfortunately, is USB based), to be able to wake the system from suspend to RAM. Of course, we have arranged there be an out of band signal from the USB wireless to wake up the system. So we don't use USB wakeup for that. - Jim On Sun, 2007-03-25 at 08:20 -0700, David Brownell wrote: > > If userspace wants the USB host to be able to wake the > system from sleep, then the simple rule is: don't use > the suspend-to-RAM mode. Nothing software does can ever > change that restriction; "slow clock mode" doesn't run > the 48 MHz clock, wakeup doesn't work without that clock. > > By forcing the system into suspend-to-RAM mode, rather > than using runtime PM to minimize power usage, userspace > has already said that being fully functional isn't the > top issue just then. > > Keep in mind that most users are already trained in that > model. Even if it didn't already make sense, that's what > MS-Windows has done forever. Those little checkboxes in > each driver's GUI properties, saying "let it wake up the > system"? They're boolean, and only reflect the details > of the ACPI tables in so far not having the checkbox if > that device is known to ACPI and isn't in that table. > It's a simple model, easily understood and generalized. > > - Dave > _______________________________________________ > linux-pm mailing list > linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/linux-pm -- Jim Gettys One Laptop Per Child _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
