I should also note that these "control" r/w calls are made very frequently. A thread is spawned for each camera that periodically polls for things like exposure levels, average brightness, etc, to update a metrics cache and UI display for said metrics.
============================================================ Matthew Giassa, MASc, BASc, EIT Security and Embedded Systems Specialist linkedin: https://ca.linkedin.com/in/giassa e-mail: [email protected] website: www.giassa.net > -------- Original Message -------- > Subject: RE: [PATCH 1/1] usb: lpm: add boot flag to disable lpm > From: "Matthew Giassa" <[email protected]> > Date: Thu, April 14, 2016 8:08 am > To: "Alan Stern" <[email protected]>, "Mathias Nyman" > <[email protected]> > Cc: "Greg KH" <[email protected]>, [email protected] > > > 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: [email protected] > website: www.giassa.net > > > -------- Original Message -------- > > Subject: Re: [PATCH 1/1] usb: lpm: add boot flag to disable lpm > > From: Alan Stern <[email protected]> > > Date: Thu, April 14, 2016 7:57 am > > To: Mathias Nyman <[email protected]> > > Cc: Greg KH <[email protected]>, Matthew Giassa > > <[email protected]>, <[email protected]> > > > > > > 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 [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
