* jarcher@pobox.com jarcher@pobox.com [031126 17:43]:
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?
Some information, like power management code, is fitting pretty well in the firmware imo. Before inventing yet another interface I strongly recommend to look at the existing ones and sort them out if they do not work for some or another reason. ACPI may be ugly, but there's a big chance to support a whole lot of hardware at once by supporting ACPI table generation in LinuxBIOS. Otoh, creating an own table/format that can be parsed by a Linux driver will basically do the same thing in yet another implementation. Result is many people sit and parse ACPI tables to create LinuxBIOS tables (or even convert it automatically)
The cleanest way would be to create FCode drivers for such components and use them in an Open Firmware environment - an OS can then decide to call methods provided by each hardware device in the device tree.
Suspend to disk can be done in software (see swsusp for linux) - I guess suspend to ram involves a lot more system management mode (SMM) programming
Stefan