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:38:07 -0700 |
| |
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
| |