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: matthew@xxxxxxxxxx website: www.giassa.net > -------- Original Message -------- > Subject: RE: [PATCH 1/1] usb: lpm: add boot flag to disable lpm > From: "Matthew Giassa" <matthew@xxxxxxxxxx> > Date: Thu, April 14, 2016 8:08 am > To: "Alan Stern" <stern@xxxxxxxxxxxxxxxxxxx>, "Mathias Nyman" > <mathias.nyman@xxxxxxxxxxxxxxx> > Cc: "Greg KH" <gregkh@xxxxxxxxxxxxxxxxxxx>, linux-usb@xxxxxxxxxxxxxxx > > > 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 -- 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
