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

[Sowjanya Komatineni <skomatineni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

On 4/7/20 4:59 PM, Sowjanya Komatineni wrote:
>
> On 4/7/20 4:38 PM, Sowjanya Komatineni wrote:
>>
>> On 4/7/20 4:36 PM, Sowjanya Komatineni wrote:
>>>
>>> On 4/7/20 4:12 PM, Dmitry Osipenko wrote:
>>>> External email: Use caution opening links or attachments
>>>>
>>>>
>>>> 08.04.2020 01:22, Sowjanya Komatineni пишет:
>>>>> On 4/7/20 3:08 PM, Dmitry Osipenko wrote:
>>>>>> External email: Use caution opening links or attachments
>>>>>>
>>>>>>
>>>>>> 08.04.2020 00:08, Sowjanya Komatineni пишет:
>>>>>> ...
>>>>>>>>> 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.
>>>>>>   From what I see in the code, you "hold on" by making kthread to 
>>>>>> spin in
>>>>>> a busy-loop while caps_inflight >= SYNCPT_FIFO_DEPTH. So some change
>>>>>> should be needed to prevent this.
>>>>>>
>>>>>> The wait_event_interruptible seems should be okay.
>>>>> We don't want to prevent that as we already have buffers available 
>>>>> for
>>>>> capture so as soon as VI HW issuing single shot is done and when 
>>>>> min 1
>>>>> slot is empty we should continue with issuing for another capture.
>>>>>
>>>>> As long as buffers are available, we should continue to capture and
>>>>> should not hold
>>>>>
>>>> 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.