On Tuesday, January 18, 2011 08:44:28 Guennadi Liakhovetski wrote:
> On Tue, 18 Jan 2011, Hans Verkuil wrote:
>
> > On Tuesday, January 18, 2011 03:30:09 Qing Xu wrote:
> > > Hi,
> > >
> > > Thanks for your answer! So, we will be waiting and keeping sync with
> > > latest soc-camera + videobuf2 framework.
> >
> > Erm, just to avoid any confusion: I am *not* going to convert soc-camera
> > to videobuf2. I just mentioned it because if someone does, then that should
> > fix your problems with REQBUFS(0) (and probably STREAMON/OFF problems as
> > well).
> >
> > I think soc-camera will benefit a lot from such a move so I hope someone
> > (Guennadi? You?) will take on this job.
>
> Yeah. I'll try to find some time to look at it... Just no idea when.
> What's the status of videobuf2, actually?
Merged last weekend, will go into 2.6.38.
> Is it something, that all
> drivers better be converted to, just because it's better?
Yes, all existing videobuf drivers should (over time) be converted to vb2.
All new drivers should use vb2 as well.
> It is also
> orthogonal to the forthcoming mc, so, that when converting to it some time
> soon, the time, spent to convert to videobuf2 won't be wasted?
It is unrelated to the mc. They don't have any impact on each other.
Main features it adds: it actually conforms to the V4L2 spec, deterministic
and documented behavior, multi-planar support, separate memory handling ops.
In the long term it should also make it possible to move buffers from one
V4L2 device to another.
Regards,
Hans
>
> Thanks
> Guennadi
>
> > Regards,
> >
> > Hans
> >
> > >
> > > -Qing
> > >
> > > -----Original Message-----
> > > From: Hans Verkuil [mailto:[email protected]]
> > > Sent: 2011年1月18日 1:54
> > > To: Guennadi Liakhovetski
> > > Cc: Qing Xu; Laurent Pinchart; [email protected]
> > > Subject: Re: soc-camera s_fmt question?
> > >
> > > 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.
> > >
> > > Regards,
> > >
> > > Hans
> > >
> > > >
> > > > Thanks
> > > > Guennadi
> > > >
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Any ideas will be appreciated!
> > > > > Thanks!
> > > > > Qing Xu
> > > > >
> > > > > Email: [email protected]
> > > > > 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 [email protected]
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > >
> > >
> > > --
> > > Hans Verkuil - video4linux developer - sponsored by Cisco
> > > �翳�.n�����+%��遍荻�w��.n��伐�{炳g����n�r■�����ㄨ&｛�夸z罐����zf＂������������赙z_璁�:+v�)撸�
> > >
> > >
> >
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>
>
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
