"ACPI in Linux . Myths vs. Reality" ... Paper - 27th June 2007

[Nate Lawson]

Wilkinson, Alex wrote:
> By Len.Brown at intel.com
> 
>    [https://ols2006.108.redhat.com/2007/Reprints/brown_1-Reprint.pdf]


Thanks for the forward.  This is a good summary.  My perspective from
the FreeBSD side:

* We don't have suspend-to-disk yet except for the couple systems that
supported S4BIOS.  If it was implemented, it would be a much more
reliable than suspend-to-ram.  This is a major project, hence it hasn't
been done yet.

* I agree most suspend-to-ram issues are devices/drivers, not ACPI.
Often, it's the case that our drivers are incomplete or lacking quirks
for particular buggy devices, not bugs in the drivers themselves.
However, issues like with video are awaiting more help from DRM and the
modesetting project.

* Hotkeys are solved by loading the acpi_ibm/panasonic/asus/whatever
driver.  We do still need a central way of adapting the device-specific
keys to general key events.  Not a hard project, but one that needs a
lot of research into Gnome, KDE, HAL, etc. to see what users expect and
how to link it to common UIs.

* We should investigate using the RTC for the timer interrupt.  Also,
the HPET has an interrupt mode that might be useful.

* I've submitted errata to the ACPI standards effort, cc'd to the Linux
list and Intel developers.  No changes have been made in that area over
3 revs of the spec.  I disagree that the ACPI spec incorporates much, if
any, community input.  Perhaps there is now a new contact but I'm not
aware of them.

* Linux Firmware kit (http://www.linuxfirmwarekit.org/) Great stuff if
people use it.  We benefit from the acpi-ca compliance.

* ACPI-CA is still changing a lot in fundamental ways, i.e. locking.
The APIs have to be reworked every 3rd revision or so.  Unfortunately
since we have a lot of support code Linux does not, we end up hostage to
the least common denominator (i.e semaphores vs. mutexes, hard-coded
lock order in ACPI-CA itself vs. WITNESS).

* Native MSR access for the acpi cpufreq module.  Hey, nice.  I didn't
see this revision before.  Chapter 3 is new and will help us make
SpeedStep work on newer systems.

* Your help -- still needed!

-Nate