Re: [RFC PATCH v6 6/9] media: tegra: Add Tegra210 Video input driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 4/8/20 12:38 PM, Sowjanya Komatineni wrote:

On 4/8/20 11:58 AM, Sowjanya Komatineni wrote:

On 4/8/20 10:45 AM, Sowjanya Komatineni wrote:

On 4/8/20 7:21 AM, Dmitry Osipenko wrote:
External email: Use caution opening links or attachments


08.04.2020 03:00, Sowjanya Komatineni пишет:
...
I suppose that taking a shot takes at least few milliseconds, which
should be unacceptable to waste.
As long as buffers are in queue we have to keep processing each
buffer and between buffers obviously we have to wait for previous
frames to finish and this why we have separate thread for frame
finish where we can have next buffer capture ready and issue while
previous frame memory write happens
Also we specified numbers buffers as 3 to vb2 queue. So this is rare
case but to prevent issuing more than 2 at a time as VI HW is only
double buffered and syncpt fifo max depth is 2 added this to be safer.
To be more clear, when more buffers are enqueued from userspace always capture list will be full and thread will be busy in capture till either
error or stop stream request happens.

If kthreads take more than 1% of CPU time during capture (video) with
more than 2 buffers in queue, then it's not good and I think you should
do something about it. If kthreads stay at ~0%, then it should be okay
as-is.

VI outstanding requests max can only be 2  as syncpt fifo depth is 2  and waiting to issue next capture when already 2 captures are inflight happens only during beginning of streaming where buffers allocated go thru capture for first time after queuing.

same buffers are returned to userspace after capture and same allocated buffers will be queued back for subsequent captures.

So this case of holding to issue single shot when already single shot is issue for 2 frames simultaneous happens only during beginning of start stream and also we set num_buffers to allocate for queue as 3 although 2 is good enough where we will not hit this case even during streaming start with 2 buffers

As 2 buffers are good enough to be clear will update in v7 to use 2 buffers so we don't need to check for more than 2 outstanding buffers.

correction: With 3 buffers, as soon as buffer is available capture starts. So right most times I see it waiting for few ms before 3rd capture to get through.

As only 2 frames single shot can be issued in sequence (inflight requests), instead of waiting for 1 of the request to finish, we can use 2 buffers and avoid waiting as 2 buffers are good enough. Will change this in v7.



Tested with 3 buffers and by checking outstanding buffers in process by VI hw and holding to start capture till one outstanding buffer in process by HW.
Also tested with 2 buffers without checking for outstanding buffers.

In both cases, I see same %CPU for the kthreads and is < 1%





[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux