[OLPC-devel] Thoughts on S3 resume.

[Matthew Garrett]

On Wed, Jul 26, 2006 at 10:39:00PM -0600, Ronald G Minnich wrote:

> How I would want to do S3: make it linux-centric. NO AML interpreter.

I believe that this is the basic plan.

> To start S3, Linux saves state of universe to ram, Linux saves PCI 
> config space to ram. Linux saves whatever it has to save to RAM. Linux 
> would do much of what it does now for software suspend to disk, save for 
> the 'save ram to disk' step.

This is all already done as part of S3 suspend in the kernel. The only 
real exception is that Linux will execute any _PTS and _GTS methods that 
are defined in the AML. S3 works fine with the Insyde BIOS and there's 
no significant AML involved there from a quick scan, so I think we ought 
to be able to use existing kernel code for pretty much everything other 
than the final "Go to sleep" stage.

The final "Go to sleep" stage is slightly more awkward than it might 
appear. The Insyde BIOS probably traps writes to the sleep registers and 
executes some sort of SMI code for stuff like memory self refresh setup, 
and we're going to have to duplicate that kernel-side instead. But 
infrastructure-wise, this is just a matter of writing some code that 
populates a pm_ops structure and passes it to the kernel. Suspend should 
just be a matter of freezing the processes, calling device_suspend() and 
doing the state transition. Then we "just" need to fix the driver bugs.

> Right before entering S3, Linux writes the string: "RESUME S3 
> PC=0xDEADBEEF,PTE=00x1004000 S3 RESUME CHECKSUM" to address 0 or 
> somewhere in page 0. Or, we could write something like:
> (RESUME (STATE S3) (PC 0xdeadbeef) (PTE 0x1001000))CHECKSUM
> since that can expand as needed. Either will work: 
> comma-seperated-variables with = or s-expressions.

There's already a defined wakeup address register - there should be no 
issue with just reusing that, right?

> I think this S3 resume would be far faster than any resume based on AML 
> bytecodes. The LinuxBIOS step would be very fast -- almost 100% of 
> linuxbios would be bypassed. Linux could then very quickly bring the 
> rest of the system back up.

The one real question I have is "Who puts the CPU back in protected 
mode". In ACPI, that's the kernel. In theory, in our case we could do it 
in the BIOS. I don't think there's any performance reason to prefer one 
over the other, and doing it in the kernel means we can use the existing 
wakeup code without any modification.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org