jarcher@pobox.com writes:
I mentioned APM because it seemed the simplest. Realisticaly you'd want to follow the LinuxBIOS approach and do minimal stuff at the BIOS level and move most of the information to a linux driver. So really all the BIOS portion has to detect and support are the conditions where the CPU goes through reset. This should only be the suspend to ram and the suspend to disk states.
So how about a new simple LinuxBIOS PM interface?
There are several pieces to this.
1) Telling operating systems what part it needs to play. 2) Switching to the suspend to RAM state. 3) Knowing in the BIOS we need to come out of suspend to RAM instead of doing a fresh initialization of the memory controller.
Thinking about Suspend to RAM I have some strange thoughts about setting up hypertransport correctly. I am wondering if a suspend to RAM would be faster than a hard_reset? Anyway...
On the LinuxBIOS side the communication can pretty much be accomplished with a CMOS parameter I think.
As far as giving information to the running OS giving it the tables it expects is not the worst way to go. Most of the power management needs to happen in the OS and in the drivers. Ideally we would package the ACPI table entries in the LinuxBIOS table as real tabular data (not functions) and then convert them to real ACPI later.
The OS needs a little bit of help to do suspend to RAM but we should keep it as minimal as possible.
Eric