Hi, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> 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. >> 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. >> I was reading the summary of the dwc3 driver features at >> https://github.com/torvalds/linux/blob/master/Documentation/driver-api/usb/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. -- balbi
Attachment:
signature.asc
Description: PGP signature
