On 4/30/20 9:04 AM, Sowjanya Komatineni wrote:
Also if we add check for both lists empty, freeze is not allowed as long as streaming is going on and in case of continuous streaming freeze will never happen.
On 4/30/20 7:13 AM, Dmitry Osipenko wrote:
30.04.2020 17:02, Dmitry Osipenko ÐÐÑÐÑ:
30.04.2020 16:56, Dmitry Osipenko ÐÐÑÐÑ:Or maybe both start / finish threads should simply be allowed to freeze
30.04.2020 01:00, Sowjanya Komatineni ÐÐÑÐÑ:And here should be some locking protection in order not race with the
+static int chan_capture_kthread_finish(void *data)I guess it won't be great to freeze in the middle of a capture process, so:
+{
+ÂÂÂ struct tegra_vi_channel *chan = data;
+ÂÂÂ struct tegra_channel_buffer *buf;
+
+ÂÂÂ set_freezable();
+
+ÂÂÂ while (1) {
+ÂÂÂÂÂÂÂ try_to_freeze();
ÂÂÂÂÂÂÂ if (list_empty(&chan->done))
ÂÂÂÂÂÂÂÂÂÂÂ try_to_freeze();
chan_capture_kthread_start because kthread_finish could freeze before
kthread_start.
only when both capture and done lists are empty.
if (list_empty(&chan->capture) &&
ÂÂÂÂ list_empty(&chan->done))
ÂÂÂÂtry_to_freeze();
good to freeze when not in middle of the frame capture but why should we not allow freeze in between captures?
Other drivers do allow freeze in between frame captures.
I guess we can freeze before dequeue for capture and in finish thread we can freeze after capture done. This also don't need to check for list_empty with freeze to allow between frame captures.