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/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.


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.







[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