2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@xxxxxx>: > Hi, > > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote: >> 2016-07-19 23:56 GMT+03:00 Bin Liu <b-liu@xxxxxx>: >> > Hi, >> > >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@xxxxxxxxxx wrote: >> >> Hello, >> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based BeagleBoneBlack SBC. >> >> I am sure that both of them are fine and work properly. >> >> I am running Linux 4.6.4 (my kernel config is available at https://clck.ru/A2kQs ) and I've just discovered, that there is an issue with frame transfer when high resolution formats are used. >> >> >> >> The issue is the following. I use simple v4l2 example tool (taken from API docs), which source code is available at http://pastebin.com/grcNXxfe >> >> >> >> When I use (see line 488) 640x480 frames >> >> >> >> fmt.fmt.pix.width = 640; >> >> fmt.fmt.pix.height = 480; >> >> >> >> then I get "select timeout" and don't get any frames. >> >> >> >> When I use 320x240 frames >> >> >> >> fmt.fmt.pix.width = 320; >> >> fmt.fmt.pix.height = 240; >> >> >> >> then about 60% frames are missed. An example outpout of ./a.out -f is available at https://yadi.sk/d/aRka8xWPtSc4y >> >> It looks like there are pauses between bulks of frames (frame counter and timestamp as returned from v4l2 API): >> >> >> >> 3 3705.142553 >> >> 8 3705.342533 >> >> 13 3705.542517 >> >> 110 3708.776208 >> >> 115 3708.976190 >> >> 120 3709.176169 >> >> 125 3709.376152 >> >> 130 3709.576144 >> >> 226 3712.807848 >> >> >> >> When I use tiny 160x120 frames >> >> >> >> fmt.fmt.pix.width = 160; >> >> fmt.fmt.pix.height = 120; >> >> >> >> then more frames are received. See output example at https://yadi.sk/d/DedBmH6ftSc9t >> >> That is why I thought that everything was fine in May when used tiny xawtv window to check kernel OOPS presence (see http://www.spinics.net/lists/linux-usb/msg141188.html for reference) >> >> >> >> Even more. When I introduce USB hub between the host and the webcam, I can not receive even any 320x240 frames. >> >> >> >> I've managed to use ftrace to see what is going on when no frames are received. >> >> I've found that pwc_isoc_handler is called frequently as the following: >> >> >> >> 0) | pwc_isoc_handler [pwc]() { >> >> 0) | usb_submit_urb [usbcore]() { >> >> 0) | usb_submit_urb.part.3 [usbcore]() { >> >> 0) | usb_hcd_submit_urb [usbcore]() { >> >> 0) 0.834 us | usb_get_urb [usbcore](); >> >> 0) | musb_map_urb_for_dma [musb_hdrc]() { >> >> 0) 0.792 us | usb_hcd_map_urb_for_dma [usbcore](); >> >> 0) 5.750 us | } >> >> 0) | musb_urb_enqueue [musb_hdrc]() { >> >> 0) 0.750 us | _raw_spin_lock_irqsave(); >> >> 0) | usb_hcd_link_urb_to_ep [usbcore]() { >> >> 0) 0.792 us | _raw_spin_lock(); >> >> 0) 0.791 us | _raw_spin_unlock(); >> >> 0) + 10.500 us | } >> >> 0) 0.791 us | _raw_spin_unlock_irqrestore(); >> >> 0) + 25.375 us | } >> >> 0) + 45.208 us | } >> >> 0) + 51.042 us | } >> >> 0) + 56.084 us | } >> >> 0) + 61.292 us | } >> >> >> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I get "select timeout" in userspace. >> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y but I can recompile it, if you think that it could provide more information. I am also ready to perform additional tests (use usbmon maybe?). >> >> >> >> How could this issue be resolved? >> >> >> >> Thank you. >> > >> > Do you have CPPI DMA enabled? If so I think you might hit on a known >> > issue in CPPI Isoch transfer, in which the MUSB controller only sends IN >> > tokens in every other SOF, so only half of the bus bandwidth is >> > utilized, which causes video frame drops in higher resolution. >> > >> >> Yes, I do use DMA: >> >> CONFIG_USB_TI_CPPI41_DMA=y > > Okay. > >> >> > To confirm this, use a bus analyzer to capture a bus trace, you would >> > see no IN tokens in every other SOF while transfering Isoch packets. >> > >> >> I am sorry, I am new to USB debugging. Do you mean I need to use >> usbmon or some external hardware device? > > I barely use usbmon, and not sure if it gives the information I am > looking for. But I meant the external test equipment - USB bus protocol > analyzer - a bus packet sniffer. > Now I see. I've googled it, they start from $1000, I don't know when/whether/where I can get one to try. Until that, could I check something else? For instance, disable CONFIG_USB_TI_CPPI41_DMA. I've found that after hours of transmit, the camera stops iso at all (until reset). Maybe its brain becomes damaged by the transfer issues at the some moment. I've just also made some usbmon records and see that even when there are no frames in userspace there is iso transfer occuring. 160x140: https://yadi.sk/d/BmUCPP_EtT8SN 640x480 (no frames in user space): https://yadi.sk/d/KXLU-g9-tT8T7 Maybe pwc people could give some useful insight looking into the records. AFAIU pwc camera support transfer compression and pwc driver negotiates automaticly the best possible compression level (older kernal provided module option to do it manually). However, in pwc_isoc_init(), I see the following /* We first try with low compression and then retry with a higher compression setting if there is not enough bandwidth. */ ret = pwc_set_video_mode(pdev, pdev->width, pdev->height, pdev->pixfmt, pdev->vframes, &compression, 1); and ret is never checked and is being overwritten a few lines further. > Regards, > -Bin, > >> >> > Regards, >> > -Bin. >> > >> >> >> >> -- >> With best regards, >> Matwey V. Kornilov. >> Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia >> 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
