Re: Pandaboard OMAP4 MUSB short packet hang on UVC gadget
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 > > ... > > [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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pandaboard OMAP4 MUSB short packet hang on UVC gadget
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 > ... > [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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Pandaboard OMAP4 MUSB short packet hang on UVC gadget
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. 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. 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" 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 ... [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 ? 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 hardware has jammed ? Stopping the pipeline (the yavta capture) and restarting, will successfully transfer (only) the first frame again. Any other hints and tips appreciated! [0] git://git.ideasonboard.org/uvc-gadget.git [1] git://git.ideasonboard.org/yavta.git [2] http://paste.ubuntu.com/p/QHrh5XzZv8/ -- Regards Kieran signature.asc Description: OpenPGP digital signature
