ACPI 高级电源管理接口Suspend与Resume

http://www.advogato.org/article/913.html

 

Back in the APM days, everything was easy. You called an ioctl on /dev/apm, and the kernel made a BIOS call. After that, it was all up to the hardware. Sure, it never really worked properly, and it was basically impossible to debug what the hardware actually did. And then ACPI came along, and nothing worked at all. Several years later, we're almost back to where we were with APM. But what's actually happening when you hit that sleep key?

 

Without the ability to suspend and resume, laptop users are doomed to spend several hours of their lives waiting for machines to boot and shutdown. This is, clearly, suboptimal. APM made it fairly easy to implement this, because almost everything was handled by the BIOS. And that, in a nutshell, is one of the primary reasons why ACPI ended up in charge.

 

The biggest problem with APM is that it left policy in hardware. Don't want to suspend on lid closure? The OS doesn't get any say in the matter, though if you're lucky there might be a BIOS option to control it. Would prefer it if the BIOS didn't scribble all over the contents of your video registers while it tries to reprogram them (probably back to the defaults of the Windows drivers...)? Sucks to be you. Want the sleep button to trigger suspend to disk, not suspend to RAM? A-ha ha ha.

 

ACPI deals with that problem, by moving almost all the useful functionality out of hardware. The downside of this is that the functionality needs to be reimplemented in the OS. Which, given that the ACPI spec is around 600 pages long, has taken a little time.

 

(Of course, it turns out that most of the ACPI spec is entirely uninteresting for suspend and resume purposes, but that's not really the point right now)

 

So, firstly, lets have some ACPI jargon. ACPI itself stands for "Advanced Configuration and Power Interface". It's not just a power management spec - it provides the OS with a description of all the built-in hardware in your system, along with a certain degree of abstraction. It gives you information about interrupt routing, tells you if someone's just removed a hot-pluggable DVD drive from a laptop and may even let you control which video output is being used.

 

This information is provided in a table called the DSDT (Discrete System Descriptor Table). The DSDT is in a bytecode called AML (ACPI Machine Language), compiled from a simple language called ASL (ACPI Source Language, shockingly enough). At boot time, the system reads the DSDT, parses it and executes various methods. These can do pretty much anything, but on the bright side they're being executed in kernel context and (in principle) you can filter out anything that you really don't want to do (such as scribbling all over CMOS or something).

 

The final relevant piece of ACPI information is something called the FADT, or Fixed Address Descriptor Table. This gives the OS information about various register addresses. It's a static structure, and doesn't contain any executable code.

 

So, how does all of this stuff actually work?

 

First of all, the user hits the sleep key. This triggers a hardware interrupt, which is caught by the embedded controller. That pokes a register in the southbridge, which flags that a general purpose event has just occured. The OS notices this, and checks the DSDT for what's supposed to happen next. Generally, this just calls a notification event. This is bounced back out to userspace via /proc/acpi/events (currently, though it's going to be moved to the input layer in future) and userspace gets to choose what happens next.

 

Let's concentrate on the common scenario, which is that someone hitting the sleep button wants to suspend to RAM. Via some abstraction (either acpid, gnome-power-manager or kpowersave or something), userspace makes that decision and initiates the suspend to RAM process by either calling a suspend script directly or bouncing via HAL.

 

Depending on distribution, this ends up running a shell script or binary which attempts to prepare the system for suspend. Right now, this tends to involve a bunch of bandaids around various broken drivers - unloading modules and reloading them is one of the easiest workarounds for breakage. Finally, the string "mem" is written to /sys/power/state.

 

This jumps back into the kernel. First, userspace is stopped. This stops it getting horribly confused when a load of hardware mysteriously stops working. Then the kernel goes through the device tree and calls suspend methods on each bound driver. Individual drivers have responsibility for storing enough state in order to be able to reprogram the device on resume - ACPI doesn't make guarantees about what the hardware state is going to be when we come back. Once the kernel-side suspend code has been run, we execute a couple of ACPI methods - PTS (Prepare To Sleep) and GTS (Going To Sleep). These tend to poke various things that the kernel knows nothing about, and so a certain amount of magic may be involved.

 

At this point, the system should be fairly quiescent. Only two things to do now. Firstly, the address of the kernel wakeup code is written to an address contained in the FADT. Secondly, two magic values from the DSDT are written to registers described in the FADT. This usually causes some sort of system management trap, which makes sure that the memory is put in self-refresh mode and actually sequences the machine into suspend. For the S3 power state, this basically involves shutting the machine (other than the RAM) down completely.

 

Time passes.

 

The user presses the power button. The system switches on, jumps to the BIOS start address, does a certain amount of setup (programming the memory controller and so on) and then looks at the ACPI status register. This tells it that the machine was previously suspended to RAM, so it then jumps to the wakeup address programmed earlier. This leads it to a bunch of real-mode x86 code provided by the kernel, which programs the CPU back into protected mode and restores register state. Suddenly we're running kernel code again.

 

 

From this point onwards, it's much the reverse of the suspend process. We call the ACPI WAK method, resume all the drivers and restart userspace. The shell script suddenly starts running again and cleans up after itself, reloading any drivers that were unloaded before suspend. As far as userspace is concerned, the only thing that's happened is that the clock has jumped forward.

 

So why is this difficult?

 

In a lot of cases, it's just down to bugs in the drivers. Restoring hardware state can be hard, especially if you don't actually have all the documentation for the hardware to start with - traditionally, many Linux drivers have ended up depending on the BIOS to have programmed the hardware into a semi-sane state, and there's no guarantee that that will happen with ACPI. Other cases can just be oversights - for instance, the bug in the APIC (not to be confused with ACPI) code that meant a single register wasn't restored, resulting in some machines resuming without any interrupts being delivered.

 

The single biggest problem is video hardware. The spec doesn't require the BIOS to reprogram the video hardware at all, and so often it'll come back in an entirely unprogrammed state. This is an issue, since we (in general) have absolutely no idea how to bring a video card up from scratch. One of the easiest workarounds is to execute code from the video BIOS in the same way that the system BIOS does on machine startup. vbetool lets you do this from userspace, and it works a surprisingly large amount of the time. However, there's no guarantee that it'll be successful. Vendors often unmap that section of BIOS after the system has been brought up, since they've got far more BIOS code than will fit in the BIOS region of the legacy address space. In the long run, the only solution is drivers that know how to program an entirely uninitialised chip. The new modesetting branch of the Intel driver aims to do this, as do the developers of noveau.

 

Despite all this misery, ACPI support is generally improving. Most machines can now suspend and resume once more. The next big challenge is improving run-time power management in order to get battery life to at least the level it is under Windows, and ideally beyond that.