Fwd: ACPI support in LinuxBIOS - moderator approval (fwd)

[Stefan Reinauer]

* jarcher at pobox.com <jarcher at 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

-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development