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

[Sowjanya Komatineni]

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.