Grabbing single stills on MX31 - Re: Solved? - Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c

[Agustin <gatoguan-os@yahoo.com>]

On Thu, 7 May 2009, Guennadi Liakhovetski wrote:

> 
> On Thu, 7 May 2009, Agustin Ferrin Pozuelo wrote:
> > ...
> > I thought about the fact that I was only queuing one buffer, and that 
> > this might be a corner case as sample code uses a lot of them. And that 
> > in the older code that funny things could happen in the handler if we 
> > ran out of buffers, though they didn't happen.
> > 
> > So I have queued an extra buffer and voila, got it working.
> > 
> > So thanks again!
> > 
> > However, this could be a bug in ipu_idmac (or some other point), as 
> > using a single buffer is very plausible, specially when grabbing huge 
> > stills.
> 
> Great, thanks for testing and debugging! Ok, so, I will have to test this 
> case some time...

Guennadi,

This workaround (queuing 2 buffers when needing only one) is having the side effect of greatly increasing the time taken.

I did several tests playing with camera vertical blanking and looking at capture times:

    Vblank / real / user / sys time:
             0 / real    0m 0.90s / user    0m 0.00s / sys     0m 0.34s
  1 frame / real    0m 1.04s / user    0m 0.00s / sys     0m 0.34s
2 frames / real    0m 1.18s / user    0m 0.00s / sys     0m 0.33s
2.5 (max)/ real    0m 1.23s / user    0m 0.00s / sys     0m 0.35s

I think the second frame is being captured altogether, and its dma transfer is not allowing any other process to run meanwhile. (VIDIOC_STREAMOFF is being called as soon as the first buffer is ready.)

Do you think it will be too hard to fix?

Regards,
--Agustín.