Laptop Suspend Resume Tasks
- P1: MP support
- P1: USB
- P1: Nvidia graphics
- P1: Intel graphics
- P2: OSS audio (4Front help required)
- P2: WiFi drivers
- P3: iprb driver (intel 10/100 nic)
- Phase II: suspend-to-disk
- Phase II: xVM support
MP Support
The initial desktop S/R prototype for U20 has committed without support for multi-processor enabled. As many models currently shipping are dual core processors, this is not acceptable. We must resolve any MP issues in order to make this useful for current generation hardware.
Coordinate very closely with Randy here. I expect that there are challenges surrounding processor sets, and bound threads/interrupts. It maybe instructive to see what SPARC does for these.
USB Suspend/Resume
The Intel UHCI driver has complete lack of support for DDI_SUSPEND. This is the USB 1.1 interface commonly found on Intel motherboards. The EHCI (USB 2.0) driver appears to support the feature, and the common devices appear to support it, but we need to validate this. (OHCI is not found on Intel based laptops.)
Nvidia Graphics
We need the graphics to POST properly. Apparently Nvidia should do this, but it doesn't happen correctly yet.
Intel Graphics
The claim from Jay Cotton is that Keith Packard says that it should Just Work. We may have to tell the hardware or BIOS to do it, but the ACPI BIOS can do the initial POST/clocking as part of an S3 resume, and X11 can just take over. More investigation/verification is needed.
OSS Audio
This isn't done yet. 4Front is going to have to do a lot of work here. Dev was present at Garrett's demonstration of DDI_SUSPEND implementation for a real driver, and asked good questions. More investigation and collaboration with 4Front is required.
WiFi Drivers
None of them have it yet, but it looks to be relatively straight-forward. Garrett will do this task, starting with wpi and ath. (Garrett doesn't have an ipw.)
Note that PCMCIA (not cardbus) is handled "automatically" by Suspend/Resume. (Verify this on x86, it is true on SPARC.) PCMCIA devices see a DDI_SUSPEND as if the card were removed.
iprb driver
This is a simple effort, mostly hampered only by the ability to test it. Garrett will own this task. Porting the driver to SPARC may help with qualification.
Phase II: Suspend-to-Disk
Suspend-to-disk is actually a critical enabling feature for two reasons. First, when battery power is critically low, the system should suspend RAM to disk, and perform a full power off.
Second, suspend-to-disk gives a chance to enable models that today lack support for S3 resume in drivers/BIOS. This is because resume-from-disk will include a normal, full post. This is how it works on SPARC.
Phase II: xVM Support
One can imagine suspend/resume in an xVM domain in two ways. One, the idea that an xVM domain could be suspended ala an S3 state, might be very useful for debug. Two, it may be that we are able to suspend a domU in order to suspend a dom0.
xVM domain migration may actually provide much of what is needed here. A more complete discussion with the xVM architects is needed. (In particular, suspending dom0 may require synchronization with domUs.)