Re: power management for usb_hci

Hi Oliver,

> > > On an unrelated note, aren't you the maintainer for the Linux bluetooth
> > > stack?  I was wondering if the rework of that code included autosuspend
> > > support for bluetooth devices.
> > 
> > I have a new driver that will replace hci_usb and only start the bulk
> > and ISOC URBs when they are needed. This will remove that driver from
> > your powertop list of bad drivers and will allow for testing autosuspend
> > and actually remote wakeup at some point.
> > 
> > However I am not sure how far we get with autosuspend and remote wakeup
> > since of these devices are particular bad ones and poorly engineered.
> 
> The devices or the standard? If worst comes to worst, we can use up/down
> only and get some savings in the completely unused case. So it is worthwhile
> in any case. But we should try before we discuss what will have gone wrong.

the standard itself is fine, but non of the Bluetooth chip manufactures
have properly tested it. They claim they support it, but that is about
it. Some dongle manufactures actually explicitly set the remote wakeup
to _not_ supported to avoid host stacks trying.

The case we have no Bluetooth connection it is easy. In that case we
only have an interrupt URB and that can be suspended easily. The problem
case is when we have a connection and put that one into sniff to save
power. That is problematic.

> Will you post code?

http://git.infradead.org/?p=users/holtmann/bluetooth-drivers.git;a=summary

Look for the the btusb.ko driver.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel