Re: soc-camera s_fmt question?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 17 Jan 2011, Hans Verkuil wrote:

> On Monday, January 17, 2011 18:43:06 Guennadi Liakhovetski wrote:
> > 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?
> 
> I think it would be a good idea to look into converting soc_camera to the
> new videobuf2 framework that was just merged. It has much better semantics
> when it comes to allocating and freeing queues. You can actually understand
> it, something that you can't say for the old videobuf. And videobuf2 does
> the right thing with REQBUFS(0) as well.

Qing Xu, you could try videobuf2 now: 
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/28658 
(please, use v2 of patches).

Thanks
Guennadi

> 
> Regards,
> 
> 	Hans
> 
> > 
> > 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
> > 
> 
> -- 
> Hans Verkuil - video4linux developer - sponsored by Cisco
> 

---
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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux