Hi,
On 02-11-17 15:17, Bastien Nocera wrote:
On Wed, 2017-11-01 at 15:31 +0100, Hans de Goede wrote:
<resend with a bunch of To and Cc address added, sorry?
Hi All,
I'm working on trying to improve the OOTB power-consumption
of Linux (Fedora Workstation) on laptops.
One of the easy wins here is enabling runtime-pm / autosuspend
for btusb, since on many laptops the USB bluetooth device is
the only USB device not using autosuspend, enabling this will
not only allow suspending the USB bluetooth device but also to
USB HCI, leading to a significant saving in power consumption
of aprox. 0.4W.
So I would like to look into enabling runtime-pm / autosuspend
for btusb by default.
Question, are there any known issues with enabling runtime-pm ?
I realize that simply enabling it for all btusb devices is a bit
of a big hammer and might be a bad idea since there will probably
be some devices out there which do not support this properly.
I was thinking that instead of enabling runtime-pm for all btusb
devices, maybe this is something which we can do a vendor-id
basis, starting with Intel and Broadcom devices ?
(Removed Gustavo from the CC:)
Is there any benefit doing this in the kernel rather than in user-
space?
IMHO it is up to the kernel to set good defaults, so that people
don't need to use things like powertop --auto-tune or TLP, which
are userspace kludges which users currently revert to because of
the lack of good defaults in the kernel.
Do you have a set test procedure that would allow checking whether the
device remains working?
No not really I've tested that HID devices keep working, e.g. typing
something on a bt keyboard after the autosuspend timeout and that works
with Intel BT hosts at least. I've also ordered a BT headset to test
that.
I could see having this as a user-space toggle being useful if we ever
want to disable the runtime PM/autosuspend so Bluetooth keyboards can
wake up desktop machines from sleep. It's a long-standing RFE, which we
still haven't handled.
With USB remote-wakeup that should actually work, at least from a USB
pov. With regular USB keyboards wakeup works fine independent of
their /sys/bus/usb/devices/x-y/power/control setting being "on" or "auto",
at least on devices where wakeup works with the "on" state which is
not always the case AFAIK.
Besides that userspace can always override the default set by the driver
by writing "on" or "auto" to /sys/bus/usb/devices/x-y/power/control.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
