Hi, > This is really useful work. I'm already seeing ~20% battery > improvement with Fedora 27 + 4.14.0-0.rc8.git3.1.fc28.x86_64 on an HP > Spectre, and so far no regressions. I get better battery life with > this combination than running Windows 10 with all the HP specific > drivers for this model. > > Some tips on how regressions might manifest and what information to > include in a good bug report would be useful. e.g. on an Intel NUC > when I run powertop --auto-tune, and walk away (it's a server so it > might be days) and come back the keyboard won't work. I've never done > any troubleshooting other than just disable the powertop systemd unit, > I'm vaguely suspicious of usb autosuspend and it not waking up when > keys are pressed. autosuspend has a high chance to be the root cause for this one. Yes, its very messy, mostly due to bad hardware. In qemu it took us quite some effort to get autosuspend working. It's very useful there too, usb hostadapter power consumtion on a laptop translates to cpu cycles for usb hostadapter emulation for a virtual machine. The fundamental problem is that hardware exists claiming to support autosuspend, but it's not working properly. Effect is exactly what you see: device stops working. Result is that operating systems don't enable autosuspend by default, to avoid disturbing users. udev has a whitelist of known-good hid devices (/lib/udev/rules.d/42-usb-hid-pm.rules) to deal with that. qemu hid devices are listed there, that way qemu has automatic autosuspend for linux guests. Microsoft created some "os-specific" usb descriptors which devices can define. One of the things you can do with that is set registry entries for the device. Qemu uses that to automatically enable autosuspend on windows guests, by setting SelectiveSuspendEnabled to 1. Microsoft specs: https://msdn.microsoft.com/en-us/library/windows/hardware/ff537430.aspx Qemu code: https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/desc-msos.c;h=3652919815777d637ed4f716772f9c1ce2d0b819;hb=HEAD Possibly this can be used on linux too, to figure which devices are known-good, without having to maintain a whitelist ... cheers, Gerd _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
