Re: usb: dwc3: dwc3 errors while video streaming with uvc-gadget

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

 



Hi Felipe,

On Monday, 5 November 2018 14:05:59 EET Felipe Balbi wrote:
> Laurent Pinchart writes:
> > On Saturday, 3 November 2018 23:07:33 EET Terence Neill wrote:
> >> Hi folks,
> >> 
> >> Thanks for the replies, I really appreciate them.  I've made some
> >> progress on this.  I'm new to USB so apologies if the following text is
> >> incorrect or is just bizarre!:
> >> 
> >> 1. The problem with streaming_maxpacket set to 2048 seemed to be caused
> >> by not enough requests being queued with the dwc3 driver at one time,
> >> resulting in request starvation at higher bandwidths.  Increasing the
> >> value of the UVC_NUM_REQUESTS macro from 4 to 16 (in
> >> drivers/usb/gadget/function/uvc.h) seemed to fix this problem.
> > 
> > This clearly needs to be fixed. I wonder if we should try to compute a
> > good value at runtime, or go for a large enough fixed value for all cases.
> 
> just go for something large. Computing in runtime would involving
> measuring latency in runtime and adapting your queue accordingly. Too
> much work for very little benefit.

I've received a request some time ago from a UVC gadget user who wanted to 
bump the UVC_NUM_REQUESTS up to store a full video frame. That's likely too 
much, we'll have to decide on a proper middle ground.

> >> 2. It looks like the problem that was happening with max_packet set to
> >> 3072 was caused by the isochronous transfer being queued for a microframe
> >> number in the past (the assumption is that there is the code just wasn't
> >> getting the first microframe queued in time).  To get around this
> >> problem, I changed the DWC3_ALIGN_FRAME() macro to add an offset of one
> >> video frame (the video is running at 10fps so about 800 microframes).
> >> This fixed the startup problem at high bandwidth. At the moment, the
> >> objective of the investigation is to prove throughput, so some latency
> >> can be accommodated.
> > 
> > Felipe has worked on this recently, but if I recall correctly there were
> > still issues that prevented patches from being upstreamed.
> 
> true
> 
> >> From reading some more about USB, it looks like isochronous transfers may
> >> have the option sending zero length packets whenever there is no data to
> >> send?  Is this true?  If so, would this be a possible option to move
> >> forward with this issue - eliminating the need to handle missed isocs at
> >> the f_uvc layer?
> > 
> > We will always have to handle the missed intervals, as something could go
> > wrong and result in such a situation, and we don't want to freeze the
> > stream in that case. Transmitting 0-length packets could be an option,
> > but I wonder how much CPU overhead it would generate (both on the gadget
> > and host side). Felipe, do you have any experience with this and/or
> > recommendation ?
> 
> I'd expect the UDC to handle that in HW. At least dwc3 does, don't know
> about MUSB and the others.

But dwc3 still returns missed intervals errors in that case, right ? I think 
Terence proposal was to explicitly queue ZLP requests in order to avoid 
missing any interval.

> >> I was reading the summary of the dwc3 driver features at
> >> https://github.com/torvalds/linux/blob/master/Documentation/driver-api/us
> >> b/d wc3.rst and point 7 mentions support for "Superspeed Bulk Streams"
> >> but I was unsure if this meant that ONLY bulk streams were supported or
> >> whether isochronous streams were also supported?
> > 
> > That's a question for Felipe :-)
> 
> Super speed defines streams for bulk endpoints only.

-- 
Regards,

Laurent Pinchart






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

  Powered by Linux