Re: v4l2-compliance utility
On Saturday, January 22, 2011 00:35:19 Andy Walls wrote: On Fri, 2011-01-21 at 23:37 +0100, Hans Verkuil wrote: Hi all, As you may have seen I have been adding a lot of tests to the v4l2-compliance utility in v4l-utils lately. It is now getting to the state that is becomes quite useful even though there is no full coverage yet. Currently the following ioctls are being tested: Hans, This is a great thing to have. Thanks! Also tested is whether you can open device nodes multiple times. These tests are pretty exhaustive and more strict than the spec itself. OK, so multiple open is not strictly required by the spec, IIRC. If you check the ivtv /dev/radio node, it does not allow multiple open, IIRC, so it should not get OK for that test. And indeed it fails on that test. I also think during the subdev conversion, some of the less popular ivtv cards with GPIO controlled radio audio may have been broken (and still not fixed yet :( ), but working for the PVR-150, PVR-500, etc.. What the tool does not do of course is test if your driver actually works. So it tests if you can e.g. set the audio output to some value, but whether you actually get audio on that output is a completely separate matter :-) The DEBUG ioctl()s can be compiled out too. In that case the tool should report 'Not Supported'. So for someone making decisions based on the output of this tool: 1. if something comes back as Not supported, that still means the driver is API specification compliant, right? Yes. And as far as the compliance tool is concerned the driver tells it that it doesn't support that particular API. E.g. a card without a tuner should report 'Not Supported' for the S/G_TUNER tests. 2. could it be the case that this compliance tool will be sensitive to the driver/hardware combination and not the driver alone? Definitely. If certain features (e.g. a tuner) are only available on certain cards, then the tool can only test what the hardware you use at the moment supports. The utility tests whether, for the current kernel configuration, driver and hardware, the V4L2 device node works as it should. Regards, Hans -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.39] Switch cpia2 and pwc to video_ioctl2
Tested with pwc, but we still have no hardware for cpia2 so that is untested. But the changes are pretty straightforward. Regards, Hans The following changes since commit cf720fed25b8078ce0d6a10036dbf7a0baded679: Mauro Carvalho Chehab (1): [media] add support for Encore FM3 are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git ioctl2 Hans Verkuil (3): pwc: convert to core-assisted locking pwc: convert to video_ioctl2 cpia2: convert to video_ioctl2 drivers/media/video/cpia2/cpia2_v4l.c | 373 drivers/media/video/pwc/pwc-if.c | 38 +- drivers/media/video/pwc/pwc-v4l.c | 1032 - drivers/media/video/pwc/pwc.h |3 +- 4 files changed, 623 insertions(+), 823 deletions(-) -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Add support for M5MO-LS 8 Mega Pixel camera
Hello,
This is second patch of I2C/V4L2 subdev driver for M5MOLS 8 Mega Pixel camera
sensor using MIPI interface.
The first version patch is here:
http://www.spinics.net/lists/linux-media/msg26246.html
And the first verion's issues was corrected referencing with quick reviews of
Hans Verkuil and Sylwester Nawrocki.
The main issues is below:
1. remove I2C function macro, and use static inline for type-safe.
2. use the v4l2 control framework documented at v4l2-control.txt.
3. Add regulator enable/disable functions
4. fix any coding problems
The driver supports currently that:
1. Preview enables on each resolution and format code V4L2_MBUS_FMT_VYUY8_2X8.
2. The 5 kind of control was working well.
This driver is tested on s5pc210 board using s5p-fimc driver.
Thanks to any ideas.
Regrads,
Heungjun Kim
Signed-off-by: Heungjun Kim riverful@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/Kconfig |2 +
drivers/media/video/Makefile |1 +
drivers/media/video/m5mols/Kconfig |6 +
drivers/media/video/m5mols/Makefile |3 +
drivers/media/video/m5mols/m5mols.h | 257
drivers/media/video/m5mols/m5mols_controls.c | 173 +
drivers/media/video/m5mols/m5mols_core.c | 898 ++
drivers/media/video/m5mols/m5mols_reg.h | 103 +++
8 files changed, 1443 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/m5mols/Kconfig
create mode 100644 drivers/media/video/m5mols/Makefile
create mode 100644 drivers/media/video/m5mols/m5mols.h
create mode 100644 drivers/media/video/m5mols/m5mols_controls.c
create mode 100644 drivers/media/video/m5mols/m5mols_core.c
create mode 100644 drivers/media/video/m5mols/m5mols_reg.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index ce3555a..fd3130a 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -746,6 +746,8 @@ config VIDEO_NOON010PC30
---help---
This driver supports NOON010PC30 CIF camera from Siliconfile
+source drivers/media/video/m5mols/Kconfig
+
config SOC_CAMERA
tristate SoC camera support
depends on VIDEO_V4L2 HAS_DMA I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 251b7ca..adb9361 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
+obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o
obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o
diff --git a/drivers/media/video/m5mols/Kconfig
b/drivers/media/video/m5mols/Kconfig
new file mode 100644
index 000..387425b
--- /dev/null
+++ b/drivers/media/video/m5mols/Kconfig
@@ -0,0 +1,6 @@
+config VIDEO_M5MOLS
+ tristate Fujitsu M5MO-LS 8MP sensor support
+ depends on I2C VIDEO_V4L2
+ ---help---
+ This driver supports Fujitsu M5MO-LS camera sensor with ISP
+
diff --git a/drivers/media/video/m5mols/Makefile
b/drivers/media/video/m5mols/Makefile
new file mode 100644
index 000..b5d19bf
--- /dev/null
+++ b/drivers/media/video/m5mols/Makefile
@@ -0,0 +1,3 @@
+m5mols-objs:= m5mols_core.o m5mols_controls.o
+
+obj-$(CONFIG_VIDEO_M5MOLS) += m5mols.o
diff --git a/drivers/media/video/m5mols/m5mols.h
b/drivers/media/video/m5mols/m5mols.h
new file mode 100644
index 000..eaeb7ca
--- /dev/null
+++ b/drivers/media/video/m5mols/m5mols.h
@@ -0,0 +1,257 @@
+/*
+ * Header for M5MOLS 8M Pixel camera sensor with ISP
+ *
+ * Copyright (C) 2011 Samsung Electronics Co., Ltd
+ * Author: HeungJun Kim, riverful@samsung.com
+ *
+ * Copyright (C) 2009 Samsung Electronics Co., Ltd
+ * Author: 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.
+ */
+
+#ifndef M5MOLS_H
+#define M5MOLS_H
+
+#include media/v4l2-subdev.h
+#include m5mols_reg.h
+
+#define v4l2msg(fmt, arg...) do {\
+ v4l2_dbg(1, m5mols_debug, info-sd, fmt, ## arg); \
+} while (0)
+
+extern int m5mols_debug;
+
+enum m5mols_mode {
+ MODE_SYSINIT,
+ MODE_PARMSET,
+ MODE_MONITOR,
+ MODE_UNKNOWN,
+};
+
+enum m5mols_i2c_size {
+ I2C_8BIT= 1,
+ I2C_16BIT = 2,
+ I2C_32BIT = 4,
+ I2C_MAX = 4,
+};
+
+enum m5mols_fps {
+ M5MOLS_FPS_AUTO = 0,
+ M5MOLS_FPS_10 = 10,
+ M5MOLS_FPS_12 = 12,
+ M5MOLS_FPS_15 = 15,
+
Re: camera on Freescale i.MX51
On Tue, Jan 18, 2011 at 3:37 PM, Claudiu Covaci claudiu.cov...@gmail.com wrote: Hi, I'm have trouble receiving a video stream on the Freescale i.MX51 processor. I've tried everything I could think, so I'm trying my luck here. I'm using a 2.6.31 kernel with some modifications: the camera capture driver [1] and the IPU (Image Processing Unit) driver [2] from the Freescale BSP 2010.11. I'm at a point where I can open the /dev/video0 device and can (at least try to) read frames, but it fails at dequeueing the video buffers (VIDIOC_DQBUF) with the message: 3ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0 Unable to dequeue buffer (62). - I've double-checked the IPU registers and they seem properly configured, but I don't get any interrupt (at end-of-frame). - The relevant IOMUX pins are also configured. - the video signal appears at the i.MX pins (so it gets there) - I've also tried activating the internal picture generator, but still nothing happens. Is there anything I overlooked? Is there a way to find out where the problem is? Any hints will be greatly appreciated. Thanks! Claudiu [1] http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=blob;f=drivers/media/video/mxc/capture/mxc_v4l2_capture.c;h=8133d202304eea22e94bbd8eaaa215002b2dc675;hb=0fae922f451a5bde63595a2e0c2cd7079f083440 [2] http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=tree;f=drivers/mxc/ipu3;h=288c21f88aa650d16d843dccec2b04ba9f1462f7;hb=0fae922f451a5bde63595a2e0c2cd7079f083440 -- 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 Hi Hans, Jean, Mauro: No ideea to help Claudiu ? -- 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
[RFC PATCH 0/3] v4l2-ctrls: add new functionality
This RFC patch series adds and documents two new features of the control framework. The first adds support to enable or disable specific controls or all controls from a control handler. This is needed to support drivers that need to change which controls are available based on the chosen input or output. In cases like this each input or output is hooked up to a different video receiver or transmitter, each with its own set of controls. Switching inputs/outputs means that the controls from the new input should be enabled, while those of the others should be disabled. The second adds support to simplify handling of 'auto-foo/foo' type of controls. E.g.: autogain/gain, autoexposure/exposure, etc. It is a bit tricky to handle that correctly and after having to do this many times when I was converting the soc_camera sensors I decided to add special support for this in the framework. It should ensure consistent handling of these special kinds of controls in the drivers. If there are no comments, then I plan on making a pull request for this for 2.6.39 and base the soc_camera and ov7670 conversions on this. For 2.6.39 I want to finish converting all subdev to the control framework and make a good start at converting the v4l2 drivers as well. -- 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
[RFC PATCH 2/3] v4l2-ctrls: add v4l2_ctrl_auto_cluster to simplify autogain/gain scenarios
It is a bit tricky to handle autogain/gain type scenerios correctly. Such
controls need to be clustered and the V4L2_CTRL_FLAG_UPDATE should be set on
the non-auto controls. If you set a non-auto control without setting the
auto control at the same time, then the auto control should switch to manual
mode. And usually the non-auto controls must be marked volatile, but this should
only be in effect if the auto control is set to auto.
The chances of drivers doing all these things correctly are pretty remote.
So a new v4l2_ctrl_auto_cluster function was added that takes care of these
issues.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/v4l2-ctrls.c | 27 -
include/media/v4l2-ctrls.h | 48 +-
2 files changed, 73 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 983e287..b5da617 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1178,6 +1178,25 @@ void v4l2_ctrl_cluster(unsigned ncontrols, struct
v4l2_ctrl **controls)
}
EXPORT_SYMBOL(v4l2_ctrl_cluster);
+void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls,
+ u8 manual_val, bool set_volatile)
+{
+ int i;
+
+ v4l2_ctrl_cluster(ncontrols, controls);
+ controls[0]-is_auto = true;
+ controls[0]-manual_mode_value = manual_val;
+
+ for (i = 1; i ncontrols; i++) {
+ if (controls[i]) {
+ controls[i]-flags |= V4L2_CTRL_FLAG_UPDATE;
+ if (set_volatile)
+ controls[i]-is_volatile = true;
+ }
+ }
+}
+EXPORT_SYMBOL(v4l2_ctrl_auto_cluster);
+
/* Activate/deactivate a control. */
void v4l2_ctrl_activate(struct v4l2_ctrl *ctrl, bool active)
{
@@ -1605,7 +1624,8 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl,
struct v4l2_ext_controls *cs
v4l2_ctrl_lock(master);
/* g_volatile_ctrl will update the current control values */
- if (ctrl-is_volatile master-ops-g_volatile_ctrl)
+ if (ctrl-is_volatile master-ops-g_volatile_ctrl
+ (!master-is_auto || master-cur.val !=
master-manual_mode_value))
ret = master-ops-g_volatile_ctrl(master);
/* If OK, then copy the current control values to the caller */
if (!ret)
@@ -1717,6 +1737,11 @@ static int try_or_set_control_cluster(struct v4l2_ctrl
*master, bool set)
/* Don't set if there is no change */
if (!ret set cluster_changed(master)) {
+ if (master-is_auto !master-is_new
+ master-cur.val != master-manual_mode_value) {
+ master-is_new = 1;
+ master-val = master-manual_mode_value;
+ }
ret = master-ops-s_ctrl(master);
/* If OK, then make the new values permanent. */
if (!ret)
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index a2b2d58..e715f4e 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -66,7 +66,16 @@ struct v4l2_ctrl_ops {
*retrieved through the g_volatile_ctrl op. Drivers can set
*this flag.
* @is_enabled: If 0, then this control is disabled and will be hidden for
- *applications. Controls are always enabled by default.
+ *applications. Controls are always enabled by default. Drivers
+ *should never set this flag.
+ * @is_auto: If set, then this control selects whether the other cluster
+ *members are in 'automatic' mode or 'manual' mode. This is
+ *used for autogain/gain type clusters. Drivers should never
+ *set this flag.
+ * @manual_mode_value: If the is_auto flag is set, then this is the value
+ *of the auto control that determines if that control is in
+ *manual mode. So if the value of the auto control equals this
+ *value, then the whole cluster is in manual mode.
* @ops: The control ops.
* @id: The control ID.
* @name: The control name.
@@ -108,6 +117,8 @@ struct v4l2_ctrl {
unsigned int is_private:1;
unsigned int is_volatile:1;
unsigned int is_enabled:1;
+ unsigned int is_auto:1;
+ unsigned int manual_mode_value:5;
const struct v4l2_ctrl_ops *ops;
u32 id;
@@ -366,6 +377,41 @@ int v4l2_ctrl_add_handler(struct v4l2_ctrl_handler *hdl,
void v4l2_ctrl_cluster(unsigned ncontrols, struct v4l2_ctrl **controls);
+/** v4l2_ctrl_auto_cluster() - Mark all controls in the cluster as belonging to
+ * that cluster and set it up for autofoo/foo-type handling.
+ * @ncontrols:The number of controls in this cluster.
+ * @controls: The cluster control array of
[RFC PATCH 1/3] v4l2-ctrls: must be able to enable/disable controls
Controls can be dependent on the chosen input/output. So it has to be possible
to enable or disable groups of controls, preventing them from being seen in
the application.
We need to allow duplicate controls as well so that two control handlers
that both have the same control will still work. The first enabled control
will win. And duplicate controls are always sorted based on when they were
added (so the sorted list and the hash are both stable lists/hashes).
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/v4l2-ctrls.c | 123 +-
include/media/v4l2-ctrls.h | 34 +++
2 files changed, 115 insertions(+), 42 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index ef66d2a..983e287 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -820,7 +820,7 @@ static struct v4l2_ctrl_ref *find_private_ref(
VIDIOC_G/S_CTRL. */
if (V4L2_CTRL_ID2CLASS(ref-ctrl-id) == V4L2_CTRL_CLASS_USER
V4L2_CTRL_DRIVER_PRIV(ref-ctrl-id)) {
- if (!type_is_int(ref-ctrl))
+ if (!ref-ctrl-is_enabled || !type_is_int(ref-ctrl))
continue;
if (id == 0)
return ref;
@@ -849,7 +849,7 @@ static struct v4l2_ctrl_ref *find_ref(struct
v4l2_ctrl_handler *hdl, u32 id)
/* Not in cache, search the hash */
ref = hdl-buckets ? hdl-buckets[bucket] : NULL;
- while (ref ref-ctrl-id != id)
+ while (ref ref-ctrl-id != id ref-ctrl-is_enabled)
ref = ref-next;
if (ref)
@@ -926,23 +926,28 @@ static int handler_new_ref(struct v4l2_ctrl_handler *hdl,
/* Find insert position in sorted list */
list_for_each_entry(ref, hdl-ctrl_refs, node) {
- if (ref-ctrl-id id)
- continue;
- /* Don't add duplicates */
- if (ref-ctrl-id == id) {
- kfree(new_ref);
- goto unlock;
+ /* If there are multiple elements with the same ID, then
+ add the new element at the end. */
+ if (ref-ctrl-id id) {
+ list_add(new_ref-node, ref-node.prev);
+ break;
}
- list_add(new_ref-node, ref-node.prev);
- break;
}
insert_in_hash:
- /* Insert the control node in the hash */
- new_ref-next = hdl-buckets[bucket];
- hdl-buckets[bucket] = new_ref;
+ /* Append the control ref to the hash */
+ if (hdl-buckets[bucket] == NULL) {
+ hdl-buckets[bucket] = new_ref;
+ } else {
+ for (ref = hdl-buckets[bucket]; ref-next; ref = ref-next)
+ ; /* empty */
+ ref-next = new_ref;
+ }
+ /* Note regarding the hdl-cached control ref: since new control refs
+ are always appended after any existing controls they will never
+ invalidate the cached control ref. So there is no need to set the
+ hdl-cached pointer to NULL. */
-unlock:
mutex_unlock(hdl-lock);
return 0;
}
@@ -960,8 +965,22 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
if (hdl-error)
return NULL;
- /* Sanity checks */
+ /* Sanity checks:
+ - id must never be 0 (reserved value as it is the starting point
+if apps want to iterate over all controls using
+V4L2_CTRL_FLAG_NEXT_CTRL).
+ - name must be set.
+ - V4L2_CID_PRIVATE_BASE IDs are no longer allowed: these IDs make
+it impossible to set the control using explicit control IDs.
+ - def must be in range and max must be = min.
+ - V4L2_CTRL_FLAG_DISABLED must not be used by drivers any more.
+There are better ways of doing this.
+ - Integer types must have a non-zero step.
+ - Menu types must have a menu.
+ - String types must have a non-zero max string length.
+*/
if (id == 0 || name == NULL || id = V4L2_CID_PRIVATE_BASE ||
+ (flags V4L2_CTRL_FLAG_DISABLED) ||
max min ||
(type == V4L2_CTRL_TYPE_INTEGER step == 0) ||
(type == V4L2_CTRL_TYPE_MENU qmenu == NULL) ||
@@ -1002,6 +1021,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
ctrl-step = step;
ctrl-qmenu = qmenu;
ctrl-priv = priv;
+ ctrl-is_enabled = 1;
ctrl-cur.val = ctrl-val = ctrl-default_value = def;
if (ctrl-type == V4L2_CTRL_TYPE_STRING) {
@@ -1193,14 +1213,39 @@ void v4l2_ctrl_grab(struct v4l2_ctrl *ctrl, bool
grabbed)
}
EXPORT_SYMBOL(v4l2_ctrl_grab);
+/* Enable/disable a control.
+ Usually used if controls can be
[RFC PATCH 3/3] v4l2-ctrls: update control framework documentation
Document how to enable/disable controls.
Document the new v4l2_ctrl_auto_cluster function.
Document the practical method of using anonymous structs to 'cluster'
controls instead of using cumbersome control pointer arrays.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
Documentation/video4linux/v4l2-controls.txt | 94 +++
1 files changed, 94 insertions(+), 0 deletions(-)
diff --git a/Documentation/video4linux/v4l2-controls.txt
b/Documentation/video4linux/v4l2-controls.txt
index 881e7f4..78b6674 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -453,6 +453,25 @@ In the example above the following are equivalent for the
VOLUME case:
ctrl == ctrl-cluster[AUDIO_CL_VOLUME] ==
state-audio_cluster[AUDIO_CL_VOLUME]
ctrl-cluster[AUDIO_CL_MUTE] == state-audio_cluster[AUDIO_CL_MUTE]
+In practice using cluster arrays like this becomes very tiresome. So instead
+the following equivalent method is used:
+
+ struct {
+ /* audio cluster */
+ struct v4l2_ctrl *volume;
+ struct v4l2_ctrl *mute;
+ };
+
+The anonymous struct is used to clearly 'cluster' these two control pointers,
+but it serves no other purpose. The effect is the same as creating an
+array with two control pointers. So you can just do:
+
+ state-volume = v4l2_ctrl_new_std(state-ctrl_handler, ...);
+ state-mute = v4l2_ctrl_new_std(state-ctrl_handler, ...);
+ v4l2_ctrl_cluster(2, state-volume);
+
+And in foo_s_ctrl you can use these pointers directly: state-mute-val.
+
Note that controls in a cluster may be NULL. For example, if for some
reason mute was never added (because the hardware doesn't support that
particular feature), then mute will be NULL. So in that case we have a
@@ -475,6 +494,55 @@ controls, then the 'is_new' flag would be 1 for both
controls.
The 'is_new' flag is always 1 when called from v4l2_ctrl_handler_setup().
+Handling autogain/gain-type Controls with Auto Clusters
+===
+
+A common type of control cluster is one that handles 'auto-foo/foo'-type
+controls. Typical examples are autogain/gain, autoexposure/exposure,
+autowhitebalance/red balance/blue balance. In all cases you have one controls
+that determines whether another control is handled automatically by the
hardware,
+or whether it is under manual control from the user.
+
+The way these are supposed to be handled is that if you set one of the 'foo'
+controls, then the 'auto-foo' control should automatically switch to manual
+mode, except when you set the 'auto-foo' control at the same time, in which
+case it will depend on the new 'auto-foo' setting whether the new 'foo' value
+is actually ignored or set in the hardware.
+
+The reasoning is that if you explicitly set a manual control, then it makes
+sense to assume that you want to switch to manual mode as well. Whereas if you
+set both the auto and manual control at the same time, then you should follow
+whatever the new value for the auto control is.
+
+Usually the 'foo' control is also volatile, since if the automatic mode is
+enabled, then the reported value for 'foo' is the value that the automatic
+mode has determined is the best at that given time. However, if manual mode
+is selected, then it is just the last stored value. So g_volatile_ctrl should
+only be called when we are in automatic mode.
+
+Finally the V4L2_CTRL_FLAG_UPDATE should also be set for the non-auto controls
+since changing one of them might affect the auto control.
+
+In order to simplify this a special variation of v4l2_ctrl_cluster was
+introduced:
+
+void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls,
+ u8 manual_val, bool set_volatile);
+
+The first two arguments are identical to v4l2_ctrl_cluster. The third argument
+tells the framework which value switches the cluster into manual mode. The
+last argument will optionally set is_volatile flag for the non-auto controls.
+
+The first control of the cluster is assumed to be the 'auto' control.
+
+Using this function will ensure that:
+
+- the right flags are set.
+- when a 'foo' control is set explicitly the 'auto-foo' control is set to
+ the manual mode before s_ctrl is called.
+- g_volatile_ctrl is never called when in manual mode.
+
+
VIDIOC_LOG_STATUS Support
=
@@ -535,6 +603,32 @@ control. The rule is to have one control for each hardware
'knob' that you
can twiddle.
+Different Handlers for Different Inputs/Outputs
+===
+
+Sometimes the available controls will change depending on which input or output
+was chosen. This can happen if input 0 handles SDTV and is hooked up to a SDTV
+video receiver and if input 1 handles HDTV and is hooked up to a HDTV receiver.
+
+Each will typically have their own controls. Which means that in this
How to re-start m2m device after suspend ?
Hello, I don't know whether the way to restart m2m device after suspend is right or not. To go to suspend state, I think m2m device should stop the job even if there are remained jobs in ready queue. After suspend, driver should restart remained jobs in resume function without ioctl command like: VIDIOC_QBUF. According the m2m framework, device_run should be called to restart. And the device_run is called by v4l2_m2m_try_run called by v4l2_m2m_try_schedule and v4l2_m2m_job_finish. And v4l2_m2m_try_schedule is only for m2m framework. So in my opinion, if driver didn't call the v4l2_m2m_job_finish in suspend function, the resume function can start from v4l2_m2m_job_finish to restart the remained jobs. Is it right the way or is there anything recommended way ? Best regards, -- 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: [RFC PATCH 1/3] v4l2-ctrls: must be able to enable/disable controls
On Sat, 2011-01-22 at 12:05 +0100, Hans Verkuil wrote:
Controls can be dependent on the chosen input/output. So it has to be possible
to enable or disable groups of controls, preventing them from being seen in
the application.
I'm not a human factors expert, but given some of the principles listed
here:
http://www.asktog.com/basics/firstPrinciples.html
I get the feeling that forcing controls to disappear and reappear will
not be good for every possible application UI design.
I'm sure that due to subdevices providing all sorts of interesting
controls, some method of disabling controls is needed so as not to show
duplicates, etc.
However, would it be better to provide a hint to the application and let
the application UI designer decide what gets shown; instead of the
kernel dictating what is shown?
Regards,
Andy
We need to allow duplicate controls as well so that two control handlers
that both have the same control will still work. The first enabled control
will win. And duplicate controls are always sorted based on when they were
added (so the sorted list and the hash are both stable lists/hashes).
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/v4l2-ctrls.c | 123
+-
include/media/v4l2-ctrls.h | 34 +++
2 files changed, 115 insertions(+), 42 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c
b/drivers/media/video/v4l2-ctrls.c
index ef66d2a..983e287 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -820,7 +820,7 @@ static struct v4l2_ctrl_ref *find_private_ref(
VIDIOC_G/S_CTRL. */
if (V4L2_CTRL_ID2CLASS(ref-ctrl-id) == V4L2_CTRL_CLASS_USER
V4L2_CTRL_DRIVER_PRIV(ref-ctrl-id)) {
- if (!type_is_int(ref-ctrl))
+ if (!ref-ctrl-is_enabled || !type_is_int(ref-ctrl))
continue;
if (id == 0)
return ref;
@@ -849,7 +849,7 @@ static struct v4l2_ctrl_ref *find_ref(struct
v4l2_ctrl_handler *hdl, u32 id)
/* Not in cache, search the hash */
ref = hdl-buckets ? hdl-buckets[bucket] : NULL;
- while (ref ref-ctrl-id != id)
+ while (ref ref-ctrl-id != id ref-ctrl-is_enabled)
ref = ref-next;
if (ref)
@@ -926,23 +926,28 @@ static int handler_new_ref(struct v4l2_ctrl_handler
*hdl,
/* Find insert position in sorted list */
list_for_each_entry(ref, hdl-ctrl_refs, node) {
- if (ref-ctrl-id id)
- continue;
- /* Don't add duplicates */
- if (ref-ctrl-id == id) {
- kfree(new_ref);
- goto unlock;
+ /* If there are multiple elements with the same ID, then
+add the new element at the end. */
+ if (ref-ctrl-id id) {
+ list_add(new_ref-node, ref-node.prev);
+ break;
}
- list_add(new_ref-node, ref-node.prev);
- break;
}
insert_in_hash:
- /* Insert the control node in the hash */
- new_ref-next = hdl-buckets[bucket];
- hdl-buckets[bucket] = new_ref;
+ /* Append the control ref to the hash */
+ if (hdl-buckets[bucket] == NULL) {
+ hdl-buckets[bucket] = new_ref;
+ } else {
+ for (ref = hdl-buckets[bucket]; ref-next; ref = ref-next)
+ ; /* empty */
+ ref-next = new_ref;
+ }
+ /* Note regarding the hdl-cached control ref: since new control refs
+are always appended after any existing controls they will never
+invalidate the cached control ref. So there is no need to set the
+hdl-cached pointer to NULL. */
-unlock:
mutex_unlock(hdl-lock);
return 0;
}
@@ -960,8 +965,22 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
if (hdl-error)
return NULL;
- /* Sanity checks */
+ /* Sanity checks:
+- id must never be 0 (reserved value as it is the starting point
+ if apps want to iterate over all controls using
+ V4L2_CTRL_FLAG_NEXT_CTRL).
+- name must be set.
+- V4L2_CID_PRIVATE_BASE IDs are no longer allowed: these IDs make
+ it impossible to set the control using explicit control IDs.
+- def must be in range and max must be = min.
+- V4L2_CTRL_FLAG_DISABLED must not be used by drivers any more.
+ There are better ways of doing this.
+- Integer types must have a non-zero step.
+- Menu types must have a menu.
+- String types must have a non-zero max string length.
+ */
if (id == 0 || name == NULL || id = V4L2_CID_PRIVATE_BASE ||
+ (flags V4L2_CTRL_FLAG_DISABLED) ||
Re: [PATCH 2/3] sr030pc30: Use the control framework
Hello Hans,
On 2011-01-20 20:09, Hans Verkuil wrote:
Hi Sylwester!
I have some review comments below...
Thank you for taking time to look at the patches.
On Thursday, January 20, 2011 02:44:01 Sylwester Nawrocki wrote:
Implement controls using the control framework.
Add horizontal/vertical flip controls, minor cleanup.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/sr030pc30.c | 311
+--
1 files changed, 132 insertions(+), 179 deletions(-)
diff --git a/drivers/media/video/sr030pc30.c
b/drivers/media/video/sr030pc30.c
index e1eced1..1a195f0 100644
--- a/drivers/media/video/sr030pc30.c
+++ b/drivers/media/video/sr030pc30.c
@@ -19,6 +19,8 @@
#include linux/i2c.h
#include linux/delay.h
#include linux/slab.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/v4l2-device.h
#include media/v4l2-subdev.h
#include media/v4l2-mediabus.h
@@ -141,17 +143,24 @@ module_param(debug, int, 0644);
struct sr030pc30_info {
struct v4l2_subdev sd;
+struct v4l2_ctrl_handler hdl;
+struct {
+/* exposure/auto-exposure cluster */
+struct v4l2_ctrl *autoexposure;
+struct v4l2_ctrl *exposure;
+};
+struct {
+/* blue/red/autowhitebalance cluster */
+struct v4l2_ctrl *autowb;
+struct v4l2_ctrl *blue;
+struct v4l2_ctrl *red;
+};
+struct v4l2_ctrl *hflip;
+struct v4l2_ctrl *vflip;
const struct sr030pc30_platform_data *pdata;
const struct sr030pc30_format *curr_fmt;
const struct sr030pc30_frmsize *curr_win;
-unsigned int auto_wb:1;
-unsigned int auto_exp:1;
-unsigned int hflip:1;
-unsigned int vflip:1;
unsigned int sleep:1;
-unsigned int exposure;
-u8 blue_balance;
-u8 red_balance;
u8 i2c_reg_page;
};
@@ -172,52 +181,6 @@ struct i2c_regval {
u16 val;
};
...
+
static inline int set_i2c_page(struct sr030pc30_info *info,
struct i2c_client *client, unsigned int reg)
{
@@ -395,59 +363,56 @@ static int sr030pc30_pwr_ctrl(struct v4l2_subdev *sd,
static inline int sr030pc30_enable_autoexposure(struct v4l2_subdev *sd, int
on)
{
-struct sr030pc30_info *info = to_sr030pc30(sd);
/* auto anti-flicker is also enabled here */
-int ret = cam_i2c_write(sd, AE_CTL1_REG, on ? 0xDC : 0x0C);
-if (!ret)
-info-auto_exp = on;
-return ret;
+return cam_i2c_write(sd, AE_CTL1_REG, on ? 0xDC : 0x0C);
}
static int sr030pc30_set_exposure(struct v4l2_subdev *sd, int value)
{
struct sr030pc30_info *info = to_sr030pc30(sd);
-
unsigned long expos = value * info-pdata-clk_rate / (8 * 1000);
+int ret;
-int ret = cam_i2c_write(sd, EXP_TIMEH_REG, expos 16 0xFF);
+ret = cam_i2c_write(sd, EXP_TIMEH_REG, expos 16 0xFF);
if (!ret)
ret = cam_i2c_write(sd, EXP_TIMEM_REG, expos 8 0xFF);
if (!ret)
ret = cam_i2c_write(sd, EXP_TIMEL_REG, expos 0xFF);
-if (!ret) { /* Turn off AE */
-info-exposure = value;
+if (!ret) /* Turn off AE */
ret = sr030pc30_enable_autoexposure(sd, 0);
-}
+
return ret;
}
/* Automatic white balance control */
static int sr030pc30_enable_autowhitebalance(struct v4l2_subdev *sd, int on)
{
-struct sr030pc30_info *info = to_sr030pc30(sd);
+int ret;
-int ret = cam_i2c_write(sd, AWB_CTL2_REG, on ? 0x2E : 0x2F);
+ret = cam_i2c_write(sd, AWB_CTL2_REG, on ? 0x2E : 0x2F);
if (!ret)
ret = cam_i2c_write(sd, AWB_CTL1_REG, on ? 0xFB : 0x7B);
-if (!ret)
-info-auto_wb = on;
return ret;
}
-static int sr030pc30_set_flip(struct v4l2_subdev *sd)
+/**
+ * sr030pc30_set_flip - set image flipping
+ * @sd: a pointer to the subdev to apply the seetings to
+ * @hflip: 1 to enable or 0 to disable horizontal flip
+ * @vflip: as above but for vertical flip
+ */
+static int sr030pc30_set_flip(struct v4l2_subdev *sd, u32 hflip, u32 vflip)
{
-struct sr030pc30_info *info = to_sr030pc30(sd);
-
s32 reg = cam_i2c_read(sd, VDO_CTL2_REG);
+
if (reg 0)
return reg;
reg = 0x7C;
-if (info-hflip)
-reg |= 0x01;
-if (info-vflip)
-reg |= 0x02;
+reg |= ((hflip 0x1) 0);
+reg |= ((vflip 0x1) 1);
+
return cam_i2c_write(sd, VDO_CTL2_REG, reg | 0x80);
}
These functions are now very small, so my suggestion is to move the code
directly
into the s_ctrl function.
yeah, that seems reasonable
@@ -468,8 +433,8 @@ static int sr030pc30_set_params(struct v4l2_subdev *sd)
ret = cam_i2c_write(sd, ISP_CTL_REG(0),
info-curr_fmt-ispctl1_reg);
if
Re: ngene Satix-S2 dual problems
On 11 Jan 2011, at 15:25, Andre wrote: On 28 Dec 2010, at 17:25, Andre wrote: / / / I seems to work with the last patch commited by Oliver Endriss. Did you/ / try with a CI ?/ / / / No I didn't, I don't have a CI./ / / / I'll try Olivers latest commit in a few days, I'm a long way from my Myth system right now :-)/ Finally got chance to try the latest commits, no extra nodes now and drivers work fine with several simultaneous HD recordings across both tuners. Satix S2 dual v2 on Ubuntu 10.0.4.1 kernel 2.6.32-25-generic Thanks Andre Hi, I've finally gotten round to trying the latest commits as well and I can also report success. No extra nodes, drivers appear to be working ok after a very quick test. I'll see how it goes over the next few days. Satix S2 dual on Gentoo with kernel 2.6.35.4. Cheers, Robert. http://vger.kernel.org/majordomo-info.html -- 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: [RFC PATCH 1/3] v4l2-ctrls: must be able to enable/disable controls
On Saturday, January 22, 2011 17:11:12 Andy Walls wrote: On Sat, 2011-01-22 at 12:05 +0100, Hans Verkuil wrote: Controls can be dependent on the chosen input/output. So it has to be possible to enable or disable groups of controls, preventing them from being seen in the application. I'm not a human factors expert, but given some of the principles listed here: http://www.asktog.com/basics/firstPrinciples.html I get the feeling that forcing controls to disappear and reappear will not be good for every possible application UI design. They already have to do that anyway since changing input might also mean changing input standard, formats, etc. I doubt many do that, though, since having different inputs with different standard/formats/controls etc. is pretty rare. Although with embedded systems this will become more common. I'm sure that due to subdevices providing all sorts of interesting controls, some method of disabling controls is needed so as not to show duplicates, etc. However, would it be better to provide a hint to the application and let the application UI designer decide what gets shown; instead of the kernel dictating what is shown? An alternative might be to enumerate all controls but set the DISABLED flag for disabled controls. But this is just half the story. For controls that are common to multiple inputs you still need to update them since the min/max ranges may have changed after you changed inputs. That said, it may not be a bad idea to use the DISABLED flag. It does allow a UI application to populate the control panel with all possible controls. However, it would require a small change to the spec since right now it says this: Table A.80. Control Flags V4L2_CTRL_FLAG_DISABLED 0x0001 This control is permanently disabled and should be ignored by the application. Any attempt to change the control will result in an EINVAL error code. That does not quite fit what the new situation will be. Regards, Hans -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: camera on Freescale i.MX51
On Saturday, January 22, 2011 11:28:33 Anca Emanuel wrote: On Tue, Jan 18, 2011 at 3:37 PM, Claudiu Covaci claudiu.cov...@gmail.com wrote: Hi, I'm have trouble receiving a video stream on the Freescale i.MX51 processor. I've tried everything I could think, so I'm trying my luck here. I'm using a 2.6.31 kernel with some modifications: the camera capture driver [1] and the IPU (Image Processing Unit) driver [2] from the Freescale BSP 2010.11. I'm at a point where I can open the /dev/video0 device and can (at least try to) read frames, but it fails at dequeueing the video buffers (VIDIOC_DQBUF) with the message: 3ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0 Unable to dequeue buffer (62). - I've double-checked the IPU registers and they seem properly configured, but I don't get any interrupt (at end-of-frame). - The relevant IOMUX pins are also configured. - the video signal appears at the i.MX pins (so it gets there) - I've also tried activating the internal picture generator, but still nothing happens. Is there anything I overlooked? Is there a way to find out where the problem is? Any hints will be greatly appreciated. Thanks! Claudiu [1] http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=blob;f=drivers/media/video/mxc/capture/mxc_v4l2_capture.c;h=8133d202304eea22e94bbd8eaaa215002b2dc675;hb=0fae922f451a5bde63595a2e0c2cd7079f083440 [2] http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=tree;f=drivers/mxc/ipu3;h=288c21f88aa650d16d843dccec2b04ba9f1462f7;hb=0fae922f451a5bde63595a2e0c2cd7079f083440 -- 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 Hi Hans, Jean, Mauro: No ideea to help Claudiu ? Not me, no. But since no interrupt arrives that typically means that either some pin assignments are wrong or some video format settings are wrong. From personal experience with other (non-freescale) boards in the past I know that that can be hard to track down. Regards, Hans -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: camera on Freescale i.MX51
Hi Claudiu, On Tue, Jan 18, 2011 at 11:37 AM, Claudiu Covaci claudiu.cov...@gmail.com wrote: Hi, I'm have trouble receiving a video stream on the Freescale i.MX51 processor. I've tried everything I could think, so I'm trying my luck here. I'm using a 2.6.31 kernel with some modifications: the camera capture driver [1] and the IPU (Image Processing Unit) driver [2] from the Freescale BSP 2010.11. I'm at a point where I can open the /dev/video0 device and can (at least try to) read frames, but it fails at dequeueing the video buffers (VIDIOC_DQBUF) with the message: 3ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0 Unable to dequeue buffer (62). - I've double-checked the IPU registers and they seem properly configured, but I don't get any interrupt (at end-of-frame). - The relevant IOMUX pins are also configured. - the video signal appears at the i.MX pins (so it gets there) - I've also tried activating the internal picture generator, but still nothing happens. Is there anything I overlooked? Is there a way to find out where the problem is? Any hints will be greatly appreciated. These are the steps I do on a MX51EVK connected to the expansion board with a OV3640 camera: modprobe mxc_v4l2_capture modprobe ov3640_camera gst-launch mfw_v4lsrc ! mfw_v4lsink Then I got the camera preview in the LCD/DVI output. Regards, Fabio Estevam -- 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
[cron job] v4l-dvb daily build: OK
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Jan 22 19:00:26 CET 2011 git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: OK spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 A linux-media.tar.bz2 archive with the latest media git sources that can be used with the media_build tree is available here: http://www.xs4all.nl/~hverkuil/logs/Saturday-linux-media.tar.bz2 Rename to linux-media.tar.bz2, put it in the media_build/linux directory, go to the directory and type 'make untar'. The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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: [RFC PATCH 02/12] sh_mobile_ceu_camera: implement the control handler.
On Wed, 12 Jan 2011, Hans Verkuil wrote:
And since this is the last and only host driver that uses controls, also
remove the now obsolete control fields from soc_camera.h.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/sh_mobile_ceu_camera.c | 95 ---
include/media/soc_camera.h |4 -
2 files changed, 42 insertions(+), 57 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index 954222b..f007f57 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -112,6 +112,7 @@ struct sh_mobile_ceu_dev {
unsigned int image_mode:1;
unsigned int is_16bit:1;
+ unsigned int added_controls:1;
};
struct sh_mobile_ceu_cam {
@@ -133,6 +134,12 @@ struct sh_mobile_ceu_cam {
enum v4l2_mbus_pixelcode code;
};
+static inline struct soc_camera_device *to_icd(struct v4l2_ctrl *ctrl)
I've been told a while ago not to use inline in .c files, and to let the
compiler decide instead. Also this file has no inline directives in it
until now, please, keep it that way.
+{
+ return container_of(ctrl-handler, struct soc_camera_device,
+ ctrl_handler);
+}
+
static unsigned long make_bus_param(struct sh_mobile_ceu_dev *pcdev)
{
unsigned long flags;
@@ -490,6 +497,33 @@ out:
return IRQ_HANDLED;
}
+static int sh_mobile_ceu_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct soc_camera_device *icd = to_icd(ctrl);
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+ struct sh_mobile_ceu_dev *pcdev = ici-priv;
+
+ ici = to_soc_camera_host(icd-dev.parent);
+ pcdev = ici-priv;
These two are redundant.
+ switch (ctrl-id) {
+ case V4L2_CID_SHARPNESS:
+ switch (icd-current_fmt-host_fmt-fourcc) {
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_NV16:
+ case V4L2_PIX_FMT_NV61:
+ ceu_write(pcdev, CLFCR, !ctrl-val);
+ return 0;
+ }
+ break;
+ }
+ return -EINVAL;
+}
+
+static const struct v4l2_ctrl_ops sh_mobile_ceu_ctrl_ops = {
+ .s_ctrl = sh_mobile_ceu_s_ctrl,
+};
+
/* Called with .video_lock held */
static int sh_mobile_ceu_add_device(struct soc_camera_device *icd)
{
@@ -500,6 +534,14 @@ static int sh_mobile_ceu_add_device(struct
soc_camera_device *icd)
if (pcdev-icd)
return -EBUSY;
+ if (!pcdev-added_controls) {
+ v4l2_ctrl_new_std(icd-ctrl_handler, sh_mobile_ceu_ctrl_ops,
+ V4L2_CID_SHARPNESS, 0, 1, 1, 0);
Hm, am I missing something with this new API? You register a handler for
only one control ID, and in the handler itself you check once more, which
ID it is?...
+ if (icd-ctrl_handler.error)
+ return icd-ctrl_handler.error;
+ pcdev-added_controls = 1;
+ }
+
dev_info(icd-dev.parent,
SuperH Mobile CEU driver attached to camera %d\n,
icd-devnum);
Thanks
Guennadi
@@ -1789,55 +1831,6 @@ static void sh_mobile_ceu_init_videobuf(struct
videobuf_queue *q,
icd, icd-video_lock);
}
-static int sh_mobile_ceu_get_ctrl(struct soc_camera_device *icd,
- struct v4l2_control *ctrl)
-{
- struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
- struct sh_mobile_ceu_dev *pcdev = ici-priv;
- u32 val;
-
- switch (ctrl-id) {
- case V4L2_CID_SHARPNESS:
- val = ceu_read(pcdev, CLFCR);
- ctrl-value = val ^ 1;
- return 0;
- }
- return -ENOIOCTLCMD;
-}
-
-static int sh_mobile_ceu_set_ctrl(struct soc_camera_device *icd,
- struct v4l2_control *ctrl)
-{
- struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
- struct sh_mobile_ceu_dev *pcdev = ici-priv;
-
- switch (ctrl-id) {
- case V4L2_CID_SHARPNESS:
- switch (icd-current_fmt-host_fmt-fourcc) {
- case V4L2_PIX_FMT_NV12:
- case V4L2_PIX_FMT_NV21:
- case V4L2_PIX_FMT_NV16:
- case V4L2_PIX_FMT_NV61:
- ceu_write(pcdev, CLFCR, !ctrl-value);
- return 0;
- }
- return -EINVAL;
- }
- return -ENOIOCTLCMD;
-}
-
-static const struct v4l2_queryctrl sh_mobile_ceu_controls[] = {
- {
- .id = V4L2_CID_SHARPNESS,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .name = Low-pass filter,
- .minimum= 0,
- .maximum= 1,
- .step = 1,
Re: [RFC PATCH 03/12] mt9m001: convert to the control framework.
On Wed, 12 Jan 2011, Hans Verkuil wrote:
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/mt9m001.c | 210
+++--
1 files changed, 75 insertions(+), 135 deletions(-)
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index f7fc88d..b9b6e33 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -15,6 +15,7 @@
#include media/v4l2-subdev.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/soc_camera.h
/*
@@ -84,15 +85,18 @@ static const struct mt9m001_datafmt
mt9m001_monochrome_fmts[] = {
struct mt9m001 {
struct v4l2_subdev subdev;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* exposure/auto-exposure cluster */
+ struct v4l2_ctrl *autoexposure;
+ struct v4l2_ctrl *exposure;
+ };
Hm, why an anonymous struct? Why not just put them directly at the top
level?
struct v4l2_rect rect; /* Sensor window */
const struct mt9m001_datafmt *fmt;
const struct mt9m001_datafmt *fmts;
int num_fmts;
int model; /* V4L2_IDENT_MT9M001* codes from v4l2-chip-ident.h */
- unsigned int gain;
- unsigned int exposure;
unsigned short y_skip_top; /* Lines to skip at the top */
- unsigned char autoexposure;
};
static struct mt9m001 *to_mt9m001(const struct i2c_client *client)
@@ -209,7 +213,6 @@ static int mt9m001_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct mt9m001 *mt9m001 = to_mt9m001(client);
struct v4l2_rect rect = a-c;
- struct soc_camera_device *icd = client-dev.platform_data;
int ret;
const u16 hblank = 9, vblank = 25;
unsigned int total_h;
@@ -251,17 +254,18 @@ static int mt9m001_s_crop(struct v4l2_subdev *sd,
struct v4l2_crop *a)
if (!ret)
ret = reg_write(client, MT9M001_WINDOW_HEIGHT,
rect.height + mt9m001-y_skip_top - 1);
- if (!ret mt9m001-autoexposure) {
+ v4l2_ctrl_lock(mt9m001-autoexposure);
+ if (!ret mt9m001-autoexposure-cur.val == V4L2_EXPOSURE_AUTO) {
ret = reg_write(client, MT9M001_SHUTTER_WIDTH, total_h);
if (!ret) {
- const struct v4l2_queryctrl *qctrl =
- soc_camera_find_qctrl(icd-ops,
- V4L2_CID_EXPOSURE);
- mt9m001-exposure = (524 + (total_h - 1) *
- (qctrl-maximum - qctrl-minimum)) /
- 1048 + qctrl-minimum;
+ struct v4l2_ctrl *ctrl = mt9m001-exposure;
+
+ ctrl-cur.val = (524 + (total_h - 1) *
+ (ctrl-maximum - ctrl-minimum)) /
+ 1048 + ctrl-minimum;
}
}
+ v4l2_ctrl_unlock(mt9m001-autoexposure);
if (!ret)
mt9m001-rect = rect;
@@ -421,107 +425,36 @@ static int mt9m001_s_register(struct v4l2_subdev *sd,
}
#endif
-static const struct v4l2_queryctrl mt9m001_controls[] = {
- {
- .id = V4L2_CID_VFLIP,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .name = Flip Vertically,
- .minimum= 0,
- .maximum= 1,
- .step = 1,
- .default_value = 0,
- }, {
- .id = V4L2_CID_GAIN,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = Gain,
- .minimum= 0,
- .maximum= 127,
- .step = 1,
- .default_value = 64,
- .flags = V4L2_CTRL_FLAG_SLIDER,
- }, {
- .id = V4L2_CID_EXPOSURE,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = Exposure,
- .minimum= 1,
- .maximum= 255,
- .step = 1,
- .default_value = 255,
- .flags = V4L2_CTRL_FLAG_SLIDER,
- }, {
- .id = V4L2_CID_EXPOSURE_AUTO,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .name = Automatic Exposure,
- .minimum= 0,
- .maximum= 1,
- .step = 1,
- .default_value = 1,
- }
-};
-
static struct soc_camera_ops mt9m001_ops = {
.set_bus_param = mt9m001_set_bus_param,
.query_bus_param= mt9m001_query_bus_param,
- .controls = mt9m001_controls,
- .num_controls = ARRAY_SIZE(mt9m001_controls),
};
-static int mt9m001_g_ctrl(struct v4l2_subdev *sd, struct
Re: [RFC PATCH 04/12] mt9m111.c: convert to the control framework.
On Wed, 12 Jan 2011, Hans Verkuil wrote:
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/mt9m111.c | 184
-
1 files changed, 54 insertions(+), 130 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index 53fa2a7..2328579 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
[snip]
-static int mt9m111_s_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
+static int mt9m111_s_ctrl(struct v4l2_ctrl *ctrl)
{
+ struct v4l2_subdev *sd =
+ container_of(ctrl-handler, struct mt9m111, hdl)-subdev;
struct i2c_client *client = v4l2_get_subdevdata(sd);
- struct mt9m111 *mt9m111 = to_mt9m111(client);
- const struct v4l2_queryctrl *qctrl;
- int ret;
-
- qctrl = soc_camera_find_qctrl(mt9m111_ops, ctrl-id);
- if (!qctrl)
- return -EINVAL;
switch (ctrl-id) {
case V4L2_CID_VFLIP:
- mt9m111-vflip = ctrl-value;
- ret = mt9m111_set_flip(client, ctrl-value,
+ return mt9m111_set_flip(client, ctrl-val,
MT9M111_RMB_MIRROR_ROWS);
- break;
case V4L2_CID_HFLIP:
- mt9m111-hflip = ctrl-value;
- ret = mt9m111_set_flip(client, ctrl-value,
+ return mt9m111_set_flip(client, ctrl-val,
MT9M111_RMB_MIRROR_COLS);
- break;
case V4L2_CID_GAIN:
- ret = mt9m111_set_global_gain(client, ctrl-value);
- break;
+ return mt9m111_set_global_gain(client, ctrl-val);
+
case V4L2_CID_EXPOSURE_AUTO:
- ret = mt9m111_set_autoexposure(client, ctrl-value);
- break;
+ return mt9m111_set_autoexposure(client, ctrl-val);
+
case V4L2_CID_AUTO_WHITE_BALANCE:
- ret = mt9m111_set_autowhitebalance(client, ctrl-value);
- break;
- default:
- ret = -EINVAL;
+ return mt9m111_set_autowhitebalance(client, ctrl-val);
}
-
- return ret;
+ return -EINVAL;
}
static int mt9m111_suspend(struct soc_camera_device *icd, pm_message_t state)
[snip]
@@ -1067,6 +968,26 @@ static int mt9m111_probe(struct i2c_client *client,
return -ENOMEM;
v4l2_i2c_subdev_init(mt9m111-subdev, client, mt9m111_subdev_ops);
+ v4l2_ctrl_handler_init(mt9m111-hdl, 5);
+ v4l2_ctrl_new_std(mt9m111-hdl, mt9m111_ctrl_ops,
+ V4L2_CID_VFLIP, 0, 1, 1, 0);
+ v4l2_ctrl_new_std(mt9m111-hdl, mt9m111_ctrl_ops,
+ V4L2_CID_HFLIP, 0, 1, 1, 0);
+ v4l2_ctrl_new_std(mt9m111-hdl, mt9m111_ctrl_ops,
+ V4L2_CID_AUTO_WHITE_BALANCE, 0, 1, 1, 1);
+ mt9m111-gain = v4l2_ctrl_new_std(mt9m111-hdl, mt9m111_ctrl_ops,
+ V4L2_CID_GAIN, 0, 63 * 2 * 2, 1, 32);
+ v4l2_ctrl_new_std_menu(mt9m111-hdl,
+ mt9m111_ctrl_ops, V4L2_CID_EXPOSURE_AUTO, 1, 0,
+ V4L2_EXPOSURE_AUTO);
+ mt9m111-subdev.ctrl_handler = mt9m111-hdl;
+ if (mt9m111-hdl.error) {
+ int err = mt9m111-hdl.error;
+
+ kfree(mt9m111);
+ return err;
+ }
+ mt9m111-gain-is_volatile = 1;
I'm not sure I like this approach: you register each control separately,
but with the same handler, and then in that handler you switch-case again
to find out which control has to be processed... If we already register
them separately, and they share no code, apart from context extraction
from parameters - why not make separate handlers, waste some memory on a
couple more structs, but avoid run-time switching (I know it is not
critical, although, with still photo-shooting you might want to care about
the time between your controls and the actual shot), and win clarity?
/* Second stage probe - when a capture adapter is there */
icd-ops= mt9m111_ops;
@@ -1080,6 +1001,7 @@ static int mt9m111_probe(struct i2c_client *client,
ret = mt9m111_video_probe(icd, client);
if (ret) {
icd-ops = NULL;
+ v4l2_ctrl_handler_free(mt9m111-hdl);
kfree(mt9m111);
}
@@ -1091,7 +1013,9 @@ static int mt9m111_remove(struct i2c_client *client)
struct mt9m111 *mt9m111 = to_mt9m111(client);
struct soc_camera_device *icd = client-dev.platform_data;
+ v4l2_device_unregister_subdev(mt9m111-subdev);
Same here - don't like redundancy with soc_camera.c
Thanks
Guennadi
icd-ops = NULL;
+ v4l2_ctrl_handler_free(mt9m111-hdl);
kfree(mt9m111);
return 0;
--
1.7.0.4
---
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
Re: [RFC PATCH 06/12] mt9t031: convert to the control framework.
Same questions as to the previous ones:
1. how is V4L2_CID_EXPOSURE taken care of? I see, that the functionality
is provided by the control cluster, but, AFAIU, user just issuing that
control will not get the desired result?
2. separate handlers
3. v4l2_device_unregister_subdev()
Thanks
Guennadi
On Wed, 12 Jan 2011, Hans Verkuil wrote:
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/mt9t031.c | 229
+++--
1 files changed, 81 insertions(+), 148 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index 7ce279c..cd73ef1 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -18,6 +18,7 @@
#include media/soc_camera.h
#include media/v4l2-chip-ident.h
#include media/v4l2-subdev.h
+#include media/v4l2-ctrls.h
/*
* mt9t031 i2c address 0x5d
@@ -64,14 +65,17 @@
struct mt9t031 {
struct v4l2_subdev subdev;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* exposure/auto-exposure cluster */
+ struct v4l2_ctrl *autoexposure;
+ struct v4l2_ctrl *exposure;
+ };
struct v4l2_rect rect; /* Sensor window */
int model; /* V4L2_IDENT_MT9T031* codes from v4l2-chip-ident.h */
u16 xskip;
u16 yskip;
- unsigned int gain;
unsigned short y_skip_top; /* Lines to skip at the top */
- unsigned int exposure;
- unsigned char autoexposure;
};
static struct mt9t031 *to_mt9t031(const struct i2c_client *client)
@@ -211,61 +215,9 @@ enum {
MT9T031_CTRL_EXPOSURE_AUTO,
};
-static const struct v4l2_queryctrl mt9t031_controls[] = {
- [MT9T031_CTRL_VFLIP] = {
- .id = V4L2_CID_VFLIP,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .name = Flip Vertically,
- .minimum= 0,
- .maximum= 1,
- .step = 1,
- .default_value = 0,
- },
- [MT9T031_CTRL_HFLIP] = {
- .id = V4L2_CID_HFLIP,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .name = Flip Horizontally,
- .minimum= 0,
- .maximum= 1,
- .step = 1,
- .default_value = 0,
- },
- [MT9T031_CTRL_GAIN] = {
- .id = V4L2_CID_GAIN,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = Gain,
- .minimum= 0,
- .maximum= 127,
- .step = 1,
- .default_value = 64,
- .flags = V4L2_CTRL_FLAG_SLIDER,
- },
- [MT9T031_CTRL_EXPOSURE] = {
- .id = V4L2_CID_EXPOSURE,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = Exposure,
- .minimum= 1,
- .maximum= 255,
- .step = 1,
- .default_value = 255,
- .flags = V4L2_CTRL_FLAG_SLIDER,
- },
- [MT9T031_CTRL_EXPOSURE_AUTO] = {
- .id = V4L2_CID_EXPOSURE_AUTO,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .name = Automatic Exposure,
- .minimum= 0,
- .maximum= 1,
- .step = 1,
- .default_value = 1,
- }
-};
-
static struct soc_camera_ops mt9t031_ops = {
.set_bus_param = mt9t031_set_bus_param,
.query_bus_param= mt9t031_query_bus_param,
- .controls = mt9t031_controls,
- .num_controls = ARRAY_SIZE(mt9t031_controls),
};
/* target must be _even_ */
@@ -364,18 +316,20 @@ static int mt9t031_set_params(struct i2c_client *client,
if (ret = 0)
ret = reg_write(client, MT9T031_WINDOW_HEIGHT,
rect-height + mt9t031-y_skip_top - 1);
- if (ret = 0 mt9t031-autoexposure) {
+ v4l2_ctrl_lock(mt9t031-autoexposure);
+ if (ret = 0 mt9t031-autoexposure-cur.val == V4L2_EXPOSURE_AUTO) {
unsigned int total_h = rect-height + mt9t031-y_skip_top +
vblank;
ret = set_shutter(client, total_h);
if (ret = 0) {
const u32 shutter_max = MT9T031_MAX_HEIGHT + vblank;
- const struct v4l2_queryctrl *qctrl =
- mt9t031_controls[MT9T031_CTRL_EXPOSURE];
- mt9t031-exposure = (shutter_max / 2 + (total_h - 1) *
- (qctrl-maximum - qctrl-minimum)) /
- shutter_max + qctrl-minimum;
+ struct v4l2_ctrl *ctrl = mt9t031-exposure;
+
+ ctrl-cur.val = (shutter_max / 2 + (total_h - 1) *
+
[RFC PATCH] Getting Hauppauge WinTV HVR-1400 (XC3028L) to work
With this patch my DVB-T receiver works now like before 2.6.34, only the first four tunings fails, after that all works fine. The code was still in there, only commented out. As the original author says, please test it with different XC3028 hardware. If no one has problems with it, please commit it. Signed-off-by: Alina Friedrichsen x-al...@gmx.net --- diff -urNp linux-2.6.37.orig/drivers/media/common/tuners/tuner-xc2028.c linux-2.6.37/drivers/media/common/tuners/tuner-xc2028.c --- linux-2.6.37.orig/drivers/media/common/tuners/tuner-xc2028.c 2011-01-22 23:46:57.0 +0100 +++ linux-2.6.37/drivers/media/common/tuners/tuner-xc2028.c 2011-01-22 23:51:33.0 +0100 @@ -967,7 +967,7 @@ static int generic_set_freq(struct dvb_f * newer firmwares */ -#if 1 +#if 0 /* * The proper adjustment would be to do it at s-code table. * However, this didn't work, as reported by -- 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 V3] v4l: OMAP3 ISP CCDC: Add support for 8bit greyscale sensors
Hi Martin, Thanks for the patch. On Friday 21 January 2011 00:43:31 Martin Hostettler wrote: Adds support for V4L2_MBUS_FMT_Y8_1X8 format and 8bit data width in synchronous interface. When using V4L2_MBUS_FMT_Y8_1X8 (or possibly another 8bit per pixel) mode set the CDCC to output 8bit per pixel instead of 16bit. Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I've submitted the patch internally, it should end up in the public tree in the (hopefully) near future. -- Regards, Laurent Pinchart -- 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] media-ctl: subdev: add Y8 format.
Hi Martin, On Friday 21 January 2011 00:00:29 Martin Hostettler wrote: --- subdev.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) This is a trivial patch for media-ctl to support monochrome 8bit video formats. Thanks for the patch. I've applied it. -- Regards, Laurent Pinchart -- 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: [RFC PATCH 03/12] mt9m001: convert to the control framework.
Hello,
I'm reading threads about the new v4l2_ctrl framework and If you don't mind
I gotta tell you my humble opinion about testing result the new v4l2_ctrl
framework subdev.
I have actually similar curcumstance, with I2C subdev M5MOLS Fujitsu device
which is just send the patch and S5PC210 board for testing this, except not
using soc_camera framework.
But, it's maybe helpful to discuss about this changes to everyone.
2011. 1. 23., 오전 6:21, Guennadi Liakhovetski 작성:
On Wed, 12 Jan 2011, Hans Verkuil wrote:
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
[snip]
-case V4L2_CID_EXPOSURE:
-/* mt9m001 has maximum == default */
-if (ctrl-value qctrl-maximum || ctrl-value
qctrl-minimum)
-return -EINVAL;
-else {
-unsigned long range = qctrl-maximum - qctrl-minimum;
-unsigned long shutter = ((ctrl-value - qctrl-minimum)
* 1048 +
+case V4L2_CID_EXPOSURE_AUTO:
+/* Force manual exposure if only the exposure was changed */
+if (!ctrl-has_new)
+ctrl-val = V4L2_EXPOSURE_MANUAL;
+if (ctrl-val == V4L2_EXPOSURE_MANUAL) {
+unsigned long range = exp-maximum - exp-minimum;
+unsigned long shutter = ((exp-val - exp-minimum) *
1048 +
range / 2) / range + 1;
dev_dbg(client-dev,
Setting shutter width from %d to %lu\n,
-reg_read(client, MT9M001_SHUTTER_WIDTH),
-shutter);
+reg_read(client, MT9M001_SHUTTER_WIDTH),
shutter);
if (reg_write(client, MT9M001_SHUTTER_WIDTH, shutter)
0)
return -EIO;
-mt9m001-exposure = ctrl-value;
-mt9m001-autoexposure = 0;
-}
-break;
-case V4L2_CID_EXPOSURE_AUTO:
-if (ctrl-value) {
+} else {
const u16 vblank = 25;
unsigned int total_h = mt9m001-rect.height +
mt9m001-y_skip_top + vblank;
-if (reg_write(client, MT9M001_SHUTTER_WIDTH,
- total_h) 0)
+
+if (reg_write(client, MT9M001_SHUTTER_WIDTH, total_h)
0)
return -EIO;
-qctrl = soc_camera_find_qctrl(icd-ops,
V4L2_CID_EXPOSURE);
-mt9m001-exposure = (524 + (total_h - 1) *
- (qctrl-maximum - qctrl-minimum)) /
-1048 + qctrl-minimum;
-mt9m001-autoexposure = 1;
-} else
-mt9m001-autoexposure = 0;
-break;
+exp-val = (524 + (total_h - 1) *
+(exp-maximum - exp-minimum)) / 1048 +
+exp-minimum;
+}
+return 0;
}
-return 0;
+return -EINVAL;
It seems to me, that you've dropped V4L2_CID_EXPOSURE here, was it
intentional? I won't verify this in detail now, because, if it wasn't
intentional and you fix it in v2, I'll have to re-check it anyway. Or is
it supposed to be handled by that V4L2_EXPOSURE_MANUAL? So, if the user
issues a V4L2_CID_EXPOSURE, are you getting V4L2_CID_EXPOSURE_AUTO with
val == V4L2_EXPOSURE_MANUAL instead? Weird...
I also wonder first at this part for a long time like below:
1. when calling V4L2_CID_EXPOSURE_AUTO with V4L2_EXPOSURE_AUTO, it's ok.
2. when calling V4L2_CID_EXPOSURE_AUTO with V4L2_EXPOSURE_MANUAL, it's
also ok.
3. when calling V4L2_CID_EXPOSURE? where the device handle this CID?
but, after testing with application step by step, I finally know below:
when calling V4L2_CID_EXPOSURE, changing internal(v4l2_ctrl framework) variable,
exactly struct v4l2_ctrl exposure, which is register for probing time by
V4L2_CID_EXPOSURE, and clustered with struct v4l2_ctrl autoexposure. So, when
the device no needs to handle this values, but it automatically calls control
clustered with
itself, in this case the V4L2_CID_EXPOSURE calls(just
words)V4L2_CID_EXPOSURE_AUTO.
So, the my POV is that foo clustered with auto_foo calls auto_foo with foo's
characteristics.
But, Hans probably would do more clear answer.
Regards,
Heungjun Kim
--
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] Add support for M5MO-LS 8 Mega Pixel camera
HeungJun,
as I didn't really get a chance to review this patch in its current
form before, please let me now add some further comments.
On 01/22/2011 11:12 AM, Kim, HeungJun wrote:
Hello,
This is second patch of I2C/V4L2 subdev driver for M5MOLS 8 Mega Pixel camera
sensor using MIPI interface.
The first version patch is here:
http://www.spinics.net/lists/linux-media/msg26246.html
And the first verion's issues was corrected referencing with quick reviews of
Hans Verkuil and Sylwester Nawrocki.
The main issues is below:
1. remove I2C function macro, and use static inline for type-safe.
2. use the v4l2 control framework documented at v4l2-control.txt.
3. Add regulator enable/disable functions
4. fix any coding problems
The driver supports currently that:
1. Preview enables on each resolution and format code V4L2_MBUS_FMT_VYUY8_2X8.
2. The 5 kind of control was working well.
This driver is tested on s5pc210 board using s5p-fimc driver.
Thanks to any ideas.
Regrads,
Heungjun Kim
Signed-off-by: Heungjun Kimriverful@samsung.com
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
drivers/media/video/Kconfig |2 +
drivers/media/video/Makefile |1 +
drivers/media/video/m5mols/Kconfig |6 +
drivers/media/video/m5mols/Makefile |3 +
drivers/media/video/m5mols/m5mols.h | 257
drivers/media/video/m5mols/m5mols_controls.c | 173 +
drivers/media/video/m5mols/m5mols_core.c | 898
++
drivers/media/video/m5mols/m5mols_reg.h | 103 +++
8 files changed, 1443 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/m5mols/Kconfig
create mode 100644 drivers/media/video/m5mols/Makefile
create mode 100644 drivers/media/video/m5mols/m5mols.h
create mode 100644 drivers/media/video/m5mols/m5mols_controls.c
create mode 100644 drivers/media/video/m5mols/m5mols_core.c
create mode 100644 drivers/media/video/m5mols/m5mols_reg.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index ce3555a..fd3130a 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -746,6 +746,8 @@ config VIDEO_NOON010PC30
---help---
This driver supports NOON010PC30 CIF camera from Siliconfile
+source drivers/media/video/m5mols/Kconfig
+
config SOC_CAMERA
tristate SoC camera support
depends on VIDEO_V4L2 HAS_DMA I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 251b7ca..adb9361 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30) += noon010pc30.o
+obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074.o
obj-$(CONFIG_SOC_CAMERA_MT9M001)+= mt9m001.o
diff --git a/drivers/media/video/m5mols/Kconfig
b/drivers/media/video/m5mols/Kconfig
new file mode 100644
index 000..387425b
--- /dev/null
+++ b/drivers/media/video/m5mols/Kconfig
@@ -0,0 +1,6 @@
+config VIDEO_M5MOLS
+ tristate Fujitsu M5MO-LS 8MP sensor support
+ depends on I2C VIDEO_V4L2
+ ---help---
+ This driver supports Fujitsu M5MO-LS camera sensor with ISP
+
diff --git a/drivers/media/video/m5mols/Makefile
b/drivers/media/video/m5mols/Makefile
new file mode 100644
index 000..b5d19bf
--- /dev/null
+++ b/drivers/media/video/m5mols/Makefile
@@ -0,0 +1,3 @@
+m5mols-objs := m5mols_core.o m5mols_controls.o
+
+obj-$(CONFIG_VIDEO_M5MOLS) += m5mols.o
diff --git a/drivers/media/video/m5mols/m5mols.h
b/drivers/media/video/m5mols/m5mols.h
new file mode 100644
index 000..eaeb7ca
--- /dev/null
+++ b/drivers/media/video/m5mols/m5mols.h
@@ -0,0 +1,257 @@
+/*
+ * Header for M5MOLS 8M Pixel camera sensor with ISP
+ *
+ * Copyright (C) 2011 Samsung Electronics Co., Ltd
+ * Author: HeungJun Kim, riverful@samsung.com
+ *
+ * Copyright (C) 2009 Samsung Electronics Co., Ltd
+ * Author: 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.
+ */
+
+#ifndef M5MOLS_H
+#define M5MOLS_H
+
+#includemedia/v4l2-subdev.h
+#include m5mols_reg.h
+
+#define v4l2msg(fmt, arg...) do {\
+ v4l2_dbg(1, m5mols_debug,info-sd, fmt, ## arg); \
+} while (0)
+
+extern int m5mols_debug;
+
+enum m5mols_mode {
+ MODE_SYSINIT,
+ MODE_PARMSET,
+ MODE_MONITOR,
+
