Hi, Bin Liu <b-liu@xxxxxx> writes: >> Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> writes: >> >>> Bin Liu <b-liu@xxxxxx> writes: >> >>> > On Mon, Apr 09, 2018 at 02:26:14PM +0300, Felipe Balbi wrote: >> >>> >> Hi guys, >> >>> >> >> >>> >> I've been working on this series for a while now. I feels like after >> >>> >> this series the transfer management code is far easier to read and >> >>> >> understand. >> >>> >> >> >>> >> Based on my tests, I have no regressions. Tested g_mass_storage and all >> >>> >> of testusb's tests (including ISOC). >> >>> >> >> >>> >> Patches are also available on dwc3-improve-isoc-endpoints in my k.org >> >>> >> tree. Test reports would be VERY, VERY, VERY welcome. Please give this a >> >>> >> go so we avoid regressions on v4.18. >> >>> > >> >>> > Have you tested g_webcam? I just tested your dwc3-improve-isoc-endpoints >> >>> >> >>> for isoc I only tested g_zero. >> >> >> >> Then writting down details on what I observed probably won't help you :( >> >> I got webcam running here, it sure _is_ helpful to let me know how you > > Great! > >> trigger the problem ;-) Also, high-speed or super-speed? > > Both. Long story short - super-speed doesn't stream the yuv video, > gadget side kernel prints "VS request completed with status -18." > flooding messages. > > high-speed does stream the video, but stopping the host application > (both yavta and luvcview) causes gadget side kernel prints error message > (I didn't keep the log). Then restart the host application doesn't > stream the video any more. > > To run the test: > gadget side: > # modprobe g_webcam (streaming_maxpacket=3072 for super-speed) > # uvc-gadget > host side: > $ yavta -c -f YUYV -t 1/30 -s 640x360 -n4 /dev/video1, or > $ luvcview -d /dev/video1 -f yuv okay, found the problem. This is actually a problem on webcam gadget which kills the stream in case of Missed Isoc. The reason why it "works" with dwc3 today is because dwc3, up until now, is really harsh whenever we miss and interval. Currently we stop the transfer and wait for the next XferNotReady. This may cause us to loose many frames. I've been talking with Laurent Pinchart (in Cc) about what would be the best way to sort this out and, our conclusion, is that webcam gadget should have a way for a single buffer to be treated as erroneous, but it shouldn't stop the stream. There's also another error in webcam gadget where default interval, maxburst and maxpacket aren't very good for HS or SS. Note that streaming_interval is, by default, 1. Which for FS means 1ms, but for HS/SS it means 1 * 125us. So host side is actually polling webcam gadget every uFrame. I got webcam gadget to behave really well with streaming_interval=4 streaming_maxburst=16 streaming_maxpacket=3072. With that, in SS, I can get around 100 fps. There are a few cases when FPS drops to 33, but that's because it coincides with a missed isoc and webcam stops and restarts the stream. -- balbi
Attachment:
signature.asc
Description: PGP signature
