Hi Alan, You are correct: the software claims and releases certain interfaces frequently. The cameras have one interface with a single BULK IN endpoint, which is used to request image data from the camera via asynchronous bulk reads via libusb. The interface is claimed for the duration of media streaming, and is released when streaming concludes (usually from the user issuing a "Stop Streaming" command via the API I maintain). The cameras have a second interface with a BULK IN and BULK OUT endpoint which is used to read/write internal registers on the camera (set frame rate, on-chip processing options, etc). One of my requirements is that that camera allows multiple processes to potentially control it, but only one processes to actually grab the streaming data from it. To accomplish this, each camera has a boost::named_mutex (ie: multi-process capable mutex) to lock down access to the control interface. When any process wants to issue a control request to that camera, it has to: 1. Lock the named mutex. 2. Claim the interface. 3. Issue the synchronous r/w call it wants. 4. Release the interface. 5. Unlock the mutex. I put the mutex in in place as I was not certain if libusb enforces serialization of synchronous r/w requests to the same interface, and the claim/release calls are required, to my understanding; before I do anything with an interface. With LPM enabled, r/w calls to the "control" interface are much slower, and read calls to the "streaming" interface are very slow (maybe one frame per minute, if it doesn't seize up entirely). ============================================================ Matthew Giassa, MASc, BASc, EIT Security and Embedded Systems Specialist linkedin: https://ca.linkedin.com/in/giassa e-mail: matthew@xxxxxxxxxx website: www.giassa.net > -------- Original Message -------- > Subject: Re: [PATCH 1/1] usb: lpm: add boot flag to disable lpm > From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > Date: Thu, April 14, 2016 7:57 am > To: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> > Cc: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>, Matthew Giassa > <matthew@xxxxxxxxxx>, <linux-usb@xxxxxxxxxxxxxxx> > > > On Thu, 14 Apr 2016, Mathias Nyman wrote: > > > 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 > > Runtime PM already is disabled for any device that is open in usbfs. > Unless Matthew's program repeatedly open and closes the device file, > the device will remain unsuspended. And indeed, the usbmon file does > not show the device getting suspended. > > As far as I can see, the only other things in the USB stack that > disable/enable LPM are: Set-Config, Set-Interface, > claim/release_interface. The log file does not show any Set-Config or > Set-Interface calls. > > Matthew, does your program claim and release the interface a lot? This > should be necessary only at the start and end of the program. > > Alan Stern -- 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
