Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
Moikka Sakari,
On 10/02/2011 09:20 AM, Sakari Ailus wrote:
On Sat, Oct 01, 2011 at 11:17:27AM +0200, Sylwester Nawrocki wrote:
Hi Sakari,
I'm sorry, I've been a little bit busy in the week to get back to this.
Hi Sylwester,
No worries!
On 09/27/2011 10:55 PM, Sakari Ailus wrote:
Sylwester Nawrocki wrote:
On 09/25/2011 12:08 PM, Sakari Ailus wrote:
On Fri, Sep 23, 2011 at 12:12:58PM +0200, Sylwester Nawrocki wrote:
On 09/23/2011 12:02 AM, Sakari Ailus wrote:
Hi Sylwester,
I have a few additional comments below, they don't depend on my earlier
ones.
Thanks a lot for your follow up review!
On Wed, Sep 21, 2011 at 07:45:07PM +0200, Sylwester Nawrocki wrote:
This driver exposes preview mode operation of the S5K6AAFX sensor with
embedded SoC ISP. It uses one of the five user predefined configuration
register sets. There is yet no support for capture (snapshot)
operation.
Following controls are supported:
manual/auto exposure and gain, power line frequency (anti-flicker),
saturation, sharpness, brightness, contrast, white balance temperature,
color effects, horizontal/vertical image flip, frame interval.
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
...
+
+struct s5k6aa_pixfmt {
+ enum v4l2_mbus_pixelcode code;
+ u32 colorspace;
+ /* REG_P_FMT(x) register value */
+ u16 reg_p_fmt;
+};
+
+struct s5k6aa_preset {
+ struct v4l2_frmsize_discrete out_size;
+ struct v4l2_rect in_win;
+ const struct s5k6aa_pixfmt *pixfmt;
+ unsigned int inv_hflip:1;
+ unsigned int inv_vflip:1;
+ u8 frame_rate_type;
+ u8 index;
+};
+
[clip]
+/* Set initial values for all preview presets */
+static void s5k6aa_presets_data_init(struct s5k6aa *s5k6aa,
+ int hflip, int vflip)
+{
+ struct s5k6aa_preset *preset =s5k6aa-presets[0];
+ int i;
+
+ for (i = 0; iS5K6AA_MAX_PRESETS; i++) {
+ preset-pixfmt =s5k6aa_formats[0];
+ preset-frame_rate_type = FR_RATE_DYNAMIC;
+ preset-inv_hflip = hflip;
+ preset-inv_vflip = vflip;
+ preset-out_size.width = S5K6AA_OUT_WIDTH_DEF;
+ preset-out_size.height = S5K6AA_OUT_HEIGHT_DEF;
+ preset-in_win.width= S5K6AA_WIN_WIDTH_MAX;
+ preset-in_win.height = S5K6AA_WIN_HEIGHT_MAX;
+ preset-in_win.left = 0;
+ preset-in_win.top = 0;
Much of this data is static, why is it copied to the presets struct?
What is the intended purpose of these presets?
I agree there is no need to keep inv_hflip/inv_vflip there. It's more a
leftover from previous driver version. I'll move it to struct s5k6aa.
And I try to keep copy of each platform_data attribute in driver's
private struct to make future transition to DT driver probing easier.
inv_[hv]flip variables are used to indicate physical layout of the
sensor,
as it varies across multiple machines. So indeed they're global, not per
the configuration set.
Preset are there in the s5k6aafx register interface to allow fast
transition
between, for instance, low resolution preview and high resolution
snapshot.
I'm planning to use this driver as an experimental rabbit for the future
snapshot mode API.
It sounds like that a snapshot mode would be an use case that presets
could support in a way, but what I'd really like to ask is how much
advantage one can get by using this mode, say, vs. re-programming the same
settings over the I2C bus? The bus transfers (I assume) roughly 40 kB/s,
so
I imagine a few tens of register writes can be avoided by most, taking
somewhere in the range of a few milliseconds.
As far as the timings are concerned, for this particular device, the
advantage is not really meaningful. We are talking about appr. 20
registers (~50 bytes on I2C bus), which is a ridiculously low number.
However, even if the interface isn't exposed to user space, in the
hardware there exist separate registers for preview and (still) capture
and it makes much sense in the driver to model this, for easier device
control.
How do you know when to switch the preset if you don't expose this to the
user space?
I don't, the user configuration data structure is there in the driver to more
precisely reflect the control interface of the device and better understand
what this driver supports and what it doesn't. Even if I use only one user
configuration register set _internally_ in the driver, there must be some
information provided to the device associated with it, like which user config
set we use, which clocks configuration applies to it, etc. Please don't make
me converting this driver to a total mess. :)
:)
Indeed. After reading the patch 4th time, I realised there's just one preset
supported right now.
I found a relatively decent
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
On Thu, Oct 06, 2011 at 10:00:50PM +0200, Sylwester Nawrocki wrote: Moikka Sakari, Hi, Sylwester! On 10/02/2011 09:20 AM, Sakari Ailus wrote: On Sat, Oct 01, 2011 at 11:17:27AM +0200, Sylwester Nawrocki wrote: [clip] That's fine because it's implemented by the sensor already. My point is that we should only show this fact in V4L2 API as little as possible. I remember Guennadi had sensors which provide something called snapshot mode. A single boolean control to turn this on or off would suffice --- snapshot mode is something that's going to be discussed in the Multimedia summit if my memory serves me right. Perhaps, although I don't expect huge outcome from one or two days meeting. Hopefully it gets us closer into the right direction. I'll try to prepare a brief summary of the m-5mols sensor requirements. This could be one option for this sensor as well but the implementation might not be quite optimal since you'd still need to switch the configuration. I believe the final result would be acceptable as well. However I recall going through a datasheet of a camera device which was capable of generating simultaneously low resolution YUV and a higher resolution capture JPEG data stream. Either on same MIPI-CSI channel or on separate ones. This was to achieve so called zero shutter lag. For this kind of device you may need two separate resolutions, at least an application and the driver must keep track of them. This kind of device requires two source pads. The same goes for the CSI-2 reciever: the CSI-2 channels are freely configurable even if the current drivers typically only use one. Two video nodes are required, too, since the images are independent of each other. In other words, this is already supported by the V4L2 interface. :-) [clip] If the hardware (or it's firmware) supports something natively why should we go for a less efficient SW emulated replacement? After all, preview and capture mode seem pretty basic features that applications will want to use. I think it depends on an application. If your application only knows it wants to do viewfinder or capture then it might be V4L2 could be a too low level interface for that job. Sorry, this is all not about the applications capabilities. Only about the V4L2 API limitations in using the existing devices. I might suggest GSTphotography instead. GstPhotography is not really impressive in its current state: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-plugins/html/GstPhotography.html I'm probably not the best person to comment on this, but do you think something is e.g. either missing or should be implemented differently? I'm not a big expert either. The GstPhotography interface seems not well documented, I just tried to imagine how it could be used with above mentioned camera chip supporting interlaced viewfinder/capture data stream. The lack of documentation aspect might be a valid complaint. :) I'm not a Gstreamer expert so take this with a grain of salt: This interface is used to control the capture process, and setting the resolutions is not part of that interface. The GSTphotography interface is provided by the camera source. A source used with Camerabin2 has three output pads: one of the pads provides viewfinder stream while another one provides captured images. The third putput pad is for video. URL:http://gstreamer.freedesktop.org/wiki/CameraBin I your case the source provides the viewfinder and captures images through the two pads. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
Hi Sylwester and Sakari, On Sunday 02 October 2011 09:20:11 Sakari Ailus wrote: On Sat, Oct 01, 2011 at 11:17:27AM +0200, Sylwester Nawrocki wrote: On 09/27/2011 10:55 PM, Sakari Ailus wrote: Sylwester Nawrocki wrote: On 09/25/2011 12:08 PM, Sakari Ailus wrote: On Fri, Sep 23, 2011 at 12:12:58PM +0200, Sylwester Nawrocki wrote: On 09/23/2011 12:02 AM, Sakari Ailus wrote: Hi Sylwester, On Wed, Sep 21, 2011 at 07:45:07PM +0200, Sylwester Nawrocki wrote: [snip] I'm not sure if this makes it easier for the user space. The user space must know about such a think and aslo which parameters it applies to. I don't Yes, I agree on this entirely. think this ocnforms to V4L2 either, but I might have misunderstood something. If there is anything in the code not conforming to V4L2 please indicate it clearly. Ok, what the driver currently implements, does conform to V4L2. But getting advantage (which I'd like to argue might be irrelevant) using different presets would be challenging to implement while obeying the V4L2 spec. That's why we probably need to extend the V4L2 spec :-) Snapshot mode is currently ill-defined. At the hardware level, the name is used to describe different concepts depending on the sensor. This can cover a wide range of features, from enabling external trigger to using different register sets. Some of those features (such as registers set) are even not restricted to preview/snapshot/capture modes and can be used for other purpose. At the application level, capturing a snapshot image usually involve much more than just selecting a snapshot mode, especially when ISPs (either on the sensor side or on the host side) are involved. Snapshot mode will be discussed in Prague. Given the complexity of the issue we won't solve it there, but I hope to at least gather a list of requirements and use cases (and if possible a list that everybody agrees on :-)). It would be nice if every person interested in the subject could prepare such a list beforehand, as we will have little time to discuss the topic. Anyway, I've taken a closer look at what I need in the single user configuration set data structure and reworked the driver quite extensively. Should post that in the coming week, unless some unexpected disasters occur;) Do you see any problem in defining real still capture interface in V4L ? It's probably just a small set of new controls, new capability, plus multi-size buffer queue Guennadi has been working on. Some devices will require explicitly switching between preview and capture mode, and it may make difference if they are programmed in advance or on demand. For this specific use case, it's probably just that. If we take other use cases into account, it isn't. I don't think we should rush in API support for snapshot capture mode in V4L2 without a proper understanding of all (or most) use cases. I don't think V4L2 should have a still capture interface. Still capture is just one use case as viewfinder and video. V4L2 deals with frames, formats and parameters that are all generic and use case independent. Instead of use cases, we have independent configurable settings and that's the way I think it should stay. If your hardware requires switching mode to still before taking a still image, then the driver should expose this functionality as such. I'd be Yeah, of course this should work. But I don't quite see how would I expose the still/normal switch control with existing API. Aren't you going to blackball this as just another 'use case' ? :) That's fine because it's implemented by the sensor already. My point is that we should only show this fact in V4L2 API as little as possible. I agree with Sakari here. We need a high level snapshot capture API in userspace, something similar to (and not necessarily separate from) GstPhotography. The userspace components will of course need proper support from V4L2, but that doesn't mean the whole snapshot capture API must be implemented in V4L2. I see this more like a collection of V4L2 extensions (such as the multi-size buffer queue) that can be used to support snapshot capture in userspace. I remember Guennadi had sensors which provide something called snapshot mode. A single boolean control to turn this on or off would suffice --- snapshot mode is something that's going to be discussed in the Multimedia summit if my memory serves me right. This could be one option for this sensor as well but the implementation might not be quite optimal since you'd still need to switch the configuration. In fact preview/still mode control seems to be a minimum needed to expose full functionality of the S5K6AAFX device in V4L2 API. But I am not really interested in still capture with this device ATM. The current driver is more than enough :) really wary of e.g. exposing register configuration flipping
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
On Sat, Oct 01, 2011 at 11:17:27AM +0200, Sylwester Nawrocki wrote:
Hi Sakari,
I'm sorry, I've been a little bit busy in the week to get back to this.
Hi Sylwester,
No worries!
On 09/27/2011 10:55 PM, Sakari Ailus wrote:
Sylwester Nawrocki wrote:
On 09/25/2011 12:08 PM, Sakari Ailus wrote:
On Fri, Sep 23, 2011 at 12:12:58PM +0200, Sylwester Nawrocki wrote:
On 09/23/2011 12:02 AM, Sakari Ailus wrote:
Hi Sylwester,
I have a few additional comments below, they don't depend on my earlier
ones.
Thanks a lot for your follow up review!
On Wed, Sep 21, 2011 at 07:45:07PM +0200, Sylwester Nawrocki wrote:
This driver exposes preview mode operation of the S5K6AAFX sensor with
embedded SoC ISP. It uses one of the five user predefined configuration
register sets. There is yet no support for capture (snapshot)
operation.
Following controls are supported:
manual/auto exposure and gain, power line frequency (anti-flicker),
saturation, sharpness, brightness, contrast, white balance temperature,
color effects, horizontal/vertical image flip, frame interval.
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
...
+
+struct s5k6aa_pixfmt {
+ enum v4l2_mbus_pixelcode code;
+ u32 colorspace;
+ /* REG_P_FMT(x) register value */
+ u16 reg_p_fmt;
+};
+
+struct s5k6aa_preset {
+ struct v4l2_frmsize_discrete out_size;
+ struct v4l2_rect in_win;
+ const struct s5k6aa_pixfmt *pixfmt;
+ unsigned int inv_hflip:1;
+ unsigned int inv_vflip:1;
+ u8 frame_rate_type;
+ u8 index;
+};
+
[clip]
+/* Set initial values for all preview presets */
+static void s5k6aa_presets_data_init(struct s5k6aa *s5k6aa,
+ int hflip, int vflip)
+{
+ struct s5k6aa_preset *preset =s5k6aa-presets[0];
+ int i;
+
+ for (i = 0; i S5K6AA_MAX_PRESETS; i++) {
+ preset-pixfmt =s5k6aa_formats[0];
+ preset-frame_rate_type = FR_RATE_DYNAMIC;
+ preset-inv_hflip = hflip;
+ preset-inv_vflip = vflip;
+ preset-out_size.width = S5K6AA_OUT_WIDTH_DEF;
+ preset-out_size.height = S5K6AA_OUT_HEIGHT_DEF;
+ preset-in_win.width= S5K6AA_WIN_WIDTH_MAX;
+ preset-in_win.height = S5K6AA_WIN_HEIGHT_MAX;
+ preset-in_win.left = 0;
+ preset-in_win.top = 0;
Much of this data is static, why is it copied to the presets struct?
What is the intended purpose of these presets?
I agree there is no need to keep inv_hflip/inv_vflip there. It's more a
leftover from previous driver version. I'll move it to struct s5k6aa.
And I try to keep copy of each platform_data attribute in driver's
private struct to make future transition to DT driver probing easier.
inv_[hv]flip variables are used to indicate physical layout of the
sensor,
as it varies across multiple machines. So indeed they're global, not per
the configuration set.
Preset are there in the s5k6aafx register interface to allow fast
transition
between, for instance, low resolution preview and high resolution
snapshot.
I'm planning to use this driver as an experimental rabbit for the future
snapshot mode API.
It sounds like that a snapshot mode would be an use case that presets
could support in a way, but what I'd really like to ask is how much
advantage one can get by using this mode, say, vs. re-programming the same
settings over the I2C bus? The bus transfers (I assume) roughly 40 kB/s,
so
I imagine a few tens of register writes can be avoided by most, taking
somewhere in the range of a few milliseconds.
As far as the timings are concerned, for this particular device, the
advantage is not really meaningful. We are talking about appr. 20
registers (~50 bytes on I2C bus), which is a ridiculously low number.
However, even if the interface isn't exposed to user space, in the
hardware there exist separate registers for preview and (still) capture
and it makes much sense in the driver to model this, for easier device
control.
How do you know when to switch the preset if you don't expose this to the
user space?
I don't, the user configuration data structure is there in the driver to more
precisely reflect the control interface of the device and better understand
what this driver supports and what it doesn't. Even if I use only one user
configuration register set _internally_ in the driver, there must be some
information provided to the device associated with it, like which user config
set we use, which clocks configuration applies to it, etc. Please don't make
me converting this driver to a total mess. :)
:)
Indeed. After reading the patch 4th time, I realised there's just one preset
supported right
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
Hi Sakari,
I'm sorry, I've been a little bit busy in the week to get back to this.
On 09/27/2011 10:55 PM, Sakari Ailus wrote:
Sylwester Nawrocki wrote:
On 09/25/2011 12:08 PM, Sakari Ailus wrote:
On Fri, Sep 23, 2011 at 12:12:58PM +0200, Sylwester Nawrocki wrote:
On 09/23/2011 12:02 AM, Sakari Ailus wrote:
Hi Sylwester,
I have a few additional comments below, they don't depend on my earlier
ones.
Thanks a lot for your follow up review!
On Wed, Sep 21, 2011 at 07:45:07PM +0200, Sylwester Nawrocki wrote:
This driver exposes preview mode operation of the S5K6AAFX sensor with
embedded SoC ISP. It uses one of the five user predefined configuration
register sets. There is yet no support for capture (snapshot) operation.
Following controls are supported:
manual/auto exposure and gain, power line frequency (anti-flicker),
saturation, sharpness, brightness, contrast, white balance temperature,
color effects, horizontal/vertical image flip, frame interval.
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
...
+
+struct s5k6aa_pixfmt {
+enum v4l2_mbus_pixelcode code;
+u32 colorspace;
+/* REG_P_FMT(x) register value */
+u16 reg_p_fmt;
+};
+
+struct s5k6aa_preset {
+struct v4l2_frmsize_discrete out_size;
+struct v4l2_rect in_win;
+const struct s5k6aa_pixfmt *pixfmt;
+unsigned int inv_hflip:1;
+unsigned int inv_vflip:1;
+u8 frame_rate_type;
+u8 index;
+};
+
[clip]
+/* Set initial values for all preview presets */
+static void s5k6aa_presets_data_init(struct s5k6aa *s5k6aa,
+ int hflip, int vflip)
+{
+struct s5k6aa_preset *preset =s5k6aa-presets[0];
+int i;
+
+for (i = 0; i S5K6AA_MAX_PRESETS; i++) {
+preset-pixfmt =s5k6aa_formats[0];
+preset-frame_rate_type = FR_RATE_DYNAMIC;
+preset-inv_hflip = hflip;
+preset-inv_vflip = vflip;
+preset-out_size.width = S5K6AA_OUT_WIDTH_DEF;
+preset-out_size.height = S5K6AA_OUT_HEIGHT_DEF;
+preset-in_win.width= S5K6AA_WIN_WIDTH_MAX;
+preset-in_win.height = S5K6AA_WIN_HEIGHT_MAX;
+preset-in_win.left = 0;
+preset-in_win.top = 0;
Much of this data is static, why is it copied to the presets struct?
What is the intended purpose of these presets?
I agree there is no need to keep inv_hflip/inv_vflip there. It's more a
leftover from previous driver version. I'll move it to struct s5k6aa.
And I try to keep copy of each platform_data attribute in driver's
private struct to make future transition to DT driver probing easier.
inv_[hv]flip variables are used to indicate physical layout of the sensor,
as it varies across multiple machines. So indeed they're global, not per
the configuration set.
Preset are there in the s5k6aafx register interface to allow fast
transition
between, for instance, low resolution preview and high resolution snapshot.
I'm planning to use this driver as an experimental rabbit for the future
snapshot mode API.
It sounds like that a snapshot mode would be an use case that presets
could support in a way, but what I'd really like to ask is how much
advantage one can get by using this mode, say, vs. re-programming the same
settings over the I2C bus? The bus transfers (I assume) roughly 40 kB/s, so
I imagine a few tens of register writes can be avoided by most, taking
somewhere in the range of a few milliseconds.
As far as the timings are concerned, for this particular device, the
advantage is not really meaningful. We are talking about appr. 20
registers (~50 bytes on I2C bus), which is a ridiculously low number.
However, even if the interface isn't exposed to user space, in the
hardware there exist separate registers for preview and (still) capture
and it makes much sense in the driver to model this, for easier device
control.
How do you know when to switch the preset if you don't expose this to the
user space?
I don't, the user configuration data structure is there in the driver to more
precisely reflect the control interface of the device and better understand
what this driver supports and what it doesn't. Even if I use only one user
configuration register set _internally_ in the driver, there must be some
information provided to the device associated with it, like which user config
set we use, which clocks configuration applies to it, etc. Please don't make
me converting this driver to a total mess. :)
I'm not sure if this makes it easier for the user space. The user space must
know about such a think and aslo which parameters it applies to. I don't
Yes, I agree on this entirely.
think this ocnforms to V4L2 either, but I might have misunderstood
something.
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
Hi Sakari, On 09/27/2011 10:58 PM, Sakari Ailus wrote: On Tue, Sep 27, 2011 at 11:55:32PM +0300, Sakari Ailus wrote: Sylwester Nawrocki wrote: Hello Sakari, Hi Sylwester, What I forgot to ask was whether there is a public datasheet for this sensor? Unfortunately I'm not aware of any official website where you could get it. AFAIK some related materials are available on http://www.aesop.or.kr And, Google should have something to tell you about that too;) From what I can see all the now publicly available documentation is slightly outdated and less complete. Regards, -- Sylwester Nawrocki Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
On Monday, September 26, 2011 23:49:56 Sylwester Nawrocki wrote:
Hi Hans,
thanks for the comments. It's good to see you back, this mailing list
had been much more quiet when you've been away for a while;)
I hope everything got well for you.
On 09/26/2011 03:21 PM, Hans Verkuil wrote:
On Wednesday, September 21, 2011 19:45:07 Sylwester Nawrocki wrote:
This driver exposes preview mode operation of the S5K6AAFX sensor with
embedded SoC ISP. It uses one of the five user predefined configuration
register sets. There is yet no support for capture (snapshot) operation.
Following controls are supported:
manual/auto exposure and gain, power line frequency (anti-flicker),
saturation, sharpness, brightness, contrast, white balance temperature,
color effects, horizontal/vertical image flip, frame interval.
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
...
+/*
+ * V4L2 subdev core and video operations
+ */
+static int s5k6aa_set_power(struct v4l2_subdev *sd, int on)
+{
+ struct s5k6aa *s5k6aa = to_s5k6aa(sd);
+ int ret = 0;
+
+ mutex_lock(s5k6aa-lock);
+
+ if (!on == s5k6aa-power) {
+ if (on) {
+ ret = __s5k6aa_power_enable(s5k6aa);
+ if (!ret)
+ ret = s5k6aa_initialize_isp(sd);
+ } else {
+ ret = __s5k6aa_power_disable(s5k6aa);
+ }
+ }
+ if (!ret !WARN_ON(s5k6aa-power 0))
+ s5k6aa-power += on ? 1 : -1;
+ mutex_unlock(s5k6aa-lock);
+
+ if (!ret on s5k6aa-power == 1)
+ return v4l2_ctrl_handler_setup(sd-ctrl_handler);
+
+ return ret;
+}
+
+static int __s5k6aa_stream(struct s5k6aa *s5k6aa, int enable)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(s5k6aa-sd);
+ int ret;
+
+ ret = s5k6aa_write(client, REG_G_ENABLE_PREV, enable);
+ if (!ret)
+ ret = s5k6aa_write(client, REG_G_ENABLE_PREV_CHG, 1);
+ if (!ret)
+ ret = s5k6aa_write(client, REG_G_NEW_CFG_SYNC, 1);
+ if (!ret)
+ s5k6aa-streaming = enable;
+
+ return ret;
+}
+
+static int s5k6aa_s_stream(struct v4l2_subdev *sd, int on)
+{
+ struct s5k6aa *s5k6aa = to_s5k6aa(sd);
+ int ret = 0;
+
+ mutex_lock(s5k6aa-lock);
Stupid question perhaps, but why do you need a lock? Usually these calls are
serialized by the bridge driver. Most subdevs don't use a lock, unless they
start some thread of their own.
I wish I could get rid of the lock, but it seems necessary as long as the
device
can be accessed through two device nodes: /dev/video? and /dev/v4l-subdev?.
Ah yes, that's true.
It holds mostly for s_ctrl, which can be called on the subdev node, the other
subdev ops generally don't attempt to access I2C.
The control framework has its own locking, so s_ctrl is guaranteed to be
serialized.
So you don't need to lock there.
So this lock is also an I2C interface mutex ensuring correct configuration
registers read/write sequences. Especially nothing should be allowed to
interfere
with the ISP initialization routine, which is executed through s_power op at
the time of /dev/video? open().
Yes, adding device node to subdevs made things slightly more complicated :)
I need to look at this some more: see if we can support the core locking
mechanism for subdev nodes as well.
I wonder how other subdevs resolve the serialization without a lock.
They don't have their own device node :-)
+
+ if (!s5k6aa-streaming == !on) {
+ mutex_unlock(s5k6aa-lock);
+ return 0;
+ }
+ if (s5k6aa-apply_new_cfg)
+ ret = s5k6aa_set_preview_preset(s5k6aa, s5k6aa-preset);
+ if (!ret)
+ ret = __s5k6aa_stream(s5k6aa, !!on);
+
+ mutex_unlock(s5k6aa-lock);
+ return ret;
+}
+
+static int s5k6aa_g_frame_interval(struct v4l2_subdev *sd,
+ struct v4l2_subdev_frame_interval *fi)
+{
+ struct s5k6aa *s5k6aa = to_s5k6aa(sd);
+
+ memset(fi-reserved, 0, sizeof(fi-reserved));
+
+ mutex_lock(s5k6aa-lock);
+ fi-interval = s5k6aa-fiv-interval;
+ mutex_unlock(s5k6aa-lock);
+
+ return 0;
+}
+
+static int __s5k6aa_set_frame_interval(struct s5k6aa *s5k6aa,
+ struct v4l2_subdev_frame_interval *fi)
+{
+ struct v4l2_frmsize_discrete *out_win =s5k6aa-preset-out_size;
+ const struct s5k6aa_interval *fiv =s5k6aa_intervals[0];
+ unsigned int err, min_err = UINT_MAX;
+ unsigned int i, fr_time;
+
+ if (fi-interval.denominator == 0)
+ return -EINVAL;
+
+ memset(fi-reserved, 0, sizeof(fi-reserved));
+ fr_time = fi-interval.numerator * 1 / fi-interval.denominator;
+
+ for (i = 0; i ARRAY_SIZE(s5k6aa_intervals); i++) {
+ const struct s5k6aa_interval *iv =s5k6aa_intervals[i];
+
+ if (out_win-width
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
On 09/27/2011 09:14 AM, Hans Verkuil wrote:
On Monday, September 26, 2011 23:49:56 Sylwester Nawrocki wrote:
Hi Hans,
thanks for the comments. It's good to see you back, this mailing list
had been much more quiet when you've been away for a while;)
I hope everything got well for you.
On 09/26/2011 03:21 PM, Hans Verkuil wrote:
On Wednesday, September 21, 2011 19:45:07 Sylwester Nawrocki wrote:
This driver exposes preview mode operation of the S5K6AAFX sensor with
embedded SoC ISP. It uses one of the five user predefined configuration
register sets. There is yet no support for capture (snapshot) operation.
Following controls are supported:
manual/auto exposure and gain, power line frequency (anti-flicker),
saturation, sharpness, brightness, contrast, white balance temperature,
color effects, horizontal/vertical image flip, frame interval.
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
...
+/*
+ * V4L2 subdev core and video operations
+ */
+static int s5k6aa_set_power(struct v4l2_subdev *sd, int on)
+{
+ struct s5k6aa *s5k6aa = to_s5k6aa(sd);
+ int ret = 0;
+
+ mutex_lock(s5k6aa-lock);
+
+ if (!on == s5k6aa-power) {
+ if (on) {
+ ret = __s5k6aa_power_enable(s5k6aa);
+ if (!ret)
+ ret = s5k6aa_initialize_isp(sd);
+ } else {
+ ret = __s5k6aa_power_disable(s5k6aa);
+ }
+ }
+ if (!ret !WARN_ON(s5k6aa-power 0))
+ s5k6aa-power += on ? 1 : -1;
+ mutex_unlock(s5k6aa-lock);
+
+ if (!ret on s5k6aa-power == 1)
+ return v4l2_ctrl_handler_setup(sd-ctrl_handler);
+
+ return ret;
+}
+
+static int __s5k6aa_stream(struct s5k6aa *s5k6aa, int enable)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(s5k6aa-sd);
+ int ret;
+
+ ret = s5k6aa_write(client, REG_G_ENABLE_PREV, enable);
+ if (!ret)
+ ret = s5k6aa_write(client, REG_G_ENABLE_PREV_CHG, 1);
+ if (!ret)
+ ret = s5k6aa_write(client, REG_G_NEW_CFG_SYNC, 1);
+ if (!ret)
+ s5k6aa-streaming = enable;
+
+ return ret;
+}
+
+static int s5k6aa_s_stream(struct v4l2_subdev *sd, int on)
+{
+ struct s5k6aa *s5k6aa = to_s5k6aa(sd);
+ int ret = 0;
+
+ mutex_lock(s5k6aa-lock);
Stupid question perhaps, but why do you need a lock? Usually these calls are
serialized by the bridge driver. Most subdevs don't use a lock, unless they
start some thread of their own.
I wish I could get rid of the lock, but it seems necessary as long as the
device
can be accessed through two device nodes: /dev/video? and /dev/v4l-subdev?.
Ah yes, that's true.
It holds mostly for s_ctrl, which can be called on the subdev node, the other
subdev ops generally don't attempt to access I2C.
The control framework has its own locking, so s_ctrl is guaranteed to be
serialized.
Yup, I was aware of that.
So you don't need to lock there.
I still need the I2C mutex there, which is used to serialize the device I2C
interface access across various subdev ops, s_ctrl among others.
So this lock is also an I2C interface mutex ensuring correct configuration
registers read/write sequences. Especially nothing should be allowed to
interfere
with the ISP initialization routine, which is executed through s_power op at
the time of /dev/video? open().
Yes, adding device node to subdevs made things slightly more complicated :)
I need to look at this some more: see if we can support the core locking
mechanism for subdev nodes as well.
I think it could be useful to have an option to use the core lock. However
I guess it's not easy to implement as the drivers are quite independent.
Maybe it could be added somewhere around v4l2_device_register_subdev_nodes().
I wonder how other subdevs resolve the serialization without a lock.
They don't have their own device node :-)
Some of them have, IIRC.
+
+ if (!s5k6aa-streaming == !on) {
+ mutex_unlock(s5k6aa-lock);
+ return 0;
+ }
+ if (s5k6aa-apply_new_cfg)
+ ret = s5k6aa_set_preview_preset(s5k6aa, s5k6aa-preset);
+ if (!ret)
+ ret = __s5k6aa_stream(s5k6aa, !!on);
+
+ mutex_unlock(s5k6aa-lock);
+ return ret;
+}
+
+static int s5k6aa_g_frame_interval(struct v4l2_subdev *sd,
+ struct v4l2_subdev_frame_interval *fi)
+{
+ struct s5k6aa *s5k6aa = to_s5k6aa(sd);
+
+ memset(fi-reserved, 0, sizeof(fi-reserved));
+
+ mutex_lock(s5k6aa-lock);
+ fi-interval = s5k6aa-fiv-interval;
+ mutex_unlock(s5k6aa-lock);
+
+ return 0;
+}
+
+static int __s5k6aa_set_frame_interval(struct s5k6aa *s5k6aa,
+ struct v4l2_subdev_frame_interval *fi)
+{
+ struct v4l2_frmsize_discrete *out_win =s5k6aa-preset-out_size;
+ const struct s5k6aa_interval *fiv =s5k6aa_intervals[0];
+ unsigned int err, min_err = UINT_MAX;
+ unsigned int i,
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
Sylwester Nawrocki wrote:
Hello Sakari,
Hi Sylwester,
On 09/25/2011 12:08 PM, Sakari Ailus wrote:
On Fri, Sep 23, 2011 at 12:12:58PM +0200, Sylwester Nawrocki wrote:
On 09/23/2011 12:02 AM, Sakari Ailus wrote:
Hi Sylwester,
I have a few additional comments below, they don't depend on my earlier
ones.
Thanks a lot for your follow up review!
On Wed, Sep 21, 2011 at 07:45:07PM +0200, Sylwester Nawrocki wrote:
This driver exposes preview mode operation of the S5K6AAFX sensor with
embedded SoC ISP. It uses one of the five user predefined configuration
register sets. There is yet no support for capture (snapshot) operation.
Following controls are supported:
manual/auto exposure and gain, power line frequency (anti-flicker),
saturation, sharpness, brightness, contrast, white balance temperature,
color effects, horizontal/vertical image flip, frame interval.
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
...
+
+struct s5k6aa_pixfmt {
+ enum v4l2_mbus_pixelcode code;
+ u32 colorspace;
+ /* REG_P_FMT(x) register value */
+ u16 reg_p_fmt;
+};
+
+struct s5k6aa_preset {
+ struct v4l2_frmsize_discrete out_size;
+ struct v4l2_rect in_win;
+ const struct s5k6aa_pixfmt *pixfmt;
+ unsigned int inv_hflip:1;
+ unsigned int inv_vflip:1;
+ u8 frame_rate_type;
+ u8 index;
+};
+
[clip]
+/* Set initial values for all preview presets */
+static void s5k6aa_presets_data_init(struct s5k6aa *s5k6aa,
+ int hflip, int vflip)
+{
+ struct s5k6aa_preset *preset =s5k6aa-presets[0];
+ int i;
+
+ for (i = 0; i S5K6AA_MAX_PRESETS; i++) {
+ preset-pixfmt =s5k6aa_formats[0];
+ preset-frame_rate_type = FR_RATE_DYNAMIC;
+ preset-inv_hflip = hflip;
+ preset-inv_vflip = vflip;
+ preset-out_size.width = S5K6AA_OUT_WIDTH_DEF;
+ preset-out_size.height = S5K6AA_OUT_HEIGHT_DEF;
+ preset-in_win.width= S5K6AA_WIN_WIDTH_MAX;
+ preset-in_win.height = S5K6AA_WIN_HEIGHT_MAX;
+ preset-in_win.left = 0;
+ preset-in_win.top = 0;
Much of this data is static, why is it copied to the presets struct?
What is the intended purpose of these presets?
I agree there is no need to keep inv_hflip/inv_vflip there. It's more a
leftover from previous driver version. I'll move it to struct s5k6aa.
And I try to keep copy of each platform_data attribute in driver's
private struct to make future transition to DT driver probing easier.
inv_[hv]flip variables are used to indicate physical layout of the sensor,
as it varies across multiple machines. So indeed they're global, not per
the configuration set.
Preset are there in the s5k6aafx register interface to allow fast transition
between, for instance, low resolution preview and high resolution snapshot.
I'm planning to use this driver as an experimental rabbit for the future
snapshot mode API.
It sounds like that a snapshot mode would be an use case that presets
could support in a way, but what I'd really like to ask is how much
advantage one can get by using this mode, say, vs. re-programming the same
settings over the I2C bus? The bus transfers (I assume) roughly 40 kB/s, so
I imagine a few tens of register writes can be avoided by most, taking
somewhere in the range of a few milliseconds.
As far as the timings are concerned, for this particular device, the
advantage is not really meaningful. We are talking about appr. 20
registers (~50 bytes on I2C bus), which is a ridiculously low number.
However, even if the interface isn't exposed to user space, in the
hardware there exist separate registers for preview and (still) capture
and it makes much sense in the driver to model this, for easier device
control.
How do you know when to switch the preset if you don't expose this to the
user space?
I'm not sure if this makes it easier for the user space. The user space must
know about such a think and aslo which parameters it applies to. I don't
think this ocnforms to V4L2 either, but I might have misunderstood
something.
Anyway, I've taken a closer look at what I need in the single user
configuration set data structure and reworked the driver quite
extensively. Should post that in the coming week, unless some unexpected
disasters occur;)
Do you see any problem in defining real still capture interface in V4L ?
It's probably just a small set of new controls, new capability, plus
multi-size buffer queue Guennadi has been working on. Some devices will
require explicitly switching between preview and capture mode, and it may
make difference if they are programmed in advance or on demand.
I don't think V4L2 should have a still capture interface. Still capture is
just one use case as viewfinder and video. V4L2 deals with frames, formats
and parameters that are all generic and use case independent. Instead of use
cases, we
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
On Tue, Sep 27, 2011 at 11:55:32PM +0300, Sakari Ailus wrote: Sylwester Nawrocki wrote: Hello Sakari, Hi Sylwester, What I forgot to ask was whether there is a public datasheet for this sensor? Regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
On Wednesday, September 21, 2011 19:45:07 Sylwester Nawrocki wrote: This driver exposes preview mode operation of the S5K6AAFX sensor with embedded SoC ISP. It uses one of the five user predefined configuration register sets. There is yet no support for capture (snapshot) operation. Following controls are supported: manual/auto exposure and gain, power line frequency (anti-flicker), saturation, sharpness, brightness, contrast, white balance temperature, color effects, horizontal/vertical image flip, frame interval. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/s5k6aa.c | 1482 ++ include/media/s5k6aa.h | 51 ++ 4 files changed, 1541 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/s5k6aa.c create mode 100644 include/media/s5k6aa.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 9da6044..ccc8172 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -496,6 +496,13 @@ config VIDEO_TCM825X This is a driver for the Toshiba TCM825x VGA camera sensor. It is used for example in Nokia N800. +config VIDEO_S5K6AA + tristate Samsung S5K6AAFX sensor support + depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + ---help--- + This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M + camera sensor with an embedded SoC image signal processor. + comment Flash devices config VIDEO_ADP1653 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index f52a771..526cb32 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o obj-$(CONFIG_VIDEO_SR030PC30)+= sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30) += noon010pc30.o obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/ +obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o obj-$(CONFIG_VIDEO_ADP1653) += adp1653.o obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074.o diff --git a/drivers/media/video/s5k6aa.c b/drivers/media/video/s5k6aa.c new file mode 100644 index 000..43b7dac --- /dev/null +++ b/drivers/media/video/s5k6aa.c @@ -0,0 +1,1482 @@ +/* + * Driver for Samsung S5K6AAFX SXGA 1/6 1.3M CMOS Image Sensor + * with embedded SoC ISP. + * + * Copyright (C) 2011, Samsung Electronics Co., Ltd. + * Author: Sylwester Nawrocki s.nawro...@samsung.com + * + * Based on a driver authored by Dongsoo Nathaniel Kim. + * Copyright (C) 2009, Dongsoo Nathaniel Kim dongsoo45@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * TODO: + * - add set/get_crop operations + * - add capture (snapshot) mode support + */ + +#include linux/clk.h +#include linux/delay.h +#include linux/gpio.h +#include linux/i2c.h +#include linux/media.h +#include linux/regulator/consumer.h +#include linux/slab.h + +#include media/media-entity.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-subdev.h +#include media/v4l2-mediabus.h +#include media/s5k6aa.h + +static int debug; +module_param(debug, int, 0644); + +#define DRIVER_NAME S5K6AA + +/* The token to indicate array termination */ +#define S5K6AA_TERM 0x +#define S5K6AA_OUT_WIDTH_DEF 640 +#define S5K6AA_OUT_HEIGHT_DEF480 +#define S5K6AA_WIN_WIDTH_MAX 1280 +#define S5K6AA_WIN_HEIGHT_MAX1024 +#define S5K6AA_WIN_WIDTH_MIN 8 +#define S5K6AA_WIN_HEIGHT_MIN8 + +/* + * H/W register Interface (0xD000 - 0xDFFF) + */ +#define AHB_MSB_ADDR_PTR 0xfcfc +#define GEN_REG_OFFSH0xd000 +#define REG_SW_RESET 0x0010 +#define REG_SW_LOAD_COMPLETE 0x0014 +#define REG_CMDWR_ADDRH 0x0028 +#define REG_CMDWR_ADDRL 0x002a +#define REG_CMDRD_ADDRH 0x002c +#define REG_CMDRD_ADDRL 0x002e + +#define REG_CMDBUF0_ADDR 0x0f12 +#define REG_CMDBUF1_ADDR 0x0f10 + +/* + * Host S/W Register interface (0x7000 - 0x70002000) + * The value of the two most significant address bytes is 0x7000, + * (HOST_SWIF_OFFS_H). The register addresses below specify 2 LSBs. + */ +#define HOST_SWIF_OFFSH 0x7000 + +/* Initialization parameters */ +/* Master clock frequency in KHz */ +#define REG_I_INCLK_FREQ_L 0x01b8 +#define REG_I_INCLK_FREQ_H 0x01ba +#define
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
Hi Hans,
thanks for the comments. It's good to see you back, this mailing list
had been much more quiet when you've been away for a while;)
I hope everything got well for you.
On 09/26/2011 03:21 PM, Hans Verkuil wrote:
On Wednesday, September 21, 2011 19:45:07 Sylwester Nawrocki wrote:
This driver exposes preview mode operation of the S5K6AAFX sensor with
embedded SoC ISP. It uses one of the five user predefined configuration
register sets. There is yet no support for capture (snapshot) operation.
Following controls are supported:
manual/auto exposure and gain, power line frequency (anti-flicker),
saturation, sharpness, brightness, contrast, white balance temperature,
color effects, horizontal/vertical image flip, frame interval.
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
...
+/*
+ * V4L2 subdev core and video operations
+ */
+static int s5k6aa_set_power(struct v4l2_subdev *sd, int on)
+{
+struct s5k6aa *s5k6aa = to_s5k6aa(sd);
+int ret = 0;
+
+mutex_lock(s5k6aa-lock);
+
+if (!on == s5k6aa-power) {
+if (on) {
+ret = __s5k6aa_power_enable(s5k6aa);
+if (!ret)
+ret = s5k6aa_initialize_isp(sd);
+} else {
+ret = __s5k6aa_power_disable(s5k6aa);
+}
+}
+if (!ret !WARN_ON(s5k6aa-power 0))
+s5k6aa-power += on ? 1 : -1;
+mutex_unlock(s5k6aa-lock);
+
+if (!ret on s5k6aa-power == 1)
+return v4l2_ctrl_handler_setup(sd-ctrl_handler);
+
+return ret;
+}
+
+static int __s5k6aa_stream(struct s5k6aa *s5k6aa, int enable)
+{
+struct i2c_client *client = v4l2_get_subdevdata(s5k6aa-sd);
+int ret;
+
+ret = s5k6aa_write(client, REG_G_ENABLE_PREV, enable);
+if (!ret)
+ret = s5k6aa_write(client, REG_G_ENABLE_PREV_CHG, 1);
+if (!ret)
+ret = s5k6aa_write(client, REG_G_NEW_CFG_SYNC, 1);
+if (!ret)
+s5k6aa-streaming = enable;
+
+return ret;
+}
+
+static int s5k6aa_s_stream(struct v4l2_subdev *sd, int on)
+{
+struct s5k6aa *s5k6aa = to_s5k6aa(sd);
+int ret = 0;
+
+mutex_lock(s5k6aa-lock);
Stupid question perhaps, but why do you need a lock? Usually these calls are
serialized by the bridge driver. Most subdevs don't use a lock, unless they
start some thread of their own.
I wish I could get rid of the lock, but it seems necessary as long as the device
can be accessed through two device nodes: /dev/video? and /dev/v4l-subdev?.
It holds mostly for s_ctrl, which can be called on the subdev node, the other
subdev ops generally don't attempt to access I2C.
So this lock is also an I2C interface mutex ensuring correct configuration
registers read/write sequences. Especially nothing should be allowed to
interfere
with the ISP initialization routine, which is executed through s_power op at
the time of /dev/video? open().
Yes, adding device node to subdevs made things slightly more complicated :)
I wonder how other subdevs resolve the serialization without a lock.
+
+if (!s5k6aa-streaming == !on) {
+mutex_unlock(s5k6aa-lock);
+return 0;
+}
+if (s5k6aa-apply_new_cfg)
+ret = s5k6aa_set_preview_preset(s5k6aa, s5k6aa-preset);
+if (!ret)
+ret = __s5k6aa_stream(s5k6aa, !!on);
+
+mutex_unlock(s5k6aa-lock);
+return ret;
+}
+
+static int s5k6aa_g_frame_interval(struct v4l2_subdev *sd,
+ struct v4l2_subdev_frame_interval *fi)
+{
+struct s5k6aa *s5k6aa = to_s5k6aa(sd);
+
+memset(fi-reserved, 0, sizeof(fi-reserved));
+
+mutex_lock(s5k6aa-lock);
+fi-interval = s5k6aa-fiv-interval;
+mutex_unlock(s5k6aa-lock);
+
+return 0;
+}
+
+static int __s5k6aa_set_frame_interval(struct s5k6aa *s5k6aa,
+ struct v4l2_subdev_frame_interval *fi)
+{
+struct v4l2_frmsize_discrete *out_win =s5k6aa-preset-out_size;
+const struct s5k6aa_interval *fiv =s5k6aa_intervals[0];
+unsigned int err, min_err = UINT_MAX;
+unsigned int i, fr_time;
+
+if (fi-interval.denominator == 0)
+return -EINVAL;
+
+memset(fi-reserved, 0, sizeof(fi-reserved));
+fr_time = fi-interval.numerator * 1 / fi-interval.denominator;
+
+for (i = 0; i ARRAY_SIZE(s5k6aa_intervals); i++) {
+const struct s5k6aa_interval *iv =s5k6aa_intervals[i];
+
+if (out_win-width iv-size.width ||
+out_win-height iv-size.height)
+continue;
+
+err = abs(iv-reg_fr_time - fr_time);
+if (err min_err) {
+fiv = iv;
+min_err = err;
+}
+}
+s5k6aa-fiv = fiv;
+
+v4l2_dbg(1, debug,s5k6aa-sd, Changed frame interval to %d us\n,
+
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
On Fri, Sep 23, 2011 at 12:12:58PM +0200, Sylwester Nawrocki wrote:
Hi Sakari,
Hi Sylwester,
On 09/23/2011 12:02 AM, Sakari Ailus wrote:
Hi Sylwester,
I have a few additional comments below, they don't depend on my earlier
ones.
Thanks a lot for your follow up review!
On Wed, Sep 21, 2011 at 07:45:07PM +0200, Sylwester Nawrocki wrote:
This driver exposes preview mode operation of the S5K6AAFX sensor with
embedded SoC ISP. It uses one of the five user predefined configuration
register sets. There is yet no support for capture (snapshot) operation.
Following controls are supported:
manual/auto exposure and gain, power line frequency (anti-flicker),
saturation, sharpness, brightness, contrast, white balance temperature,
color effects, horizontal/vertical image flip, frame interval.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
...
+
+struct s5k6aa_pixfmt {
+ enum v4l2_mbus_pixelcode code;
+ u32 colorspace;
+ /* REG_P_FMT(x) register value */
+ u16 reg_p_fmt;
+};
+
+struct s5k6aa_preset {
+ struct v4l2_frmsize_discrete out_size;
+ struct v4l2_rect in_win;
+ const struct s5k6aa_pixfmt *pixfmt;
+ unsigned int inv_hflip:1;
+ unsigned int inv_vflip:1;
+ u8 frame_rate_type;
+ u8 index;
+};
+
[clip]
+/* Set initial values for all preview presets */
+static void s5k6aa_presets_data_init(struct s5k6aa *s5k6aa,
+ int hflip, int vflip)
+{
+ struct s5k6aa_preset *preset = s5k6aa-presets[0];
+ int i;
+
+ for (i = 0; i S5K6AA_MAX_PRESETS; i++) {
+ preset-pixfmt = s5k6aa_formats[0];
+ preset-frame_rate_type = FR_RATE_DYNAMIC;
+ preset-inv_hflip = hflip;
+ preset-inv_vflip = vflip;
+ preset-out_size.width = S5K6AA_OUT_WIDTH_DEF;
+ preset-out_size.height = S5K6AA_OUT_HEIGHT_DEF;
+ preset-in_win.width= S5K6AA_WIN_WIDTH_MAX;
+ preset-in_win.height = S5K6AA_WIN_HEIGHT_MAX;
+ preset-in_win.left = 0;
+ preset-in_win.top = 0;
Much of this data is static, why is it copied to the presets struct?
What is the intended purpose of these presets?
I agree there is no need to keep inv_hflip/inv_vflip there. It's more a
leftover from previous driver version. I'll move it to struct s5k6aa.
And I try to keep copy of each platform_data attribute in driver's
private struct to make future transition to DT driver probing easier.
inv_[hv]flip variables are used to indicate physical layout of the sensor,
as it varies across multiple machines. So indeed they're global, not per
the configuration set.
Preset are there in the s5k6aafx register interface to allow fast transition
between, for instance, low resolution preview and high resolution snapshot.
I'm planning to use this driver as an experimental rabbit for the future
snapshot mode API.
It sounds like that a snapshot mode would be an use case that presets
could support in a way, but what I'd really like to ask is how much
advantage one can get by using this mode, say, vs. re-programming the same
settings over the I2C bus? The bus transfers (I assume) roughly 40 kB/s, so
I imagine a few tens of register writes can be avoided by most, taking
somewhere in the range of a few milliseconds.
I would rather measure and attempt to optimise the register writes in the
driver first before adding complexity to user space interface.
Or do the presets provide other advantages than just storing configurations?
in_win field is there for cropping support. So for now it's static data,
but this will change. I've covered pretty much functionality of the device
in this driver and I'd like to have it in mainline at this stage.
I've spent pretty much time on this driver, trying to figure out some
things on trial and error basis.
[clip]
+
+/* Set horizontal and vertical image flipping */
+static int s5k6aa_set_mirror(struct s5k6aa *s5k6aa, int horiz_flip)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(s5k6aa-sd);
+ struct s5k6aa_preset *preset = s5k6aa-preset;
+
+ unsigned int vflip = s5k6aa-ctrls.vflip-val ^ preset-inv_vflip;
+ unsigned int hflip = horiz_flip ^ preset-inv_hflip;
I don't see a need to store inv_hflip to presets. Instead, you might just
have a mirror bit in the platform data.
Agreed, except I'd like to keep that in driver's private data structure,
not to rely on the platform data after the driver probing.
There's no reason to avoid using platform data after probing that I am aware
of.
+ return s5k6aa_write(client, REG_P_PREV_MIRROR(preset-index),
+ hflip | (vflip 1));
+}
+
...
+
+static int __s5k6aa_power_enable(struct s5k6aa *s5k6aa)
+{
+ int ret;
+
+ ret = regulator_bulk_enable(S5K6AA_NUM_SUPPLIES, s5k6aa-supplies);
+
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
Hi Sakari,
On 09/23/2011 12:02 AM, Sakari Ailus wrote:
Hi Sylwester,
I have a few additional comments below, they don't depend on my earlier
ones.
Thanks a lot for your follow up review!
On Wed, Sep 21, 2011 at 07:45:07PM +0200, Sylwester Nawrocki wrote:
This driver exposes preview mode operation of the S5K6AAFX sensor with
embedded SoC ISP. It uses one of the five user predefined configuration
register sets. There is yet no support for capture (snapshot) operation.
Following controls are supported:
manual/auto exposure and gain, power line frequency (anti-flicker),
saturation, sharpness, brightness, contrast, white balance temperature,
color effects, horizontal/vertical image flip, frame interval.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
...
+
+struct s5k6aa_pixfmt {
+enum v4l2_mbus_pixelcode code;
+u32 colorspace;
+/* REG_P_FMT(x) register value */
+u16 reg_p_fmt;
+};
+
+struct s5k6aa_preset {
+struct v4l2_frmsize_discrete out_size;
+struct v4l2_rect in_win;
+const struct s5k6aa_pixfmt *pixfmt;
+unsigned int inv_hflip:1;
+unsigned int inv_vflip:1;
+u8 frame_rate_type;
+u8 index;
+};
+
+/* Not all controls supported by the driver are in this struct. */
+struct s5k6aa_ctrls {
+struct v4l2_ctrl_handler handler;
+/* Mirror cluster */
+struct v4l2_ctrl *hflip;
+struct v4l2_ctrl *vflip;
+/* Auto exposure / manual exposure and gain cluster */
+struct v4l2_ctrl *auto_exp;
+struct v4l2_ctrl *exposure;
+struct v4l2_ctrl *gain;
+};
+
+struct s5k6aa_interval {
+u16 reg_fr_time;
+struct v4l2_fract interval;
+/* Maximum rectangle for the interval */
+struct v4l2_frmsize_discrete size;
+};
+
+struct s5k6aa {
+struct v4l2_subdev sd;
+struct media_pad pad;
+
+enum v4l2_mbus_type bus_type;
+u8 mipi_lanes;
+
+int (*s_power)(int enable);
+struct regulator_bulk_data supplies[S5K6AA_NUM_SUPPLIES];
+struct s5k6aa_gpio gpio[GPIO_NUM];
+
+/* master clock frequency */
+unsigned long mclk_frequency;
+u16 clk_fop;
+u16 clk_fmin;
+u16 clk_fmax;
+
+/* protects the struct members below */
+struct mutex lock;
+
+struct s5k6aa_ctrls ctrls;
+struct s5k6aa_preset presets[S5K6AA_MAX_PRESETS];
+struct s5k6aa_preset *preset;
+const struct s5k6aa_interval *fiv;
+
+unsigned int streaming:1;
+unsigned int apply_new_cfg:1;
+unsigned int power;
+};
+
+static struct s5k6aa_regval s5k6aa_analog_config[] = {
+/* Analog settings */
+{ 0x112A, 0x }, { 0x1132, 0x },
+{ 0x113E, 0x }, { 0x115C, 0x },
+{ 0x1164, 0x }, { 0x1174, 0x },
+{ 0x1178, 0x }, { 0x077A, 0x },
+{ 0x077C, 0x }, { 0x077E, 0x },
+{ 0x0780, 0x }, { 0x0782, 0x },
+{ 0x0784, 0x }, { 0x0786, 0x },
+{ 0x0788, 0x }, { 0x07A2, 0x },
+{ 0x07A4, 0x }, { 0x07A6, 0x },
+{ 0x07A8, 0x }, { 0x07B6, 0x },
+{ 0x07B8, 0x0002 }, { 0x07BA, 0x0004 },
+{ 0x07BC, 0x0004 }, { 0x07BE, 0x0005 },
+{ 0x07C0, 0x0005 }, { S5K6AA_TERM, 0 },
A number of the hexadecimals are upper case. Should be lower.
opps, looking at this so many times still missed that:) I'll fix it.
+};
+
+/* TODO: Add RGB888 and Bayer format */
+static const struct s5k6aa_pixfmt s5k6aa_formats[] = {
+{ V4L2_MBUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_JPEG, 5 },
+/* range 16-240 */
+{ V4L2_MBUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_REC709, 6 },
+{ V4L2_MBUS_FMT_RGB565_2X8_BE, V4L2_COLORSPACE_JPEG, 0 },
+};
+
+static const struct s5k6aa_interval s5k6aa_intervals[] = {
+{ 1000, {1, 100}, {1280, 1024} }, /* 10 fps */
+{ 666, {15000, 100}, {1280, 1024} }, /* 15 fps */
+{ 500, {2, 100}, {1280, 720} }, /* 20 fps */
+{ 400, {25000, 100}, {640, 480} }, /* 25 fps */
+{ 333, {33300, 100}, {640, 480} }, /* 30 fps */
+};
+
+#define S5K6AA_INTERVAL_DEF_INDEX 1 /* 15 fps */
+
+static struct v4l2_subdev *ctrl_to_sd(struct v4l2_ctrl *ctrl)
+{
+return container_of(ctrl-handler, struct s5k6aa, ctrls.handler)-sd;
+}
+
+static struct s5k6aa *to_s5k6aa(struct v4l2_subdev *sd)
+{
+return container_of(sd, struct s5k6aa, sd);
+}
+
+/* Set initial values for all preview presets */
+static void s5k6aa_presets_data_init(struct s5k6aa *s5k6aa,
+ int hflip, int vflip)
+{
+struct s5k6aa_preset *preset = s5k6aa-presets[0];
+int i;
+
+for (i = 0; i S5K6AA_MAX_PRESETS; i++) {
+preset-pixfmt = s5k6aa_formats[0];
+preset-frame_rate_type = FR_RATE_DYNAMIC;
+preset-inv_hflip = hflip;
+preset-inv_vflip = vflip;
+preset-out_size.width =
Re: [PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
Hi Sylwester, I have a few additional comments below, they don't depend on my earlier ones. On Wed, Sep 21, 2011 at 07:45:07PM +0200, Sylwester Nawrocki wrote: This driver exposes preview mode operation of the S5K6AAFX sensor with embedded SoC ISP. It uses one of the five user predefined configuration register sets. There is yet no support for capture (snapshot) operation. Following controls are supported: manual/auto exposure and gain, power line frequency (anti-flicker), saturation, sharpness, brightness, contrast, white balance temperature, color effects, horizontal/vertical image flip, frame interval. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/s5k6aa.c | 1482 ++ include/media/s5k6aa.h | 51 ++ 4 files changed, 1541 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/s5k6aa.c create mode 100644 include/media/s5k6aa.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 9da6044..ccc8172 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -496,6 +496,13 @@ config VIDEO_TCM825X This is a driver for the Toshiba TCM825x VGA camera sensor. It is used for example in Nokia N800. +config VIDEO_S5K6AA + tristate Samsung S5K6AAFX sensor support + depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + ---help--- + This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M + camera sensor with an embedded SoC image signal processor. + comment Flash devices config VIDEO_ADP1653 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index f52a771..526cb32 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o obj-$(CONFIG_VIDEO_SR030PC30)+= sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30) += noon010pc30.o obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/ +obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o obj-$(CONFIG_VIDEO_ADP1653) += adp1653.o obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074.o diff --git a/drivers/media/video/s5k6aa.c b/drivers/media/video/s5k6aa.c new file mode 100644 index 000..43b7dac --- /dev/null +++ b/drivers/media/video/s5k6aa.c @@ -0,0 +1,1482 @@ +/* + * Driver for Samsung S5K6AAFX SXGA 1/6 1.3M CMOS Image Sensor + * with embedded SoC ISP. + * + * Copyright (C) 2011, Samsung Electronics Co., Ltd. + * Author: Sylwester Nawrocki s.nawro...@samsung.com + * + * Based on a driver authored by Dongsoo Nathaniel Kim. + * Copyright (C) 2009, Dongsoo Nathaniel Kim dongsoo45@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * TODO: + * - add set/get_crop operations + * - add capture (snapshot) mode support + */ + +#include linux/clk.h +#include linux/delay.h +#include linux/gpio.h +#include linux/i2c.h +#include linux/media.h +#include linux/regulator/consumer.h +#include linux/slab.h + +#include media/media-entity.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-subdev.h +#include media/v4l2-mediabus.h +#include media/s5k6aa.h + +static int debug; +module_param(debug, int, 0644); + +#define DRIVER_NAME S5K6AA + +/* The token to indicate array termination */ +#define S5K6AA_TERM 0x +#define S5K6AA_OUT_WIDTH_DEF 640 +#define S5K6AA_OUT_HEIGHT_DEF480 +#define S5K6AA_WIN_WIDTH_MAX 1280 +#define S5K6AA_WIN_HEIGHT_MAX1024 +#define S5K6AA_WIN_WIDTH_MIN 8 +#define S5K6AA_WIN_HEIGHT_MIN8 + +/* + * H/W register Interface (0xD000 - 0xDFFF) + */ +#define AHB_MSB_ADDR_PTR 0xfcfc +#define GEN_REG_OFFSH0xd000 +#define REG_SW_RESET 0x0010 +#define REG_SW_LOAD_COMPLETE 0x0014 +#define REG_CMDWR_ADDRH 0x0028 +#define REG_CMDWR_ADDRL 0x002a +#define REG_CMDRD_ADDRH 0x002c +#define REG_CMDRD_ADDRL 0x002e + +#define REG_CMDBUF0_ADDR 0x0f12 +#define REG_CMDBUF1_ADDR 0x0f10 + +/* + * Host S/W Register interface (0x7000 - 0x70002000) + * The value of the two most significant address bytes is 0x7000, + * (HOST_SWIF_OFFS_H). The register addresses below specify 2 LSBs. + */ +#define HOST_SWIF_OFFSH 0x7000 + +/* Initialization parameters */ +/* Master clock frequency in KHz */ +#define
[PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
This driver exposes preview mode operation of the S5K6AAFX sensor with embedded SoC ISP. It uses one of the five user predefined configuration register sets. There is yet no support for capture (snapshot) operation. Following controls are supported: manual/auto exposure and gain, power line frequency (anti-flicker), saturation, sharpness, brightness, contrast, white balance temperature, color effects, horizontal/vertical image flip, frame interval. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/s5k6aa.c | 1482 ++ include/media/s5k6aa.h | 51 ++ 4 files changed, 1541 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/s5k6aa.c create mode 100644 include/media/s5k6aa.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 9da6044..ccc8172 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -496,6 +496,13 @@ config VIDEO_TCM825X This is a driver for the Toshiba TCM825x VGA camera sensor. It is used for example in Nokia N800. +config VIDEO_S5K6AA + tristate Samsung S5K6AAFX sensor support + depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + ---help--- + This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M + camera sensor with an embedded SoC image signal processor. + comment Flash devices config VIDEO_ADP1653 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index f52a771..526cb32 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/ +obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o diff --git a/drivers/media/video/s5k6aa.c b/drivers/media/video/s5k6aa.c new file mode 100644 index 000..43b7dac --- /dev/null +++ b/drivers/media/video/s5k6aa.c @@ -0,0 +1,1482 @@ +/* + * Driver for Samsung S5K6AAFX SXGA 1/6 1.3M CMOS Image Sensor + * with embedded SoC ISP. + * + * Copyright (C) 2011, Samsung Electronics Co., Ltd. + * Author: Sylwester Nawrocki s.nawro...@samsung.com + * + * Based on a driver authored by Dongsoo Nathaniel Kim. + * Copyright (C) 2009, Dongsoo Nathaniel Kim dongsoo45@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * TODO: + * - add set/get_crop operations + * - add capture (snapshot) mode support + */ + +#include linux/clk.h +#include linux/delay.h +#include linux/gpio.h +#include linux/i2c.h +#include linux/media.h +#include linux/regulator/consumer.h +#include linux/slab.h + +#include media/media-entity.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-subdev.h +#include media/v4l2-mediabus.h +#include media/s5k6aa.h + +static int debug; +module_param(debug, int, 0644); + +#define DRIVER_NAMES5K6AA + +/* The token to indicate array termination */ +#define S5K6AA_TERM0x +#define S5K6AA_OUT_WIDTH_DEF 640 +#define S5K6AA_OUT_HEIGHT_DEF 480 +#define S5K6AA_WIN_WIDTH_MAX 1280 +#define S5K6AA_WIN_HEIGHT_MAX 1024 +#define S5K6AA_WIN_WIDTH_MIN 8 +#define S5K6AA_WIN_HEIGHT_MIN 8 + +/* + * H/W register Interface (0xD000 - 0xDFFF) + */ +#define AHB_MSB_ADDR_PTR 0xfcfc +#define GEN_REG_OFFSH 0xd000 +#define REG_SW_RESET 0x0010 +#define REG_SW_LOAD_COMPLETE 0x0014 +#define REG_CMDWR_ADDRH0x0028 +#define REG_CMDWR_ADDRL0x002a +#define REG_CMDRD_ADDRH0x002c +#define REG_CMDRD_ADDRL0x002e + +#define REG_CMDBUF0_ADDR 0x0f12 +#define REG_CMDBUF1_ADDR 0x0f10 + +/* + * Host S/W Register interface (0x7000 - 0x70002000) + * The value of the two most significant address bytes is 0x7000, + * (HOST_SWIF_OFFS_H). The register addresses below specify 2 LSBs. + */ +#define HOST_SWIF_OFFSH0x7000 + +/* Initialization parameters */ +/* Master clock frequency in KHz */ +#define REG_I_INCLK_FREQ_L 0x01b8 +#define REG_I_INCLK_FREQ_H 0x01ba +#define REG_I_USE_NPVI_CLOCKS 0x01c6 +#define REG_I_USE_NMIPI_CLOCKS 0x01c8 + +/* Clock configurations, n = 0..3. REG_I_* frequency unit is 4 kHz. */ +#define
