After playing around with gnome-power-manager so that it can support spicctrl (which is to be done in hal, actually) to be able to adjust LCD brightness according to whether the AC adapter is plugged or not, I wanted to go a bit further in my quest for battery life. To be honest, I was already adjusting the LCD brightness with a custom acpid event script, but it's still nicer to have it out of the box.

Anyway, the main issue I remembered for battery life, apart from LCD backlight and Wi-Fi, is CPU power states.

When on battery, the CPU in my laptop can handle 4 such states. From C1 to C4 (According to the acpi docs there's actually a C0 state, so that'd make 5). But when on battery, the CPU never goes past level C2. I did some basic check a long time ago, by removing modules, and after removing Firewire, PCMCIA, and USB support, the CPU would go in C3 and C4 states. Though this definitely saves battery because it turns off parts of the computer, I wanted to know exactly what was sucking the CPU, and to keep at least USB, that I use more than the rest.

After selectively removing the modules, it turns out the uhci_hcd support (USB1) is somehow responsible. Which is sad, because my USB mouse is USB1. But it also turns out there's always a peripheral connected to the USB1 hub on my laptop. Indeed, the internal bluetooth support, which is activated at the same time as Wi-Fi, is connected internally through USB1. If I turn off Wi-Fi, it disconects the BT USB device. It appears that in this configuration, having uhci_hcd loaded doesn't have an influence on the CPU. It still reaches C3 and C4 levels. Problem is I don't want to turn off Wi-Fi.

So, with the help of my friend google, I found out that it's possible to unbind drivers from devices, and successfully unbound the USB port the BT device is connected to, without deactivating all the other (external) ports. The sad thing is that when doing such, it also automagically disables the Wi-Fi device (an ipw2200) IRQ, but modprobing ipw2200 again enables it without enabling the BT device.

Next step was to find a way to have this set-up applied automatically at boot-time. I tried to add the following to my udev rules:
ACTION=="add", SUBSYSTEM=="pci", ID=="0000:00:1d.2", ENV{UDEV_START}==1, OPTIONS="ignore_device"
which i'd have expected to do what i want, but it doesn't. I also tried:
ACTION=="add", DRIVER=="uhci_hcd", RUN+="/bin/echo -n 0000:00:1d.2 > /sys/bus/pci/drivers/uhci_hcd/unbind"
which doesn't work either. But:
ACTION=="add", DRIVER=="uhci_hcd", RUN+="/some/script/containing/the/previous/echo"
does. Well, it does work when you restart udev, but not when you reboot. Unfortunately, the initramfs (built with the initramfs-tools) loads a lot of modules, including USB. Meaning that udev doesn't load these and doesn't apply the rules then. Unless I write my own list of modules to load at boot time, initramfs-tools won't produce a useful initramfs for my case. Yaird, on the other hand, did what I wanted it to do, except that it still lacks support for resuming from suspend-to-disk.

In the end, I put a script in /etc/rcS.d. This script unbinds the uhci_hcd driver from the BT device port and re-modprobes ipw2200.

I got a bad surprise, though. After a fresh startup, the CPU would be stuck on C2 state again. Remember how the OpenGL performance would drop if I switch to console and back to X ? It also turns out that it also makes the CPU able to reach C3 and C4 states. There seems to be something odd with the radeon driver...

2006-07-02 09:53:01+0900

miscellaneous, p.d.o

Both comments and pings are currently closed.