On Mon, 17 Jan 2011, Qing Xu wrote:
> Hi,
>
> We are now nearly complete porting our camera driver to align with
> soc-camera framework, however, we encounter a problem when it works with
> our application during switch format from preview to still capture,
> application's main calling sequence is as follow:
> 1) s_fmt /* preview @ YUV, VGA */
> 2) request buffer (buffer count = 6)
> 2) queue buffer
> 3) stream on
> 4) q-buf, dq-buf...
> 5) stream off
>
> 6) s_fmt /* still capture @ jpeg, 2592x1944*/
> 7) request buffer (buffer count = 3)
> 8) same as 3)->5)...
>
> The point is in soc_camera_s_fmt_vid_cap() {
> if (icd->vb_vidq.bufs[0]) {
> dev_err(&icd->dev, "S_FMT denied: queue initialised\n");
> ret = -EBUSY;
> goto unlock;
> }
> }
> We didn't find vb_vidq.bufs[0] be free, (it is freed in
> videobuf_mmap_free(), and in __videobuf_mmap_setup, but no one calls
> videobuf_mmap_free(), and in __videobuf_mmap_setup it is freed at first
> and then allocated sequentially), so we always fail at calling s_fmt.
> My idea is to implement soc_camera_reqbufs(buffer count = 0), to provide
> application opportunity to free this buffer node, refer to v4l2 spec,
> http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html
> "A count value of zero frees all buffers, after aborting or finishing
> any DMA in progress, an implicit VIDIOC_STREAMOFF."
Currently buffers are freed in soc-camera upon close(). Yes, I know about
that clause in the API spec, and I know, that it is unimplemented in
soc-camera. Do you have a reason to prefer that over close()ing and
re-open()ing the device?
Thanks
Guennadi
>
> What do you think?
>
> Any ideas will be appreciated!
> Thanks!
> Qing Xu
>
> Email: qingx@xxxxxxxxxxx
> Application Processor Systems Engineering,
> Marvell Technology Group Ltd.
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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
