Article: The status of the Linux ACPI support (“acpi4linux”)
Mar 18, 2001 — by Rick Lehrbaum — from the LinuxDevices Archive — 5 viewsForeword
ACPI stands for “Advanced Configuration and Power Interface.” This is a specification developed by Toshiba, Intel, and Microsoft. Besides many other things, ACPI also defines power management — which is why ACPI is often compared to the older Advanced Power Management (APM) support.
Linux provides relatively mature support for APM; however, that support depends on code which must be contained within the system's BIOS for functions such as suspend-to-ram, suspend-to-disk, and system power states. Now that ACPI is in common use in the laptop/desktop PC realm, APM support can be expected to disappear from the BIOS of new PC-compatible systems. As a result, ACPI support directly within the Linux kernel is required.
Although the latest Linux kernel does contain the beginnings of ACPI support, what is currently implemented is far from complete. A project to develop ACPI for Linux is in process, which to date has largely depended on efforts by Intel. More recently, Transmeta has also been contributing to this project as part of their Midori Linux project — particularly in the area of suspend-to-ram, which is very important for reducing power consumption in small systems.
To learn more about the ongoing development of ACPI support for Linux, LinuxDevices.com contacted Guy Therien, a Software Architecture Manager with Intel's TRL/Mobile Architecture Lab, who is serving as a spokesperson for the project. Here's what Therien told us . . .
Current status of Linux ACPI
Shortly we will be posting an ACPI status document on the acpi4linux website for the exact purpose of answering the questions you have asked, as a number of folks have asked the same.
As you probably know, the Linux ACPI support is based on Intel's ACPI Component Architecture (“ACPI CA”) which is provided in source form and is integrated into many operating systems. Core functionality required to support ACPI includes the ability to process ACPI description tables and consume the ACPI namespace. This includes the ability to evaluate objects in the namespace and the implementation of the APCI event model. The ACPI support currently provided in Linux 2.4 provides this capability.
ACPI encompasses both motherboard device enumeration and power management. The current release of ACPI CA for Linux includes a draft power management framework and supports a number of ACPI-defined devices. It includes support for CPU power management, thermal zones, power button, sleep button, embedded controller, and a few other things.
Currently the ACPI support DOES NOT provide a functional replacement for APM. There is no sleep support implemented.
The big deal is that Linux is not a plug-and-play OS and ACPI assumes one. In Linux 2.5, there will be major changes to the OS initialization sequence to support ACPI. In addition, the Linux driver model needs to change to support both power management and plug and play. This is required before a system can successfully sleep and wake using ACPI mechanisms.
It is difficult for a large number of developers to contribute to the ACPI core functionality, and the scope of doing it kept anyone from trying that before we stepped up to do it.
Once the driver model changes are established, a lot of work will be needed to get drivers changed to the new driver model — not unlike drivers changing to the WDM model under Windows. We have a team here at Intel working on the core enhancements to enable ACPI-based initialization and the device driver model enhancements and power management frame work. These things should be introduced in Linux 2.5 dev kernel.
Project organization
Andy Grover is the official ACPI maintainer. He integrates contributions to the project from other developers in the Linux community. When Andy posts the status doc on the acpi4linux site, the goal is to try and point folks towards the areas where work is needed. We have done a lot of work to plan/outline the required tasks to enable Linux/ACPI moving forward, and we are working on a number of them.
In general, forward looking statements can have negative effects as they set delivery expectations; but what can be even worse, is for a developer to make a contribution that we immediately replace with something we have been working on for a while without telling folks it was coming.
In some cases folks think about things that we will not need for a while — however, the contributions are very welcomed. This was the case, for example, with some S3 resume code that was contributed lately but that we cannot as yet take advantage of, due to other missing pieces.
The biggest problem we have had thus far is in setting the correct expectation for folks using the experimental code. Quite often they expect the system to sleep with the current support — they think ACPI is a replacement for APM when really ACPI/OSPM is a replacement for APM, and it is the Linux OSPM part that is sorely lacking at this point and is a huge effort to develop.
Regarding embedded systems
As far as embedded Linux goes . . . ACPI is not necessarily well suited for all platforms. In the case of a wide distribution OS on multiple platforms like the PC, ACPI makes sense to keep multiple OEMs from maintaining APM firmware and to provide a uniform experience to the system users — i.e., how the users perform power management on a system. This may not be the case for an embedded system, and the overhead required to support ACPI must be considered.
Then again, if you had the memory resources and the driver model supported it, implementing ACPI-based power management on an embedded system would eliminate the burden of developing specialized device drivers or firmware as is done today for these systems.
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.