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
--
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
