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 :
> 2016-08-22 1:00 GMT+03:00 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?
>>
>
> 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 149a
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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 :
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 :
> 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 :
>> I've just checked 4.8-rc2 - same behaviour.
>>
>> 2016-08-18 16:31 GMT+03:00 Matwey V. Kornilov :
>>> Any ideas?
>>>
>>> 2016-08-04 23:08 GMT+03:00 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 :
> 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 :
>> 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 :
>>> 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 :
 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.
 [   

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 :
> I've just checked 4.8-rc2 - same behaviour.
>
> 2016-08-18 16:31 GMT+03:00 Matwey V. Kornilov :
>> Any ideas?
>>
>> 2016-08-04 23:08 GMT+03:00 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 :
 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 :
> 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 :
>> 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 :
>>> 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.
>>> [   

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 :
> Any ideas?
>
> 2016-08-04 23:08 GMT+03:00 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 :
>>> 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 :
 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 :
> 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 :
>> 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.

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

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

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 :
> 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 :
>> 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 :
>>> 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 :
 Hello,

 I've also just found that the same commit 

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 :
> 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 :
>> 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 :
>>> 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 :
 Hello,

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

 commit 

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 :
> 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 :
>> 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 :
>>> Hello,
>>>
>>> I've found that the following commit fixes the issue:
>>>
>>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>>> Author: Viresh Kumar 
>>> 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 :
 

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 :
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 :
> 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 :
>> Hello,
>>
>> I've found that the following commit fixes the issue:
>>
>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>> Author: Viresh Kumar 
>> 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 :
>>> Hello,
>>>
>>> I've just bisected commit, which fixed the issue in v4.7
>>>
>>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>>> Merge: f55532a febce40
>>> Author: Rafael J. Wysocki 
>>> 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 :
 Hello,

 I've just biseced commit, which introduced this issue

 commit f551e13529833e052f75ec628a8af7b034af20f9
 Author: Bin Liu 
 Date:   Mon Apr 25 

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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 :
> 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 :
>> > Hello,
>> >
>> > I've found that the following commit fixes the issue:
>> >
>> > commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>> > Author: Viresh Kumar 
>> > 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 10 (-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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 :
> > Hello,
> >
> > I've found that the following commit fixes the issue:
> >
> > commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
> > Author: Viresh Kumar 
> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 :
> Hello,
>
> I've found that the following commit fixes the issue:
>
> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
> Author: Viresh Kumar 
> 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 :
>> Hello,
>>
>> I've just bisected commit, which fixed the issue in v4.7
>>
>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>> Merge: f55532a febce40
>> Author: Rafael J. Wysocki 
>> 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 :
>>> Hello,
>>>
>>> I've just biseced commit, which introduced this issue
>>>
>>> commit f551e13529833e052f75ec628a8af7b034af20f9
>>> Author: Bin Liu 
>>> 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 :
 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov :
> 2016-07-20 18:06 GMT+03:00 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 :
>>> > 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 :
>>> >> > 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 :
>>> >> >> > Hi,
>>> >> >> >
>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@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 

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 
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 :
> Hello,
>
> I've just bisected commit, which fixed the issue in v4.7
>
> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
> Merge: f55532a febce40
> Author: Rafael J. Wysocki 
> 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 :
>> Hello,
>>
>> I've just biseced commit, which introduced this issue
>>
>> commit f551e13529833e052f75ec628a8af7b034af20f9
>> Author: Bin Liu 
>> 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 :
>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov :
 2016-07-20 18:06 GMT+03:00 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 :
>> > 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 :
>> >> > 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 :
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@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 
>> >> >> >> 

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 
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 :
> Hello,
>
> I've just biseced commit, which introduced this issue
>
> commit f551e13529833e052f75ec628a8af7b034af20f9
> Author: Bin Liu 
> 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 :
>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov :
>>> 2016-07-20 18:06 GMT+03:00 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 :
> > 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 :
> >> > 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 :
> >> >> > Hi,
> >> >> >
> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@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 

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 
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 :
> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov :
>> 2016-07-20 18:06 GMT+03:00 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 :
 > 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 :
 >> > 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 :
 >> >> > Hi,
 >> >> >
 >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@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) + 

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 :
> 2016-07-20 18:06 GMT+03:00 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 :
>>> > 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 :
>>> >> > 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 :
>>> >> >> > Hi,
>>> >> >> >
>>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@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?
>>> >> >> >>
>>> 

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

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

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

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

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 :
> 2016-07-20 0:34 GMT+03:00 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 :
>>> > Hi,
>>> >
>>> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@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 

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

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 :
> > Hi,
> >
> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

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 :
> Hi,
>
> On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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, mat...@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.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html