Extra half Frame delay before DQBUF returns

Luke,

For me it looks like expected behavior based on the above discussion. You can not expect to release the buffer on which device is working currently, so we always release the last buffer filled/processed.

If you really want to customize this driver for your need and If you understand pros/cons of this then you can modify the driver to mark current frame as a VIDEOBUF_DONE, to achieve this you can make use of VD0/VD1 interrupts to get interrupt at the required interval along with HS/VS for buffer processing.

I may not have understood some of the things here, like

 - I am bit confused with imager in-reset/out-reset process here, is it something mandatory here?

- Does this ~half frame delay really affects the application use-case, I am not sure why you can not afford this delay which is expected from driver.

Thanks,

Vaibhav

I'm not expecting the driver to release the buffer that is being filled.  The problem is that we don't get the first buffer returned until the second buffer is half filled.  We would like to get the first buffer as soon as it is finished.  As I said before, the frame times are long and speed is very critical.

The reason for holding the imager in reset is to be ready to start taking a sequence of images as soon as the user requests it.  We get the driver all setup with the imager in reset so that the imager isn't putting out any VD/HD signals and the frame buffers aren't being filled until we are ready to start.  This isn't a video application - it is more like digital still camera.  When an image sequence is requested, we take the imager out of reset so it starts putting out pixels and VD/HD.  As soon as the driver releases the first buffer, we can start processing the images.  After a sequence of images, the imager is put back in reset and we stop the video capture driver.  Getting the finished image out as quickly as possible is a requirement of the project.

The buffer state is being set to STATE_DONE in the VD_INT0 interrupt.  But then there must be some V4L2 mechanism that prevents the buffer from being released immediately.

Thanks for your help.

Luke

Hi,

In the interrupt V4L2 driver marks the state of the buffer as "done" when buffer capture is complete. When the application calls "VIDIOC_DQBUF" ioctl, driver internally calls the V4L2 video buffer layer.  This checks the status of the buffer and if the status of the buffer is not marked as  "done" it will schedule the task which will return again to check the status only after  the jiffy period. By the time task runs again interrupt would have occurred and marked the status of the buffer as done.  So there will always a time difference between the interrupt(capture complete) and the de-queue being release based on when "VIDIOC_DQBUF" is called.

To avoid this problem, you open the driver in non-blocking mode so "VIDIOC_DQBUF" will return without scheduling the task with "EAGAIN" error code if state of the buffer is not marked as "done".  You can do this in loop till "VIDIOC_DQBUF" returns success so there will be no delay between the interrupt occurrence and buffer de-queue.

Regards,

Hardik Shah

Hardik,

Thank you for your response.  We tried setting up the driver as non-blocking and polling until we got a frame but the result was the same.  We have been looking at timing signals more and I think we now understand the problem is a little different.

The nature of the application dictates that there is a large blanking time between frames.  There are reasons for that and I can explain if necessary.  VIDINT0 is setup to fire on the first line of a new frame.  For us, that's 150ms after the previous frame has finished readout.  We would like for the video port to mark the frame done after it gets the last line of the current frame, not the first line of the next frame.

We tried changing the VDINT0 interrupt to be equal to the image height in lines but that didn't work - the interrupt never fired for some reason.  If anyone has an other suggestions, that would be appreciated.

Luke

Hi Luke,

150ms of blanking period is huge amount of time, and that itself explains why you wanted to process the buffer before next frame. And as I explained before, from software point of view it is expected that we are marking previous buffer as a DONE when device is using current buffer. so I believe you should be able to configure VDINT0 to expected value to trigger the interrupt and mark the buffer as a DONE.

Have you configured VDINT0 = image height ??? Then it won't work, since the as per description you must configure i to "image height - 1" OR try some lower value than image height.

Also you can try using VDINT1 interrupt, but please note that resulting value for both is "VDINTx + 1", so you should configure it to <Image height - 1

Thanks,

Vaibhav