Hi Felipe, On Friday, 20 April 2018 13:57:23 EEST Felipe Balbi wrote: > 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. What is your test platform ? I'm using a TI AM574x EVM and I can't get video to stream at all in high-speed. Super-speed seems out of question as the only port supporting device mode on that board is connect to a DWC3 instance that is limited to high-speed :-/ I'm testing v4.17-rc5 without this patch series applied, please let me know if I should apply it first. > > 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. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
