Re: [RFC PATCH v6 6/9] media: tegra: Add Tegra210 Video input driver
From: Sowjanya Komatineni
Date: Wed Apr 08 2020 - 13:45:46 EST
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