RE: [PATCH 1/1] usb: lpm: add boot flag to disable lpm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Replying in-line:

> > You are correct: the software claims and releases certain interfaces
> > frequently. 
> 
> How frequently?  The usbmon log you attached to the Bugzilla report
> shows it happening at intervals of approximately 20-40 ms (sometimes
> longer) -- and often with no messages sent in between.  Does that seem
> at all reasonable?
That polling interval you describe is the extreme case, but its not that
uncommon. It just depends what "metrics" are enabled by the "gathering"
thread. The case of no messages being passed does not seem reasonable.
Data is expected to be transferred between each claim/release.


> > 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.
> 
> Then why does the log show sequences of claim/release with no 
> synchronous r/w call in between?
That part I can't explain. We expect a transfer to occur in those cases.


> > 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).
> 
> Have you tried, just for the sake of testing, getting rid of all those
> claims and releases?  Simply claim both interfaces once, at the start
> of the program, and release them at the end.
I do a long-term claim/release on the bulk interface already. I could
try for the sake of testing, but I would not be allowed to claim the
"control" interface for the duration of a streaming session, as that
would break an existing product feature.

Is the frequent claim/release of interfaces bad behavior in general?
It's to my understanding I should always claim an interface before use,
otherwise I get error log entries in `dmesg'.

Thanks.


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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux