Hi Bin, On Wednesday, 16 May 2018 18:45:40 EEST Bin Liu wrote: > On Tue, May 15, 2018 at 10:58:16PM +0100, Kieran Bingham wrote: > > Hi Bin, Felipe, > > > > We have been trying to get a UVC gadget operational on the Pandaboard ES > > platform, and we believe we've hit an issue with short packets on the MUSB > > in DMA mode. > > I don't have a Pandaboard. Does it use MUSB internal DMA engine? It uses the OMAP2+ glue and the Inventra DMA engine, yes. > > Using the g_webcam module, I can instantiate a UVC video node, and use the > > uvc-gadget helper application [0] to handle the frame generation. > > > > With DMA disabled using CONFIG_MUSB_PIO_ONLY I am able to process frames > > on the host using yavta [1] > > > > However when DMA is enabled, only the first frame is transmitted to the > > host, and I get an error from the musb_log debug prints which indicate > > that the MUSB_TXCSR_TXPKTRDY is not cleared following a short packet. > > The MUSB_TXCSR_TXPKTRDY bit should be clear by the MUSB controller after > the TX packet is transmitted, there is no sw involved. I've just found https://groups.google.com/forum/?hl=en#!topic/beagleboard-gsoc/k8Azwfp75CU that seems to be related. We'll try it out. Does the patch make sense to you ? > > A capture of the musb_log trace-points [2] shows the following at the end > > of the log: > > > > The 'mode' has been set to '0' instead of '1', buffer length is 902 > > instead of 1024 (expected behaviour for the last packet): > > "ep13-Tx pkt_sz 1024, dma_addr 0xadfbbc00 length 902, mode 0" > > > > And then there is a fault reported: > > "ep13 old packet still ready , txcsr 2003" > > I just checked the same testcase on Beaglebone Black which uses CPPI41 > DMA, this bit is cleared after sent the 902-bytes end-of-frame packet. That would point to an issue with the Inventra DMA engine, which would be consistent with the above patch. > > The host (linux, running the uvc driver with extra debug prints) reports: > > > > [24517.711147] uvcvideo: decode_data: len: 1022, maxlen 460800 > > [24517.759117] uvcvideo: decode_data: len: 1022, maxlen 459778 > > <snip> ... > > [24529.375018] uvcvideo: decode_data: len: 1022, maxlen 2944 > > [24529.399073] uvcvideo: decode_data: len: 1022, maxlen 1922 > > [24529.427014] uvcvideo: decode_data: len: 900, maxlen 900 > > > > And receives no further data following the end of the first frame. > > > > > > Are there any known issues on the musb-gadget with short-packet handling - > > or any other tests I can perform to check this ? > > Nothing that I am aware of. > > > Should I be looking to try to get the txstate() call to re-execute after a > > delay (using musb_queue_resume_work() perhaps?) or does this indicate > > that the > > I am not sure how that will make the controller to clear the TXPKTRDY > bit. > > > hardware has jammed ? Stopping the pipeline (the yavta capture) and > > restarting, > > Likely that is the case. > > > will successfully transfer (only) the first frame again. > > > > Any other hints and tips appreciated! > > Does the usecase ever worked on Pandaboard with older kernels? If so, > you can try to bisect the commit which causes the regression. Not that I recall. The use case was initially developed on a Davinci system, and has been tested on a Beagleboard, but I don't remember having tested it on OMAP4. -- 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
