Hi, 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? > 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. > 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. > 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. Regards, -Bin. -- 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
