pwc over musb: 100% frame drop (lost) on high resolution stream

pwc over musb: 100% frame drop (lost) on high resolution stream

[matwey]

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.

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Bin Liu]

Hi,

On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.

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.

Regards,
-Bin.

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-19 23:56 GMT+03:00 Bin Liu <b-liu@ti.com>:
> Hi,
>
> On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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

> 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?

> 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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Bin Liu]

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@ti.com>:
> > Hi,
> >
> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.

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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
> 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@ti.com>:
>> > Hi,
>> >
>> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-20 9:09 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>> 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@ti.com>:
>>> > Hi,
>>> >
>>> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>

I also have part of dmesg output: https://yadi.sk/d/tjr4EljCtTNbV but
not sure that it can help.

>
>
>> 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



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Bin Liu]

Hi,

On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
> > 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@ti.com>:
> >> > Hi,
> >> >
> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.

I think you might be able to check it without a sniffer - MUSB
controller can generate SOF interrupts, but it is masked in current
driver. So I think you could enable SOF interrupt, then if you get a log
as
	SOF
	rx packet
	SOF
	rx packet
	SOF
	...
or
	SOF
	rx packet
	rx packet
	rx packet
	SOF
	rx packet
	rx packet
	rx packet
	SOF
	...

which means your issue is different from the one I mentioned. But if
you get a log as

	SOF
	rx packet
	SOF
	SOF	<--- no rx packets in two consecutive SOFs
	rx packet
	SOF
	SOF

then you hit on the known issue I mentioned.

> Until that, could I check something else? For instance, disable
> CONFIG_USB_TI_CPPI41_DMA.

You could disable it, but I don't think you will get yuv video stream
of 640x480@30fps. PIO mode does not support such high bandwidth. What is
your video requirement anyway?

> 
> 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

How did you check that? MUSB stopped generating RX EP interrupt?

> 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

Sorry, I am unable to read it behind my firewall.

Regards,
-Bin.

> 
> 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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
> Hi,
>
> On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>> > 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@ti.com>:
>> >> > Hi,
>> >> >
>> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>
> I think you might be able to check it without a sniffer - MUSB
> controller can generate SOF interrupts, but it is masked in current
> driver. So I think you could enable SOF interrupt, then if you get a log
> as
>         SOF
>         rx packet
>         SOF
>         rx packet
>         SOF
>         ...
> or
>         SOF
>         rx packet
>         rx packet
>         rx packet
>         SOF
>         rx packet
>         rx packet
>         rx packet
>         SOF
>         ...
>
> which means your issue is different from the one I mentioned. But if
> you get a log as
>
>         SOF
>         rx packet
>         SOF
>         SOF     <--- no rx packets in two consecutive SOFs
>         rx packet
>         SOF
>         SOF
>
> then you hit on the known issue I mentioned.
>
>> Until that, could I check something else? For instance, disable
>> CONFIG_USB_TI_CPPI41_DMA.
>
> You could disable it, but I don't think you will get yuv video stream
> of 640x480@30fps. PIO mode does not support such high bandwidth. What is
> your video requirement anyway?

Many thanks for your guidance. I will answer the rest later when will
be ready to play with SOF interrupt.
Now, I would like to say that use_dma=0 doesn't change the behaviour:

# cat /sys/module/musb_hdrc/parameters/use_dma
N

I would like 640x480@5fps which works with x86 based PC. Issue here,
that I can not obtain 640x480 at any FPS on musb.

>
>>
>> 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
>
> How did you check that? MUSB stopped generating RX EP interrupt?

Something like that, I suppose. Normally, I see input data flow in
usbmon, but don't see frames in v4l2.
But when camera 'hungs', I don't see nor input flow (except the
control packages exchange) neither frames.

>
>> 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
>
> Sorry, I am unable to read it behind my firewall.
>
> Regards,
> -Bin.
>
>>
>> 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
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Bin Liu]

Hi,

On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
> > Hi,
> >
> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
> >> > 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@ti.com>:
> >> >> > Hi,
> >> >> >
> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
> >
> > I think you might be able to check it without a sniffer - MUSB
> > controller can generate SOF interrupts, but it is masked in current
> > driver. So I think you could enable SOF interrupt, then if you get a log
> > as
> >         SOF
> >         rx packet
> >         SOF
> >         rx packet
> >         SOF
> >         ...
> > or
> >         SOF
> >         rx packet
> >         rx packet
> >         rx packet
> >         SOF
> >         rx packet
> >         rx packet
> >         rx packet
> >         SOF
> >         ...
> >
> > which means your issue is different from the one I mentioned. But if
> > you get a log as
> >
> >         SOF
> >         rx packet
> >         SOF
> >         SOF     <--- no rx packets in two consecutive SOFs
> >         rx packet
> >         SOF
> >         SOF
> >
> > then you hit on the known issue I mentioned.
> >
> >> Until that, could I check something else? For instance, disable
> >> CONFIG_USB_TI_CPPI41_DMA.
> >
> > You could disable it, but I don't think you will get yuv video stream
> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
> > your video requirement anyway?
> 
> Many thanks for your guidance. I will answer the rest later when will
> be ready to play with SOF interrupt.
> Now, I would like to say that use_dma=0 doesn't change the behaviour:
> 
> # cat /sys/module/musb_hdrc/parameters/use_dma
> N

It sounds like you have a different issue here. With usb_dma=0, I
remembered I can get 320x240 YUV stream @30fps from uvc cameras.

> 
> I would like 640x480@5fps which works with x86 based PC. Issue here,
> that I can not obtain 640x480 at any FPS on musb.

The current CPPI41 driver should be able to handle this. I think you
really have to debug the pwc driver to figure out why it drops the video
frame. I personally don't have a pwc supported camera, never looked the
pwc driver...

> 
> >
> >>
> >> 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
> >
> > How did you check that? MUSB stopped generating RX EP interrupt?
> 
> Something like that, I suppose. Normally, I see input data flow in
> usbmon, but don't see frames in v4l2.
> But when camera 'hungs', I don't see nor input flow (except the
> control packages exchange) neither frames.

Fair enough.

Regards,
-Bin.

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
> Hi,
>
> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>> > Hi,
>> >
>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>> >> > 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@ti.com>:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>> >
>> > I think you might be able to check it without a sniffer - MUSB
>> > controller can generate SOF interrupts, but it is masked in current
>> > driver. So I think you could enable SOF interrupt, then if you get a log
>> > as
>> >         SOF
>> >         rx packet
>> >         SOF
>> >         rx packet
>> >         SOF
>> >         ...
>> > or
>> >         SOF
>> >         rx packet
>> >         rx packet
>> >         rx packet
>> >         SOF
>> >         rx packet
>> >         rx packet
>> >         rx packet
>> >         SOF
>> >         ...
>> >
>> > which means your issue is different from the one I mentioned. But if
>> > you get a log as
>> >
>> >         SOF
>> >         rx packet
>> >         SOF
>> >         SOF     <--- no rx packets in two consecutive SOFs
>> >         rx packet
>> >         SOF
>> >         SOF
>> >
>> > then you hit on the known issue I mentioned.
>> >
>> >> Until that, could I check something else? For instance, disable
>> >> CONFIG_USB_TI_CPPI41_DMA.
>> >
>> > You could disable it, but I don't think you will get yuv video stream
>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>> > your video requirement anyway?
>>
>> Many thanks for your guidance. I will answer the rest later when will
>> be ready to play with SOF interrupt.
>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>
>> # cat /sys/module/musb_hdrc/parameters/use_dma
>> N
>
> It sounds like you have a different issue here. With usb_dma=0, I
> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>
>>
>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>> that I can not obtain 640x480 at any FPS on musb.
>
> The current CPPI41 driver should be able to handle this. I think you
> really have to debug the pwc driver to figure out why it drops the video
> frame. I personally don't have a pwc supported camera, never looked the
> pwc driver...

Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
640x480 frames.
Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
Quad-code Atom E3800 based PC with 4.1 also works fine.

So, I even don't know what to say. Probably, the issue depends on CPU
latency/performance and it was there for a while.
Fortunately, I think, I could use git bisect if I found latest forking
kernel for my laptop.

>
>>
>> >
>> >>
>> >> 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
>> >
>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>
>> Something like that, I suppose. Normally, I see input data flow in
>> usbmon, but don't see frames in v4l2.
>> But when camera 'hungs', I don't see nor input flow (except the
>> control packages exchange) neither frames.
>
> Fair enough.
>
> 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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>> Hi,
>>
>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>> > Hi,
>>> >
>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>> >> > 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@ti.com>:
>>> >> >> > Hi,
>>> >> >> >
>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>> >
>>> > I think you might be able to check it without a sniffer - MUSB
>>> > controller can generate SOF interrupts, but it is masked in current
>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>> > as
>>> >         SOF
>>> >         rx packet
>>> >         SOF
>>> >         rx packet
>>> >         SOF
>>> >         ...
>>> > or
>>> >         SOF
>>> >         rx packet
>>> >         rx packet
>>> >         rx packet
>>> >         SOF
>>> >         rx packet
>>> >         rx packet
>>> >         rx packet
>>> >         SOF
>>> >         ...
>>> >
>>> > which means your issue is different from the one I mentioned. But if
>>> > you get a log as
>>> >
>>> >         SOF
>>> >         rx packet
>>> >         SOF
>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>> >         rx packet
>>> >         SOF
>>> >         SOF
>>> >
>>> > then you hit on the known issue I mentioned.
>>> >
>>> >> Until that, could I check something else? For instance, disable
>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>> >
>>> > You could disable it, but I don't think you will get yuv video stream
>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>> > your video requirement anyway?
>>>
>>> Many thanks for your guidance. I will answer the rest later when will
>>> be ready to play with SOF interrupt.
>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>
>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>> N
>>
>> It sounds like you have a different issue here. With usb_dma=0, I
>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>
>>>
>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>> that I can not obtain 640x480 at any FPS on musb.
>>
>> The current CPPI41 driver should be able to handle this. I think you
>> really have to debug the pwc driver to figure out why it drops the video
>> frame. I personally don't have a pwc supported camera, never looked the
>> pwc driver...
>
> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
> 640x480 frames.
> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
> Quad-code Atom E3800 based PC with 4.1 also works fine.
>
> So, I even don't know what to say. Probably, the issue depends on CPU
> latency/performance and it was there for a while.
> Fortunately, I think, I could use git bisect if I found latest forking
> kernel for my laptop.
>

It seems that the issue is gone in 4.7-rc7, so forget it.

>>
>>>
>>> >
>>> >>
>>> >> 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
>>> >
>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>
>>> Something like that, I suppose. Normally, I see input data flow in
>>> usbmon, but don't see frames in v4l2.
>>> But when camera 'hungs', I don't see nor input flow (except the
>>> control packages exchange) neither frames.
>>
>> Fair enough.
>>
>> 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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

Hello,

I've just biseced commit, which introduced this issue

commit f551e13529833e052f75ec628a8af7b034af20f9
Author: Bin Liu <b-liu@ti.com>
Date:   Mon Apr 25 15:53:30 2016 -0500

    Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
return in bottom half"

I have not checked yet, if it was intentionnaly fixed.

2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>> Hi,
>>>
>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>> > Hi,
>>>> >
>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>> >> > 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@ti.com>:
>>>> >> >> > Hi,
>>>> >> >> >
>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>>> >
>>>> > I think you might be able to check it without a sniffer - MUSB
>>>> > controller can generate SOF interrupts, but it is masked in current
>>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>>> > as
>>>> >         SOF
>>>> >         rx packet
>>>> >         SOF
>>>> >         rx packet
>>>> >         SOF
>>>> >         ...
>>>> > or
>>>> >         SOF
>>>> >         rx packet
>>>> >         rx packet
>>>> >         rx packet
>>>> >         SOF
>>>> >         rx packet
>>>> >         rx packet
>>>> >         rx packet
>>>> >         SOF
>>>> >         ...
>>>> >
>>>> > which means your issue is different from the one I mentioned. But if
>>>> > you get a log as
>>>> >
>>>> >         SOF
>>>> >         rx packet
>>>> >         SOF
>>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>>> >         rx packet
>>>> >         SOF
>>>> >         SOF
>>>> >
>>>> > then you hit on the known issue I mentioned.
>>>> >
>>>> >> Until that, could I check something else? For instance, disable
>>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>>> >
>>>> > You could disable it, but I don't think you will get yuv video stream
>>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>>> > your video requirement anyway?
>>>>
>>>> Many thanks for your guidance. I will answer the rest later when will
>>>> be ready to play with SOF interrupt.
>>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>>
>>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>>> N
>>>
>>> It sounds like you have a different issue here. With usb_dma=0, I
>>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>>
>>>>
>>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>>> that I can not obtain 640x480 at any FPS on musb.
>>>
>>> The current CPPI41 driver should be able to handle this. I think you
>>> really have to debug the pwc driver to figure out why it drops the video
>>> frame. I personally don't have a pwc supported camera, never looked the
>>> pwc driver...
>>
>> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
>> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
>> 640x480 frames.
>> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
>> Quad-code Atom E3800 based PC with 4.1 also works fine.
>>
>> So, I even don't know what to say. Probably, the issue depends on CPU
>> latency/performance and it was there for a while.
>> Fortunately, I think, I could use git bisect if I found latest forking
>> kernel for my laptop.
>>
>
> It seems that the issue is gone in 4.7-rc7, so forget it.
>
>>>
>>>>
>>>> >
>>>> >>
>>>> >> 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
>>>> >
>>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>>
>>>> Something like that, I suppose. Normally, I see input data flow in
>>>> usbmon, but don't see frames in v4l2.
>>>> But when camera 'hungs', I don't see nor input flow (except the
>>>> control packages exchange) neither frames.
>>>
>>> Fair enough.
>>>
>>> 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



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

Hello,

I've just bisected commit, which fixed the issue in v4.7

commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
Merge: f55532a febce40
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Sat Apr 2 01:07:17 2016 +0200

    Merge back intel_pstate fixes for v4.6.

    * pm-cpufreq:
      intel_pstate: Avoid extra invocation of intel_pstate_sample()
      intel_pstate: Do not set utilization update hook too early

Unfortunately, intel_pstate branch doesn't have
f551e13529833e052f75ec628a8af7b034af20f9 applied.
I'll try to bisect this branch with the patch manually applied.

2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> Hello,
>
> I've just biseced commit, which introduced this issue
>
> commit f551e13529833e052f75ec628a8af7b034af20f9
> Author: Bin Liu <b-liu@ti.com>
> Date:   Mon Apr 25 15:53:30 2016 -0500
>
>     Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
> return in bottom half"
>
> I have not checked yet, if it was intentionnaly fixed.
>
> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>> Hi,
>>>>
>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>> > Hi,
>>>>> >
>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>> >> > 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@ti.com>:
>>>>> >> >> > Hi,
>>>>> >> >> >
>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>>>> >
>>>>> > I think you might be able to check it without a sniffer - MUSB
>>>>> > controller can generate SOF interrupts, but it is masked in current
>>>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>>>> > as
>>>>> >         SOF
>>>>> >         rx packet
>>>>> >         SOF
>>>>> >         rx packet
>>>>> >         SOF
>>>>> >         ...
>>>>> > or
>>>>> >         SOF
>>>>> >         rx packet
>>>>> >         rx packet
>>>>> >         rx packet
>>>>> >         SOF
>>>>> >         rx packet
>>>>> >         rx packet
>>>>> >         rx packet
>>>>> >         SOF
>>>>> >         ...
>>>>> >
>>>>> > which means your issue is different from the one I mentioned. But if
>>>>> > you get a log as
>>>>> >
>>>>> >         SOF
>>>>> >         rx packet
>>>>> >         SOF
>>>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>>>> >         rx packet
>>>>> >         SOF
>>>>> >         SOF
>>>>> >
>>>>> > then you hit on the known issue I mentioned.
>>>>> >
>>>>> >> Until that, could I check something else? For instance, disable
>>>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>>>> >
>>>>> > You could disable it, but I don't think you will get yuv video stream
>>>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>>>> > your video requirement anyway?
>>>>>
>>>>> Many thanks for your guidance. I will answer the rest later when will
>>>>> be ready to play with SOF interrupt.
>>>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>>>
>>>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>>>> N
>>>>
>>>> It sounds like you have a different issue here. With usb_dma=0, I
>>>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>>>
>>>>>
>>>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>>>> that I can not obtain 640x480 at any FPS on musb.
>>>>
>>>> The current CPPI41 driver should be able to handle this. I think you
>>>> really have to debug the pwc driver to figure out why it drops the video
>>>> frame. I personally don't have a pwc supported camera, never looked the
>>>> pwc driver...
>>>
>>> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
>>> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
>>> 640x480 frames.
>>> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
>>> Quad-code Atom E3800 based PC with 4.1 also works fine.
>>>
>>> So, I even don't know what to say. Probably, the issue depends on CPU
>>> latency/performance and it was there for a while.
>>> Fortunately, I think, I could use git bisect if I found latest forking
>>> kernel for my laptop.
>>>
>>
>> It seems that the issue is gone in 4.7-rc7, so forget it.
>>
>>>>
>>>>>
>>>>> >
>>>>> >>
>>>>> >> 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
>>>>> >
>>>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>>>
>>>>> Something like that, I suppose. Normally, I see input data flow in
>>>>> usbmon, but don't see frames in v4l2.
>>>>> But when camera 'hungs', I don't see nor input flow (except the
>>>>> control packages exchange) neither frames.
>>>>
>>>> Fair enough.
>>>>
>>>> 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
>
>
>
> --
> 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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

Hello,

I've found that the following commit fixes the issue:

commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Fri Apr 22 16:58:42 2016 +0530

    cpufreq: omap: Use generic platdev driver

    The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
    device now, reuse that and remove similar code from platform code.


2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> Hello,
>
> I've just bisected commit, which fixed the issue in v4.7
>
> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
> Merge: f55532a febce40
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date:   Sat Apr 2 01:07:17 2016 +0200
>
>     Merge back intel_pstate fixes for v4.6.
>
>     * pm-cpufreq:
>       intel_pstate: Avoid extra invocation of intel_pstate_sample()
>       intel_pstate: Do not set utilization update hook too early
>
> Unfortunately, intel_pstate branch doesn't have
> f551e13529833e052f75ec628a8af7b034af20f9 applied.
> I'll try to bisect this branch with the patch manually applied.
>
> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> Hello,
>>
>> I've just biseced commit, which introduced this issue
>>
>> commit f551e13529833e052f75ec628a8af7b034af20f9
>> Author: Bin Liu <b-liu@ti.com>
>> Date:   Mon Apr 25 15:53:30 2016 -0500
>>
>>     Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
>> return in bottom half"
>>
>> I have not checked yet, if it was intentionnaly fixed.
>>
>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>> Hi,
>>>>>
>>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>> > Hi,
>>>>>> >
>>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>> >> > 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@ti.com>:
>>>>>> >> >> > Hi,
>>>>>> >> >> >
>>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>>>>> >
>>>>>> > I think you might be able to check it without a sniffer - MUSB
>>>>>> > controller can generate SOF interrupts, but it is masked in current
>>>>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>>>>> > as
>>>>>> >         SOF
>>>>>> >         rx packet
>>>>>> >         SOF
>>>>>> >         rx packet
>>>>>> >         SOF
>>>>>> >         ...
>>>>>> > or
>>>>>> >         SOF
>>>>>> >         rx packet
>>>>>> >         rx packet
>>>>>> >         rx packet
>>>>>> >         SOF
>>>>>> >         rx packet
>>>>>> >         rx packet
>>>>>> >         rx packet
>>>>>> >         SOF
>>>>>> >         ...
>>>>>> >
>>>>>> > which means your issue is different from the one I mentioned. But if
>>>>>> > you get a log as
>>>>>> >
>>>>>> >         SOF
>>>>>> >         rx packet
>>>>>> >         SOF
>>>>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>>>>> >         rx packet
>>>>>> >         SOF
>>>>>> >         SOF
>>>>>> >
>>>>>> > then you hit on the known issue I mentioned.
>>>>>> >
>>>>>> >> Until that, could I check something else? For instance, disable
>>>>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>>>>> >
>>>>>> > You could disable it, but I don't think you will get yuv video stream
>>>>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>>>>> > your video requirement anyway?
>>>>>>
>>>>>> Many thanks for your guidance. I will answer the rest later when will
>>>>>> be ready to play with SOF interrupt.
>>>>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>>>>
>>>>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>>>>> N
>>>>>
>>>>> It sounds like you have a different issue here. With usb_dma=0, I
>>>>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>>>>
>>>>>>
>>>>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>>>>> that I can not obtain 640x480 at any FPS on musb.
>>>>>
>>>>> The current CPPI41 driver should be able to handle this. I think you
>>>>> really have to debug the pwc driver to figure out why it drops the video
>>>>> frame. I personally don't have a pwc supported camera, never looked the
>>>>> pwc driver...
>>>>
>>>> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
>>>> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
>>>> 640x480 frames.
>>>> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
>>>> Quad-code Atom E3800 based PC with 4.1 also works fine.
>>>>
>>>> So, I even don't know what to say. Probably, the issue depends on CPU
>>>> latency/performance and it was there for a while.
>>>> Fortunately, I think, I could use git bisect if I found latest forking
>>>> kernel for my laptop.
>>>>
>>>
>>> It seems that the issue is gone in 4.7-rc7, so forget it.
>>>
>>>>>
>>>>>>
>>>>>> >
>>>>>> >>
>>>>>> >> 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
>>>>>> >
>>>>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>>>>
>>>>>> Something like that, I suppose. Normally, I see input data flow in
>>>>>> usbmon, but don't see frames in v4l2.
>>>>>> But when camera 'hungs', I don't see nor input flow (except the
>>>>>> control packages exchange) neither frames.
>>>>>
>>>>> Fair enough.
>>>>>
>>>>> 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
>>
>>
>>
>> --
>> 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



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

Hello,

I've also just found that the same commit breaks cpufreq on BeagleBone Black :)

So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
frequency, which is unlisted and being set to 720Mhz by cpufreq driver
(as it did whet there was cpufreq driver).

2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> Hello,
>
> I've found that the following commit fixes the issue:
>
> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
> Author: Viresh Kumar <viresh.kumar@linaro.org>
> Date:   Fri Apr 22 16:58:42 2016 +0530
>
>     cpufreq: omap: Use generic platdev driver
>
>     The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>     device now, reuse that and remove similar code from platform code.
>
>
> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> Hello,
>>
>> I've just bisected commit, which fixed the issue in v4.7
>>
>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>> Merge: f55532a febce40
>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> Date:   Sat Apr 2 01:07:17 2016 +0200
>>
>>     Merge back intel_pstate fixes for v4.6.
>>
>>     * pm-cpufreq:
>>       intel_pstate: Avoid extra invocation of intel_pstate_sample()
>>       intel_pstate: Do not set utilization update hook too early
>>
>> Unfortunately, intel_pstate branch doesn't have
>> f551e13529833e052f75ec628a8af7b034af20f9 applied.
>> I'll try to bisect this branch with the patch manually applied.
>>
>> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>> Hello,
>>>
>>> I've just biseced commit, which introduced this issue
>>>
>>> commit f551e13529833e052f75ec628a8af7b034af20f9
>>> Author: Bin Liu <b-liu@ti.com>
>>> Date:   Mon Apr 25 15:53:30 2016 -0500
>>>
>>>     Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
>>> return in bottom half"
>>>
>>> I have not checked yet, if it was intentionnaly fixed.
>>>
>>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>> Hi,
>>>>>>
>>>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>> >> > 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@ti.com>:
>>>>>>> >> >> > Hi,
>>>>>>> >> >> >
>>>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>>>>>> >
>>>>>>> > I think you might be able to check it without a sniffer - MUSB
>>>>>>> > controller can generate SOF interrupts, but it is masked in current
>>>>>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>>>>>> > as
>>>>>>> >         SOF
>>>>>>> >         rx packet
>>>>>>> >         SOF
>>>>>>> >         rx packet
>>>>>>> >         SOF
>>>>>>> >         ...
>>>>>>> > or
>>>>>>> >         SOF
>>>>>>> >         rx packet
>>>>>>> >         rx packet
>>>>>>> >         rx packet
>>>>>>> >         SOF
>>>>>>> >         rx packet
>>>>>>> >         rx packet
>>>>>>> >         rx packet
>>>>>>> >         SOF
>>>>>>> >         ...
>>>>>>> >
>>>>>>> > which means your issue is different from the one I mentioned. But if
>>>>>>> > you get a log as
>>>>>>> >
>>>>>>> >         SOF
>>>>>>> >         rx packet
>>>>>>> >         SOF
>>>>>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>>>>>> >         rx packet
>>>>>>> >         SOF
>>>>>>> >         SOF
>>>>>>> >
>>>>>>> > then you hit on the known issue I mentioned.
>>>>>>> >
>>>>>>> >> Until that, could I check something else? For instance, disable
>>>>>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>>>>>> >
>>>>>>> > You could disable it, but I don't think you will get yuv video stream
>>>>>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>>>>>> > your video requirement anyway?
>>>>>>>
>>>>>>> Many thanks for your guidance. I will answer the rest later when will
>>>>>>> be ready to play with SOF interrupt.
>>>>>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>>>>>
>>>>>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>>>>>> N
>>>>>>
>>>>>> It sounds like you have a different issue here. With usb_dma=0, I
>>>>>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>>>>>
>>>>>>>
>>>>>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>>>>>> that I can not obtain 640x480 at any FPS on musb.
>>>>>>
>>>>>> The current CPPI41 driver should be able to handle this. I think you
>>>>>> really have to debug the pwc driver to figure out why it drops the video
>>>>>> frame. I personally don't have a pwc supported camera, never looked the
>>>>>> pwc driver...
>>>>>
>>>>> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
>>>>> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
>>>>> 640x480 frames.
>>>>> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
>>>>> Quad-code Atom E3800 based PC with 4.1 also works fine.
>>>>>
>>>>> So, I even don't know what to say. Probably, the issue depends on CPU
>>>>> latency/performance and it was there for a while.
>>>>> Fortunately, I think, I could use git bisect if I found latest forking
>>>>> kernel for my laptop.
>>>>>
>>>>
>>>> It seems that the issue is gone in 4.7-rc7, so forget it.
>>>>
>>>>>>
>>>>>>>
>>>>>>> >
>>>>>>> >>
>>>>>>> >> 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
>>>>>>> >
>>>>>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>>>>>
>>>>>>> Something like that, I suppose. Normally, I see input data flow in
>>>>>>> usbmon, but don't see frames in v4l2.
>>>>>>> But when camera 'hungs', I don't see nor input flow (except the
>>>>>>> control packages exchange) neither frames.
>>>>>>
>>>>>> Fair enough.
>>>>>>
>>>>>> 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
>>>
>>>
>>>
>>> --
>>> 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
>
>
>
> --
> 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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Viresh Kumar]

On 31-07-16, 23:31, Matwey V. Kornilov wrote:
> Hello,
> 
> I've also just found that the same commit breaks cpufreq on BeagleBone Black :)
> 
> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
> (as it did whet there was cpufreq driver).
> 
> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> > Hello,
> >
> > I've found that the following commit fixes the issue:
> >
> > commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
> > Author: Viresh Kumar <viresh.kumar@linaro.org>
> > Date:   Fri Apr 22 16:58:42 2016 +0530
> >
> >     cpufreq: omap: Use generic platdev driver
> >
> >     The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
> >     device now, reuse that and remove similar code from platform code.

Sorry for this commit and the man hours wasted to get to this :(

I am trying to figure out why things break though, as this patch shouldn't have
had any functional impacts. So, some of the assumptions I had are surely
incorrect..

The defconfig linked in the original thread [1] has this:

CONFIG_CPUFREQ_DT=m

So, the cpufreq-dt module needs to get inserted to make it work.

Can someone provide the output of:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

with and without this patch ?

It looks like we wanted to select "omap-cpufreq" for beaglebone and selected
"cpufreq-dt" by mistake.

[Note]: I am not subscribed to USB lists and so please include me for any emails
you want my response on.

--
viresh

[1] http://www.spinics.net/lists/linux-usb/msg143956.html

-- 
viresh

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-08-01 19:50 GMT+03:00 Viresh Kumar <viresh.kumar@linaro.org>:
> On 31-07-16, 23:31, Matwey V. Kornilov wrote:
>> Hello,
>>
>> I've also just found that the same commit breaks cpufreq on BeagleBone Black :)
>>
>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>> (as it did whet there was cpufreq driver).
>>
>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> > Hello,
>> >
>> > I've found that the following commit fixes the issue:
>> >
>> > commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>> > Author: Viresh Kumar <viresh.kumar@linaro.org>
>> > Date:   Fri Apr 22 16:58:42 2016 +0530
>> >
>> >     cpufreq: omap: Use generic platdev driver
>> >
>> >     The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>> >     device now, reuse that and remove similar code from platform code.
>
> Sorry for this commit and the man hours wasted to get to this :(
>
> I am trying to figure out why things break though, as this patch shouldn't have
> had any functional impacts. So, some of the assumptions I had are surely
> incorrect..

Actually, nothing to sorry about.
I suppose, that with this patch my BeagleBone run at 1Ghz after boot,
because usually cpufreq limits it to 720Mhz saying
[   14.255646] cpu cpu0: dev_pm_opp_set_rate: failed to find current
OPP for freq 1000000000 (-34)
And actually musb is still broken after f551e13529833e052f75ec628a8af7
(" Revert "usb: musb: musb_host")

>
> The defconfig linked in the original thread [1] has this:
>
> CONFIG_CPUFREQ_DT=m
>
> So, the cpufreq-dt module needs to get inserted to make it work.
>

It has been inserted automatically by alias `platform:cpufreq-dt'
Issue here that 4.7 stopped to provide `platfrom:cpufreq-dt' on BeagleBone.
Have you received my patch fixing it yet?

> Can someone provide the output of:
>
> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
>
> with and without this patch ?

With this patch, there is no cpufreq directory here.

Without this patch, the output is the following:

nohostname:~ # uname -a
Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15
08:08:50 UTC 2016 (ecd9058) armv7l armv7l armv7l GNU/Linux
nohostname:~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
cpufreq-dt

>
> It looks like we wanted to select "omap-cpufreq" for beaglebone and selected
> "cpufreq-dt" by mistake.

No, I am not sure, cpufreq-dt worked well until v4.7 where it is disappeared.

>
> [Note]: I am not subscribed to USB lists and so please include me for any emails
> you want my response on.
>
> --
> viresh
>
> [1] http://www.spinics.net/lists/linux-usb/msg143956.html
>
> --
> viresh
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Viresh Kumar]

On 01-08-16, 20:01, Matwey V. Kornilov wrote:
> With this patch, there is no cpufreq directory here.
> 
> Without this patch, the output is the following:
> 
> nohostname:~ # uname -a
> Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15
> 08:08:50 UTC 2016 (ecd9058) armv7l armv7l armv7l GNU/Linux
> nohostname:~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
> cpufreq-dt

I hope that the below patch fixes it for you?

[PATCH] cpufreq: am33xx: Use generic platdev driver

-- 
viresh

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-08-01 20:06 GMT+03:00 Viresh Kumar <viresh.kumar@linaro.org>:
> On 01-08-16, 20:01, Matwey V. Kornilov wrote:
>> With this patch, there is no cpufreq directory here.
>>
>> Without this patch, the output is the following:
>>
>> nohostname:~ # uname -a
>> Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15
>> 08:08:50 UTC 2016 (ecd9058) armv7l armv7l armv7l GNU/Linux
>> nohostname:~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
>> cpufreq-dt
>
> I hope that the below patch fixes it for you?
>

Yes, it is. Thank you.

> [PATCH] cpufreq: am33xx: Use generic platdev driver
>
> --
> viresh
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

pwc module output with trace=511 is the following:

[   24.793109] usbcore: registered new interface driver Philips webcam
[   29.276979] pwc: Unsupported pixel format
[   29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
bytesperline=640, sizeimage=460800, pixelformat=YU12
[   29.277090] pwc: Trying to set format to: width=640 height=480
fps=15 format=YU12
[   29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
[   29.277145] pwc: decode_size = 5.
[   29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
[   29.277204] pwc: Set resolution to 640x480
[   29.277225] pwc: pwc_set_video_mode(), return=0
[   29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
bytesperline=640, sizeimage=460800, pixelformat=YU12
[   29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
[   29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
bytesperline=640, sizeimage=460800, pixelformat=YU12
[   29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
[   29.277475] pwc: decode_size = 5.
[   29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
[   29.278750] pwc: Set resolution to 640x480
[   29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
[   29.300420] pwc: decode_size = 5.
[   29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
[   29.441792] pwc: Set resolution to 640x480
[   29.441824] pwc: Setting alternate interface 9
[   29.455061] pwc: Allocated URB at 0xc9b83600
[   29.455850] pwc: Allocated URB at 0xc9b83400
[   29.456040] pwc: Allocated URB at 0xc9b83200
[   29.456271] pwc: URB 0xc9b83600 submitted.
[   29.456310] pwc: URB 0xc9b83400 submitted.
[   29.456341] pwc: URB 0xc9b83200 submitted.
[   29.456362] pwc: << pwc_isoc_init()
[   30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
[   30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
[   30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
[   30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
[   30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
[   30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
[   30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
[   30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
[   30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
[   30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
[   31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
[   31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
[   31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
[   31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
[   31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
[   31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
[   31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
[   31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
[   31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
[   31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.


2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> Hello,
>
> I've also just found that the same commit breaks cpufreq on BeagleBone Black :)
>
> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
> (as it did whet there was cpufreq driver).
>
> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> Hello,
>>
>> I've found that the following commit fixes the issue:
>>
>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>> Author: Viresh Kumar <viresh.kumar@linaro.org>
>> Date:   Fri Apr 22 16:58:42 2016 +0530
>>
>>     cpufreq: omap: Use generic platdev driver
>>
>>     The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>>     device now, reuse that and remove similar code from platform code.
>>
>>
>> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>> Hello,
>>>
>>> I've just bisected commit, which fixed the issue in v4.7
>>>
>>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>>> Merge: f55532a febce40
>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>> Date:   Sat Apr 2 01:07:17 2016 +0200
>>>
>>>     Merge back intel_pstate fixes for v4.6.
>>>
>>>     * pm-cpufreq:
>>>       intel_pstate: Avoid extra invocation of intel_pstate_sample()
>>>       intel_pstate: Do not set utilization update hook too early
>>>
>>> Unfortunately, intel_pstate branch doesn't have
>>> f551e13529833e052f75ec628a8af7b034af20f9 applied.
>>> I'll try to bisect this branch with the patch manually applied.
>>>
>>> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>> Hello,
>>>>
>>>> I've just biseced commit, which introduced this issue
>>>>
>>>> commit f551e13529833e052f75ec628a8af7b034af20f9
>>>> Author: Bin Liu <b-liu@ti.com>
>>>> Date:   Mon Apr 25 15:53:30 2016 -0500
>>>>
>>>>     Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
>>>> return in bottom half"
>>>>
>>>> I have not checked yet, if it was intentionnaly fixed.
>>>>
>>>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>>>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>> > Hi,
>>>>>>>> >
>>>>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>>>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>> >> > 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@ti.com>:
>>>>>>>> >> >> > Hi,
>>>>>>>> >> >> >
>>>>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>>>>>>> >
>>>>>>>> > I think you might be able to check it without a sniffer - MUSB
>>>>>>>> > controller can generate SOF interrupts, but it is masked in current
>>>>>>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>>>>>>> > as
>>>>>>>> >         SOF
>>>>>>>> >         rx packet
>>>>>>>> >         SOF
>>>>>>>> >         rx packet
>>>>>>>> >         SOF
>>>>>>>> >         ...
>>>>>>>> > or
>>>>>>>> >         SOF
>>>>>>>> >         rx packet
>>>>>>>> >         rx packet
>>>>>>>> >         rx packet
>>>>>>>> >         SOF
>>>>>>>> >         rx packet
>>>>>>>> >         rx packet
>>>>>>>> >         rx packet
>>>>>>>> >         SOF
>>>>>>>> >         ...
>>>>>>>> >
>>>>>>>> > which means your issue is different from the one I mentioned. But if
>>>>>>>> > you get a log as
>>>>>>>> >
>>>>>>>> >         SOF
>>>>>>>> >         rx packet
>>>>>>>> >         SOF
>>>>>>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>>>>>>> >         rx packet
>>>>>>>> >         SOF
>>>>>>>> >         SOF
>>>>>>>> >
>>>>>>>> > then you hit on the known issue I mentioned.
>>>>>>>> >
>>>>>>>> >> Until that, could I check something else? For instance, disable
>>>>>>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>>>>>>> >
>>>>>>>> > You could disable it, but I don't think you will get yuv video stream
>>>>>>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>>>>>>> > your video requirement anyway?
>>>>>>>>
>>>>>>>> Many thanks for your guidance. I will answer the rest later when will
>>>>>>>> be ready to play with SOF interrupt.
>>>>>>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>>>>>>
>>>>>>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>>>>>>> N
>>>>>>>
>>>>>>> It sounds like you have a different issue here. With usb_dma=0, I
>>>>>>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>>>>>>
>>>>>>>>
>>>>>>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>>>>>>> that I can not obtain 640x480 at any FPS on musb.
>>>>>>>
>>>>>>> The current CPPI41 driver should be able to handle this. I think you
>>>>>>> really have to debug the pwc driver to figure out why it drops the video
>>>>>>> frame. I personally don't have a pwc supported camera, never looked the
>>>>>>> pwc driver...
>>>>>>
>>>>>> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
>>>>>> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
>>>>>> 640x480 frames.
>>>>>> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
>>>>>> Quad-code Atom E3800 based PC with 4.1 also works fine.
>>>>>>
>>>>>> So, I even don't know what to say. Probably, the issue depends on CPU
>>>>>> latency/performance and it was there for a while.
>>>>>> Fortunately, I think, I could use git bisect if I found latest forking
>>>>>> kernel for my laptop.
>>>>>>
>>>>>
>>>>> It seems that the issue is gone in 4.7-rc7, so forget it.
>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> >
>>>>>>>> >>
>>>>>>>> >> 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
>>>>>>>> >
>>>>>>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>>>>>>
>>>>>>>> Something like that, I suppose. Normally, I see input data flow in
>>>>>>>> usbmon, but don't see frames in v4l2.
>>>>>>>> But when camera 'hungs', I don't see nor input flow (except the
>>>>>>>> control packages exchange) neither frames.
>>>>>>>
>>>>>>> Fair enough.
>>>>>>>
>>>>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
>>
>>
>> --
>> 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



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

I've just found that many packages in URBs have zero actual_length (It
is a question why).
Then the following end of frame criteria leads to `frame underflow' message:

                if (flen < pdev->vlast_packet_size) {
                        /* Shorter packet... end of frame */
                        if (pdev->vsync == 2)
                                pwc_frame_complete(pdev);
                        if (pdev->fill_buf == NULL)
                                pdev->fill_buf = pwc_get_next_fill_buf(pdev);
                        if (pdev->fill_buf) {
                                pdev->fill_buf->filled = 0;
                                pdev->vsync = 1;
                        }
                }

2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> pwc module output with trace=511 is the following:
>
> [   24.793109] usbcore: registered new interface driver Philips webcam
> [   29.276979] pwc: Unsupported pixel format
> [   29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
> bytesperline=640, sizeimage=460800, pixelformat=YU12
> [   29.277090] pwc: Trying to set format to: width=640 height=480
> fps=15 format=YU12
> [   29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
> [   29.277145] pwc: decode_size = 5.
> [   29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
> [   29.277204] pwc: Set resolution to 640x480
> [   29.277225] pwc: pwc_set_video_mode(), return=0
> [   29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
> bytesperline=640, sizeimage=460800, pixelformat=YU12
> [   29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
> [   29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
> bytesperline=640, sizeimage=460800, pixelformat=YU12
> [   29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
> [   29.277475] pwc: decode_size = 5.
> [   29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
> [   29.278750] pwc: Set resolution to 640x480
> [   29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
> [   29.300420] pwc: decode_size = 5.
> [   29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
> [   29.441792] pwc: Set resolution to 640x480
> [   29.441824] pwc: Setting alternate interface 9
> [   29.455061] pwc: Allocated URB at 0xc9b83600
> [   29.455850] pwc: Allocated URB at 0xc9b83400
> [   29.456040] pwc: Allocated URB at 0xc9b83200
> [   29.456271] pwc: URB 0xc9b83600 submitted.
> [   29.456310] pwc: URB 0xc9b83400 submitted.
> [   29.456341] pwc: URB 0xc9b83200 submitted.
> [   29.456362] pwc: << pwc_isoc_init()
> [   30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
> [   30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
> [   30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
> [   30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
> [   30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
> [   30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
> [   30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
> [   30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
> [   30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
> [   30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
> [   31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
> [   31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
> [   31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
> [   31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
> [   31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
> [   31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
> [   31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
> [   31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
> [   31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
> [   31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.
>
>
> 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> Hello,
>>
>> I've also just found that the same commit breaks cpufreq on BeagleBone Black :)
>>
>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>> (as it did whet there was cpufreq driver).
>>
>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>> Hello,
>>>
>>> I've found that the following commit fixes the issue:
>>>
>>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>>> Author: Viresh Kumar <viresh.kumar@linaro.org>
>>> Date:   Fri Apr 22 16:58:42 2016 +0530
>>>
>>>     cpufreq: omap: Use generic platdev driver
>>>
>>>     The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>>>     device now, reuse that and remove similar code from platform code.
>>>
>>>
>>> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>> Hello,
>>>>
>>>> I've just bisected commit, which fixed the issue in v4.7
>>>>
>>>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>>>> Merge: f55532a febce40
>>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>> Date:   Sat Apr 2 01:07:17 2016 +0200
>>>>
>>>>     Merge back intel_pstate fixes for v4.6.
>>>>
>>>>     * pm-cpufreq:
>>>>       intel_pstate: Avoid extra invocation of intel_pstate_sample()
>>>>       intel_pstate: Do not set utilization update hook too early
>>>>
>>>> Unfortunately, intel_pstate branch doesn't have
>>>> f551e13529833e052f75ec628a8af7b034af20f9 applied.
>>>> I'll try to bisect this branch with the patch manually applied.
>>>>
>>>> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>> Hello,
>>>>>
>>>>> I've just biseced commit, which introduced this issue
>>>>>
>>>>> commit f551e13529833e052f75ec628a8af7b034af20f9
>>>>> Author: Bin Liu <b-liu@ti.com>
>>>>> Date:   Mon Apr 25 15:53:30 2016 -0500
>>>>>
>>>>>     Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
>>>>> return in bottom half"
>>>>>
>>>>> I have not checked yet, if it was intentionnaly fixed.
>>>>>
>>>>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>>>>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>> > Hi,
>>>>>>>>> >
>>>>>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>>>>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>> >> > 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@ti.com>:
>>>>>>>>> >> >> > Hi,
>>>>>>>>> >> >> >
>>>>>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>>>>>>>> >
>>>>>>>>> > I think you might be able to check it without a sniffer - MUSB
>>>>>>>>> > controller can generate SOF interrupts, but it is masked in current
>>>>>>>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>>>>>>>> > as
>>>>>>>>> >         SOF
>>>>>>>>> >         rx packet
>>>>>>>>> >         SOF
>>>>>>>>> >         rx packet
>>>>>>>>> >         SOF
>>>>>>>>> >         ...
>>>>>>>>> > or
>>>>>>>>> >         SOF
>>>>>>>>> >         rx packet
>>>>>>>>> >         rx packet
>>>>>>>>> >         rx packet
>>>>>>>>> >         SOF
>>>>>>>>> >         rx packet
>>>>>>>>> >         rx packet
>>>>>>>>> >         rx packet
>>>>>>>>> >         SOF
>>>>>>>>> >         ...
>>>>>>>>> >
>>>>>>>>> > which means your issue is different from the one I mentioned. But if
>>>>>>>>> > you get a log as
>>>>>>>>> >
>>>>>>>>> >         SOF
>>>>>>>>> >         rx packet
>>>>>>>>> >         SOF
>>>>>>>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>>>>>>>> >         rx packet
>>>>>>>>> >         SOF
>>>>>>>>> >         SOF
>>>>>>>>> >
>>>>>>>>> > then you hit on the known issue I mentioned.
>>>>>>>>> >
>>>>>>>>> >> Until that, could I check something else? For instance, disable
>>>>>>>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>>>>>>>> >
>>>>>>>>> > You could disable it, but I don't think you will get yuv video stream
>>>>>>>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>>>>>>>> > your video requirement anyway?
>>>>>>>>>
>>>>>>>>> Many thanks for your guidance. I will answer the rest later when will
>>>>>>>>> be ready to play with SOF interrupt.
>>>>>>>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>>>>>>>
>>>>>>>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>>>>>>>> N
>>>>>>>>
>>>>>>>> It sounds like you have a different issue here. With usb_dma=0, I
>>>>>>>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>>>>>>>> that I can not obtain 640x480 at any FPS on musb.
>>>>>>>>
>>>>>>>> The current CPPI41 driver should be able to handle this. I think you
>>>>>>>> really have to debug the pwc driver to figure out why it drops the video
>>>>>>>> frame. I personally don't have a pwc supported camera, never looked the
>>>>>>>> pwc driver...
>>>>>>>
>>>>>>> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
>>>>>>> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
>>>>>>> 640x480 frames.
>>>>>>> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
>>>>>>> Quad-code Atom E3800 based PC with 4.1 also works fine.
>>>>>>>
>>>>>>> So, I even don't know what to say. Probably, the issue depends on CPU
>>>>>>> latency/performance and it was there for a while.
>>>>>>> Fortunately, I think, I could use git bisect if I found latest forking
>>>>>>> kernel for my laptop.
>>>>>>>
>>>>>>
>>>>>> It seems that the issue is gone in 4.7-rc7, so forget it.
>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> >
>>>>>>>>> >>
>>>>>>>>> >> 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
>>>>>>>>> >
>>>>>>>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>>>>>>>
>>>>>>>>> Something like that, I suppose. Normally, I see input data flow in
>>>>>>>>> usbmon, but don't see frames in v4l2.
>>>>>>>>> But when camera 'hungs', I don't see nor input flow (except the
>>>>>>>>> control packages exchange) neither frames.
>>>>>>>>
>>>>>>>> Fair enough.
>>>>>>>>
>>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>
>>>
>>>
>>> --
>>> 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
>
>
>
> --
> 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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

I've just found that dma->actual_len equals to zero in most cases at
musb_host.c line 1946.
And this produces zero-length packages.

http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946

Any ideas why?

2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> I've just found that many packages in URBs have zero actual_length (It
> is a question why).
> Then the following end of frame criteria leads to `frame underflow' message:
>
>                 if (flen < pdev->vlast_packet_size) {
>                         /* Shorter packet... end of frame */
>                         if (pdev->vsync == 2)
>                                 pwc_frame_complete(pdev);
>                         if (pdev->fill_buf == NULL)
>                                 pdev->fill_buf = pwc_get_next_fill_buf(pdev);
>                         if (pdev->fill_buf) {
>                                 pdev->fill_buf->filled = 0;
>                                 pdev->vsync = 1;
>                         }
>                 }
>
> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> pwc module output with trace=511 is the following:
>>
>> [   24.793109] usbcore: registered new interface driver Philips webcam
>> [   29.276979] pwc: Unsupported pixel format
>> [   29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>> [   29.277090] pwc: Trying to set format to: width=640 height=480
>> fps=15 format=YU12
>> [   29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>> [   29.277145] pwc: decode_size = 5.
>> [   29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>> [   29.277204] pwc: Set resolution to 640x480
>> [   29.277225] pwc: pwc_set_video_mode(), return=0
>> [   29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>> [   29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>> [   29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>> [   29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>> [   29.277475] pwc: decode_size = 5.
>> [   29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>> [   29.278750] pwc: Set resolution to 640x480
>> [   29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>> [   29.300420] pwc: decode_size = 5.
>> [   29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>> [   29.441792] pwc: Set resolution to 640x480
>> [   29.441824] pwc: Setting alternate interface 9
>> [   29.455061] pwc: Allocated URB at 0xc9b83600
>> [   29.455850] pwc: Allocated URB at 0xc9b83400
>> [   29.456040] pwc: Allocated URB at 0xc9b83200
>> [   29.456271] pwc: URB 0xc9b83600 submitted.
>> [   29.456310] pwc: URB 0xc9b83400 submitted.
>> [   29.456341] pwc: URB 0xc9b83200 submitted.
>> [   29.456362] pwc: << pwc_isoc_init()
>> [   30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>> [   30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
>> [   30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
>> [   30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
>> [   30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
>> [   30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
>> [   30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
>> [   30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
>> [   30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
>> [   30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
>> [   31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
>> [   31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
>> [   31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
>> [   31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
>> [   31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
>> [   31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
>> [   31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
>> [   31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
>> [   31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
>> [   31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.
>>
>>
>> 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>> Hello,
>>>
>>> I've also just found that the same commit breaks cpufreq on BeagleBone Black :)
>>>
>>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>>> (as it did whet there was cpufreq driver).
>>>
>>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>> Hello,
>>>>
>>>> I've found that the following commit fixes the issue:
>>>>
>>>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>>>> Author: Viresh Kumar <viresh.kumar@linaro.org>
>>>> Date:   Fri Apr 22 16:58:42 2016 +0530
>>>>
>>>>     cpufreq: omap: Use generic platdev driver
>>>>
>>>>     The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>>>>     device now, reuse that and remove similar code from platform code.
>>>>
>>>>
>>>> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>> Hello,
>>>>>
>>>>> I've just bisected commit, which fixed the issue in v4.7
>>>>>
>>>>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>>>>> Merge: f55532a febce40
>>>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>>> Date:   Sat Apr 2 01:07:17 2016 +0200
>>>>>
>>>>>     Merge back intel_pstate fixes for v4.6.
>>>>>
>>>>>     * pm-cpufreq:
>>>>>       intel_pstate: Avoid extra invocation of intel_pstate_sample()
>>>>>       intel_pstate: Do not set utilization update hook too early
>>>>>
>>>>> Unfortunately, intel_pstate branch doesn't have
>>>>> f551e13529833e052f75ec628a8af7b034af20f9 applied.
>>>>> I'll try to bisect this branch with the patch manually applied.
>>>>>
>>>>> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>> Hello,
>>>>>>
>>>>>> I've just biseced commit, which introduced this issue
>>>>>>
>>>>>> commit f551e13529833e052f75ec628a8af7b034af20f9
>>>>>> Author: Bin Liu <b-liu@ti.com>
>>>>>> Date:   Mon Apr 25 15:53:30 2016 -0500
>>>>>>
>>>>>>     Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
>>>>>> return in bottom half"
>>>>>>
>>>>>> I have not checked yet, if it was intentionnaly fixed.
>>>>>>
>>>>>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>> > Hi,
>>>>>>>>>> >
>>>>>>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>> >> > 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@ti.com>:
>>>>>>>>>> >> >> > Hi,
>>>>>>>>>> >> >> >
>>>>>>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>>>>>>>>> >
>>>>>>>>>> > I think you might be able to check it without a sniffer - MUSB
>>>>>>>>>> > controller can generate SOF interrupts, but it is masked in current
>>>>>>>>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>>>>>>>>> > as
>>>>>>>>>> >         SOF
>>>>>>>>>> >         rx packet
>>>>>>>>>> >         SOF
>>>>>>>>>> >         rx packet
>>>>>>>>>> >         SOF
>>>>>>>>>> >         ...
>>>>>>>>>> > or
>>>>>>>>>> >         SOF
>>>>>>>>>> >         rx packet
>>>>>>>>>> >         rx packet
>>>>>>>>>> >         rx packet
>>>>>>>>>> >         SOF
>>>>>>>>>> >         rx packet
>>>>>>>>>> >         rx packet
>>>>>>>>>> >         rx packet
>>>>>>>>>> >         SOF
>>>>>>>>>> >         ...
>>>>>>>>>> >
>>>>>>>>>> > which means your issue is different from the one I mentioned. But if
>>>>>>>>>> > you get a log as
>>>>>>>>>> >
>>>>>>>>>> >         SOF
>>>>>>>>>> >         rx packet
>>>>>>>>>> >         SOF
>>>>>>>>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>>>>>>>>> >         rx packet
>>>>>>>>>> >         SOF
>>>>>>>>>> >         SOF
>>>>>>>>>> >
>>>>>>>>>> > then you hit on the known issue I mentioned.
>>>>>>>>>> >
>>>>>>>>>> >> Until that, could I check something else? For instance, disable
>>>>>>>>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>>>>>>>>> >
>>>>>>>>>> > You could disable it, but I don't think you will get yuv video stream
>>>>>>>>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>>>>>>>>> > your video requirement anyway?
>>>>>>>>>>
>>>>>>>>>> Many thanks for your guidance. I will answer the rest later when will
>>>>>>>>>> be ready to play with SOF interrupt.
>>>>>>>>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>>>>>>>>
>>>>>>>>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>>>>>>>>> N
>>>>>>>>>
>>>>>>>>> It sounds like you have a different issue here. With usb_dma=0, I
>>>>>>>>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>>>>>>>>> that I can not obtain 640x480 at any FPS on musb.
>>>>>>>>>
>>>>>>>>> The current CPPI41 driver should be able to handle this. I think you
>>>>>>>>> really have to debug the pwc driver to figure out why it drops the video
>>>>>>>>> frame. I personally don't have a pwc supported camera, never looked the
>>>>>>>>> pwc driver...
>>>>>>>>
>>>>>>>> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
>>>>>>>> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
>>>>>>>> 640x480 frames.
>>>>>>>> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
>>>>>>>> Quad-code Atom E3800 based PC with 4.1 also works fine.
>>>>>>>>
>>>>>>>> So, I even don't know what to say. Probably, the issue depends on CPU
>>>>>>>> latency/performance and it was there for a while.
>>>>>>>> Fortunately, I think, I could use git bisect if I found latest forking
>>>>>>>> kernel for my laptop.
>>>>>>>>
>>>>>>>
>>>>>>> It seems that the issue is gone in 4.7-rc7, so forget it.
>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> >
>>>>>>>>>> >>
>>>>>>>>>> >> 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
>>>>>>>>>> >
>>>>>>>>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>>>>>>>>
>>>>>>>>>> Something like that, I suppose. Normally, I see input data flow in
>>>>>>>>>> usbmon, but don't see frames in v4l2.
>>>>>>>>>> But when camera 'hungs', I don't see nor input flow (except the
>>>>>>>>>> control packages exchange) neither frames.
>>>>>>>>>
>>>>>>>>> Fair enough.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
>>
>>
>> --
>> 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



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

I've just found that in such cases, when DMA actual length is zero,
both cppi41_channel->prog_len and txstate.residue equal 960 at
musb_cppi41 line 225:

http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225

2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> I've just found that dma->actual_len equals to zero in most cases at
> musb_host.c line 1946.
> And this produces zero-length packages.
>
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>
> Any ideas why?
>
> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> I've just found that many packages in URBs have zero actual_length (It
>> is a question why).
>> Then the following end of frame criteria leads to `frame underflow' message:
>>
>>                 if (flen < pdev->vlast_packet_size) {
>>                         /* Shorter packet... end of frame */
>>                         if (pdev->vsync == 2)
>>                                 pwc_frame_complete(pdev);
>>                         if (pdev->fill_buf == NULL)
>>                                 pdev->fill_buf = pwc_get_next_fill_buf(pdev);
>>                         if (pdev->fill_buf) {
>>                                 pdev->fill_buf->filled = 0;
>>                                 pdev->vsync = 1;
>>                         }
>>                 }
>>
>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>> pwc module output with trace=511 is the following:
>>>
>>> [   24.793109] usbcore: registered new interface driver Philips webcam
>>> [   29.276979] pwc: Unsupported pixel format
>>> [   29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>> [   29.277090] pwc: Trying to set format to: width=640 height=480
>>> fps=15 format=YU12
>>> [   29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>> [   29.277145] pwc: decode_size = 5.
>>> [   29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>>> [   29.277204] pwc: Set resolution to 640x480
>>> [   29.277225] pwc: pwc_set_video_mode(), return=0
>>> [   29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>> [   29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>> [   29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>> [   29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>> [   29.277475] pwc: decode_size = 5.
>>> [   29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>> [   29.278750] pwc: Set resolution to 640x480
>>> [   29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>> [   29.300420] pwc: decode_size = 5.
>>> [   29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>> [   29.441792] pwc: Set resolution to 640x480
>>> [   29.441824] pwc: Setting alternate interface 9
>>> [   29.455061] pwc: Allocated URB at 0xc9b83600
>>> [   29.455850] pwc: Allocated URB at 0xc9b83400
>>> [   29.456040] pwc: Allocated URB at 0xc9b83200
>>> [   29.456271] pwc: URB 0xc9b83600 submitted.
>>> [   29.456310] pwc: URB 0xc9b83400 submitted.
>>> [   29.456341] pwc: URB 0xc9b83200 submitted.
>>> [   29.456362] pwc: << pwc_isoc_init()
>>> [   30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>>> [   30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
>>> [   30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
>>> [   30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
>>> [   30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
>>> [   30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
>>> [   30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
>>> [   30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
>>> [   30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
>>> [   30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
>>> [   31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>> [   31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
>>> [   31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
>>> [   31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
>>> [   31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
>>> [   31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>> [   31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
>>> [   31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
>>> [   31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
>>> [   31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>
>>>
>>> 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>> Hello,
>>>>
>>>> I've also just found that the same commit breaks cpufreq on BeagleBone Black :)
>>>>
>>>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>>>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>>>> (as it did whet there was cpufreq driver).
>>>>
>>>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>> Hello,
>>>>>
>>>>> I've found that the following commit fixes the issue:
>>>>>
>>>>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>>>>> Author: Viresh Kumar <viresh.kumar@linaro.org>
>>>>> Date:   Fri Apr 22 16:58:42 2016 +0530
>>>>>
>>>>>     cpufreq: omap: Use generic platdev driver
>>>>>
>>>>>     The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>>>>>     device now, reuse that and remove similar code from platform code.
>>>>>
>>>>>
>>>>> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>> Hello,
>>>>>>
>>>>>> I've just bisected commit, which fixed the issue in v4.7
>>>>>>
>>>>>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>>>>>> Merge: f55532a febce40
>>>>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>>>> Date:   Sat Apr 2 01:07:17 2016 +0200
>>>>>>
>>>>>>     Merge back intel_pstate fixes for v4.6.
>>>>>>
>>>>>>     * pm-cpufreq:
>>>>>>       intel_pstate: Avoid extra invocation of intel_pstate_sample()
>>>>>>       intel_pstate: Do not set utilization update hook too early
>>>>>>
>>>>>> Unfortunately, intel_pstate branch doesn't have
>>>>>> f551e13529833e052f75ec628a8af7b034af20f9 applied.
>>>>>> I'll try to bisect this branch with the patch manually applied.
>>>>>>
>>>>>> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I've just biseced commit, which introduced this issue
>>>>>>>
>>>>>>> commit f551e13529833e052f75ec628a8af7b034af20f9
>>>>>>> Author: Bin Liu <b-liu@ti.com>
>>>>>>> Date:   Mon Apr 25 15:53:30 2016 -0500
>>>>>>>
>>>>>>>     Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
>>>>>>> return in bottom half"
>>>>>>>
>>>>>>> I have not checked yet, if it was intentionnaly fixed.
>>>>>>>
>>>>>>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>> > Hi,
>>>>>>>>>>> >
>>>>>>>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>> >> > 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@ti.com>:
>>>>>>>>>>> >> >> > Hi,
>>>>>>>>>>> >> >> >
>>>>>>>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>>>>>>>>>> >
>>>>>>>>>>> > I think you might be able to check it without a sniffer - MUSB
>>>>>>>>>>> > controller can generate SOF interrupts, but it is masked in current
>>>>>>>>>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>>>>>>>>>> > as
>>>>>>>>>>> >         SOF
>>>>>>>>>>> >         rx packet
>>>>>>>>>>> >         SOF
>>>>>>>>>>> >         rx packet
>>>>>>>>>>> >         SOF
>>>>>>>>>>> >         ...
>>>>>>>>>>> > or
>>>>>>>>>>> >         SOF
>>>>>>>>>>> >         rx packet
>>>>>>>>>>> >         rx packet
>>>>>>>>>>> >         rx packet
>>>>>>>>>>> >         SOF
>>>>>>>>>>> >         rx packet
>>>>>>>>>>> >         rx packet
>>>>>>>>>>> >         rx packet
>>>>>>>>>>> >         SOF
>>>>>>>>>>> >         ...
>>>>>>>>>>> >
>>>>>>>>>>> > which means your issue is different from the one I mentioned. But if
>>>>>>>>>>> > you get a log as
>>>>>>>>>>> >
>>>>>>>>>>> >         SOF
>>>>>>>>>>> >         rx packet
>>>>>>>>>>> >         SOF
>>>>>>>>>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>>>>>>>>>> >         rx packet
>>>>>>>>>>> >         SOF
>>>>>>>>>>> >         SOF
>>>>>>>>>>> >
>>>>>>>>>>> > then you hit on the known issue I mentioned.
>>>>>>>>>>> >
>>>>>>>>>>> >> Until that, could I check something else? For instance, disable
>>>>>>>>>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>>>>>>>>>> >
>>>>>>>>>>> > You could disable it, but I don't think you will get yuv video stream
>>>>>>>>>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>>>>>>>>>> > your video requirement anyway?
>>>>>>>>>>>
>>>>>>>>>>> Many thanks for your guidance. I will answer the rest later when will
>>>>>>>>>>> be ready to play with SOF interrupt.
>>>>>>>>>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>>>>>>>>>
>>>>>>>>>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>>>>>>>>>> N
>>>>>>>>>>
>>>>>>>>>> It sounds like you have a different issue here. With usb_dma=0, I
>>>>>>>>>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>>>>>>>>>> that I can not obtain 640x480 at any FPS on musb.
>>>>>>>>>>
>>>>>>>>>> The current CPPI41 driver should be able to handle this. I think you
>>>>>>>>>> really have to debug the pwc driver to figure out why it drops the video
>>>>>>>>>> frame. I personally don't have a pwc supported camera, never looked the
>>>>>>>>>> pwc driver...
>>>>>>>>>
>>>>>>>>> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
>>>>>>>>> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
>>>>>>>>> 640x480 frames.
>>>>>>>>> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
>>>>>>>>> Quad-code Atom E3800 based PC with 4.1 also works fine.
>>>>>>>>>
>>>>>>>>> So, I even don't know what to say. Probably, the issue depends on CPU
>>>>>>>>> latency/performance and it was there for a while.
>>>>>>>>> Fortunately, I think, I could use git bisect if I found latest forking
>>>>>>>>> kernel for my laptop.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It seems that the issue is gone in 4.7-rc7, so forget it.
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> >
>>>>>>>>>>> >>
>>>>>>>>>>> >> 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
>>>>>>>>>>> >
>>>>>>>>>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>>>>>>>>>
>>>>>>>>>>> Something like that, I suppose. Normally, I see input data flow in
>>>>>>>>>>> usbmon, but don't see frames in v4l2.
>>>>>>>>>>> But when camera 'hungs', I don't see nor input flow (except the
>>>>>>>>>>> control packages exchange) neither frames.
>>>>>>>>>>
>>>>>>>>>> Fair enough.
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>
>>>
>>>
>>> --
>>> 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
>
>
>
> --
> 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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

When DMA is not used, I see the same behavior: lots of zero-length
packages received.

Can It be related to some kind of USB overflow due to long input data
processing with disabled IRQ?
When HCD_BC is used then part of processing is postponed and this can
explain greater throughput due to better latency.

2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> I've just found that in such cases, when DMA actual length is zero,
> both cppi41_channel->prog_len and txstate.residue equal 960 at
> musb_cppi41 line 225:
>
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>
> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> I've just found that dma->actual_len equals to zero in most cases at
>> musb_host.c line 1946.
>> And this produces zero-length packages.
>>
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>
>> Any ideas why?
>>
>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>> I've just found that many packages in URBs have zero actual_length (It
>>> is a question why).
>>> Then the following end of frame criteria leads to `frame underflow' message:
>>>
>>>                 if (flen < pdev->vlast_packet_size) {
>>>                         /* Shorter packet... end of frame */
>>>                         if (pdev->vsync == 2)
>>>                                 pwc_frame_complete(pdev);
>>>                         if (pdev->fill_buf == NULL)
>>>                                 pdev->fill_buf = pwc_get_next_fill_buf(pdev);
>>>                         if (pdev->fill_buf) {
>>>                                 pdev->fill_buf->filled = 0;
>>>                                 pdev->vsync = 1;
>>>                         }
>>>                 }
>>>
>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>> pwc module output with trace=511 is the following:
>>>>
>>>> [   24.793109] usbcore: registered new interface driver Philips webcam
>>>> [   29.276979] pwc: Unsupported pixel format
>>>> [   29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>> [   29.277090] pwc: Trying to set format to: width=640 height=480
>>>> fps=15 format=YU12
>>>> [   29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>> [   29.277145] pwc: decode_size = 5.
>>>> [   29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>>>> [   29.277204] pwc: Set resolution to 640x480
>>>> [   29.277225] pwc: pwc_set_video_mode(), return=0
>>>> [   29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>> [   29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>> [   29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>> [   29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>> [   29.277475] pwc: decode_size = 5.
>>>> [   29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>> [   29.278750] pwc: Set resolution to 640x480
>>>> [   29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>> [   29.300420] pwc: decode_size = 5.
>>>> [   29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>> [   29.441792] pwc: Set resolution to 640x480
>>>> [   29.441824] pwc: Setting alternate interface 9
>>>> [   29.455061] pwc: Allocated URB at 0xc9b83600
>>>> [   29.455850] pwc: Allocated URB at 0xc9b83400
>>>> [   29.456040] pwc: Allocated URB at 0xc9b83200
>>>> [   29.456271] pwc: URB 0xc9b83600 submitted.
>>>> [   29.456310] pwc: URB 0xc9b83400 submitted.
>>>> [   29.456341] pwc: URB 0xc9b83200 submitted.
>>>> [   29.456362] pwc: << pwc_isoc_init()
>>>> [   30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>> [   30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>> [   30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>> [   30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>> [   30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>> [   30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>> [   30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>> [   30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>> [   30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>> [   30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>> [   31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>> [   31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>> [   31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>> [   31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>> [   31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>> [   31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>> [   31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
>>>> [   31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>> [   31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>> [   31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>
>>>>
>>>> 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>> Hello,
>>>>>
>>>>> I've also just found that the same commit breaks cpufreq on BeagleBone Black :)
>>>>>
>>>>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>>>>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>>>>> (as it did whet there was cpufreq driver).
>>>>>
>>>>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>> Hello,
>>>>>>
>>>>>> I've found that the following commit fixes the issue:
>>>>>>
>>>>>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>>>>>> Author: Viresh Kumar <viresh.kumar@linaro.org>
>>>>>> Date:   Fri Apr 22 16:58:42 2016 +0530
>>>>>>
>>>>>>     cpufreq: omap: Use generic platdev driver
>>>>>>
>>>>>>     The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>>>>>>     device now, reuse that and remove similar code from platform code.
>>>>>>
>>>>>>
>>>>>> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I've just bisected commit, which fixed the issue in v4.7
>>>>>>>
>>>>>>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>>>>>>> Merge: f55532a febce40
>>>>>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>>>>> Date:   Sat Apr 2 01:07:17 2016 +0200
>>>>>>>
>>>>>>>     Merge back intel_pstate fixes for v4.6.
>>>>>>>
>>>>>>>     * pm-cpufreq:
>>>>>>>       intel_pstate: Avoid extra invocation of intel_pstate_sample()
>>>>>>>       intel_pstate: Do not set utilization update hook too early
>>>>>>>
>>>>>>> Unfortunately, intel_pstate branch doesn't have
>>>>>>> f551e13529833e052f75ec628a8af7b034af20f9 applied.
>>>>>>> I'll try to bisect this branch with the patch manually applied.
>>>>>>>
>>>>>>> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I've just biseced commit, which introduced this issue
>>>>>>>>
>>>>>>>> commit f551e13529833e052f75ec628a8af7b034af20f9
>>>>>>>> Author: Bin Liu <b-liu@ti.com>
>>>>>>>> Date:   Mon Apr 25 15:53:30 2016 -0500
>>>>>>>>
>>>>>>>>     Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
>>>>>>>> return in bottom half"
>>>>>>>>
>>>>>>>> I have not checked yet, if it was intentionnaly fixed.
>>>>>>>>
>>>>>>>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>> > Hi,
>>>>>>>>>>>> >
>>>>>>>>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>> >> > 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@ti.com>:
>>>>>>>>>>>> >> >> > Hi,
>>>>>>>>>>>> >> >> >
>>>>>>>>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>>>>>>>>>>> >
>>>>>>>>>>>> > I think you might be able to check it without a sniffer - MUSB
>>>>>>>>>>>> > controller can generate SOF interrupts, but it is masked in current
>>>>>>>>>>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>>>>>>>>>>> > as
>>>>>>>>>>>> >         SOF
>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>> >         SOF
>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>> >         SOF
>>>>>>>>>>>> >         ...
>>>>>>>>>>>> > or
>>>>>>>>>>>> >         SOF
>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>> >         SOF
>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>> >         SOF
>>>>>>>>>>>> >         ...
>>>>>>>>>>>> >
>>>>>>>>>>>> > which means your issue is different from the one I mentioned. But if
>>>>>>>>>>>> > you get a log as
>>>>>>>>>>>> >
>>>>>>>>>>>> >         SOF
>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>> >         SOF
>>>>>>>>>>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>> >         SOF
>>>>>>>>>>>> >         SOF
>>>>>>>>>>>> >
>>>>>>>>>>>> > then you hit on the known issue I mentioned.
>>>>>>>>>>>> >
>>>>>>>>>>>> >> Until that, could I check something else? For instance, disable
>>>>>>>>>>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>>>>>>>>>>> >
>>>>>>>>>>>> > You could disable it, but I don't think you will get yuv video stream
>>>>>>>>>>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>>>>>>>>>>> > your video requirement anyway?
>>>>>>>>>>>>
>>>>>>>>>>>> Many thanks for your guidance. I will answer the rest later when will
>>>>>>>>>>>> be ready to play with SOF interrupt.
>>>>>>>>>>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>>>>>>>>>>
>>>>>>>>>>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>>>>>>>>>>> N
>>>>>>>>>>>
>>>>>>>>>>> It sounds like you have a different issue here. With usb_dma=0, I
>>>>>>>>>>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>>>>>>>>>>> that I can not obtain 640x480 at any FPS on musb.
>>>>>>>>>>>
>>>>>>>>>>> The current CPPI41 driver should be able to handle this. I think you
>>>>>>>>>>> really have to debug the pwc driver to figure out why it drops the video
>>>>>>>>>>> frame. I personally don't have a pwc supported camera, never looked the
>>>>>>>>>>> pwc driver...
>>>>>>>>>>
>>>>>>>>>> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
>>>>>>>>>> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
>>>>>>>>>> 640x480 frames.
>>>>>>>>>> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
>>>>>>>>>> Quad-code Atom E3800 based PC with 4.1 also works fine.
>>>>>>>>>>
>>>>>>>>>> So, I even don't know what to say. Probably, the issue depends on CPU
>>>>>>>>>> latency/performance and it was there for a while.
>>>>>>>>>> Fortunately, I think, I could use git bisect if I found latest forking
>>>>>>>>>> kernel for my laptop.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It seems that the issue is gone in 4.7-rc7, so forget it.
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> >
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> 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
>>>>>>>>>>>> >
>>>>>>>>>>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>>>>>>>>>>
>>>>>>>>>>>> Something like that, I suppose. Normally, I see input data flow in
>>>>>>>>>>>> usbmon, but don't see frames in v4l2.
>>>>>>>>>>>> But when camera 'hungs', I don't see nor input flow (except the
>>>>>>>>>>>> control packages exchange) neither frames.
>>>>>>>>>>>
>>>>>>>>>>> Fair enough.
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
>>
>>
>> --
>> 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



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

Any ideas?

2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> When DMA is not used, I see the same behavior: lots of zero-length
> packages received.
>
> Can It be related to some kind of USB overflow due to long input data
> processing with disabled IRQ?
> When HCD_BC is used then part of processing is postponed and this can
> explain greater throughput due to better latency.
>
> 2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> I've just found that in such cases, when DMA actual length is zero,
>> both cppi41_channel->prog_len and txstate.residue equal 960 at
>> musb_cppi41 line 225:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>>
>> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>> I've just found that dma->actual_len equals to zero in most cases at
>>> musb_host.c line 1946.
>>> And this produces zero-length packages.
>>>
>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>>
>>> Any ideas why?
>>>
>>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>> I've just found that many packages in URBs have zero actual_length (It
>>>> is a question why).
>>>> Then the following end of frame criteria leads to `frame underflow' message:
>>>>
>>>>                 if (flen < pdev->vlast_packet_size) {
>>>>                         /* Shorter packet... end of frame */
>>>>                         if (pdev->vsync == 2)
>>>>                                 pwc_frame_complete(pdev);
>>>>                         if (pdev->fill_buf == NULL)
>>>>                                 pdev->fill_buf = pwc_get_next_fill_buf(pdev);
>>>>                         if (pdev->fill_buf) {
>>>>                                 pdev->fill_buf->filled = 0;
>>>>                                 pdev->vsync = 1;
>>>>                         }
>>>>                 }
>>>>
>>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>> pwc module output with trace=511 is the following:
>>>>>
>>>>> [   24.793109] usbcore: registered new interface driver Philips webcam
>>>>> [   29.276979] pwc: Unsupported pixel format
>>>>> [   29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>> [   29.277090] pwc: Trying to set format to: width=640 height=480
>>>>> fps=15 format=YU12
>>>>> [   29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>>> [   29.277145] pwc: decode_size = 5.
>>>>> [   29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>>>>> [   29.277204] pwc: Set resolution to 640x480
>>>>> [   29.277225] pwc: pwc_set_video_mode(), return=0
>>>>> [   29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>> [   29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>>> [   29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>> [   29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>> [   29.277475] pwc: decode_size = 5.
>>>>> [   29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>>> [   29.278750] pwc: Set resolution to 640x480
>>>>> [   29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>> [   29.300420] pwc: decode_size = 5.
>>>>> [   29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>>> [   29.441792] pwc: Set resolution to 640x480
>>>>> [   29.441824] pwc: Setting alternate interface 9
>>>>> [   29.455061] pwc: Allocated URB at 0xc9b83600
>>>>> [   29.455850] pwc: Allocated URB at 0xc9b83400
>>>>> [   29.456040] pwc: Allocated URB at 0xc9b83200
>>>>> [   29.456271] pwc: URB 0xc9b83600 submitted.
>>>>> [   29.456310] pwc: URB 0xc9b83400 submitted.
>>>>> [   29.456341] pwc: URB 0xc9b83200 submitted.
>>>>> [   29.456362] pwc: << pwc_isoc_init()
>>>>> [   30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>> [   30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>>> [   30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>> [   30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>> [   30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>> [   30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>> [   30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>>> [   30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>> [   30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>> [   30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>> [   31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>> [   31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>>> [   31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>> [   31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>> [   31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>> [   31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>> [   31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
>>>>> [   31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>> [   31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>> [   31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>>
>>>>>
>>>>> 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>> Hello,
>>>>>>
>>>>>> I've also just found that the same commit breaks cpufreq on BeagleBone Black :)
>>>>>>
>>>>>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>>>>>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>>>>>> (as it did whet there was cpufreq driver).
>>>>>>
>>>>>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I've found that the following commit fixes the issue:
>>>>>>>
>>>>>>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>>>>>>> Author: Viresh Kumar <viresh.kumar@linaro.org>
>>>>>>> Date:   Fri Apr 22 16:58:42 2016 +0530
>>>>>>>
>>>>>>>     cpufreq: omap: Use generic platdev driver
>>>>>>>
>>>>>>>     The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>>>>>>>     device now, reuse that and remove similar code from platform code.
>>>>>>>
>>>>>>>
>>>>>>> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I've just bisected commit, which fixed the issue in v4.7
>>>>>>>>
>>>>>>>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>>>>>>>> Merge: f55532a febce40
>>>>>>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>>>>>> Date:   Sat Apr 2 01:07:17 2016 +0200
>>>>>>>>
>>>>>>>>     Merge back intel_pstate fixes for v4.6.
>>>>>>>>
>>>>>>>>     * pm-cpufreq:
>>>>>>>>       intel_pstate: Avoid extra invocation of intel_pstate_sample()
>>>>>>>>       intel_pstate: Do not set utilization update hook too early
>>>>>>>>
>>>>>>>> Unfortunately, intel_pstate branch doesn't have
>>>>>>>> f551e13529833e052f75ec628a8af7b034af20f9 applied.
>>>>>>>> I'll try to bisect this branch with the patch manually applied.
>>>>>>>>
>>>>>>>> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I've just biseced commit, which introduced this issue
>>>>>>>>>
>>>>>>>>> commit f551e13529833e052f75ec628a8af7b034af20f9
>>>>>>>>> Author: Bin Liu <b-liu@ti.com>
>>>>>>>>> Date:   Mon Apr 25 15:53:30 2016 -0500
>>>>>>>>>
>>>>>>>>>     Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
>>>>>>>>> return in bottom half"
>>>>>>>>>
>>>>>>>>> I have not checked yet, if it was intentionnaly fixed.
>>>>>>>>>
>>>>>>>>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>>> > Hi,
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>>> >> > 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@ti.com>:
>>>>>>>>>>>>> >> >> > Hi,
>>>>>>>>>>>>> >> >> >
>>>>>>>>>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > I think you might be able to check it without a sniffer - MUSB
>>>>>>>>>>>>> > controller can generate SOF interrupts, but it is masked in current
>>>>>>>>>>>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>>>>>>>>>>>> > as
>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>> >         ...
>>>>>>>>>>>>> > or
>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>> >         ...
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > which means your issue is different from the one I mentioned. But if
>>>>>>>>>>>>> > you get a log as
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > then you hit on the known issue I mentioned.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >> Until that, could I check something else? For instance, disable
>>>>>>>>>>>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > You could disable it, but I don't think you will get yuv video stream
>>>>>>>>>>>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>>>>>>>>>>>> > your video requirement anyway?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Many thanks for your guidance. I will answer the rest later when will
>>>>>>>>>>>>> be ready to play with SOF interrupt.
>>>>>>>>>>>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>>>>>>>>>>>
>>>>>>>>>>>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>>>>>>>>>>>> N
>>>>>>>>>>>>
>>>>>>>>>>>> It sounds like you have a different issue here. With usb_dma=0, I
>>>>>>>>>>>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>>>>>>>>>>>> that I can not obtain 640x480 at any FPS on musb.
>>>>>>>>>>>>
>>>>>>>>>>>> The current CPPI41 driver should be able to handle this. I think you
>>>>>>>>>>>> really have to debug the pwc driver to figure out why it drops the video
>>>>>>>>>>>> frame. I personally don't have a pwc supported camera, never looked the
>>>>>>>>>>>> pwc driver...
>>>>>>>>>>>
>>>>>>>>>>> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
>>>>>>>>>>> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
>>>>>>>>>>> 640x480 frames.
>>>>>>>>>>> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
>>>>>>>>>>> Quad-code Atom E3800 based PC with 4.1 also works fine.
>>>>>>>>>>>
>>>>>>>>>>> So, I even don't know what to say. Probably, the issue depends on CPU
>>>>>>>>>>> latency/performance and it was there for a while.
>>>>>>>>>>> Fortunately, I think, I could use git bisect if I found latest forking
>>>>>>>>>>> kernel for my laptop.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It seems that the issue is gone in 4.7-rc7, so forget it.
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> >> 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
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Something like that, I suppose. Normally, I see input data flow in
>>>>>>>>>>>>> usbmon, but don't see frames in v4l2.
>>>>>>>>>>>>> But when camera 'hungs', I don't see nor input flow (except the
>>>>>>>>>>>>> control packages exchange) neither frames.
>>>>>>>>>>>>
>>>>>>>>>>>> Fair enough.
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>
>>>
>>>
>>> --
>>> 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
>
>
>
> --
> 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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

I've just checked 4.8-rc2 - same behaviour.

2016-08-18 16:31 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> Any ideas?
>
> 2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> When DMA is not used, I see the same behavior: lots of zero-length
>> packages received.
>>
>> Can It be related to some kind of USB overflow due to long input data
>> processing with disabled IRQ?
>> When HCD_BC is used then part of processing is postponed and this can
>> explain greater throughput due to better latency.
>>
>> 2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>> I've just found that in such cases, when DMA actual length is zero,
>>> both cppi41_channel->prog_len and txstate.residue equal 960 at
>>> musb_cppi41 line 225:
>>>
>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>>>
>>> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>> I've just found that dma->actual_len equals to zero in most cases at
>>>> musb_host.c line 1946.
>>>> And this produces zero-length packages.
>>>>
>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>>>
>>>> Any ideas why?
>>>>
>>>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>> I've just found that many packages in URBs have zero actual_length (It
>>>>> is a question why).
>>>>> Then the following end of frame criteria leads to `frame underflow' message:
>>>>>
>>>>>                 if (flen < pdev->vlast_packet_size) {
>>>>>                         /* Shorter packet... end of frame */
>>>>>                         if (pdev->vsync == 2)
>>>>>                                 pwc_frame_complete(pdev);
>>>>>                         if (pdev->fill_buf == NULL)
>>>>>                                 pdev->fill_buf = pwc_get_next_fill_buf(pdev);
>>>>>                         if (pdev->fill_buf) {
>>>>>                                 pdev->fill_buf->filled = 0;
>>>>>                                 pdev->vsync = 1;
>>>>>                         }
>>>>>                 }
>>>>>
>>>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>> pwc module output with trace=511 is the following:
>>>>>>
>>>>>> [   24.793109] usbcore: registered new interface driver Philips webcam
>>>>>> [   29.276979] pwc: Unsupported pixel format
>>>>>> [   29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>> [   29.277090] pwc: Trying to set format to: width=640 height=480
>>>>>> fps=15 format=YU12
>>>>>> [   29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>>>> [   29.277145] pwc: decode_size = 5.
>>>>>> [   29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>>>>>> [   29.277204] pwc: Set resolution to 640x480
>>>>>> [   29.277225] pwc: pwc_set_video_mode(), return=0
>>>>>> [   29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>> [   29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>>>> [   29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>> [   29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>>> [   29.277475] pwc: decode_size = 5.
>>>>>> [   29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>>>> [   29.278750] pwc: Set resolution to 640x480
>>>>>> [   29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>>> [   29.300420] pwc: decode_size = 5.
>>>>>> [   29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>>>> [   29.441792] pwc: Set resolution to 640x480
>>>>>> [   29.441824] pwc: Setting alternate interface 9
>>>>>> [   29.455061] pwc: Allocated URB at 0xc9b83600
>>>>>> [   29.455850] pwc: Allocated URB at 0xc9b83400
>>>>>> [   29.456040] pwc: Allocated URB at 0xc9b83200
>>>>>> [   29.456271] pwc: URB 0xc9b83600 submitted.
>>>>>> [   29.456310] pwc: URB 0xc9b83400 submitted.
>>>>>> [   29.456341] pwc: URB 0xc9b83200 submitted.
>>>>>> [   29.456362] pwc: << pwc_isoc_init()
>>>>>> [   30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>>> [   30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>>>> [   30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>>> [   30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>>> [   30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>>> [   30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>>> [   30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>>>> [   30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>>> [   30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>>> [   30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>>> [   31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>>> [   31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>>>> [   31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>>> [   31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>>> [   31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>>> [   31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>>> [   31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
>>>>>> [   31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>>> [   31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>>> [   31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>>>
>>>>>>
>>>>>> 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I've also just found that the same commit breaks cpufreq on BeagleBone Black :)
>>>>>>>
>>>>>>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>>>>>>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>>>>>>> (as it did whet there was cpufreq driver).
>>>>>>>
>>>>>>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I've found that the following commit fixes the issue:
>>>>>>>>
>>>>>>>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>>>>>>>> Author: Viresh Kumar <viresh.kumar@linaro.org>
>>>>>>>> Date:   Fri Apr 22 16:58:42 2016 +0530
>>>>>>>>
>>>>>>>>     cpufreq: omap: Use generic platdev driver
>>>>>>>>
>>>>>>>>     The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>>>>>>>>     device now, reuse that and remove similar code from platform code.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I've just bisected commit, which fixed the issue in v4.7
>>>>>>>>>
>>>>>>>>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>>>>>>>>> Merge: f55532a febce40
>>>>>>>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>>>>>>> Date:   Sat Apr 2 01:07:17 2016 +0200
>>>>>>>>>
>>>>>>>>>     Merge back intel_pstate fixes for v4.6.
>>>>>>>>>
>>>>>>>>>     * pm-cpufreq:
>>>>>>>>>       intel_pstate: Avoid extra invocation of intel_pstate_sample()
>>>>>>>>>       intel_pstate: Do not set utilization update hook too early
>>>>>>>>>
>>>>>>>>> Unfortunately, intel_pstate branch doesn't have
>>>>>>>>> f551e13529833e052f75ec628a8af7b034af20f9 applied.
>>>>>>>>> I'll try to bisect this branch with the patch manually applied.
>>>>>>>>>
>>>>>>>>> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I've just biseced commit, which introduced this issue
>>>>>>>>>>
>>>>>>>>>> commit f551e13529833e052f75ec628a8af7b034af20f9
>>>>>>>>>> Author: Bin Liu <b-liu@ti.com>
>>>>>>>>>> Date:   Mon Apr 25 15:53:30 2016 -0500
>>>>>>>>>>
>>>>>>>>>>     Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
>>>>>>>>>> return in bottom half"
>>>>>>>>>>
>>>>>>>>>> I have not checked yet, if it was intentionnaly fixed.
>>>>>>>>>>
>>>>>>>>>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>>>> > Hi,
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>>>> >> > 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@ti.com>:
>>>>>>>>>>>>>> >> >> > Hi,
>>>>>>>>>>>>>> >> >> >
>>>>>>>>>>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > I think you might be able to check it without a sniffer - MUSB
>>>>>>>>>>>>>> > controller can generate SOF interrupts, but it is masked in current
>>>>>>>>>>>>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>>>>>>>>>>>>> > as
>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>> >         ...
>>>>>>>>>>>>>> > or
>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>> >         ...
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > which means your issue is different from the one I mentioned. But if
>>>>>>>>>>>>>> > you get a log as
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > then you hit on the known issue I mentioned.
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> >> Until that, could I check something else? For instance, disable
>>>>>>>>>>>>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > You could disable it, but I don't think you will get yuv video stream
>>>>>>>>>>>>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>>>>>>>>>>>>> > your video requirement anyway?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Many thanks for your guidance. I will answer the rest later when will
>>>>>>>>>>>>>> be ready to play with SOF interrupt.
>>>>>>>>>>>>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>>>>>>>>>>>>> N
>>>>>>>>>>>>>
>>>>>>>>>>>>> It sounds like you have a different issue here. With usb_dma=0, I
>>>>>>>>>>>>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>>>>>>>>>>>>> that I can not obtain 640x480 at any FPS on musb.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The current CPPI41 driver should be able to handle this. I think you
>>>>>>>>>>>>> really have to debug the pwc driver to figure out why it drops the video
>>>>>>>>>>>>> frame. I personally don't have a pwc supported camera, never looked the
>>>>>>>>>>>>> pwc driver...
>>>>>>>>>>>>
>>>>>>>>>>>> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
>>>>>>>>>>>> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
>>>>>>>>>>>> 640x480 frames.
>>>>>>>>>>>> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
>>>>>>>>>>>> Quad-code Atom E3800 based PC with 4.1 also works fine.
>>>>>>>>>>>>
>>>>>>>>>>>> So, I even don't know what to say. Probably, the issue depends on CPU
>>>>>>>>>>>> latency/performance and it was there for a while.
>>>>>>>>>>>> Fortunately, I think, I could use git bisect if I found latest forking
>>>>>>>>>>>> kernel for my laptop.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It seems that the issue is gone in 4.7-rc7, so forget it.
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>> >> 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
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Something like that, I suppose. Normally, I see input data flow in
>>>>>>>>>>>>>> usbmon, but don't see frames in v4l2.
>>>>>>>>>>>>>> But when camera 'hungs', I don't see nor input flow (except the
>>>>>>>>>>>>>> control packages exchange) neither frames.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Fair enough.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
>>
>>
>> --
>> 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



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

I've just measured that

it takes 150 us in average for pwc_isoc_handler to run
350 us - __usb_hcd_giveback_urb

So, it takes either 50 us (with HCD_BH) or 400 us (without) for
usb_hcd_giveback_urb to run.


2016-08-20 21:09 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> I've just checked 4.8-rc2 - same behaviour.
>
> 2016-08-18 16:31 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> Any ideas?
>>
>> 2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>> When DMA is not used, I see the same behavior: lots of zero-length
>>> packages received.
>>>
>>> Can It be related to some kind of USB overflow due to long input data
>>> processing with disabled IRQ?
>>> When HCD_BC is used then part of processing is postponed and this can
>>> explain greater throughput due to better latency.
>>>
>>> 2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>> I've just found that in such cases, when DMA actual length is zero,
>>>> both cppi41_channel->prog_len and txstate.residue equal 960 at
>>>> musb_cppi41 line 225:
>>>>
>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>>>>
>>>> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>> I've just found that dma->actual_len equals to zero in most cases at
>>>>> musb_host.c line 1946.
>>>>> And this produces zero-length packages.
>>>>>
>>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>>>>
>>>>> Any ideas why?
>>>>>
>>>>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>> I've just found that many packages in URBs have zero actual_length (It
>>>>>> is a question why).
>>>>>> Then the following end of frame criteria leads to `frame underflow' message:
>>>>>>
>>>>>>                 if (flen < pdev->vlast_packet_size) {
>>>>>>                         /* Shorter packet... end of frame */
>>>>>>                         if (pdev->vsync == 2)
>>>>>>                                 pwc_frame_complete(pdev);
>>>>>>                         if (pdev->fill_buf == NULL)
>>>>>>                                 pdev->fill_buf = pwc_get_next_fill_buf(pdev);
>>>>>>                         if (pdev->fill_buf) {
>>>>>>                                 pdev->fill_buf->filled = 0;
>>>>>>                                 pdev->vsync = 1;
>>>>>>                         }
>>>>>>                 }
>>>>>>
>>>>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>> pwc module output with trace=511 is the following:
>>>>>>>
>>>>>>> [   24.793109] usbcore: registered new interface driver Philips webcam
>>>>>>> [   29.276979] pwc: Unsupported pixel format
>>>>>>> [   29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>> [   29.277090] pwc: Trying to set format to: width=640 height=480
>>>>>>> fps=15 format=YU12
>>>>>>> [   29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>>>>> [   29.277145] pwc: decode_size = 5.
>>>>>>> [   29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>>>>>>> [   29.277204] pwc: Set resolution to 640x480
>>>>>>> [   29.277225] pwc: pwc_set_video_mode(), return=0
>>>>>>> [   29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>> [   29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>>>>> [   29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>> [   29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>>>> [   29.277475] pwc: decode_size = 5.
>>>>>>> [   29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>>>>> [   29.278750] pwc: Set resolution to 640x480
>>>>>>> [   29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>>>> [   29.300420] pwc: decode_size = 5.
>>>>>>> [   29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>>>>> [   29.441792] pwc: Set resolution to 640x480
>>>>>>> [   29.441824] pwc: Setting alternate interface 9
>>>>>>> [   29.455061] pwc: Allocated URB at 0xc9b83600
>>>>>>> [   29.455850] pwc: Allocated URB at 0xc9b83400
>>>>>>> [   29.456040] pwc: Allocated URB at 0xc9b83200
>>>>>>> [   29.456271] pwc: URB 0xc9b83600 submitted.
>>>>>>> [   29.456310] pwc: URB 0xc9b83400 submitted.
>>>>>>> [   29.456341] pwc: URB 0xc9b83200 submitted.
>>>>>>> [   29.456362] pwc: << pwc_isoc_init()
>>>>>>> [   30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>>>> [   30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>>>>> [   30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>>>> [   30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>>>> [   30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>>>> [   30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>>>> [   30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>>>>> [   30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>>>> [   30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>>>> [   30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>>>> [   31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>>>> [   31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>>>>> [   31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>>>> [   31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>>>> [   31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>>>> [   31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>>>> [   31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
>>>>>>> [   31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>>>> [   31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>>>> [   31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>>>>
>>>>>>>
>>>>>>> 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I've also just found that the same commit breaks cpufreq on BeagleBone Black :)
>>>>>>>>
>>>>>>>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>>>>>>>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>>>>>>>> (as it did whet there was cpufreq driver).
>>>>>>>>
>>>>>>>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I've found that the following commit fixes the issue:
>>>>>>>>>
>>>>>>>>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>>>>>>>>> Author: Viresh Kumar <viresh.kumar@linaro.org>
>>>>>>>>> Date:   Fri Apr 22 16:58:42 2016 +0530
>>>>>>>>>
>>>>>>>>>     cpufreq: omap: Use generic platdev driver
>>>>>>>>>
>>>>>>>>>     The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>>>>>>>>>     device now, reuse that and remove similar code from platform code.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I've just bisected commit, which fixed the issue in v4.7
>>>>>>>>>>
>>>>>>>>>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>>>>>>>>>> Merge: f55532a febce40
>>>>>>>>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>>>>>>>> Date:   Sat Apr 2 01:07:17 2016 +0200
>>>>>>>>>>
>>>>>>>>>>     Merge back intel_pstate fixes for v4.6.
>>>>>>>>>>
>>>>>>>>>>     * pm-cpufreq:
>>>>>>>>>>       intel_pstate: Avoid extra invocation of intel_pstate_sample()
>>>>>>>>>>       intel_pstate: Do not set utilization update hook too early
>>>>>>>>>>
>>>>>>>>>> Unfortunately, intel_pstate branch doesn't have
>>>>>>>>>> f551e13529833e052f75ec628a8af7b034af20f9 applied.
>>>>>>>>>> I'll try to bisect this branch with the patch manually applied.
>>>>>>>>>>
>>>>>>>>>> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> I've just biseced commit, which introduced this issue
>>>>>>>>>>>
>>>>>>>>>>> commit f551e13529833e052f75ec628a8af7b034af20f9
>>>>>>>>>>> Author: Bin Liu <b-liu@ti.com>
>>>>>>>>>>> Date:   Mon Apr 25 15:53:30 2016 -0500
>>>>>>>>>>>
>>>>>>>>>>>     Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
>>>>>>>>>>> return in bottom half"
>>>>>>>>>>>
>>>>>>>>>>> I have not checked yet, if it was intentionnaly fixed.
>>>>>>>>>>>
>>>>>>>>>>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>>>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>>>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>>>>> > Hi,
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>>>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>>>>> >> > 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@ti.com>:
>>>>>>>>>>>>>>> >> >> > Hi,
>>>>>>>>>>>>>>> >> >> >
>>>>>>>>>>>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > I think you might be able to check it without a sniffer - MUSB
>>>>>>>>>>>>>>> > controller can generate SOF interrupts, but it is masked in current
>>>>>>>>>>>>>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>>>>>>>>>>>>>> > as
>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>> >         ...
>>>>>>>>>>>>>>> > or
>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>> >         ...
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > which means your issue is different from the one I mentioned. But if
>>>>>>>>>>>>>>> > you get a log as
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > then you hit on the known issue I mentioned.
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> >> Until that, could I check something else? For instance, disable
>>>>>>>>>>>>>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > You could disable it, but I don't think you will get yuv video stream
>>>>>>>>>>>>>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>>>>>>>>>>>>>> > your video requirement anyway?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Many thanks for your guidance. I will answer the rest later when will
>>>>>>>>>>>>>>> be ready to play with SOF interrupt.
>>>>>>>>>>>>>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>>>>>>>>>>>>>> N
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It sounds like you have a different issue here. With usb_dma=0, I
>>>>>>>>>>>>>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>>>>>>>>>>>>>> that I can not obtain 640x480 at any FPS on musb.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The current CPPI41 driver should be able to handle this. I think you
>>>>>>>>>>>>>> really have to debug the pwc driver to figure out why it drops the video
>>>>>>>>>>>>>> frame. I personally don't have a pwc supported camera, never looked the
>>>>>>>>>>>>>> pwc driver...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
>>>>>>>>>>>>> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
>>>>>>>>>>>>> 640x480 frames.
>>>>>>>>>>>>> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
>>>>>>>>>>>>> Quad-code Atom E3800 based PC with 4.1 also works fine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, I even don't know what to say. Probably, the issue depends on CPU
>>>>>>>>>>>>> latency/performance and it was there for a while.
>>>>>>>>>>>>> Fortunately, I think, I could use git bisect if I found latest forking
>>>>>>>>>>>>> kernel for my laptop.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It seems that the issue is gone in 4.7-rc7, so forget it.
>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>> >> 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
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Something like that, I suppose. Normally, I see input data flow in
>>>>>>>>>>>>>>> usbmon, but don't see frames in v4l2.
>>>>>>>>>>>>>>> But when camera 'hungs', I don't see nor input flow (except the
>>>>>>>>>>>>>>> control packages exchange) neither frames.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Fair enough.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>
>>>
>>>
>>> --
>>> 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
>
>
>
> --
> 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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

In both cases (with or without HCD_BH), usb_hcd_giveback_urb is called
every 0.01 sec. It is not clear why behavior is so different.

2016-08-21 17:02 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> I've just measured that
>
> it takes 150 us in average for pwc_isoc_handler to run
> 350 us - __usb_hcd_giveback_urb
>
> So, it takes either 50 us (with HCD_BH) or 400 us (without) for
> usb_hcd_giveback_urb to run.
>
>
> 2016-08-20 21:09 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>> I've just checked 4.8-rc2 - same behaviour.
>>
>> 2016-08-18 16:31 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>> Any ideas?
>>>
>>> 2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>> When DMA is not used, I see the same behavior: lots of zero-length
>>>> packages received.
>>>>
>>>> Can It be related to some kind of USB overflow due to long input data
>>>> processing with disabled IRQ?
>>>> When HCD_BC is used then part of processing is postponed and this can
>>>> explain greater throughput due to better latency.
>>>>
>>>> 2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>> I've just found that in such cases, when DMA actual length is zero,
>>>>> both cppi41_channel->prog_len and txstate.residue equal 960 at
>>>>> musb_cppi41 line 225:
>>>>>
>>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>>>>>
>>>>> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>> I've just found that dma->actual_len equals to zero in most cases at
>>>>>> musb_host.c line 1946.
>>>>>> And this produces zero-length packages.
>>>>>>
>>>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>>>>>
>>>>>> Any ideas why?
>>>>>>
>>>>>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>> I've just found that many packages in URBs have zero actual_length (It
>>>>>>> is a question why).
>>>>>>> Then the following end of frame criteria leads to `frame underflow' message:
>>>>>>>
>>>>>>>                 if (flen < pdev->vlast_packet_size) {
>>>>>>>                         /* Shorter packet... end of frame */
>>>>>>>                         if (pdev->vsync == 2)
>>>>>>>                                 pwc_frame_complete(pdev);
>>>>>>>                         if (pdev->fill_buf == NULL)
>>>>>>>                                 pdev->fill_buf = pwc_get_next_fill_buf(pdev);
>>>>>>>                         if (pdev->fill_buf) {
>>>>>>>                                 pdev->fill_buf->filled = 0;
>>>>>>>                                 pdev->vsync = 1;
>>>>>>>                         }
>>>>>>>                 }
>>>>>>>
>>>>>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>> pwc module output with trace=511 is the following:
>>>>>>>>
>>>>>>>> [   24.793109] usbcore: registered new interface driver Philips webcam
>>>>>>>> [   29.276979] pwc: Unsupported pixel format
>>>>>>>> [   29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>>> [   29.277090] pwc: Trying to set format to: width=640 height=480
>>>>>>>> fps=15 format=YU12
>>>>>>>> [   29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>>>>>> [   29.277145] pwc: decode_size = 5.
>>>>>>>> [   29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>>>>>>>> [   29.277204] pwc: Set resolution to 640x480
>>>>>>>> [   29.277225] pwc: pwc_set_video_mode(), return=0
>>>>>>>> [   29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>>> [   29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>>>>>> [   29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>>> [   29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>>>>> [   29.277475] pwc: decode_size = 5.
>>>>>>>> [   29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>>>>>> [   29.278750] pwc: Set resolution to 640x480
>>>>>>>> [   29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>>>>> [   29.300420] pwc: decode_size = 5.
>>>>>>>> [   29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>>>>>> [   29.441792] pwc: Set resolution to 640x480
>>>>>>>> [   29.441824] pwc: Setting alternate interface 9
>>>>>>>> [   29.455061] pwc: Allocated URB at 0xc9b83600
>>>>>>>> [   29.455850] pwc: Allocated URB at 0xc9b83400
>>>>>>>> [   29.456040] pwc: Allocated URB at 0xc9b83200
>>>>>>>> [   29.456271] pwc: URB 0xc9b83600 submitted.
>>>>>>>> [   29.456310] pwc: URB 0xc9b83400 submitted.
>>>>>>>> [   29.456341] pwc: URB 0xc9b83200 submitted.
>>>>>>>> [   29.456362] pwc: << pwc_isoc_init()
>>>>>>>> [   30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>>>>> [   30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>>>>>> [   30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>>>>> [   30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>>>>> [   30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>>>>> [   30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>>>>> [   30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>>>>>> [   30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>>>>> [   30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>>>>> [   30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>>>>> [   31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>>>>> [   31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>>>>>> [   31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>>>>> [   31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>>>>> [   31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>>>>> [   31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>>>>>> [   31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
>>>>>>>> [   31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>>>>>> [   31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>>>>>> [   31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I've also just found that the same commit breaks cpufreq on BeagleBone Black :)
>>>>>>>>>
>>>>>>>>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>>>>>>>>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>>>>>>>>> (as it did whet there was cpufreq driver).
>>>>>>>>>
>>>>>>>>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I've found that the following commit fixes the issue:
>>>>>>>>>>
>>>>>>>>>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>>>>>>>>>> Author: Viresh Kumar <viresh.kumar@linaro.org>
>>>>>>>>>> Date:   Fri Apr 22 16:58:42 2016 +0530
>>>>>>>>>>
>>>>>>>>>>     cpufreq: omap: Use generic platdev driver
>>>>>>>>>>
>>>>>>>>>>     The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>>>>>>>>>>     device now, reuse that and remove similar code from platform code.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> I've just bisected commit, which fixed the issue in v4.7
>>>>>>>>>>>
>>>>>>>>>>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>>>>>>>>>>> Merge: f55532a febce40
>>>>>>>>>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>>>>>>>>> Date:   Sat Apr 2 01:07:17 2016 +0200
>>>>>>>>>>>
>>>>>>>>>>>     Merge back intel_pstate fixes for v4.6.
>>>>>>>>>>>
>>>>>>>>>>>     * pm-cpufreq:
>>>>>>>>>>>       intel_pstate: Avoid extra invocation of intel_pstate_sample()
>>>>>>>>>>>       intel_pstate: Do not set utilization update hook too early
>>>>>>>>>>>
>>>>>>>>>>> Unfortunately, intel_pstate branch doesn't have
>>>>>>>>>>> f551e13529833e052f75ec628a8af7b034af20f9 applied.
>>>>>>>>>>> I'll try to bisect this branch with the patch manually applied.
>>>>>>>>>>>
>>>>>>>>>>> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> I've just biseced commit, which introduced this issue
>>>>>>>>>>>>
>>>>>>>>>>>> commit f551e13529833e052f75ec628a8af7b034af20f9
>>>>>>>>>>>> Author: Bin Liu <b-liu@ti.com>
>>>>>>>>>>>> Date:   Mon Apr 25 15:53:30 2016 -0500
>>>>>>>>>>>>
>>>>>>>>>>>>     Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
>>>>>>>>>>>> return in bottom half"
>>>>>>>>>>>>
>>>>>>>>>>>> I have not checked yet, if it was intentionnaly fixed.
>>>>>>>>>>>>
>>>>>>>>>>>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>>>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
>>>>>>>>>>>>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>>>>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>>>>>> > Hi,
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>>>>>>>>>>>>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-liu@ti.com>:
>>>>>>>>>>>>>>>> >> > 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@ti.com>:
>>>>>>>>>>>>>>>> >> >> > Hi,
>>>>>>>>>>>>>>>> >> >> >
>>>>>>>>>>>>>>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, matwey@sai.msu.ru 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.
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> > I think you might be able to check it without a sniffer - MUSB
>>>>>>>>>>>>>>>> > controller can generate SOF interrupts, but it is masked in current
>>>>>>>>>>>>>>>> > driver. So I think you could enable SOF interrupt, then if you get a log
>>>>>>>>>>>>>>>> > as
>>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>>> >         ...
>>>>>>>>>>>>>>>> > or
>>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>>> >         ...
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> > which means your issue is different from the one I mentioned. But if
>>>>>>>>>>>>>>>> > you get a log as
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>>> >         SOF     <--- no rx packets in two consecutive SOFs
>>>>>>>>>>>>>>>> >         rx packet
>>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>>> >         SOF
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> > then you hit on the known issue I mentioned.
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> >> Until that, could I check something else? For instance, disable
>>>>>>>>>>>>>>>> >> CONFIG_USB_TI_CPPI41_DMA.
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> > You could disable it, but I don't think you will get yuv video stream
>>>>>>>>>>>>>>>> > of 640x480@30fps. PIO mode does not support such high bandwidth. What is
>>>>>>>>>>>>>>>> > your video requirement anyway?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Many thanks for your guidance. I will answer the rest later when will
>>>>>>>>>>>>>>>> be ready to play with SOF interrupt.
>>>>>>>>>>>>>>>> Now, I would like to say that use_dma=0 doesn't change the behaviour:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> # cat /sys/module/musb_hdrc/parameters/use_dma
>>>>>>>>>>>>>>>> N
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It sounds like you have a different issue here. With usb_dma=0, I
>>>>>>>>>>>>>>> remembered I can get 320x240 YUV stream @30fps from uvc cameras.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would like 640x480@5fps which works with x86 based PC. Issue here,
>>>>>>>>>>>>>>>> that I can not obtain 640x480 at any FPS on musb.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The current CPPI41 driver should be able to handle this. I think you
>>>>>>>>>>>>>>> really have to debug the pwc driver to figure out why it drops the video
>>>>>>>>>>>>>>> frame. I personally don't have a pwc supported camera, never looked the
>>>>>>>>>>>>>>> pwc driver...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Surprisingly, I've found that my 10-year-old laptop (Intel Core Solo
>>>>>>>>>>>>>> T1350) has the similar issue with pwc (kernel 3.16). It drops 80% of
>>>>>>>>>>>>>> 640x480 frames.
>>>>>>>>>>>>>> Vortex86 200Mhz based rugged PC with 2.6.14 works fine.
>>>>>>>>>>>>>> Quad-code Atom E3800 based PC with 4.1 also works fine.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, I even don't know what to say. Probably, the issue depends on CPU
>>>>>>>>>>>>>> latency/performance and it was there for a while.
>>>>>>>>>>>>>> Fortunately, I think, I could use git bisect if I found latest forking
>>>>>>>>>>>>>> kernel for my laptop.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It seems that the issue is gone in 4.7-rc7, so forget it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>> >> 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
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> > How did you check that? MUSB stopped generating RX EP interrupt?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Something like that, I suppose. Normally, I see input data flow in
>>>>>>>>>>>>>>>> usbmon, but don't see frames in v4l2.
>>>>>>>>>>>>>>>> But when camera 'hungs', I don't see nor input flow (except the
>>>>>>>>>>>>>>>> control packages exchange) neither frames.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Fair enough.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
>>
>>
>> --
>> 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



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Alan Stern]

On Sun, 21 Aug 2016, Matwey V. Kornilov wrote:

> In both cases (with or without HCD_BH), usb_hcd_giveback_urb is called
> every 0.01 sec. It is not clear why behavior is so different.

What behavior are you asking about?  The difference between HCD_BH set 
and not set?

Alan Stern

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-08-22 1:00 GMT+03:00 Alan Stern <stern@rowland.harvard.edu>:
> On Sun, 21 Aug 2016, Matwey V. Kornilov wrote:
>
>> In both cases (with or without HCD_BH), usb_hcd_giveback_urb is called
>> every 0.01 sec. It is not clear why behavior is so different.
>
> What behavior are you asking about?  The difference between HCD_BH set
> and not set?
>

The difference between HCD_BH set and not set is that when it is not
set then usb_hcd_giveback_urb() receive zero-length URBs. And this
breaks my pwc webcam. And the question is how to fix it.
As far as I can see, usb_hcd_giveback_urb is being called with the
same rate in both cases, so zero-length URBs are probably supposed to
be data-carrying.

> Alan Stern
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-08-22 11:32 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> 2016-08-22 1:00 GMT+03:00 Alan Stern <stern@rowland.harvard.edu>:
>> On Sun, 21 Aug 2016, Matwey V. Kornilov wrote:
>>
>>> In both cases (with or without HCD_BH), usb_hcd_giveback_urb is called
>>> every 0.01 sec. It is not clear why behavior is so different.
>>
>> What behavior are you asking about?  The difference between HCD_BH set
>> and not set?
>>
>
> The difference between HCD_BH set and not set is that when it is not
> set then usb_hcd_giveback_urb() receive zero-length URBs. And this
> breaks my pwc webcam. And the question is how to fix it.
> As far as I can see, usb_hcd_giveback_urb is being called with the
> same rate in both cases, so zero-length URBs are probably supposed to
> be data-carrying.
>

I can't understand what makes the difference. What I found to this
moment is the following:

1) isoc transfer works in two empirical modes or regimes. I called
them 'normal' one and 'broken'.
1a) In the 'normal' mode, every package is 956 bytes long and
c->desc->pd2 (see cppi41_irq) is 1400009a
1b) In the 'broken' mode, every package is 0 bytes long and
c->desc->pd2 (see cppi41_irq) is 1408009a
2) In each mode cppi41_irq is invoked every 1 ms.
2a) When the time lag between two subsequent calls of cppi41_irq is
greater (up to 2 ms) or less (0.3 ms) than 1 ms then the mode is
switched. It can happen inside single URB without calling complete().
So, the data are flowing in large bulks of either empty or full packages.
3) When HCD_BH is not set, then this two regimes are being flipped
constantly breaking internal pwc logic. When HCD_BH is set, then first
dozens packages are empty, then there is a pause between cppi41_irq
and the rest packages are fine.


>> Alan Stern
>>
>
>
>
> --
> 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