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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <15d8b525-67b5-b437-f7fd-89f80cd0d9f6@nvidia.com>
Date:   Wed, 8 Apr 2020 10:45:39 -0700
From:   Sowjanya Komatineni <skomatineni@...dia.com>
To:     Dmitry Osipenko <digetx@...il.com>, <thierry.reding@...il.com>,
        <jonathanh@...dia.com>, <frankc@...dia.com>, <hverkuil@...all.nl>,
        <sakari.ailus@....fi>, <helen.koike@...labora.com>
CC:     <sboyd@...nel.org>, <linux-media@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-clk@...r.kernel.org>,
        <linux-tegra@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v6 6/9] media: tegra: Add Tegra210 Video input driver


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