On Fri, Apr 20, 2018 at 01:57:23PM +0300, Felipe Balbi wrote: > > Hi, > > Bin Liu <b-...@ti.com> writes: > >> Felipe Balbi <felipe.ba...@linux.intel.com> writes: > >> >>> Bin Liu <b-...@ti.com> 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.
Great! Drop me an email whenever it is ready to re-test, in case I missed any related conversation/patch in the mailing list. Regards, -Bin. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
