Wiki code for Suspend/Resume

Hide Line numbers
1: == Laptop Suspend Resume Tasks
2: * P1: MP support
3: * P1: USB
4: * P1: Nvidia graphics
5: * P1: Intel graphics
6: * P2: OSS audio (4Front help required)
7: * P2: WiFi drivers
8: * P3: iprb driver (intel 10/100 nic)
9: * Phase II: suspend-to-disk
10: * Phase II: xVM support
11: 
12: == MP Support
13: 
14: 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.
15: 
16: 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.
17: 
18: == USB Suspend/Resume
19: 
20: 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.)
21: 
22: == Nvidia Graphics
23: 
24: We need the graphics to POST properly.  Apparently Nvidia should do this, but it doesn’t happen correctly yet.
25: 
26: == Intel Graphics
27: 
28: 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.
29: 
30: == OSS Audio
31: 
32: 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.
33: 
34: == WiFi Drivers
35: 
36: 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.)
37: 
38: 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.
39: 
40: 
41: == iprb driver
42: 
43: 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.
44: 
45: == Phase II: Suspend-to-Disk
46: 
47: 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.
48: 
49: 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.
50: 
51: == Phase II: xVM Support
52: 
53: 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.
54: 
55: 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.)
OpenSolaris

Top Menu

Wiki code for Suspend/Resume

Search

Collectives

Community Group

Project

User Group

Subsites

Project suspend-resume Pages
