Thanks for your information! I could try it on our driver. -Qing -----Original Message----- From: Guennadi Liakhovetski [mailto:g.liakhovetski@xxxxxx] Sent: 2011年1月30日 2:10 To: Hans Verkuil Cc: Qing Xu; Laurent Pinchart; linux-media@xxxxxxxxxxxxxxx Subject: Re: soc-camera s_fmt question? 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/ ?韬{.n?????%??檩??w?{.n???{炳g???^n?■???h?璀?｛?夸z罐?+€?zf＂?????i?????_璁?:+v??撸?
