All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bin Liu <b-liu@ti.com>
To: "Matwey V. Kornilov" <matwey@sai.msu.ru>
Cc: <hdegoede@redhat.com>, <linux-media@vger.kernel.org>,
	<linux-usb@vger.kernel.org>
Subject: Re: pwc over musb: 100% frame drop (lost) on high resolution stream
Date: Tue, 19 Jul 2016 16:34:26 -0500	[thread overview]
Message-ID: <20160719213426.GB14569@uda0271908> (raw)
In-Reply-To: <CAJs94EY_cXLA6eggC391eKiPBS-RVPmfPd7Wh4mhjZTQiCSUrA@mail.gmail.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.

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

  reply	other threads:[~2016-07-19 21:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-19 20:21 pwc over musb: 100% frame drop (lost) on high resolution stream matwey
2016-07-19 20:56 ` Bin Liu
2016-07-19 21:25   ` Matwey V. Kornilov
2016-07-19 21:34     ` Bin Liu [this message]
2016-07-20  6:09       ` Matwey V. Kornilov
2016-07-20  8:21         ` Matwey V. Kornilov
2016-07-20 14:13         ` Bin Liu
2016-07-20 14:44           ` Matwey V. Kornilov
2016-07-20 15:06             ` Bin Liu
2016-07-20 18:56               ` Matwey V. Kornilov
2016-07-23 19:24                 ` Matwey V. Kornilov
2016-07-27 17:34                   ` Matwey V. Kornilov
2016-07-28 16:16                     ` Matwey V. Kornilov
2016-07-29 18:01                       ` Matwey V. Kornilov
2016-07-31 20:31                         ` Matwey V. Kornilov
2016-08-01 16:50                           ` Viresh Kumar
2016-08-01 17:01                             ` Matwey V. Kornilov
2016-08-01 17:06                               ` Viresh Kumar
2016-08-01 18:11                                 ` Matwey V. Kornilov
2016-08-01 18:16                           ` Matwey V. Kornilov
2016-08-04 16:57                             ` Matwey V. Kornilov
2016-08-04 19:08                               ` Matwey V. Kornilov
2016-08-04 19:58                                 ` Matwey V. Kornilov
2016-08-04 20:08                                   ` Matwey V. Kornilov
2016-08-18 13:31                                     ` Matwey V. Kornilov
2016-08-20 18:09                                       ` Matwey V. Kornilov
2016-08-21 14:02                                         ` Matwey V. Kornilov
2016-08-21 16:07                                           ` Matwey V. Kornilov
2016-08-21 22:00                                             ` Alan Stern
2016-08-22  8:32                                               ` Matwey V. Kornilov
2016-08-24 18:17                                                 ` Matwey V. Kornilov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160719213426.GB14569@uda0271908 \
    --to=b-liu@ti.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=matwey@sai.msu.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.