Hello again, On Thursday, 24 May 2018 22:59:18 EEST Laurent Pinchart wrote: > 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. I tried to merge your dwc3-improve-isoc-endpoints branch but it unfortunately didn't help. I still can't capture any frame on the host. With and without your patches I get the following messages in the device's kernel log. - At gadget creation and plug time: [ 12.361591] configfs-gadget gadget: uvc_function_bind [ 16.783801] configfs-gadget gadget: high-speed config #1: c [ 16.790032] configfs-gadget gadget: uvc_function_set_alt(0, 0) [ 16.796166] configfs-gadget gadget: reset UVC Control [ 16.801537] configfs-gadget gadget: uvc_function_set_alt(1, 0) [ 16.818799] configfs-gadget gadget: uvc_function_set_alt(1, 0) - At stream start time: [ 23.093891] configfs-gadget gadget: uvc_function_set_alt(1, 1) [ 23.103072] configfs-gadget gadget: reset UVC [ 23.111108] dwc3 488d0000.usb: ep2in: ran out of requests and everything stops there. > >> 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
