Re: [RFC PATCH v6 6/9] media: tegra: Add Tegra210 Video input driver
From: Sowjanya Komatineni
Date: Tue Apr 07 2020 - 17:08:43 EST
On 4/6/20 4:48 PM, Sowjanya Komatineni wrote:
On 4/6/20 4:18 PM, Dmitry Osipenko wrote:
External email: Use caution opening links or attachments
07.04.2020 01:07, Sowjanya Komatineni ÐÐÑÐÑ:
On 4/6/20 3:00 PM, Sowjanya Komatineni wrote:
On 4/6/20 2:39 PM, Sowjanya Komatineni wrote:
On 4/6/20 2:15 PM, Sowjanya Komatineni wrote:
On 4/6/20 2:11 PM, Dmitry Osipenko wrote:
External email: Use caution opening links or attachments
07.04.2020 00:02, Sowjanya Komatineni ÐÐÑÐÑ:
Am I understanding correctly that this thread will take 100%
CPU,
spinning here, if more than 2 frame-captures queued?
on more than 2 frames captures, it breaks thread and on next
wakeup it
continues
The wait_event() won't wait if condition is true.
condition is checked when waitqueue is woken up
https://elixir.bootlin.com/linux/v5.6.2/source/include/linux/wait.h#L462
process is put to sleep until the condition evaluates to true or
signal
is received.
condition is checked each time the waitqueue head is woken up.
This is a wrong assumption in accordance to the code.
process is in sleep until the condition is evaluated and when
condition is true wakeup still happens only when wake_up on waitqueue
is called
This is the reason for using this to prevent blocking while waiting
for the buffers.
w.r.t capture list update, wakeup happens when wake_up on waitqueue is
called.
wakeup also happens on kthread stop signal event.
when every buffer is available as long as we are in streaming, we
should process it.
So if wake up happens when list has buffer, it will be processed but
at a time we limit processing 2 simultaneous buffer capture starts
only.
Fixing typo.
I meant when ever buffer is available as long as we are in streaming,
we should process it.
So capture thread processes as long as buffers are available from
user space limiting 2 simultaneous trigger of captures and thread
will be in sleep when capture buffers list is empty or no stop thread
is signaled.
IIUC, the waiting won't happen if more than 2 captures are queued and
thread will be spinning until captures are processed.
I think you need a semaphore with resource count = 2.
we hold on to issuing capture if more than 2 buffers are queued and it
continues only after fifo has min 1 slot empty
Just want to close on this part of feedback. Hope above explanation is
clear regarding triggering/issuing at max 2 frame capture to VI HW and
also regarding capture threads where they use wait_event_interruptible
to prevent blocking waiting for buffers to be available for captures.
So no changes related to this part are needed in v7.