Hi! > > Actually, what you are doing is _not_ suspend-to-RAM. You are doing > > (trying to do?) very advanced kind of runtime power management on PC > > platform (that happens to use S3). > > What Jim said ... nothing about that wireless stuff is special. > You can do _exactly_ the same thing today, as follows: No, wireless stuff is not special... > - Linux-USB peripheral, using "gadget" stack, running wireless > hardware and software to do the routing, and supporting remote > wakeup of the host; > > - Linux USB host, telling that peripheral to enter the USB suspend > state and enabling remote wakeup for when a WLAN packet should > be sent to the USB host. > > The essential difference is just that the USB peripheral firmware > in the Broadcom thing is likely not using Linux for its RTOS. > > Similarly with the display ... nothing prevents suspend states > from leaving a display on if that's more appropriate. ...but leaving machine "suspended" with display running (and pressumably keyboard still reactive to keypresses) is really a bit different from "normal" suspend-to-RAM. > That said, it might be more appropriate to view the host side > sleep state as a "standby" (S1) than "suspend to RAM" (S3) in > the cases where quick wakeup is a priority. (To ACPI, the speed > of those transitions is a key differentiator.) And of course, the > fact that ACPI defines (very loosely!) S1 and S3 doesn't mean > there aren't a whole collection of S1 and S3 states that a > given hardware platform could define and use. Yes, S1 is probably right description of above state. IIRC I seen machines that left dispaly ON in S1... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
