Re: [RFC PATCH v11 6/9] media: tegra: Add Tegra210 Video input driver

Sowjanya Komatineni
2020-04-30T16:30:31Z

On 4/30/20 9:04 AM, Sowjanya Komatineni wrote:
>
> On 4/30/20 7:13 AM, Dmitry Osipenko wrote:
>> 30.04.2020 17:02, Dmitry Osipenko пишет:
>>> 30.04.2020 16:56, Dmitry Osipenko пишет:
>>>> 30.04.2020 01:00, Sowjanya Komatineni пишет:
>>>>> +static int chan_capture_kthread_finish(void *data)
>>>>> +{
>>>>> +    struct tegra_vi_channel *chan = data;
>>>>> +    struct tegra_channel_buffer *buf;
>>>>> +
>>>>> +    set_freezable();
>>>>> +
>>>>> +    while (1) {
>>>>> +        try_to_freeze();
>>>> I guess it won't be great to freeze in the middle of a capture
>>>> process, so:
>>>>         if (list_empty(&chan->done))
>>>>             try_to_freeze();
>>> And here should be some locking protection in order not race with the
>>> chan_capture_kthread_start because kthread_finish could freeze before
>>> kthread_start.
>> Or maybe both start / finish threads should simply be allowed to freeze
>> 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.
>
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.