Hi Guennadi, In close(), the sensor/camera controller will be totally powered-off/clock-off, then in open(), we will set hundreds of default values into sensor's registers by I2C, to enable/configure sensor to a default status, it takes too much time(several seconds) to switch from preview to still capture that our customers can not bear. So, instead, when switch format, our application just calls stream-off/stream-on, as in stream-off(), we put the sensor/camera controller to a pause state, once switch format, we only need to set several sensor registers, it takes a little time to switch from preview to still capture. And, further more, during preview, customers would like to set some special effect to image, such as turning color to blue, changing the brightness, etc, when they capture the picture, they would hope the picture looks the same as the what they change during preview, so, our application does not totally close() camera, just stream-off(), in this way, the registers values are kept in sensor, those special effect status is also kept. The 2 reasons above make our application will not close/open, but just stream-off/stream-on during switching format from preview to still capture. Thanks! -Qing -----Original Message----- From: Guennadi Liakhovetski [mailto:g.liakhovetski@xxxxxx] Sent: 2011年1月18日 1:43 To: Qing Xu Cc: Laurent Pinchart; linux-media@xxxxxxxxxxxxxxx Subject: Re: soc-camera s_fmt question? 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? 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/ ?韬{.n?????%??檩??w?{.n???{炳g???^n?■???h?璀?｛?夸z罐?+€?zf＂?????i?????_璁?:+v??撸?
