On 14.04.2016 01:36, Greg KH wrote:
On Wed, Apr 13, 2016 at 03:21:09PM -0700, Matthew Giassa wrote:
The devices support LPM and are USB3.0 certified, and they work fine in
Windows using the same Intel 8/9/10 Series USB host controllers, along
with Renesas and Fresco controllers. On Linux the devices either seize
up or slow down dramatically ever since LPM support was enabled.
Then we need to fix Linux, as it must be our bug.
Mathias, any ideas?
Matthews usbmon log show a flood of LPM related requests that match
something continuously calling usb_disable_lpm() and usb_enable_lpm().
I Understood that Matthew uses usbfs (libusb), not uvc. That means
the pm callback in usb_device_pm_ops are used, right?
usb_runtime_suspend() and usb_runtime_resume() will end up calling
usb_disable_lpm() and usb_enable_lpm() through usb_generic_driver.suspend / resume.
So I see two possible issues here
* Unnecessary LPM enabling/ disabling at runtime resume/suspsend
We should avoid changing LPM values at runtime suspend/resume. The original
motivation for this was that devices can not move from LPM U2 state to U3 directly,
they need to go via U0. Disabling LPM will force the link state to U0, but we do a lot
of request to get this done, both to hub and device (4 at least).
I think this is not a task for the driver. Hub hardware should be able to move the link from U2
to U0 and finally to U3 on a single Set Port Feature(PORT_LINK_STATE U3) by itself [1].
* way too active runtime resuming/suspending using usbfs
It could be possible that runtime suspsend/resume are called way too often when using
usbfs. Not sure if libusb is opening/closing usbfs files all the time, or what triggers it.
I haven't looked into this part yet. Maybe we need a way to prevent autosuspend, or set
autosuspend delay via usbfs
[1] USB 3.1 specification section 10.16.2.10 Set Port Feature:
"If the value is 3, then host software wants to selectively suspend the device connected to this
port. The hub shall transition the link to U3 from any of the other U states using allowed link
state transitions. If the port is not already in the U0 state, then it shall transition the port to the
U0 state and then initiate the transition to U3. While this state is active, the hub does not
propagate downstream-directed traffic to this port, but the hub will respond to resume signaling
from the port"
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
