Re: [PATCH 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
2018-07-24 23:55 GMT+03:00 Alan Stern : > On Tue, 24 Jul 2018, Matwey V. Kornilov wrote: > >> 2018-07-23 21:57 GMT+03:00 Alan Stern : >> > On Mon, 23 Jul 2018, Matwey V. Kornilov wrote: >> > >> >> I've tried to strategies: >> >> >> >> 1) Use dma_unmap and dma_map inside the handler (I suppose this is >> >> similar to how USB core does when there is no URB_NO_TRANSFER_DMA_MAP) >> > >> > Yes. >> > >> >> 2) Use sync_cpu and sync_device inside the handler (and dma_map only >> >> once at memory allocation) >> >> >> >> It is interesting that dma_unmap/dma_map pair leads to the lower >> >> overhead (+1us) than sync_cpu/sync_device (+2us) at x86_64 platform. >> >> At armv7l platform using dma_unmap/dma_map leads to ~50 usec in the >> >> handler, and sync_cpu/sync_device - ~65 usec. >> >> >> >> However, I am not sure is it mandatory to call >> >> dma_sync_single_for_device for FROM_DEVICE direction? >> > >> > According to Documentation/DMA-API-HOWTO.txt, the CPU should not write >> > to a DMA_FROM_DEVICE-mapped area, so dma_sync_single_for_device() is >> > not needed. >> >> Well, I measured the following at armv7l. The handler execution time >> (URB_NO_TRANSFER_DMA_MAP is used for all cases): >> >> 1) coherent DMA: ~3000 usec (pwc is not functional) >> 2) explicit dma_unmap and dma_map in the handler: ~52 usec >> 3) explicit dma_sync_single_for_cpu (no dma_sync_single_for_device): ~56 usec >> >> So, I suppose that unfortunately Tomasz suggestion doesn't work. There >> is no performance improvement when dma_sync_single is used. >> >> At x86_64 the following happens: >> >> 1) coherent DMA: ~2 usec >> 2) explicit dma_unmap and dma_map in the handler: ~3.5 usec >> 3) explicit dma_sync_single_for_cpu (no dma_sync_single_for_device): ~4 usec >> >> So, whats to do next? Personally, I think that DMA streaming API >> introduces not so great overhead. >> Does anybody happy with turning to streaming DMA or I'll introduce >> module-level switch as Ezequiel suggested? > > How about using the dma_unmap and dma_map calls in the USB core? If > they add the same overhead as putting them in the handler, I think it > would be acceptable for x86_64. Sure, that is the simplest way to implement streaming API. > > It certainly is odd that the dma_sync_single APIs take longer than > simply mapping and unmapping. Well. I am surprised too. Probably, it is related to that only 9560 bytes are used for each URB. It is only three memory pages. > > Alan Stern > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
Re: [BUG] musb: broken isochronous transfer at TI AM335x platform
2018-02-16 19:27 GMT+03:00 Tony Lindgren <t...@atomide.com>: > * Matwey V. Kornilov <mat...@sai.msu.ru> [180215 17:55]: >> [] 7.219456 d= 0.000997 [181.0 + 3.667] [ 3] IN : 4.5 >> [T ] 7.219459 d= 0.03 [181.0 + 7.083] [800] DATA0: 53 da >> ... >> [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN : 4.5 >> [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0: 13 36 >> ... >> [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5 >> [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00 00 >> [] 7.223456 d= 0.000997 [185.0 + 3.667] [ 3] IN : 4.5 >> [] 7.223459 d= 0.03 [185.0 + 7.000] [ 3] DATA0: 00 00 >> >> Please note, that the time moment "7.221456" has missed IN request >> packet which must be sent out every 1ms in this low-speed USB case. >> Then, all incoming packets became empty ones. Such moments coincide >> with frame discarding in pwc driver. > > Well sounds like you may be able to fix it since you have a test > case for it :) Well, I am not an USB expert and I need some guidance and advice to find acceptable solution. No doubts I could implement and test it, but I would like to spend time for something known to be useful. > >> Even though IN sending is usually handled by USB host hardware, it is >> not fully true for MUSB. Every IN is triggered by musb kernel driver >> (see MUSB_RXCSR_H_REQPKT usage in musb_host_packet_rx() and >> musb_ep_program()) since auto IN is not used. Rather complicated logic >> is incorporated to decide whether IN packet has to be sent. First, >> musb_host_packet_rx() handles IN sending when current URB is not >> completed (i.e. current URB has another packet which has to be >> received next). Second, musb_advance_schedule() (via musb_start_urb()) >> handles the case when current URB is completed but there is another >> URB pending. It seems that there is a hardware logic to fire IN packet >> in a way to have exactly 1ms between two consequent INs. So, >> MUSB_RXCSR_H_REQPKT is considered as IN requesting flag. > > Yeah this is a known issue with musb, there is not much ISO support > currently really. The regression should be fixed though. > > Sorry I don't have much ideas on how to improve things here. One > way might be to attempt to split the large musb functions into > smaller functions and see if that then allows finer grained control. > > Just to try to come up with some new ideas.. Maybe there's some way > to swap the hardware EP config dynamically and have some packets > mostly preconfigured and waiting to be triggered? > > Regards, > > Tony > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
[BUG] musb: broken isochronous transfer at TI AM335x platform
roposed a patch to swap time-consuming urb->giveback() and
MUSB_RXCSR_H_REQPKT writing but the patch has not been accepted since
it complicates IN-requesting logic even more. [5]
However, there is another level in this issue, the performance of
urb->giveback (pwc_isoc_handler()) itself. It takes 350us for the
handler to be executed that seems to be too much to copy 9560 bytes of
the data from urb->transmit_buffer to internal pwc data structures.
Using trace event points I measured exact timings in two cases. [6]
The median memcpy() performance is 28 MBps. Given CPU frequency at
lowest possible state in 'ondemand' cpufreq policy, it roughly equals
to 10 CPU cycles per byte. Reverting commit
63c5b4ca7d0d ("usb: musb: do not change dev's dma_mask")
raises the rate to 280 MBps (~ 1 cycle per byte) and fully fixes the
issue when PIO in musb is used.
The reason is the following. pwc uses usb_alloc_coherent() to allocate
memory for urb->transfer_buffer. It seems to be a common practice
among webcam drivers: uvc, gspca and others do the same, though it is
not clear what is the reason to use so strict requirement as full
coherence here. Internally, usb_alloc_coherent() does
dma_alloc_coherent() or kmalloc() (when dev->dma_mask is NULL). In
case of MUSB, usb_alloc_coherent() always behaves as
dma_alloc_coherent() (mind 63c5b4ca7d0d, dma_mask is always set). At
the same time AFAIU AM335x doesn't have truly coherent DMA and it is
emulated in the kernel by pgprot nocache flags in the pages table. So,
we always have uncacheable (slow) memory for urb->transfer_buffer.
In conclusion, I think there is possibility to fix the issue (because
there are known cases when things work), though the way is not clear
to me. memcpy() is "slow" for uncacheable memory (not sure that
something can be done with it). usb_alloc_coherent() is probably
misused in pwc and a number of USB peripherial drivers. musb_host_rx()
interrupt handler performs less important things (urb->giveback) prior
to more important (writing MUSB_RXCSR_H_REQPKT).
References:
[1] https://www.spinics.net/lists/linux-usb/msg143956.html
[2] https://www.spinics.net/lists/linux-usb/msg145747.html
[3] http://openvizsla.org/
[4] https://www.spinics.net/lists/linux-usb/msg156107.html
[5] https://www.spinics.net/lists/linux-usb/msg156486.html
[6]
https://github.com/matwey/linux/commit/2b36e1add5aaf552923c8c1340e50bd7c2050fde
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
Re: musb: isoc pkt loss with pwc
aa 8e 52 a5 2b 6c fa 50 ca a4 76
a0 54 b4 9b 47 ad 1d 22 b5 12 1c 95 4d a2 84 43 b9 0d a2 74 15 45 05
41 49 b2 28 94 66 d1 a8 46 a0 94 6a a4 6c da 1e ba 94 4a b5 01 55 6d
8a aa 1c ab d2 96 55 c5 36 41 d4 87 1a 5b 3c Unexpected ERR CRC
[] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5
[] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00 00
[] 7.223456 d= 0.000997 [185.0 + 3.667] [ 3] IN : 4.5
[] 7.223459 d= 0.03 [185.0 + 7.000] [ 3] DATA0: 00 00
[] 7.224456 d= 0.000997 [186 + 3.583] [ 3] IN : 4.5
[] 7.224459 d= 0.03 [186 + 6.917] [ 3] DATA0: 00 00
[] 7.225456 d= 0.000997 [187.0 + 3.667] [ 3] IN : 4.5
[] 7.225459 d= 0.03 [187.0 + 7.000] [ 3] DATA0: 00 00
Here, I believe that IN request is missed at 7.221 and this leads to
the issues with missed data.
2016-08-28 13:13 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
> Hello Bin,
>
> I would like to start new thread on my issue. Let me recall where the issue
> is:
> There is 100% frame lost in pwc webcam driver due to lots of
> zero-length packages coming from musb driver.
> The issue is present in all kernels (including 4.8) starting from the commit:
>
> f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
> musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
>
> The issue is here both when DMA enabled and DMA disabled.
>
> Attached here is a plot. The vertical axis designates the value of
> rx_count variable from function musb_host_packet_rx(). One may see
> that there are only two possibilities: 0 bytes and 956 bytes.
> The horizontal axis is the last three digits of the timestamp when
> musb_host_packet_rx() invoked. I.e for [ 38.115379] it is 379. Given
> that my webcam is USB 1.1 and base time is 1 ms, then all frames
> should be grouped close to some single value. (Repeating package
> receive event every 1 ms won't change last tree digits considerably)
> One may see that it is not true, in practice there are two groups. And
> receive time strongly correlates with the package size. Packages
> received near round ms are 956 bytes long, packages received near 400
> us are 0 bytes long.
>
> I don't know how exactly SOF and IN are synchronized in musb, could
> someone give a hint? But from what I see the time difference between
> subsequent IN package requests is sometimes more than 1 ms due to
> heavy urb->complete() callback. After such events only zero length
> packages are received. Surprisingly, that `synchronization' is
> recovered sometimes in the middle of URB like the following:
>
> [ 163.207363] musb int
> [ 163.207380] rx_count 0
> [ 163.207393] req pkt c9c76200 // Expected musb int at 163.208393
> [ 163.207403] int end
> // No interrupt at 163.208393
> [ 163.209001] musb int
> [ 163.209017] rx_count 956
> [ 163.209108] req pkt c9c76200
> [ 163.209118] int end
>
> And then the series of 956 bytes long packages are received until URB
> giveback will occasionally break it again.
> Do I understand correctly, that SOF is generated every 1 ms by
> hardware and should be followed by IN immediately?
> If so, it is not clear to me how they should be aligned when the time
> difference between to subsequent INs is greater than 1ms.
>
> --
> 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
119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
Re: musb: isoc pkt loss with pwc
2016-11-01 23:33 GMT+03:00 Bin Liu <b-...@ti.com>: > On Sat, Oct 15, 2016 at 10:25:42PM +0300, Matwey V. Kornilov wrote: > > [snip] > >> >>> > Which means without this commit your camera has been working without >> >>> > issues, and this is a regression with this commit, right? >> >>> > >> >>> >> >>> Right >> >> >> >> Okay, thanks for confirming. >> >> >> >> But we cannot just simply add this flag, as it breaks many other use >> >> cases. I will continue work on this to find a solution which works on >> >> all use cases. >> >> >> > >> > Ok, thank you. >> > >> >> Excuse me. Any news? > > Not solved yet. I used uvc class to exam the issue. uvc_video driver > takes longer time to execute urb complete() on my platform. Using HCD_BH > flag doesn't help, because urb->complete() was running with irq disabled > because of the local_irq. Removing the local_irq as in [1] causes the > system to lockup - uart and network stop responsing, so hard to debug > for now. > > Right now, I added a workqueue in musb_host to handle urb->complete() > with local_irq removed. It seems working fine in my test, but it is > still a long way find the proper fix for upstream. I didn't have much > time on this issue. > > Once I have a proper solution, I will post it to the mailing list. > Maybe I could help somehow? > [1] http://marc.info/?l=linux-usb=147560701431267=2 > > 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: musb: isoc pkt loss with pwc
2016-09-12 22:38 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
> 2016-09-12 21:57 GMT+03:00 Bin Liu <b-...@ti.com>:
>> Hi,
>>
>> On Mon, Sep 12, 2016 at 11:52:46AM +0300, Matwey V. Kornilov wrote:
>>> 2016-09-12 6:28 GMT+03:00 Bin Liu <b-...@ti.com>:
>>> > Hi,
>>> >
>>> > On Tue, Aug 30, 2016 at 11:44:33PM +0300, Matwey V. Kornilov wrote:
>>> >> 2016-08-30 21:30 GMT+03:00 Bin Liu <b-...@ti.com>:
>>> >> > Hi,
>>> >> >
>>> >> > On Sun, Aug 28, 2016 at 01:13:55PM +0300, Matwey V. Kornilov wrote:
>>> >> >> Hello Bin,
>>> >> >>
>>> >> >> I would like to start new thread on my issue. Let me recall where the
>>> >> >> issue is:
>>> >> >> There is 100% frame lost in pwc webcam driver due to lots of
>>> >> >> zero-length packages coming from musb driver.
>>> >> >
>>> >> > What is the video resolution and fps?
>>> >>
>>> >> 640x480 YUV420 10 frames per second.
>>> >> pwc uses proprietary compression during device-host transmission, but
>>> >> I don't know how effective it is.
>>> >
>>> > The data rate for VGA YUV420 @10fps is 640x480*1.5*10 = 4.6MB/s, which
>>> > is much higher than full-speed 12Mbps. So the video data on the bus is
>>> > compressed, not YUV420, I believe.
>>> >
>>> >>
>>> >> >
>>> >> >> The issue is present in all kernels (including 4.8) starting from the
>>> >> >> commit:
>>> >> >>
>>> >> >> f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
>>> >> >> musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
>>> >> >
>>> >> > What is the behavior without this commit?
>>> >>
>>> >> Without this commit all frames are being received correctly. Single
>>> >
>>> > Which means without this commit your camera has been working without
>>> > issues, and this is a regression with this commit, right?
>>> >
>>>
>>> Right
>>
>> Okay, thanks for confirming.
>>
>> But we cannot just simply add this flag, as it breaks many other use
>> cases. I will continue work on this to find a solution which works on
>> all use cases.
>>
>
> Ok, thank you.
>
Excuse me. Any news?
>> Regards,
>> -Bin.
>>
>
>
>
> --
> With best regards,
> Matwey V. Kornilov.
> Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
> 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb: isoc pkt loss with pwc
2016-09-12 21:57 GMT+03:00 Bin Liu <b-...@ti.com>:
> Hi,
>
> On Mon, Sep 12, 2016 at 11:52:46AM +0300, Matwey V. Kornilov wrote:
>> 2016-09-12 6:28 GMT+03:00 Bin Liu <b-...@ti.com>:
>> > Hi,
>> >
>> > On Tue, Aug 30, 2016 at 11:44:33PM +0300, Matwey V. Kornilov wrote:
>> >> 2016-08-30 21:30 GMT+03:00 Bin Liu <b-...@ti.com>:
>> >> > Hi,
>> >> >
>> >> > On Sun, Aug 28, 2016 at 01:13:55PM +0300, Matwey V. Kornilov wrote:
>> >> >> Hello Bin,
>> >> >>
>> >> >> I would like to start new thread on my issue. Let me recall where the
>> >> >> issue is:
>> >> >> There is 100% frame lost in pwc webcam driver due to lots of
>> >> >> zero-length packages coming from musb driver.
>> >> >
>> >> > What is the video resolution and fps?
>> >>
>> >> 640x480 YUV420 10 frames per second.
>> >> pwc uses proprietary compression during device-host transmission, but
>> >> I don't know how effective it is.
>> >
>> > The data rate for VGA YUV420 @10fps is 640x480*1.5*10 = 4.6MB/s, which
>> > is much higher than full-speed 12Mbps. So the video data on the bus is
>> > compressed, not YUV420, I believe.
>> >
>> >>
>> >> >
>> >> >> The issue is present in all kernels (including 4.8) starting from the
>> >> >> commit:
>> >> >>
>> >> >> f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
>> >> >> musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
>> >> >
>> >> > What is the behavior without this commit?
>> >>
>> >> Without this commit all frames are being received correctly. Single
>> >
>> > Which means without this commit your camera has been working without
>> > issues, and this is a regression with this commit, right?
>> >
>>
>> Right
>
> Okay, thanks for confirming.
>
> But we cannot just simply add this flag, as it breaks many other use
> cases. I will continue work on this to find a solution which works on
> all use cases.
>
Ok, thank you.
> 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: musb: isoc pkt loss with pwc
2016-09-12 6:28 GMT+03:00 Bin Liu <b-...@ti.com>:
> Hi,
>
> On Tue, Aug 30, 2016 at 11:44:33PM +0300, Matwey V. Kornilov wrote:
>> 2016-08-30 21:30 GMT+03:00 Bin Liu <b-...@ti.com>:
>> > Hi,
>> >
>> > On Sun, Aug 28, 2016 at 01:13:55PM +0300, Matwey V. Kornilov wrote:
>> >> Hello Bin,
>> >>
>> >> I would like to start new thread on my issue. Let me recall where the
>> >> issue is:
>> >> There is 100% frame lost in pwc webcam driver due to lots of
>> >> zero-length packages coming from musb driver.
>> >
>> > What is the video resolution and fps?
>>
>> 640x480 YUV420 10 frames per second.
>> pwc uses proprietary compression during device-host transmission, but
>> I don't know how effective it is.
>
> The data rate for VGA YUV420 @10fps is 640x480*1.5*10 = 4.6MB/s, which
> is much higher than full-speed 12Mbps. So the video data on the bus is
> compressed, not YUV420, I believe.
>
>>
>> >
>> >> The issue is present in all kernels (including 4.8) starting from the
>> >> commit:
>> >>
>> >> f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
>> >> musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
>> >
>> > What is the behavior without this commit?
>>
>> Without this commit all frames are being received correctly. Single
>
> Which means without this commit your camera has been working without
> issues, and this is a regression with this commit, right?
>
Right
>> one issue is a number of zero byte package at the beginning of iso
>> stream (probably during camera internal sync, I have to check how the
>> stream is started on x86 later). But they are never repeated after
>> this.
>
> I think this zero byte packet is normal. I don't know much about pwc,
> but with uvc cameras, the beginning of the stream is similar, with many
> 12-bytes packets. 12 byte is typical uvc header length, so 12-byte
> packet means zero data payload.
>
>>
>> >>
>> >> The issue is here both when DMA enabled and DMA disabled.
>> >>
>> >> Attached here is a plot. The vertical axis designates the value of
>> >> rx_count variable from function musb_host_packet_rx(). One may see
>> >> that there are only two possibilities: 0 bytes and 956 bytes.
>> >> The horizontal axis is the last three digits of the timestamp when
>> >> musb_host_packet_rx() invoked. I.e for [ 38.115379] it is 379. Given
>> >> that my webcam is USB 1.1 and base time is 1 ms, then all frames
>> >> should be grouped close to some single value. (Repeating package
>> >> receive event every 1 ms won't change last tree digits considerably)
>> >> One may see that it is not true, in practice there are two groups. And
>> >> receive time strongly correlates with the package size. Packages
>> >> received near round ms are 956 bytes long, packages received near 400
>> >> us are 0 bytes long.
>> >
>> > When the host IN packet passed the deadline, the device drops the video
>> > data, so device only sends 0 byte packet (or 12 bytes which is only the
>> > uvc header without data payload).
>>
>> Doesn't it mean that free part of the frame, i.e (1 msec - (t_IN -
>> t_SOF)) is not enough to transmit 956 bytes in device firmware
>> opinion?
>>
>> >
>> >>
>> >> I don't know how exactly SOF and IN are synchronized in musb, could
>> >> someone give a hint? But from what I see the time difference between
>> >> subsequent IN package requests is sometimes more than 1 ms due to
>> >> heavy urb->complete() callback. After such events only zero length
>> >
>> > Why musb delayed the IN packets, it needs to be investigated. I will
>> > start to look at this webcam issue with musb soon, after I cleaned up
>> > the musb patches queued recently. I will update once I have progress in
>> > my investigation.
>>
>> The last package in URB has different code path.
>> IN after the last package of URB is not requested in musb_host_packet_rx().
>> Instead, IN request is performed in the end of musb_advance_schedule()
>> by musb_start_urb().
>
> I am seeing the samilar issue with my Logitech pro9000 camera, and I
> have been looking at it whenever I got some time.
>
> I believe the IN after the last packet is coming from a new URB, that is
> why it is performed by musb_start_urb().
>
>> musb_advance_sched
Re: musb: isoc pkt loss with pwc
2016-08-30 21:30 GMT+03:00 Bin Liu <b-...@ti.com>:
> Hi,
>
> On Sun, Aug 28, 2016 at 01:13:55PM +0300, Matwey V. Kornilov wrote:
>> Hello Bin,
>>
>> I would like to start new thread on my issue. Let me recall where the issue
>> is:
>> There is 100% frame lost in pwc webcam driver due to lots of
>> zero-length packages coming from musb driver.
>
> What is the video resolution and fps?
640x480 YUV420 10 frames per second.
pwc uses proprietary compression during device-host transmission, but
I don't know how effective it is.
>
>> The issue is present in all kernels (including 4.8) starting from the commit:
>>
>> f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
>> musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
>
> What is the behavior without this commit?
Without this commit all frames are being received correctly. Single
one issue is a number of zero byte package at the beginning of iso
stream (probably during camera internal sync, I have to check how the
stream is started on x86 later). But they are never repeated after
this.
>>
>> The issue is here both when DMA enabled and DMA disabled.
>>
>> Attached here is a plot. The vertical axis designates the value of
>> rx_count variable from function musb_host_packet_rx(). One may see
>> that there are only two possibilities: 0 bytes and 956 bytes.
>> The horizontal axis is the last three digits of the timestamp when
>> musb_host_packet_rx() invoked. I.e for [ 38.115379] it is 379. Given
>> that my webcam is USB 1.1 and base time is 1 ms, then all frames
>> should be grouped close to some single value. (Repeating package
>> receive event every 1 ms won't change last tree digits considerably)
>> One may see that it is not true, in practice there are two groups. And
>> receive time strongly correlates with the package size. Packages
>> received near round ms are 956 bytes long, packages received near 400
>> us are 0 bytes long.
>
> When the host IN packet passed the deadline, the device drops the video
> data, so device only sends 0 byte packet (or 12 bytes which is only the
> uvc header without data payload).
Doesn't it mean that free part of the frame, i.e (1 msec - (t_IN -
t_SOF)) is not enough to transmit 956 bytes in device firmware
opinion?
>
>>
>> I don't know how exactly SOF and IN are synchronized in musb, could
>> someone give a hint? But from what I see the time difference between
>> subsequent IN package requests is sometimes more than 1 ms due to
>> heavy urb->complete() callback. After such events only zero length
>
> Why musb delayed the IN packets, it needs to be investigated. I will
> start to look at this webcam issue with musb soon, after I cleaned up
> the musb patches queued recently. I will update once I have progress in
> my investigation.
The last package in URB has different code path.
IN after the last package of URB is not requested in musb_host_packet_rx().
Instead, IN request is performed in the end of musb_advance_schedule()
by musb_start_urb().
musb_advance_schedule() has the following code:
qh->is_ready = 0;
musb_giveback(musb, urb, status);
qh->is_ready = ready;
Which can be executed pretty long if urb->complete() handler is not
postphoned by HCD_BH.
In my case, it takes about 300 us for pwc urb->complete() to run.
Probably, the logic should be modified here, to run giveback on
current URB after the start of next URB.
>
>> packages are received. Surprisingly, that `synchronization' is
>> recovered sometimes in the middle of URB like the following:
>>
>> [ 163.207363] musb int
>> [ 163.207380] rx_count 0
>> [ 163.207393] req pkt c9c76200 // Expected musb int at 163.208393
>> [ 163.207403] int end
>> // No interrupt at 163.208393
>> [ 163.209001] musb int
>> [ 163.209017] rx_count 956
>> [ 163.209108] req pkt c9c76200
>> [ 163.209118] int end
>
> It looks like you used plain printk for these debug logs, which normally
> is not a good idea for this type of performance debugging. printk
> changes timing especially if the log is printed via uart console.
>
I think next time I will use tracepoints or something like that. Thank
you for pointing.
>> And then the series of 956 bytes long packages are received until URB
>> giveback will occasionally break it again.
>> Do I understand correctly, that SOF is generated every 1 ms by
>> hardware and should be followed by IN immediately?
>
> My understanding is that is does not have to be 'immediately', for
> example, in a few ns, it should be okay as long as the interval of IN
> packets is fixed, but I forgot what the to
musb: isoc pkt loss with pwc
Hello Bin,
I would like to start new thread on my issue. Let me recall where the issue is:
There is 100% frame lost in pwc webcam driver due to lots of
zero-length packages coming from musb driver.
The issue is present in all kernels (including 4.8) starting from the commit:
f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
The issue is here both when DMA enabled and DMA disabled.
Attached here is a plot. The vertical axis designates the value of
rx_count variable from function musb_host_packet_rx(). One may see
that there are only two possibilities: 0 bytes and 956 bytes.
The horizontal axis is the last three digits of the timestamp when
musb_host_packet_rx() invoked. I.e for [ 38.115379] it is 379. Given
that my webcam is USB 1.1 and base time is 1 ms, then all frames
should be grouped close to some single value. (Repeating package
receive event every 1 ms won't change last tree digits considerably)
One may see that it is not true, in practice there are two groups. And
receive time strongly correlates with the package size. Packages
received near round ms are 956 bytes long, packages received near 400
us are 0 bytes long.
I don't know how exactly SOF and IN are synchronized in musb, could
someone give a hint? But from what I see the time difference between
subsequent IN package requests is sometimes more than 1 ms due to
heavy urb->complete() callback. After such events only zero length
packages are received. Surprisingly, that `synchronization' is
recovered sometimes in the middle of URB like the following:
[ 163.207363] musb int
[ 163.207380] rx_count 0
[ 163.207393] req pkt c9c76200 // Expected musb int at 163.208393
[ 163.207403] int end
// No interrupt at 163.208393
[ 163.209001] musb int
[ 163.209017] rx_count 956
[ 163.209108] req pkt c9c76200
[ 163.209118] int end
And then the series of 956 bytes long packages are received until URB
giveback will occasionally break it again.
Do I understand correctly, that SOF is generated every 1 ms by
hardware and should be followed by IN immediately?
If so, it is not clear to me how they should be aligned when the time
difference between to subsequent INs is greater than 1ms.
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
Rplots.pdf
Description: Adobe PDF document
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-08-22 11:32 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: > 2016-08-22 1:00 GMT+03:00 Alan Stern <st...@rowland.harvard.edu>: >> On Sun, 21 Aug 2016, Matwey V. Kornilov wrote: >> >>> In both cases (with or without HCD_BH), usb_hcd_giveback_urb is called >>> every 0.01 sec. It is not clear why behavior is so different. >> >> What behavior are you asking about? The difference between HCD_BH set >> and not set? >> > > The difference between HCD_BH set and not set is that when it is not > set then usb_hcd_giveback_urb() receive zero-length URBs. And this > breaks my pwc webcam. And the question is how to fix it. > As far as I can see, usb_hcd_giveback_urb is being called with the > same rate in both cases, so zero-length URBs are probably supposed to > be data-carrying. > I can't understand what makes the difference. What I found to this moment is the following: 1) isoc transfer works in two empirical modes or regimes. I called them 'normal' one and 'broken'. 1a) In the 'normal' mode, every package is 956 bytes long and c->desc->pd2 (see cppi41_irq) is 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
2016-08-22 1:00 GMT+03:00 Alan Stern <st...@rowland.harvard.edu>: > On Sun, 21 Aug 2016, Matwey V. Kornilov wrote: > >> In both cases (with or without HCD_BH), usb_hcd_giveback_urb is called >> every 0.01 sec. It is not clear why behavior is so different. > > What behavior are you asking about? The difference between HCD_BH set > and not set? > The difference between HCD_BH set and not set is that when it is not set then usb_hcd_giveback_urb() receive zero-length URBs. And this breaks my pwc webcam. And the question is how to fix it. As far as I can see, usb_hcd_giveback_urb is being called with the same rate in both cases, so zero-length URBs are probably supposed to be data-carrying. > Alan Stern > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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
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 <mat...@sai.msu.ru>:
> I've just measured that
>
> it takes 150 us in average for pwc_isoc_handler to run
> 350 us - __usb_hcd_giveback_urb
>
> So, it takes either 50 us (with HCD_BH) or 400 us (without) for
> usb_hcd_giveback_urb to run.
>
>
> 2016-08-20 21:09 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>> I've just checked 4.8-rc2 - same behaviour.
>>
>> 2016-08-18 16:31 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>> Any ideas?
>>>
>>> 2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>> When DMA is not used, I see the same behavior: lots of zero-length
>>>> packages received.
>>>>
>>>> Can It be related to some kind of USB overflow due to long input data
>>>> processing with disabled IRQ?
>>>> When HCD_BC is used then part of processing is postponed and this can
>>>> explain greater throughput due to better latency.
>>>>
>>>> 2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>>> I've just found that in such cases, when DMA actual length is zero,
>>>>> both cppi41_channel->prog_len and txstate.residue equal 960 at
>>>>> musb_cppi41 line 225:
>>>>>
>>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>>>>>
>>>>> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>>>> I've just found that dma->actual_len equals to zero in most cases at
>>>>>> musb_host.c line 1946.
>>>>>> And this produces zero-length packages.
>>>>>>
>>>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>>>>>
>>>>>> Any ideas why?
>>>>>>
>>>>>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>>>>> I've just found that many packages in URBs have zero actual_length (It
>>>>>>> is a question why).
>>>>>>> Then the following end of frame criteria leads to `frame underflow'
>>>>>>> message:
>>>>>>>
>>>>>>> if (flen < pdev->vlast_packet_size) {
>>>>>>> /* Shorter packet... end of frame */
>>>>>>> if (pdev->vsync == 2)
>>>>>>> pwc_frame_complete(pdev);
>>>>>>> if (pdev->fill_buf == NULL)
>>>>>>> pdev->fill_buf =
>>>>>>> pwc_get_next_fill_buf(pdev);
>>>>>>> if (pdev->fill_buf) {
>>>>>>> pdev->fill_buf->filled = 0;
>>>>>>> pdev->vsync = 1;
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>>>>>> pwc module output with trace=511 is the following:
>>>>>>>>
>>>>>>>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>>>>>>>> [ 29.276979] pwc: Unsupported pixel format
>>>>>>>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>>>>>>>> fps=15 format=YU12
>>>>>>>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>>>>>> [ 29.277145] pwc: decode_size = 5.
>>>>>>>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5,
>>>>>>>> vbandlength=526
>>>>>>>> [ 29.277204] pwc: Set resolution to 640x480
>>>>>>>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>>>>>>>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>>> bytes
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
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 <mat...@sai.msu.ru>:
> I've just checked 4.8-rc2 - same behaviour.
>
> 2016-08-18 16:31 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>> Any ideas?
>>
>> 2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>> When DMA is not used, I see the same behavior: lots of zero-length
>>> packages received.
>>>
>>> Can It be related to some kind of USB overflow due to long input data
>>> processing with disabled IRQ?
>>> When HCD_BC is used then part of processing is postponed and this can
>>> explain greater throughput due to better latency.
>>>
>>> 2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>> I've just found that in such cases, when DMA actual length is zero,
>>>> both cppi41_channel->prog_len and txstate.residue equal 960 at
>>>> musb_cppi41 line 225:
>>>>
>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>>>>
>>>> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>>> I've just found that dma->actual_len equals to zero in most cases at
>>>>> musb_host.c line 1946.
>>>>> And this produces zero-length packages.
>>>>>
>>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>>>>
>>>>> Any ideas why?
>>>>>
>>>>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>>>> I've just found that many packages in URBs have zero actual_length (It
>>>>>> is a question why).
>>>>>> Then the following end of frame criteria leads to `frame underflow'
>>>>>> message:
>>>>>>
>>>>>> if (flen < pdev->vlast_packet_size) {
>>>>>> /* Shorter packet... end of frame */
>>>>>> if (pdev->vsync == 2)
>>>>>> pwc_frame_complete(pdev);
>>>>>> if (pdev->fill_buf == NULL)
>>>>>> pdev->fill_buf =
>>>>>> pwc_get_next_fill_buf(pdev);
>>>>>> if (pdev->fill_buf) {
>>>>>> pdev->fill_buf->filled = 0;
>>>>>> pdev->vsync = 1;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>>>>> pwc module output with trace=511 is the following:
>>>>>>>
>>>>>>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>>>>>>> [ 29.276979] pwc: Unsupported pixel format
>>>>>>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>>>>>>> fps=15 format=YU12
>>>>>>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>>>>> [ 29.277145] pwc: decode_size = 5.
>>>>>>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5,
>>>>>>> vbandlength=526
>>>>>>> [ 29.277204] pwc: Set resolution to 640x480
>>>>>>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>>>>>>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>>>>> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>>> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>>>> [ 29.277475] pwc: decode_size = 5.
>>>>>>> [ 29.278726] p
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
I've just checked 4.8-rc2 - same behaviour.
2016-08-18 16:31 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
> Any ideas?
>
> 2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>> When DMA is not used, I see the same behavior: lots of zero-length
>> packages received.
>>
>> Can It be related to some kind of USB overflow due to long input data
>> processing with disabled IRQ?
>> When HCD_BC is used then part of processing is postponed and this can
>> explain greater throughput due to better latency.
>>
>> 2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>> I've just found that in such cases, when DMA actual length is zero,
>>> both cppi41_channel->prog_len and txstate.residue equal 960 at
>>> musb_cppi41 line 225:
>>>
>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>>>
>>> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>> I've just found that dma->actual_len equals to zero in most cases at
>>>> musb_host.c line 1946.
>>>> And this produces zero-length packages.
>>>>
>>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>>>
>>>> Any ideas why?
>>>>
>>>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>>> I've just found that many packages in URBs have zero actual_length (It
>>>>> is a question why).
>>>>> Then the following end of frame criteria leads to `frame underflow'
>>>>> message:
>>>>>
>>>>> if (flen < pdev->vlast_packet_size) {
>>>>> /* Shorter packet... end of frame */
>>>>> if (pdev->vsync == 2)
>>>>> pwc_frame_complete(pdev);
>>>>> if (pdev->fill_buf == NULL)
>>>>> pdev->fill_buf =
>>>>> pwc_get_next_fill_buf(pdev);
>>>>> if (pdev->fill_buf) {
>>>>> pdev->fill_buf->filled = 0;
>>>>> pdev->vsync = 1;
>>>>> }
>>>>> }
>>>>>
>>>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>>>> pwc module output with trace=511 is the following:
>>>>>>
>>>>>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>>>>>> [ 29.276979] pwc: Unsupported pixel format
>>>>>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>>>>>> fps=15 format=YU12
>>>>>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>>>> [ 29.277145] pwc: decode_size = 5.
>>>>>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5,
>>>>>> vbandlength=526
>>>>>> [ 29.277204] pwc: Set resolution to 640x480
>>>>>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>>>>>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>>>> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>>> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>>> [ 29.277475] pwc: decode_size = 5.
>>>>>> [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5,
>>>>>> vbandlength=788
>>>>>> [ 29.278750] pwc: Set resolution to 640x480
>>>>>> [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>>> [ 29.300420] pwc: decode_size = 5.
>>>>>> [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5,
>>>>>> vbandlength=788
>>>>>> [ 29.441792] pwc: Set resolution to 640x480
>>>>>> [ 29.441824] pwc: Setting alternate interface 9
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
Any ideas?
2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
> When DMA is not used, I see the same behavior: lots of zero-length
> packages received.
>
> Can It be related to some kind of USB overflow due to long input data
> processing with disabled IRQ?
> When HCD_BC is used then part of processing is postponed and this can
> explain greater throughput due to better latency.
>
> 2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>> I've just found that in such cases, when DMA actual length is zero,
>> both cppi41_channel->prog_len and txstate.residue equal 960 at
>> musb_cppi41 line 225:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>>
>> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>> I've just found that dma->actual_len equals to zero in most cases at
>>> musb_host.c line 1946.
>>> And this produces zero-length packages.
>>>
>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>>
>>> Any ideas why?
>>>
>>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>> I've just found that many packages in URBs have zero actual_length (It
>>>> is a question why).
>>>> Then the following end of frame criteria leads to `frame underflow'
>>>> message:
>>>>
>>>> if (flen < pdev->vlast_packet_size) {
>>>> /* Shorter packet... end of frame */
>>>> if (pdev->vsync == 2)
>>>> pwc_frame_complete(pdev);
>>>> if (pdev->fill_buf == NULL)
>>>> pdev->fill_buf =
>>>> pwc_get_next_fill_buf(pdev);
>>>> if (pdev->fill_buf) {
>>>> pdev->fill_buf->filled = 0;
>>>> pdev->vsync = 1;
>>>> }
>>>> }
>>>>
>>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>>> pwc module output with trace=511 is the following:
>>>>>
>>>>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>>>>> [ 29.276979] pwc: Unsupported pixel format
>>>>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>>>>> fps=15 format=YU12
>>>>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>>> [ 29.277145] pwc: decode_size = 5.
>>>>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>>>>> [ 29.277204] pwc: Set resolution to 640x480
>>>>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>>>>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>>> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>>> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>> [ 29.277475] pwc: decode_size = 5.
>>>>> [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>>> [ 29.278750] pwc: Set resolution to 640x480
>>>>> [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>>> [ 29.300420] pwc: decode_size = 5.
>>>>> [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>>> [ 29.441792] pwc: Set resolution to 640x480
>>>>> [ 29.441824] pwc: Setting alternate interface 9
>>>>> [ 29.455061] pwc: Allocated URB at 0xc9b83600
>>>>> [ 29.455850] pwc: Allocated URB at 0xc9b83400
>>>>> [ 29.456040] pwc: Allocated URB at 0xc9b83200
>>>>> [ 29.456271] pwc: URB 0xc9b83600 submitted.
>>>>> [ 29.456310] pwc: URB 0xc9b83400 submitted.
>>>>> [ 29.456341] pwc: URB 0xc9b83200 submitted.
>>>>> [ 29.456362] pwc: << pwc_isoc_init()
>>>>
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
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 <mat...@sai.msu.ru>:
> I've just found that in such cases, when DMA actual length is zero,
> both cppi41_channel->prog_len and txstate.residue equal 960 at
> musb_cppi41 line 225:
>
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225
>
> 2016-08-04 22:08 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>> I've just found that dma->actual_len equals to zero in most cases at
>> musb_host.c line 1946.
>> And this produces zero-length packages.
>>
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>>
>> Any ideas why?
>>
>> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>> I've just found that many packages in URBs have zero actual_length (It
>>> is a question why).
>>> Then the following end of frame criteria leads to `frame underflow' message:
>>>
>>> if (flen < pdev->vlast_packet_size) {
>>> /* Shorter packet... end of frame */
>>> if (pdev->vsync == 2)
>>> pwc_frame_complete(pdev);
>>> if (pdev->fill_buf == NULL)
>>> pdev->fill_buf =
>>> pwc_get_next_fill_buf(pdev);
>>> if (pdev->fill_buf) {
>>> pdev->fill_buf->filled = 0;
>>> pdev->vsync = 1;
>>> }
>>> }
>>>
>>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>>> pwc module output with trace=511 is the following:
>>>>
>>>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>>>> [ 29.276979] pwc: Unsupported pixel format
>>>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>>>> fps=15 format=YU12
>>>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>>> [ 29.277145] pwc: decode_size = 5.
>>>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>>>> [ 29.277204] pwc: Set resolution to 640x480
>>>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>>>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>>> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>>> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>> [ 29.277475] pwc: decode_size = 5.
>>>> [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>> [ 29.278750] pwc: Set resolution to 640x480
>>>> [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>>> [ 29.300420] pwc: decode_size = 5.
>>>> [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>>> [ 29.441792] pwc: Set resolution to 640x480
>>>> [ 29.441824] pwc: Setting alternate interface 9
>>>> [ 29.455061] pwc: Allocated URB at 0xc9b83600
>>>> [ 29.455850] pwc: Allocated URB at 0xc9b83400
>>>> [ 29.456040] pwc: Allocated URB at 0xc9b83200
>>>> [ 29.456271] pwc: URB 0xc9b83600 submitted.
>>>> [ 29.456310] pwc: URB 0xc9b83400 submitted.
>>>> [ 29.456341] pwc: URB 0xc9b83200 submitted.
>>>> [ 29.456362] pwc: << pwc_isoc_init()
>>>> [ 30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>>>> [ 30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
>>>> [ 30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
>>>> [ 30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
>>>> [ 30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
>>&
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
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 <mat...@sai.msu.ru>:
> I've just found that dma->actual_len equals to zero in most cases at
> musb_host.c line 1946.
> And this produces zero-length packages.
>
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946
>
> Any ideas why?
>
> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>> I've just found that many packages in URBs have zero actual_length (It
>> is a question why).
>> Then the following end of frame criteria leads to `frame underflow' message:
>>
>> if (flen < pdev->vlast_packet_size) {
>> /* Shorter packet... end of frame */
>> if (pdev->vsync == 2)
>> pwc_frame_complete(pdev);
>> if (pdev->fill_buf == NULL)
>> pdev->fill_buf = pwc_get_next_fill_buf(pdev);
>> if (pdev->fill_buf) {
>> pdev->fill_buf->filled = 0;
>> pdev->vsync = 1;
>> }
>> }
>>
>> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>> pwc module output with trace=511 is the following:
>>>
>>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>>> [ 29.276979] pwc: Unsupported pixel format
>>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>>> fps=15 format=YU12
>>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>>> [ 29.277145] pwc: decode_size = 5.
>>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>>> [ 29.277204] pwc: Set resolution to 640x480
>>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>>> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>>> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>> [ 29.277475] pwc: decode_size = 5.
>>> [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>> [ 29.278750] pwc: Set resolution to 640x480
>>> [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>>> [ 29.300420] pwc: decode_size = 5.
>>> [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>>> [ 29.441792] pwc: Set resolution to 640x480
>>> [ 29.441824] pwc: Setting alternate interface 9
>>> [ 29.455061] pwc: Allocated URB at 0xc9b83600
>>> [ 29.455850] pwc: Allocated URB at 0xc9b83400
>>> [ 29.456040] pwc: Allocated URB at 0xc9b83200
>>> [ 29.456271] pwc: URB 0xc9b83600 submitted.
>>> [ 29.456310] pwc: URB 0xc9b83400 submitted.
>>> [ 29.456341] pwc: URB 0xc9b83200 submitted.
>>> [ 29.456362] pwc: << pwc_isoc_init()
>>> [ 30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>>> [ 30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
>>> [ 30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
>>> [ 30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
>>> [ 30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
>>> [ 30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
>>> [ 30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
>>> [ 30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
>>> [ 30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
>>> [ 30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
>>> [ 31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
>>> [ 31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
>>> [ 31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
>>> [ 31.374545] pwc: Frame buffe
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
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 <mat...@sai.msu.ru>:
> I've just found that many packages in URBs have zero actual_length (It
> is a question why).
> Then the following end of frame criteria leads to `frame underflow' message:
>
> if (flen < pdev->vlast_packet_size) {
> /* Shorter packet... end of frame */
> if (pdev->vsync == 2)
> pwc_frame_complete(pdev);
> if (pdev->fill_buf == NULL)
> pdev->fill_buf = pwc_get_next_fill_buf(pdev);
> if (pdev->fill_buf) {
> pdev->fill_buf->filled = 0;
> pdev->vsync = 1;
> }
> }
>
> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>> pwc module output with trace=511 is the following:
>>
>> [ 24.793109] usbcore: registered new interface driver Philips webcam
>> [ 29.276979] pwc: Unsupported pixel format
>> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>> [ 29.277090] pwc: Trying to set format to: width=640 height=480
>> fps=15 format=YU12
>> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
>> [ 29.277145] pwc: decode_size = 5.
>> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
>> [ 29.277204] pwc: Set resolution to 640x480
>> [ 29.277225] pwc: pwc_set_video_mode(), return=0
>> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
>> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
>> bytesperline=640, sizeimage=460800, pixelformat=YU12
>> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>> [ 29.277475] pwc: decode_size = 5.
>> [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>> [ 29.278750] pwc: Set resolution to 640x480
>> [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
>> [ 29.300420] pwc: decode_size = 5.
>> [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
>> [ 29.441792] pwc: Set resolution to 640x480
>> [ 29.441824] pwc: Setting alternate interface 9
>> [ 29.455061] pwc: Allocated URB at 0xc9b83600
>> [ 29.455850] pwc: Allocated URB at 0xc9b83400
>> [ 29.456040] pwc: Allocated URB at 0xc9b83200
>> [ 29.456271] pwc: URB 0xc9b83600 submitted.
>> [ 29.456310] pwc: URB 0xc9b83400 submitted.
>> [ 29.456341] pwc: URB 0xc9b83200 submitted.
>> [ 29.456362] pwc: << pwc_isoc_init()
>> [ 30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
>> [ 30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
>> [ 30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
>> [ 30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
>> [ 30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
>> [ 30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
>> [ 30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
>> [ 30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
>> [ 30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
>> [ 30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
>> [ 31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
>> [ 31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
>> [ 31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
>> [ 31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
>> [ 31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
>> [ 31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
>> [ 31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
>> [ 31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
>> [ 31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
>> [ 31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.
>>
>>
>> 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>> Hello,
>&
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
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 <mat...@sai.msu.ru>:
> pwc module output with trace=511 is the following:
>
> [ 24.793109] usbcore: registered new interface driver Philips webcam
> [ 29.276979] pwc: Unsupported pixel format
> [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
> bytesperline=640, sizeimage=460800, pixelformat=YU12
> [ 29.277090] pwc: Trying to set format to: width=640 height=480
> fps=15 format=YU12
> [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
> [ 29.277145] pwc: decode_size = 5.
> [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
> [ 29.277204] pwc: Set resolution to 640x480
> [ 29.277225] pwc: pwc_set_video_mode(), return=0
> [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
> bytesperline=640, sizeimage=460800, pixelformat=YU12
> [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
> [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
> bytesperline=640, sizeimage=460800, pixelformat=YU12
> [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
> [ 29.277475] pwc: decode_size = 5.
> [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
> [ 29.278750] pwc: Set resolution to 640x480
> [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
> [ 29.300420] pwc: decode_size = 5.
> [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
> [ 29.441792] pwc: Set resolution to 640x480
> [ 29.441824] pwc: Setting alternate interface 9
> [ 29.455061] pwc: Allocated URB at 0xc9b83600
> [ 29.455850] pwc: Allocated URB at 0xc9b83400
> [ 29.456040] pwc: Allocated URB at 0xc9b83200
> [ 29.456271] pwc: URB 0xc9b83600 submitted.
> [ 29.456310] pwc: URB 0xc9b83400 submitted.
> [ 29.456341] pwc: URB 0xc9b83200 submitted.
> [ 29.456362] pwc: << pwc_isoc_init()
> [ 30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
> [ 30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
> [ 30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
> [ 30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
> [ 30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
> [ 30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
> [ 30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
> [ 30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
> [ 30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
> [ 30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
> [ 31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
> [ 31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
> [ 31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
> [ 31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
> [ 31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
> [ 31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
> [ 31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
> [ 31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
> [ 31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
> [ 31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.
>
>
> 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>> Hello,
>>
>> I've also just found that the same commit breaks cpufreq on BeagleBone Black
>> :)
>>
>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>> (as it did whet there was cpufreq driver).
>>
>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>>> Hello,
>>>
>>> I've found that the following commit fixes the issue:
>>>
>>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>>> Author: Viresh Kumar <viresh.ku...@lina
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-08-01 20:06 GMT+03:00 Viresh Kumar <viresh.ku...@linaro.org>: > On 01-08-16, 20:01, Matwey V. Kornilov wrote: >> With this patch, there is no cpufreq directory here. >> >> Without this patch, the output is the following: >> >> nohostname:~ # uname -a >> Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15 >> 08:08:50 UTC 2016 (ecd9058) armv7l armv7l armv7l GNU/Linux >> nohostname:~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver >> cpufreq-dt > > I hope that the below patch fixes it for you? > Yes, it is. Thank you. > [PATCH] cpufreq: am33xx: Use generic platdev driver > > -- > viresh > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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
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 <mat...@sai.msu.ru>: > Hello, > > I've also just found that the same commit breaks cpufreq on BeagleBone Black > :) > > So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU > frequency, which is unlisted and being set to 720Mhz by cpufreq driver > (as it did whet there was cpufreq driver). > > 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: >> Hello, >> >> I've found that the following commit fixes the issue: >> >> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063 >> Author: Viresh Kumar <viresh.ku...@linaro.org> >> Date: Fri Apr 22 16:58:42 2016 +0530 >> >> cpufreq: omap: Use generic platdev driver >> >> The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform >> device now, reuse that and remove similar code from platform code. >> >> >> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: >>> Hello, >>> >>> I've just bisected commit, which fixed the issue in v4.7 >>> >>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342 >>> Merge: f55532a febce40 >>> Author: Rafael J. Wysocki <rafael.j.wyso...@intel.com> >>> Date: Sat Apr 2 01:07:17 2016 +0200 >>> >>> Merge back intel_pstate fixes for v4.6. >>> >>> * pm-cpufreq: >>> intel_pstate: Avoid extra invocation of intel_pstate_sample() >>> intel_pstate: Do not set utilization update hook too early >>> >>> Unfortunately, intel_pstate branch doesn't have >>> f551e13529833e052f75ec628a8af7b034af20f9 applied. >>> I'll try to bi
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-08-01 19:50 GMT+03:00 Viresh Kumar <viresh.ku...@linaro.org>:
> On 31-07-16, 23:31, Matwey V. Kornilov wrote:
>> Hello,
>>
>> I've also just found that the same commit breaks cpufreq on BeagleBone Black
>> :)
>>
>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>> (as it did whet there was cpufreq driver).
>>
>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
>> > Hello,
>> >
>> > I've found that the following commit fixes the issue:
>> >
>> > commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>> > Author: Viresh Kumar <viresh.ku...@linaro.org>
>> > Date: Fri Apr 22 16:58:42 2016 +0530
>> >
>> > cpufreq: omap: Use generic platdev driver
>> >
>> > The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>> > device now, reuse that and remove similar code from platform code.
>
> Sorry for this commit and the man hours wasted to get to this :(
>
> I am trying to figure out why things break though, as this patch shouldn't
> have
> had any functional impacts. So, some of the assumptions I had are surely
> incorrect..
Actually, nothing to sorry about.
I suppose, that with this patch my BeagleBone run at 1Ghz after boot,
because usually cpufreq limits it to 720Mhz saying
[ 14.255646] cpu cpu0: dev_pm_opp_set_rate: failed to find current
OPP for freq 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
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 <mat...@sai.msu.ru>: > Hello, > > I've found that the following commit fixes the issue: > > commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063 > Author: Viresh Kumar <viresh.ku...@linaro.org> > Date: Fri Apr 22 16:58:42 2016 +0530 > > cpufreq: omap: Use generic platdev driver > > The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform > device now, reuse that and remove similar code from platform code. > > > 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: >> Hello, >> >> I've just bisected commit, which fixed the issue in v4.7 >> >> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342 >> Merge: f55532a febce40 >> Author: Rafael J. Wysocki <rafael.j.wyso...@intel.com> >> Date: Sat Apr 2 01:07:17 2016 +0200 >> >> Merge back intel_pstate fixes for v4.6. >> >> * pm-cpufreq: >> intel_pstate: Avoid extra invocation of intel_pstate_sample() >> intel_pstate: Do not set utilization update hook too early >> >> Unfortunately, intel_pstate branch doesn't have >> f551e13529833e052f75ec628a8af7b034af20f9 applied. >> I'll try to bisect this branch with the patch manually applied. >> >> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: >>> Hello, >>> >>> I've just biseced commit, which introduced this issue >>> >>> commit f551e13529833e052f75ec628a8af7b034af20f9 >>> Author: Bin Liu <b-...@ti.com> >>> Date: Mon Apr 25 15:53:30 2016 -0500 >>> >>> Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb >>> return in bottom half" >>> >>> I have not checked yet, if it was intentionnaly fixed. >>> >>> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: >>>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: >>>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-...@ti.com>: >>>>>> Hi, >>>>>> >>>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote: >>>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-...@ti.com>: >>>>>>> > Hi, >>>>>>> > >>>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote: >>>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-...@ti.com>: >>>>>>> >> > Hi, >>>>>>> >> > >>>>>>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote: >>>>>>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu <b-...@ti.com>: >>>>>>> >> >> > 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 >>>>>>> >>
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
Hello, I've found that the following commit fixes the issue: commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063 Author: Viresh Kumar <viresh.ku...@linaro.org> Date: Fri Apr 22 16:58:42 2016 +0530 cpufreq: omap: Use generic platdev driver The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform device now, reuse that and remove similar code from platform code. 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: > Hello, > > I've just bisected commit, which fixed the issue in v4.7 > > commit 9fa64d6424adabf0e3a546ae24d01a62a927b342 > Merge: f55532a febce40 > Author: Rafael J. Wysocki <rafael.j.wyso...@intel.com> > Date: Sat Apr 2 01:07:17 2016 +0200 > > Merge back intel_pstate fixes for v4.6. > > * pm-cpufreq: > intel_pstate: Avoid extra invocation of intel_pstate_sample() > intel_pstate: Do not set utilization update hook too early > > Unfortunately, intel_pstate branch doesn't have > f551e13529833e052f75ec628a8af7b034af20f9 applied. > I'll try to bisect this branch with the patch manually applied. > > 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: >> Hello, >> >> I've just biseced commit, which introduced this issue >> >> commit f551e13529833e052f75ec628a8af7b034af20f9 >> Author: Bin Liu <b-...@ti.com> >> Date: Mon Apr 25 15:53:30 2016 -0500 >> >> Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb >> return in bottom half" >> >> I have not checked yet, if it was intentionnaly fixed. >> >> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: >>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: >>>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-...@ti.com>: >>>>> Hi, >>>>> >>>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote: >>>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-...@ti.com>: >>>>>> > Hi, >>>>>> > >>>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote: >>>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-...@ti.com>: >>>>>> >> > Hi, >>>>>> >> > >>>>>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote: >>>>>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu <b-...@ti.com>: >>>>>> >> >> > 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; >
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
Hello, I've just bisected commit, which fixed the issue in v4.7 commit 9fa64d6424adabf0e3a546ae24d01a62a927b342 Merge: f55532a febce40 Author: Rafael J. Wysocki <rafael.j.wyso...@intel.com> Date: Sat Apr 2 01:07:17 2016 +0200 Merge back intel_pstate fixes for v4.6. * pm-cpufreq: intel_pstate: Avoid extra invocation of intel_pstate_sample() intel_pstate: Do not set utilization update hook too early Unfortunately, intel_pstate branch doesn't have f551e13529833e052f75ec628a8af7b034af20f9 applied. I'll try to bisect this branch with the patch manually applied. 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: > Hello, > > I've just biseced commit, which introduced this issue > > commit f551e13529833e052f75ec628a8af7b034af20f9 > Author: Bin Liu <b-...@ti.com> > Date: Mon Apr 25 15:53:30 2016 -0500 > > Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb > return in bottom half" > > I have not checked yet, if it was intentionnaly fixed. > > 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: >> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: >>> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-...@ti.com>: >>>> Hi, >>>> >>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote: >>>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-...@ti.com>: >>>>> > Hi, >>>>> > >>>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote: >>>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-...@ti.com>: >>>>> >> > Hi, >>>>> >> > >>>>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote: >>>>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu <b-...@ti.com>: >>>>> >> >> > 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.776
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
Hello, I've just biseced commit, which introduced this issue commit f551e13529833e052f75ec628a8af7b034af20f9 Author: Bin Liu <b-...@ti.com> Date: Mon Apr 25 15:53:30 2016 -0500 Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb return in bottom half" I have not checked yet, if it was intentionnaly fixed. 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: > 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: >> 2016-07-20 18:06 GMT+03:00 Bin Liu <b-...@ti.com>: >>> Hi, >>> >>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote: >>>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-...@ti.com>: >>>> > Hi, >>>> > >>>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote: >>>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-...@ti.com>: >>>> >> > Hi, >>>> >> > >>>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote: >>>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu <b-...@ti.com>: >>>> >> >> > 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 th
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>: > 2016-07-20 18:06 GMT+03:00 Bin Liu <b-...@ti.com>: >> Hi, >> >> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote: >>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-...@ti.com>: >>> > Hi, >>> > >>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote: >>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-...@ti.com>: >>> >> > Hi, >>> >> > >>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote: >>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu <b-...@ti.com>: >>> >> >> > 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 recei
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-20 18:06 GMT+03:00 Bin Liu <b-...@ti.com>:
> Hi,
>
> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>> 2016-07-20 17:13 GMT+03:00 Bin Liu <b-...@ti.com>:
>> > Hi,
>> >
>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-...@ti.com>:
>> >> > Hi,
>> >> >
>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu <b-...@ti.com>:
>> >> >> > 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) |
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-20 17:13 GMT+03:00 Bin Liu <b-...@ti.com>:
> Hi,
>
> On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-...@ti.com>:
>> > Hi,
>> >
>> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> >> 2016-07-19 23:56 GMT+03:00 Bin Liu <b-...@ti.com>:
>> >> > 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
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-20 9:09 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
> 2016-07-20 0:34 GMT+03:00 Bin Liu <b-...@ti.com>:
>> Hi,
>>
>> On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>>> 2016-07-19 23:56 GMT+03:00 Bin Liu <b-...@ti.com>:
>>> > 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_iso
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-20 0:34 GMT+03:00 Bin Liu <b-...@ti.com>:
> Hi,
>
> On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> 2016-07-19 23:56 GMT+03:00 Bin Liu <b-...@ti.com>:
>> > 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
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-19 23:56 GMT+03:00 Bin Liu <b-...@ti.com>:
> 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
pwc over musb: 100% frame drop (lost) on high resolution stream
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
v4l2 api: supported resolution negotiation
Hello, I learned from V2L2 API how to detect all supported formats using VIDIOC_ENUM_FMT. When I perform VIDIOC_S_FMT I don't know how to fill fmt.pix.width and fmt.pix.height, since I know only format. How should I negotiate device resolution? Could you point me? -- 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
[PATCH RFC] drivers: parport: Ask user for irqreturn_t value
Current parport_irq_handler behaviour is not correct when IRQ is shared.
LDDv3 on page 279 requires us:
Be sure to return IRQ_NONE whenever your handler is called and finds
the device is not interrupting.
This is not the case of parport_irq_handler.
Current implementation of IRQ handling use this to optimize shared IRQ
processing.
When an action returns IRQ_HANDLED no other actions are processed.
Modify callback function void (*irq_func)(void *) to irqreturn_t
(*irq_func)(void *) and return the value in parport_irq_handler
This also fixes https://bugzilla.kernel.org/show_bug.cgi?id=85221
Signed-off-by: Matwey V. Kornilov mat...@sai.msu.ru
---
drivers/char/ppdev.c | 4 +++-
drivers/i2c/busses/i2c-parport.c | 5 -
drivers/input/joystick/walkera0701.c | 6 --
drivers/net/hamradio/baycom_par.c | 4 +++-
drivers/net/plip/plip.c| 8 +---
drivers/parport/share.c| 6 ++
drivers/pps/clients/pps_parport.c | 6 +++---
drivers/staging/media/lirc/lirc_parallel.c | 12 +++-
include/linux/parport.h| 12
9 files changed, 39 insertions(+), 24 deletions(-)
diff --git a/drivers/char/ppdev.c b/drivers/char/ppdev.c
index ae0b42b..61fec51 100644
--- a/drivers/char/ppdev.c
+++ b/drivers/char/ppdev.c
@@ -264,7 +264,7 @@ static ssize_t pp_write (struct file * file, const char
__user * buf,
return bytes_written;
}
-static void pp_irq (void *private)
+static irqreturn_t pp_irq (void *private)
{
struct pp_struct *pp = private;
@@ -275,6 +275,8 @@ static void pp_irq (void *private)
atomic_inc (pp-irqc);
wake_up_interruptible (pp-irq_wait);
+
+ return IRQ_HANDLED;
}
static int register_device (int minor, struct pp_struct *pp)
diff --git a/drivers/i2c/busses/i2c-parport.c b/drivers/i2c/busses/i2c-parport.c
index a27aae2..7549e10 100644
--- a/drivers/i2c/busses/i2c-parport.c
+++ b/drivers/i2c/busses/i2c-parport.c
@@ -151,7 +151,7 @@ static const struct i2c_algo_bit_data parport_algo_data = {
/* - I2c and parallel port call-back functions and structures - */
-static void i2c_parport_irq(void *data)
+static irqreturn_t i2c_parport_irq(void *data)
{
struct i2c_par *adapter = data;
struct i2c_client *ara = adapter-ara;
@@ -159,9 +159,12 @@ static void i2c_parport_irq(void *data)
if (ara) {
dev_dbg(ara-dev, SMBus alert received\n);
i2c_handle_smbus_alert(ara);
+ return IRQ_HANDLED;
} else
dev_dbg(adapter-adapter.dev,
SMBus alert received but no ARA client!\n);
+
+ return IRQ_NONE;
}
static void i2c_parport_attach(struct parport *port)
diff --git a/drivers/input/joystick/walkera0701.c
b/drivers/input/joystick/walkera0701.c
index b76ac58..f3903a6 100644
--- a/drivers/input/joystick/walkera0701.c
+++ b/drivers/input/joystick/walkera0701.c
@@ -124,7 +124,7 @@ static inline int read_ack(struct pardevice *p)
}
/* falling edge, prepare to BIN value calculation */
-static void walkera0701_irq_handler(void *handler_data)
+static irqreturn_t walkera0701_irq_handler(void *handler_data)
{
u64 pulse_time;
struct walkera_dev *w = handler_data;
@@ -136,7 +136,7 @@ static void walkera0701_irq_handler(void *handler_data)
/* cancel timer, if in handler or active do resync */
if (unlikely(0 != hrtimer_try_to_cancel(w-timer))) {
w-counter = NO_SYNC;
- return;
+ return IRQ_HANDLED;
}
if (w-counter NO_SYNC) {
@@ -166,6 +166,8 @@ static void walkera0701_irq_handler(void *handler_data)
w-counter = 0;
hrtimer_start(w-timer, ktime_set(0, BIN_SAMPLE), HRTIMER_MODE_REL);
+
+ return IRQ_HANDLED;
}
static enum hrtimer_restart timer_handler(struct hrtimer
diff --git a/drivers/net/hamradio/baycom_par.c
b/drivers/net/hamradio/baycom_par.c
index acb6369..1fd9a7b 100644
--- a/drivers/net/hamradio/baycom_par.c
+++ b/drivers/net/hamradio/baycom_par.c
@@ -269,7 +269,7 @@ static __inline__ void par96_rx(struct net_device *dev,
struct baycom_state *bc)
/* - */
-static void par96_interrupt(void *dev_id)
+static irqreturn_t par96_interrupt(void *dev_id)
{
struct net_device *dev = dev_id;
struct baycom_state *bc = netdev_priv(dev);
@@ -292,6 +292,8 @@ static void par96_interrupt(void *dev_id)
hdlcdrv_transmitter(dev, bc-hdrv);
hdlcdrv_receiver(dev, bc-hdrv);
local_irq_disable();
+
+ return IRQ_HANDLED;
}
/* - */
diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
index 040b897..00a8b3a 100644
--- a/drivers/net/plip/plip.c
+++ b/drivers/net/plip/plip.c
@@ -143,7 +143,7 @@ static
Re: [PATCH RFC] drivers: parport: Ask user for irqreturn_t value
Forget it, I invented something strange.
2014-09-28 12:02 GMT+04:00 Matwey V. Kornilov mat...@sai.msu.ru:
Current parport_irq_handler behaviour is not correct when IRQ is shared.
LDDv3 on page 279 requires us:
Be sure to return IRQ_NONE whenever your handler is called and finds
the device is not interrupting.
This is not the case of parport_irq_handler.
Current implementation of IRQ handling use this to optimize shared IRQ
processing.
When an action returns IRQ_HANDLED no other actions are processed.
Modify callback function void (*irq_func)(void *) to irqreturn_t
(*irq_func)(void *) and return the value in parport_irq_handler
This also fixes https://bugzilla.kernel.org/show_bug.cgi?id=85221
Signed-off-by: Matwey V. Kornilov mat...@sai.msu.ru
---
drivers/char/ppdev.c | 4 +++-
drivers/i2c/busses/i2c-parport.c | 5 -
drivers/input/joystick/walkera0701.c | 6 --
drivers/net/hamradio/baycom_par.c | 4 +++-
drivers/net/plip/plip.c| 8 +---
drivers/parport/share.c| 6 ++
drivers/pps/clients/pps_parport.c | 6 +++---
drivers/staging/media/lirc/lirc_parallel.c | 12 +++-
include/linux/parport.h| 12
9 files changed, 39 insertions(+), 24 deletions(-)
diff --git a/drivers/char/ppdev.c b/drivers/char/ppdev.c
index ae0b42b..61fec51 100644
--- a/drivers/char/ppdev.c
+++ b/drivers/char/ppdev.c
@@ -264,7 +264,7 @@ static ssize_t pp_write (struct file * file, const char
__user * buf,
return bytes_written;
}
-static void pp_irq (void *private)
+static irqreturn_t pp_irq (void *private)
{
struct pp_struct *pp = private;
@@ -275,6 +275,8 @@ static void pp_irq (void *private)
atomic_inc (pp-irqc);
wake_up_interruptible (pp-irq_wait);
+
+ return IRQ_HANDLED;
}
static int register_device (int minor, struct pp_struct *pp)
diff --git a/drivers/i2c/busses/i2c-parport.c
b/drivers/i2c/busses/i2c-parport.c
index a27aae2..7549e10 100644
--- a/drivers/i2c/busses/i2c-parport.c
+++ b/drivers/i2c/busses/i2c-parport.c
@@ -151,7 +151,7 @@ static const struct i2c_algo_bit_data parport_algo_data =
{
/* - I2c and parallel port call-back functions and structures -
*/
-static void i2c_parport_irq(void *data)
+static irqreturn_t i2c_parport_irq(void *data)
{
struct i2c_par *adapter = data;
struct i2c_client *ara = adapter-ara;
@@ -159,9 +159,12 @@ static void i2c_parport_irq(void *data)
if (ara) {
dev_dbg(ara-dev, SMBus alert received\n);
i2c_handle_smbus_alert(ara);
+ return IRQ_HANDLED;
} else
dev_dbg(adapter-adapter.dev,
SMBus alert received but no ARA client!\n);
+
+ return IRQ_NONE;
}
static void i2c_parport_attach(struct parport *port)
diff --git a/drivers/input/joystick/walkera0701.c
b/drivers/input/joystick/walkera0701.c
index b76ac58..f3903a6 100644
--- a/drivers/input/joystick/walkera0701.c
+++ b/drivers/input/joystick/walkera0701.c
@@ -124,7 +124,7 @@ static inline int read_ack(struct pardevice *p)
}
/* falling edge, prepare to BIN value calculation */
-static void walkera0701_irq_handler(void *handler_data)
+static irqreturn_t walkera0701_irq_handler(void *handler_data)
{
u64 pulse_time;
struct walkera_dev *w = handler_data;
@@ -136,7 +136,7 @@ static void walkera0701_irq_handler(void *handler_data)
/* cancel timer, if in handler or active do resync */
if (unlikely(0 != hrtimer_try_to_cancel(w-timer))) {
w-counter = NO_SYNC;
- return;
+ return IRQ_HANDLED;
}
if (w-counter NO_SYNC) {
@@ -166,6 +166,8 @@ static void walkera0701_irq_handler(void *handler_data)
w-counter = 0;
hrtimer_start(w-timer, ktime_set(0, BIN_SAMPLE), HRTIMER_MODE_REL);
+
+ return IRQ_HANDLED;
}
static enum hrtimer_restart timer_handler(struct hrtimer
diff --git a/drivers/net/hamradio/baycom_par.c
b/drivers/net/hamradio/baycom_par.c
index acb6369..1fd9a7b 100644
--- a/drivers/net/hamradio/baycom_par.c
+++ b/drivers/net/hamradio/baycom_par.c
@@ -269,7 +269,7 @@ static __inline__ void par96_rx(struct net_device *dev,
struct baycom_state *bc)
/* - */
-static void par96_interrupt(void *dev_id)
+static irqreturn_t par96_interrupt(void *dev_id)
{
struct net_device *dev = dev_id;
struct baycom_state *bc = netdev_priv(dev);
@@ -292,6 +292,8 @@ static void par96_interrupt(void *dev_id)
hdlcdrv_transmitter(dev, bc-hdrv);
hdlcdrv_receiver(dev, bc-hdrv);
local_irq_disable();
+
+ return IRQ_HANDLED
