Decrease long resume time of Intel Bluetooth module

Decrease long resume time of Intel Bluetooth module

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 3222 bytes --]

Dear Linux folks,


The USB Bluetooth device 8087:0a2b is used in quite a lot of portable 
devices. In my case it’s the TUXEDO Book BU1406 [1]. I am trying to 
decrease the overall (suspend and) resume time of the Linux kernel.

```
$ more /proc/version
Linux version 4.10.0+ (helmuth@helmuth-N24-25BU) (gcc version 6.2.0 
20161005 (Ubuntu 6.2.0-5ubuntu12) ) #1 SMP Fri Feb 24 16:56:56 CET 2017
$ lsusb -d 8087:0a2b
Bus 001 Device 002: ID 8087:0a2b Intel Corp.
$ journalctl -k -o cat | grep usb
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: xHCI Host Controller
usb usb1: Manufacturer: Linux 4.10.0+ xhci-hcd
usb usb1: SerialNumber: 0000:00:14.0
usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: xHCI Host Controller
usb usb2: Manufacturer: Linux 4.10.0+ xhci-hcd
usb usb2: SerialNumber: 0000:00:14.0
usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: xHCI Host Controller
usb usb3: Manufacturer: Linux 4.10.0+ xhci-hcd
usb usb3: SerialNumber: 0000:01:00.0
usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: xHCI Host Controller
usb usb4: Manufacturer: Linux 4.10.0+ xhci-hcd
usb usb4: SerialNumber: 0000:01:00.0
usb 1-5: new full-speed USB device number 2 using xhci_hcd
usb 1-5: New USB device found, idVendor=8087, idProduct=0a2b
usb 1-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-6: new high-speed USB device number 3 using xhci_hcd
usb 1-6: New USB device found, idVendor=5986, idProduct=1112
usb 1-6: New USB device strings: Mfr=3, Product=1, SerialNumber=2
usb 1-6: Product: BisonCam,NB Pro
usb 1-6: Manufacturer: Bison
usb 1-6: SerialNumber: 200901010001
usbcore: registered new interface driver btusb
input: BisonCam,NB Pro as 
/devices/pci0000:00/0000:00:14.0/usb1/1-6/1-6:1.0/input/input21
usbcore: registered new interface driver uvcvideo
```

Suspending and resuming of this devices takes quite a bit of time for 
that device.

 From running `analyze_suspend.py` [2] – `scripts/analyze_suspend.py` in 
Linux repository – the following value is measured.

> usb @ 8087:0a2b [1-5] {usb} async_device (Total Suspend: 588.807 ms Total Resume: 561.912 ms)

The overall timings are below.

> Kernel Suspend: 1237.805 ms	Firmware Suspend: 0.000 ms	Firmware Resume: 1.318 ms	Kernel Resume: 869.322 ms

So that device needs over half a second for each of suspend and resume, 
which is the majority of the overall time.

Is there a way to debug and optimize that – besides taking the device 
out – to get resume times on par with other devices like Google 
Chromebooks or Apple MacBooks?


Thanks,

Paul


[1] https://www.tuxedocomputers.com/bu1406
[2] https://01.org/suspendresume/

[-- Attachment #2: helmuth-N24-25BU_mem.html.7z --]
[-- Type: application/x-7z-compressed, Size: 29333 bytes --]

Re: Decrease long resume time of Intel Bluetooth module

[Greg KH]

On Tue, Feb 28, 2017 at 11:20:11AM +0100, Paul Menzel wrote:
> Is there a way to debug and optimize that – besides taking the device out –
> to get resume times on par with other devices like Google Chromebooks or
> Apple MacBooks?

A Chromebook is running the same Linux kernel as your desktop, so
perhaps you can see if it really is doing something different here or
not?

thanks,

greg k-h

Re: Decrease long resume time of Intel Bluetooth module

[Paul Menzel]

Dear Greg,


On 02/28/17 12:00, Greg KH wrote:
> On Tue, Feb 28, 2017 at 11:20:11AM +0100, Paul Menzel wrote:
>> Is there a way to debug and optimize that – besides taking the device out –
>> to get resume times on par with other devices like Google Chromebooks or
>> Apple MacBooks?
>
> A Chromebook is running the same Linux kernel as your desktop, so
> perhaps you can see if it really is doing something different here or
> not?

Sorry, for being ambiguous. I don’t know if there are Google Chromebooks 
using that USB device, and I wouldn’t have access to it.

I just meant, that it would be great to get fast resume times.


Kind regards,

Paul

Re: Decrease long resume time of Intel Bluetooth module

[Greg KH]

On Tue, Feb 28, 2017 at 12:06:38PM +0100, Paul Menzel wrote:
> Dear Greg,
> 
> 
> On 02/28/17 12:00, Greg KH wrote:
> > On Tue, Feb 28, 2017 at 11:20:11AM +0100, Paul Menzel wrote:
> > > Is there a way to debug and optimize that – besides taking the device out –
> > > to get resume times on par with other devices like Google Chromebooks or
> > > Apple MacBooks?
> > 
> > A Chromebook is running the same Linux kernel as your desktop, so
> > perhaps you can see if it really is doing something different here or
> > not?
> 
> Sorry, for being ambiguous. I don’t know if there are Google Chromebooks
> using that USB device, and I wouldn’t have access to it.

Then perhaps the hardware itself just can't do this type of "quick"
suspend/resume?  Have you tried it in MacBook and measured it there?

> I just meant, that it would be great to get fast resume times.

I agree, but sometimes hardware just sucks :)

thanks,

greg k-h

Re: Decrease long resume time of Intel Bluetooth module

[Paul Menzel]

Dear Greg,


On 02/28/17 13:39, Greg KH wrote:
> On Tue, Feb 28, 2017 at 12:06:38PM +0100, Paul Menzel wrote:

>> On 02/28/17 12:00, Greg KH wrote:
>>> On Tue, Feb 28, 2017 at 11:20:11AM +0100, Paul Menzel wrote:
>>>> Is there a way to debug and optimize that – besides taking the device out –
>>>> to get resume times on par with other devices like Google Chromebooks or
>>>> Apple MacBooks?
>>>
>>> A Chromebook is running the same Linux kernel as your desktop, so
>>> perhaps you can see if it really is doing something different here or
>>> not?
>>
>> Sorry, for being ambiguous. I don’t know if there are Google Chromebooks
>> using that USB device, and I wouldn’t have access to it.
>
> Then perhaps the hardware itself just can't do this type of "quick"
> suspend/resume?  Have you tried it in MacBook and measured it there?

I also don’t know if the device in question is used there either. Sorry. 
I just know, that Apple MacBooks like Google Chromebooks resume very 
quickly. Firmware, the kernel and the user space seem to take less then 
a second, so that after resume the device is fully functional after when 
the screen is fully opened.

>> I just meant, that it would be great to get fast resume times.
>
> I agree, but sometimes hardware just sucks :)

And finding solutions to work around that makes our work interesting, 
doesn’t it. ;-)

No really, I thought, that first it’s possible to somehow trace, where 
the 500 ms are spent, and then find out, if that can be improved in the 
Linux kernel, or for example, it’s clear the problem lies with the 
device or it’s firmware, and the hardware vendor, which is Intel in this 
case, can maybe fix it.


Kind regards,

Paul