Hi, Thanks for your answer! So, we will be waiting and keeping sync with latest soc-camera + videobuf2 framework. -Qing -----Original Message----- From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx] Sent: 2011年1月18日 1:54 To: Guennadi Liakhovetski Cc: Qing Xu; Laurent Pinchart; linux-media@xxxxxxxxxxxxxxx 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: 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 ?韬{.n?????%??檩??w?{.n???{炳g???^n?■???h?璀?｛?夸z罐?+€?zf＂?????i?????_璁?:+v??撸?
