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: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ï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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
