-Paul Eaves
+Paul Elder
On 03/11/18 23:07, 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.
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.
With these two changes, the video streams at higher bandwidth but freezes
sporadically. This problem seems to be caused by the following (there's a
bit of guesswork going on in this explanation):
a. The video stream that is being transmitted has less bandwidth than
available on the USB link (1280x720@10fps uncompressed). It looks like
about 150Mbps versus the 192Mbps for the USB link.
b. The video is not transmitted evenly and, at the end of each video frame
time there are a number of microframes where there is no data to transmit.
c. When the next video packet is queued with the dwc3 driver after the gap
in transmission, the driver generates a string of missed isoc events (it
looks like a missed isoc event for every previous microframe that has been
missed). These events come as a burst into the driver (after every new
frame is queued into the dwc3).
d. This is reported back to the f_uvc driver via the uvc_video_complete()
function call. The f_uvc tidies up it's queues based on the callback, but
the dwc3 driver hasn't transmitted any data (it is reporting the missed isoc
from previously). This seems to cause the video to freeze (dumping frames
before they are transmitted).
As a quick hack, I changed uvc_video_complete() so that it requeued the
request on receipt of the -EXDEV. This has fixed the freezing video but
there is video corruption (not surprised as the fix was just to prove that
the freezing was caused by the missed isocs). I think that this tallies
with what you are saying Laurent about the handling of missed isocs.
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?
In addition, I've moved on to testing at superspeed (with the same video
source 1280x720@10fps uncompressed). At the moment, with the superspeed
link set to a burst size of 16 and an interval of 8, the dwc3 driver will
not stream at all, it continuously reports missed isoc events for all
microframes despite having the delay added in (2) above. Has anyone any
experience using isochronous transfers with the dwc3 driver at superspeed?
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?
Thanks again for the help,
Regards,
Terry Neill
-----Original Message-----
From: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
Sent: 02 November 2018 11:49
To: Roger Quadros <rogerq@xxxxxx>
Cc: Terence Neill <t.neill@xxxxxxxxxxxxxx>; linux-usb@xxxxxxxxxxxxxxx;
Eaves, Paul <p-eaves@xxxxxx>
Subject: Re: usb: dwc3: dwc3 errors while video streaming with uvc-gadget
Hello,
On Friday, 2 November 2018 11:50:47 EET Roger Quadros wrote:
On 15/10/18 19:34, Terence Neill wrote:
Hi Felipe,
I am having some issues when attempting to stream 1280x720
uncompressed video @ 10fps over a USB 2.0 High-Speed link.
The system setup is:
WebCam --- USB 2.0 link ---> x86 Linux Machine running uvc-gadget
---- USB 2.0 link ---> x86 Host Machine running Windows 10.
When running this setup, I am experiencing the following:
1. With streaming_maxpacket set to 2048 (2 transactions per
microframe) the video will stream for approximately one minute
before terminating with "VS request completed with status -18" reported
in the kernel logs.
2. With streaming_maxpacket set to 3072 (3 transactions per
microframe) the video does not stream at all with "VS request
completed with status -18" reported in the error logs.
There were some updates pushed recently to the uvc-gadget utility [1].
Could you please try with that and see if this issue still persists?
Thanks.
[1] http://git.ideasonboard.org/uvc-gadget.git
Worth a try, but I don't think this will make a difference. The UVC gadget
function driver is known not to handle missed isoc intervals correctly. I
started having a look at that, but unfortunately had to move to other
projects, and I don't know when I'll have the time to get back to this issue
:-/
From trying to analyse what is going on (looking at traces), it
looks like the dwc3 driver is initially forwarding video buffers as
expected.
Because the bandwdith of the USB link is greater than the bandiwidth
of the video being transmitted, at some point the dwc3 driver looks
for more buffers to transmit and there aren't any. At this point,
it seems to enter a state that is not recovered from whenever a new
buffer becomes available to transmit.
I have included a trace and register dump as requested for further
analysis.
In terms of hardware/software versions for the test setup:
Linux machine - Intel n4200 - running Ubuntu 18.04 - kernel version
4.19.0-041900rc8-generic (I updated to this version this morning to
make sure I was using the latest dwc3 driver, the same problem
exists (with a different error code -104) with the stock Ubuntu 18.04
kernel).
Windows machine - Core i5-4570 - Windows 10 Enterprise.
Any help with further investigation of this problem would be
appreciated?
Could this problem be caused by the configuration setup that I'm
using for the uvc gadget?
Thanks in advance for your help,
--
Regards,
Laurent Pinchart
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
