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.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
