Messages in this thread | | | Subject | Re: [RFC PATCH v6 6/9] media: tegra: Add Tegra210 Video input driver | From | Sowjanya Komatineni <> | Date | Tue, 7 Apr 2020 16:57:42 -0700 |
| |
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.
| |