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
