Re: MT9M131 on I.MX6DL CSI color issue
On Fri, 12 Jan 2018 10:58:40 +0100 Anatolij Gustschin ag...@denx.de wrote: ... > gst-launch v4l2src device=/dev/video4 num-buffers=1 ! \ >videoparse format=5 width=1280 height=1024 framerate=25/1 ! \ >jpegenc ! filesink location=capture1.jpeg I forgot the videoconvert, sorry. Try gst-launch v4l2src device=/dev/video4 num-buffers=1 ! \ filesink location=frame.raw gst-launch filesrc num-buffers=1 location=frame.raw ! \ videoparse format=5 width=1280 height=1024 framerate=25/1 ! \ videoconvert ! jpegenc ! filesink location=capture1.jpeg Anatolij
Re: MT9M131 on I.MX6DL CSI color issue
On Fri, 12 Jan 2018 01:16:03 +0100 Florian Boor florian.b...@kernelconcepts.de wrote: ... >Basically it works pretty well apart from the really strange colors. I guess >its >some YUV vs. RGB issue or similar. Here [1] is an example generated with the >following command. > >gst-launch v4l2src device=/dev/video4 num-buffers=1 ! jpegenc ! filesink >location=capture1.jpeg > >Apart from the colors everything is fine. >I'm pretty sure I have not seen such an effect before - what might be wrong >here? You need conversion to RGB before JPEG encoding. Try with gst-launch v4l2src device=/dev/video4 num-buffers=1 ! \ videoparse format=5 width=1280 height=1024 framerate=25/1 ! \ jpegenc ! filesink location=capture1.jpeg For "format" codes see gst-inspect-1.0 videoparse. HTH, Anatolij
Re: [PATCH v6 13/17] [media] fsl-viu: adjust for OF based clock lookup
On Sat, 30 Nov 2013 23:51:33 +0100 Gerhard Sittig g...@denx.de wrote: after device tree based clock lookup became available, the VIU driver need no longer use the previous global viu_clk name, but should use the ipg clock name specific to the OF node Cc: Mauro Carvalho Chehab m.che...@samsung.com Cc: linux-media@vger.kernel.org Signed-off-by: Gerhard Sittig g...@denx.de --- drivers/media/platform/fsl-viu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) applied to next. Thanks! Anatolij -- 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 0/5] fsl-viu: v4l2 compliance fixes
Hi Hans, On Sat, 16 Feb 2013 11:18:22 +0100 Hans Verkuil hverk...@xs4all.nl wrote: This patch series converts fsl-viu to the control framework and provides some additional v4l2 compliance fixes. Anatolij, are you able to test this? Sorry for long delay, finally managed to set up the board with recent kernel to test the fsl-viu driver patches. Ideally I'd like to see the output of the v4l2-compliance tool (found in the http://git.linuxtv.org/v4l-utils.git repository). I know that there are remaining issues, especially with the fact that there can be one user at a time only (very bad!) and some overlay issues. I can try to fix those, but I need someone to test otherwise I won't bother. Below is the output of the v4l2-compliance: # v4l2-compliance -v -d 0 Driver Info: Driver name : viu Card type : viu Bus info : platform:viu Driver version: 3.9.0 Capabilities : 0x8505 Video Capture Video Overlay Read/Write Streaming Device Capabilities Device Caps : 0x0505 Video Capture Video Overlay Read/Write Streaming Compliance test for device /dev/video0 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: FAIL Debug ioctls: test VIDIOC_DBG_G_CHIP_IDENT: OK (Not Supported) test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK Input ioctls: test VIDIOC_G/S_TUNER: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) fail: v4l2-test-input-output.cpp(415): could set input to invalid input 1 test VIDIOC_G/S/ENUMINPUT: FAIL test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 1 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Control ioctls: info: checking v4l2_queryctrl of control 'User Controls' (0x00980001) info: checking v4l2_queryctrl of control 'Brightness' (0x00980900) info: checking v4l2_queryctrl of control 'Contrast' (0x00980901) info: checking v4l2_queryctrl of control 'Saturation' (0x00980902) info: checking v4l2_queryctrl of control 'Hue' (0x00980903) info: checking v4l2_queryctrl of control 'Chroma AGC' (0x0098091d) info: checking v4l2_queryctrl of control 'Chroma Gain' (0x00980924) info: checking v4l2_queryctrl of control 'Brightness' (0x00980900) info: checking v4l2_queryctrl of control 'Contrast' (0x00980901) info: checking v4l2_queryctrl of control 'Saturation' (0x00980902) info: checking v4l2_queryctrl of control 'Hue' (0x00980903) info: checking v4l2_queryctrl of control 'Chroma AGC' (0x0098091d) info: checking v4l2_queryctrl of control 'Chroma Gain' (0x00980924) test VIDIOC_QUERYCTRL/MENU: OK info: checking control 'User Controls' (0x00980001) info: checking control 'Brightness' (0x00980900) info: checking control 'Contrast' (0x00980901) info: checking control 'Saturation' (0x00980902) info: checking control 'Hue' (0x00980903) info: checking control 'Chroma AGC' (0x0098091d) info: checking control 'Chroma Gain' (0x00980924) test VIDIOC_G/S_CTRL: OK info: checking extended control 'User Controls' (0x00980001) info: checking extended control 'Brightness' (0x00980900) info: checking extended control 'Contrast' (0x00980901) info: checking extended control 'Saturation' (0x00980902) info: checking extended control 'Hue' (0x00980903) info: checking extended control 'Chroma AGC' (0x0098091d) info: checking extended control 'Chroma Gain' (0x00980924) test VIDIOC_G/S/TRY_EXT_CTRLS: OK info: checking control event 'User Controls' (0x00980001) info: checking control event 'Brightness' (0x00980900) info: checking control event 'Contrast' (0x00980901) info: checking control event 'Saturation' (0x00980902) info: checking control event 'Hue' (0x00980903) info: checking control event 'Chroma AGC' (0x0098091d) info: checking control
Re: [PATCH v6 1/7] media: V4L2: add temporary clock helpers
On Thu, 21 Mar 2013 13:49:50 +0530 Prabhakar Lad prabhakar.cse...@gmail.com wrote: ... drivers/media/v4l2-core/Makefile |2 +- drivers/media/v4l2-core/v4l2-clk.c | 184 include/media/v4l2-clk.h | 55 +++ 3 files changed, 240 insertions(+), 1 deletions(-) create mode 100644 drivers/media/v4l2-core/v4l2-clk.c create mode 100644 include/media/v4l2-clk.h While trying out this patch I got following error (using 3.9-rc3):- drivers/media/v4l2-core/v4l2-clk.c: In function 'v4l2_clk_register': drivers/media/v4l2-core/v4l2-clk.c:134:2: error: implicit declaration of function 'kzalloc' drivers/media/v4l2-core/v4l2-clk.c:134:6: warning: assignment makes pointer from integer without a cast drivers/media/v4l2-core/v4l2-clk.c:162:2: error: implicit declaration of function 'kfree' make[3]: *** [drivers/media/v4l2-core/v4l2-clk.o] Error 1 make[2]: *** [drivers/media/v4l2-core] Error 2 please try adding #include linux/slab.h in the affected file. Thanks, Anatolij -- 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 -next] [media] mt9v022: fix potential NULL pointer dereference in mt9v022_probe()
On Wed, 28 Nov 2012 21:56:15 -0500
Wei Yongjun weiyj...@gmail.com wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
The dereference to 'icl' should be moved below the NULL test.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Acked-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/i2c/soc_camera/mt9v022.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/soc_camera/mt9v022.c
b/drivers/media/i2c/soc_camera/mt9v022.c
index d40a885..7509802 100644
--- a/drivers/media/i2c/soc_camera/mt9v022.c
+++ b/drivers/media/i2c/soc_camera/mt9v022.c
@@ -875,7 +875,7 @@ static int mt9v022_probe(struct i2c_client *client,
struct mt9v022 *mt9v022;
struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
- struct mt9v022_platform_data *pdata = icl-priv;
+ struct mt9v022_platform_data *pdata;
int ret;
if (!icl) {
@@ -893,6 +893,7 @@ static int mt9v022_probe(struct i2c_client *client,
if (!mt9v022)
return -ENOMEM;
+ pdata = icl-priv;
v4l2_i2c_subdev_init(mt9v022-subdev, client, mt9v022_subdev_ops);
v4l2_ctrl_handler_init(mt9v022-hdl, 6);
v4l2_ctrl_new_std(mt9v022-hdl, mt9v022_ctrl_ops,
--
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] soc_camera: fix VIDIOC_S_GROP ioctl
Sometimes VIDIOC_S_GROP ioctl doesn't work, soc-camera driver reports: soc-camera-pdrv soc-camera-pdrv.0: S_CROP denied: getting current crop failed The VIDIOC_G_CROP documentation states that the type field needs to be set to the respective buffer type when querying, so the check in .g_crop() of the subdevices returns -EINVAL if the type is not set properly. Here the uninitialized local variable 'current_crop' is passed to the .g_crop() and this leads to the observed error. Initialize the type field of the local 'current_crop' before get_crop call. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/media/platform/soc_camera/soc_camera.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index d3f0b84..7ebc784 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -902,6 +902,8 @@ static int soc_camera_s_crop(struct file *file, void *fh, dev_dbg(icd-pdev, S_CROP(%ux%u@%u:%u)\n, rect-width, rect-height, rect-left, rect-top); + current_crop.type = a-type; + /* If get_crop fails, we'll let host and / or client drivers decide */ ret = ici-ops-get_crop(icd, current_crop); -- 1.7.1 -- 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] OV5642: fix VIDIOC_S_GROP ioctl
Hi Guennadi, On Mon, 26 Nov 2012 16:20:14 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -902,6 +902,8 @@ static int soc_camera_s_crop(struct file *file, void *fh, dev_dbg(icd-pdev, S_CROP(%ux%u@%u:%u)\n, rect-width, rect-height, rect-left, rect-top); + current_crop.type = a-type; + /* If get_crop fails, we'll let host and / or client drivers decide */ ret = ici-ops-get_crop(icd, current_crop); What do you think? Yes, this makes sense. Please, submit a patch. Done. And the type field should be checked in .s_crop() anyway, I think. It is checked in soc_camera_s_crop() just a couple of lines above the snippet above. Or what do you mean? Yes, you are right! Okay, then there is no need to check it again in the subdevice driver. Thanks, Anatolij -- 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
Using OV5642 sensor driver for CM8206-A500SA-E
Hi, I'm trying to use mainline ov5642 driver for ov5642 based camera module CM8206-A500SA-E from TRULY. The driver loads and initializes the sensor, but the initialization seems to be incomplete, the sensor doesn't generate pixel clock and sync signals. For a quick test I've replaced the default initialisation sequences from ov5642_default_regs_init[] and ov5642_default_regs_finalise[] with an init sequence in ov5642_setting_30fps_720P_1280_720[] taken from Freescale ov5642 driver [1] and commented out ov5642_set_resolution() in ov5642_s_power(). With these changes to the mainline driver the sensor starts clocking out pixels and I receive 1280x720 image. Is anyone using the mainline ov5642 driver for mentioned TRULY camera module? Just wanted to ask before digging further to find out what changes to the mainline driver are really needed to make it working with TRULY camera module. Thanks, Anatolij [1] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/plain/drivers/media/video/mxc/capture/ov5642.c?h=imx_3.0.15 -- 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] OV5642: fix VIDIOC_S_GROP ioctl
On Tue, 6 Nov 2012 12:45:51 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Tue, 6 Nov 2012, Anatolij Gustschin wrote: VIDIOC_S_GROP ioctl doesn't work, soc-camera driver reports: soc-camera-pdrv soc-camera-pdrv.0: S_CROP denied: getting current crop failed The issue is caused by checking for V4L2_BUF_TYPE_VIDEO_CAPTURE type in driver's g_crop callback. This check should be in s_crop instead, g_crop should just set the type field to V4L2_BUF_TYPE_VIDEO_CAPTURE as other drivers do. Move the V4L2_BUF_TYPE_VIDEO_CAPTURE type check to s_crop callback. I'm not sure this is correct: http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-crop.html Or is the .g_crop() subdev operation using a different semantics? Where is that documented? I do not know if it is documented somewhere. But it seems natural to me that a sensor driver sets the type field to V4L2_BUF_TYPE_VIDEO_CAPTURE in its .g_crop(). A sensor is a capture device, not an output or overlay device. And this ioctl is a query operation. OTOH I'm fine with this type checking in .g_crop() and it can help to discover bugs in user space apps. The VIDIOC_G_CROP documentation states that the type field needs to be set to the respective buffer type when querying, so the check in .g_crop() is perfectly valid. But then I need following patch to fix the observed issue: --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -902,6 +902,8 @@ static int soc_camera_s_crop(struct file *file, void *fh, dev_dbg(icd-pdev, S_CROP(%ux%u@%u:%u)\n, rect-width, rect-height, rect-left, rect-top); + current_crop.type = a-type; + /* If get_crop fails, we'll let host and / or client drivers decide */ ret = ici-ops-get_crop(icd, current_crop); What do you think? And the type field should be checked in .s_crop() anyway, I think. Thanks, Anatolij -- 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: Using OV5642 sensor driver for CM8206-A500SA-E
Hi Bastian, On Tue, 6 Nov 2012 10:38:40 +0100 Bastian Hecht hec...@googlemail.com wrote: Hi Anatolij, if I remember correctly I had the same issue inverted. For me the initialization sequence of the freescale driver didn't work. Generally it was quite difficult to deduce anything from the docs to split the initialization into sensible parts. Too many parts were undocumented or didn't work as expected. Maybe there are different hardware revisions out there that need a different register setup. Unfortunately I can only give you some general notes here as I no longer possess an OV5642. Okay, thanks for the info anyway! Anatolij -- 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] OV5642: fix VIDIOC_S_GROP ioctl
VIDIOC_S_GROP ioctl doesn't work, soc-camera driver reports: soc-camera-pdrv soc-camera-pdrv.0: S_CROP denied: getting current crop failed The issue is caused by checking for V4L2_BUF_TYPE_VIDEO_CAPTURE type in driver's g_crop callback. This check should be in s_crop instead, g_crop should just set the type field to V4L2_BUF_TYPE_VIDEO_CAPTURE as other drivers do. Move the V4L2_BUF_TYPE_VIDEO_CAPTURE type check to s_crop callback. Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de --- drivers/media/i2c/soc_camera/ov5642.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/media/i2c/soc_camera/ov5642.c b/drivers/media/i2c/soc_camera/ov5642.c index 8577e0c..19863e5 100644 --- a/drivers/media/i2c/soc_camera/ov5642.c +++ b/drivers/media/i2c/soc_camera/ov5642.c @@ -872,6 +872,9 @@ static int ov5642_s_crop(struct v4l2_subdev *sd, const struct v4l2_crop *a) struct v4l2_rect rect = a-c; int ret; + if (a-type != V4L2_BUF_TYPE_VIDEO_CAPTURE) + return -EINVAL; + v4l_bound_align_image(rect.width, 48, OV5642_MAX_WIDTH, 1, rect.height, 32, OV5642_MAX_HEIGHT, 1, 0); @@ -899,9 +902,7 @@ static int ov5642_g_crop(struct v4l2_subdev *sd, struct v4l2_crop *a) struct ov5642 *priv = to_ov5642(client); struct v4l2_rect *rect = a-c; - if (a-type != V4L2_BUF_TYPE_VIDEO_CAPTURE) - return -EINVAL; - + a-type = V4L2_BUF_TYPE_VIDEO_CAPTURE; *rect = priv-crop_rect; return 0; -- 1.7.1 -- 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] mt9v022: support required register settings in snapshot mode
On Mon, 8 Oct 2012 11:22:05 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Sat, 6 Oct 2012, Anatolij Gustschin wrote:
Hi Guennadi,
On Fri, 28 Sep 2012 15:30:33 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Fri, 28 Sep 2012, Anatolij Gustschin wrote:
Hi Guennadi,
On Fri, 28 Sep 2012 14:33:34 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
...
@@ -235,12 +238,32 @@ static int mt9v022_s_stream(struct
v4l2_subdev *sd, int enable)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct mt9v022 *mt9v022 = to_mt9v022(client);
- if (enable)
+ if (enable) {
/* Switch to master normal mode */
mt9v022-chip_control = ~0x10;
- else
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+* Unset snapshot mode specific settings: clear
bit 9
+* and bit 2 in reg. 0x20 when in normal mode.
+*/
+ if (reg_clear(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ } else {
/* Switch to snapshot mode */
mt9v022-chip_control |= 0x10;
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+* Required settings for snapshot mode: set bit
9
+* (RST enable) and bit 2 (CR enable) in reg.
0x20
+* See TechNote TN0960 or TN-09-225.
+*/
+ if (reg_set(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ }
Do I understand it right, that now on mt9v022 rev.3 and mt9v024 you
unconditionally added using REG32 for leaving the snapshot mode on
streamon and entering it on streamoff. This should be ok in
principle,
since that's also what we're trying to do, using the CHIP_CONTROL
register. But in your comment you say, that on some _systems_ you can
only
_operate_ in snapshot mode. I.e. the snapshot mode enabled during
running
streaming, right? Then how does this patch help you with that?
Yes. But i.e. the driver calling the sub-device stream control function
on streamon knows that the normal mode is not supported and therefore it
calls this function with argument enable == 0, effectively setting the
snapshot mode.
Right, I thought you could be doing that... Well, on the one hand I
should
be happy, that the problem is solved without driver modifications, OTOH
this isn't pretty... In fact this shouldn't work at all. After a
stream-off the buffer queue should be stopped too.
Why shouldn't it work? The buffer queue is handled by the host driver,
not by the sensor driver. And in my case the host driver stops the buffer
queue in its streamoff, as it should. It works without issues and doesn't
cause any problems for other mt9v022 users.
Because one shouldn't abuse the API by activating streaming on the bridge
driver and deactivating it on the sensor.
I don't see how is it an abuse of the API at all. The sensor is just
configured to snapshot mode but is still able to stream if it is
triggered continuously by external events. It is actually a streaming
case.
Thanks,
Anatolij
--
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] mt9v022: support required register settings in snapshot mode
Hi Guennadi,
On Fri, 28 Sep 2012 15:30:33 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Fri, 28 Sep 2012, Anatolij Gustschin wrote:
Hi Guennadi,
On Fri, 28 Sep 2012 14:33:34 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
...
@@ -235,12 +238,32 @@ static int mt9v022_s_stream(struct v4l2_subdev
*sd, int enable)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct mt9v022 *mt9v022 = to_mt9v022(client);
- if (enable)
+ if (enable) {
/* Switch to master normal mode */
mt9v022-chip_control = ~0x10;
- else
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+* Unset snapshot mode specific settings: clear
bit 9
+* and bit 2 in reg. 0x20 when in normal mode.
+*/
+ if (reg_clear(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ } else {
/* Switch to snapshot mode */
mt9v022-chip_control |= 0x10;
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+* Required settings for snapshot mode: set bit
9
+* (RST enable) and bit 2 (CR enable) in reg.
0x20
+* See TechNote TN0960 or TN-09-225.
+*/
+ if (reg_set(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ }
Do I understand it right, that now on mt9v022 rev.3 and mt9v024 you
unconditionally added using REG32 for leaving the snapshot mode on
streamon and entering it on streamoff. This should be ok in principle,
since that's also what we're trying to do, using the CHIP_CONTROL
register. But in your comment you say, that on some _systems_ you can
only
_operate_ in snapshot mode. I.e. the snapshot mode enabled during running
streaming, right? Then how does this patch help you with that?
Yes. But i.e. the driver calling the sub-device stream control function
on streamon knows that the normal mode is not supported and therefore it
calls this function with argument enable == 0, effectively setting the
snapshot mode.
Right, I thought you could be doing that... Well, on the one hand I should
be happy, that the problem is solved without driver modifications, OTOH
this isn't pretty... In fact this shouldn't work at all. After a
stream-off the buffer queue should be stopped too.
Why shouldn't it work? The buffer queue is handled by the host driver,
not by the sensor driver. And in my case the host driver stops the buffer
queue in its streamoff, as it should. It works without issues and doesn't
cause any problems for other mt9v022 users.
Thanks,
Anatolij
--
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 1/3] mt9v022: add v4l2 controls for blanking
Hi Guennadi, On Fri, 28 Sep 2012 00:03:45 +0200 Anatolij Gustschin ag...@denx.de wrote: Add controls for horizontal and vertical blanking. Also add an error message for case that the control handler init failed. Since setting the blanking registers is done by controls now, we shouldn't change these registers outside of the control function. Use v4l2_ctrl_s_ctrl() to set them. Signed-off-by: Anatolij Gustschin ag...@denx.de --- Changes since first version: - drop analog and reg32 setting controls - use more descriptive error message for handler init error - revise commit log - rebase on staging/for_v3.7 branch drivers/media/i2c/soc_camera/mt9v022.c | 49 +-- 1 files changed, 45 insertions(+), 4 deletions(-) Can these mt9v022 patches be queued for mainlining, please? Thanks, Anatolij -- 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 2/2] V4L: soc_camera: disable I2C subdev streamon for mpc52xx_csi
Hi Guennadi, On Wed, 3 Oct 2012 00:09:29 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Anatolij +#if !defined(CONFIG_VIDEO_MPC52xx_CSI) \ +!defined(CONFIG_VIDEO_MPC52xx_CSI_MODULE) No, we're not adding any preprocessor or run-time hardware dependencies to soc-camera or to any other generic code. I have no idea what those IFM O2D cameras are. If it's their common feature, that they cannot take any further I2C commands, while streaming, their drivers have to do that themselves. I'm not sure I understand you. To do what themselves? They - subdevice drivers of such IFM O2D cameras - should take care to avoid any I2C commands during a running read-out. Neither the bridge driver nor the framework core can or should know these details. This is just a generic call to a subdevice's .s_stream() method. What the driver does in it is totally its own business. Nobody says, that you have to issue I2C commands in it. The fact that many I2C commands are permitted during streaming doesn't necessary mean that an application must use them during streaming. Our camera application is aware of I2C bus access limitations during steaming and after streamon it doesn't use configurations resulting in I2C accesses to the sensor. But I'm not arguing for the ifdef here. We are using mt9v022 subdevice driver and I'd really avoid creating new custom subdevice driver, duplicating the mt9v022 driver functionality. This custom duplicated driver also won't be accepted in mainline, I think. I was thinking about a proposal for adding I2C bus access limitation awareness to the mt9v022 subdev driver. In our case we enable the snapshot mode by calling subdevice's .s_stream() in the .start_streaming() of the capture driver (that means as part of vb2_streamon() in soc_camera_streamon()) and then configure the logic for read-out there. Here is the relevant part from soc_camera_streamon(): if (ici-ops-init_videobuf) ret = videobuf_streamon(icd-vb_vidq); else ret = vb2_streamon(icd-vb2_vidq, i); After that I2C access is not possible until .stop_streaming() in the capture driver. After enabling streaming in .s_stream() the subdevice driver will have to filter (optionaly) further I2C accesses and return success code for them so that soc_camera_streamon() finaly succeeds. Currently the return code of s_stream v4l2_subdev_call() is not checked: if (!ret) v4l2_subdev_call(sd, video, s_stream, 1); But for the case it will be fixed, we have to return success code in s_stream, at least. Otherwise VIDIOC_STREAMON will fail. Will you accept adding optional I2C access filtering to the mt9v022 subdev driver? Thanks, Anatolij -- 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 2/2] V4L: soc_camera: disable I2C subdev streamon for mpc52xx_csi
On Fri, 5 Oct 2012 16:31:58 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Anatolij On Fri, 5 Oct 2012, Anatolij Gustschin wrote: Hi Guennadi, On Wed, 3 Oct 2012 00:09:29 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Anatolij +#if !defined(CONFIG_VIDEO_MPC52xx_CSI) \ +!defined(CONFIG_VIDEO_MPC52xx_CSI_MODULE) No, we're not adding any preprocessor or run-time hardware dependencies to soc-camera or to any other generic code. I have no idea what those IFM O2D cameras are. If it's their common feature, that they cannot take any further I2C commands, while streaming, their drivers have to do that themselves. I'm not sure I understand you. To do what themselves? They - subdevice drivers of such IFM O2D cameras - should take care to avoid any I2C commands during a running read-out. Neither the bridge driver nor the framework core can or should know these details. This is just a generic call to a subdevice's .s_stream() method. What the driver does in it is totally its own business. Nobody says, that you have to issue I2C commands in it. Unfortunately you still haven't explained what IFM O2D cameras are and why they have that I2C command restriction. This is not true. I did. And I did it even _before_ anyone has asked me to explain it. Please read the commit log of this patch again. The fact that many I2C commands are permitted during streaming doesn't necessary mean that an application must use them during streaming. Our camera application is aware of I2C bus access limitations during steaming and after streamon it doesn't use configurations resulting in I2C accesses to the sensor. But I'm not arguing for the ifdef here. But that's the only thing, that your patch is doing. So, this patch can be dropped? Only if there will be another possibility to isolate I2C access after streamon. Otherwise the capturing won't work. We are using mt9v022 subdevice driver and I'd really avoid creating new custom subdevice driver, duplicating the mt9v022 driver functionality. This custom duplicated driver also won't be accepted in mainline, I think. Correct. I was thinking about a proposal for adding I2C bus access limitation awareness to the mt9v022 subdev driver. I think I begin to understand. This is exactly why you need the snapshot mode in mt9v022, right? No! Not only. There are many different requirements for industrial camera applications. I.e. one requirement is to trigger a single frame on some external event and to capture exactly this triggered frame. Streaming mode is not suitable here. And in your camera host driver you issue a stream-off command on stream-on to switch into the snapshot mode, then you have to suppress the stream-on in soc-camera core. If I understand correctly, then this is broken. Your host driver will stop streaming on all sensor drivers and the ifdef will suppress the streamon from the soc-camera core, so, your host driver will only work on this specific board, where you have to use the snapshot mode on mt9v022. What is wrong with this? Nothing is broken at all. This host driver is written for this specific board family and is not used on other boards. It cannot be used on other boards at all since these do not provide needed sensor glue logic. Even if other sensor drivers should ever be used on this board (most probably it will never be the case), they have to be used in snapshot mode anyway. The proper solution, as I already suggested before, would be to implement a snapshot mode support. In that case the mt9v022 driver will be aware, that it has to work in the snapshot mode and will not switch over into the streaming mode. This topic has been raised several times on the mailing list, but until now nobody had a real need for a snapshot mode. The easiest way to do this would be to add a camera class control, however, I suspect, this is a much more complex topic, see, e.g. this recent thread: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/54079 Maybe you could review that thread and reply to it with your requirements? I did already read this thread partially. Unfortunately I do not have time for it now, maybe later. Thanks, Anatolij -- 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 3/3] fsl-viu: fix compiler warning.
On Tue, 2 Oct 2012 10:57:20 +0200 Hans Verkuil hans.verk...@cisco.com wrote: drivers/media/platform/fsl-viu.c: In function 'vidioc_s_fbuf': drivers/media/platform/fsl-viu.c:867:32: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] This is fall-out from this commit: commit e6eb28c2207b9397d0ab56e238865a4ee95b7ef9 Author: Hans Verkuil hans.verk...@cisco.com Date: Tue Sep 4 10:26:45 2012 -0300 [media] v4l2: make vidioc_s_fbuf const Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/platform/fsl-viu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Anatolij Gustschin ag...@denx.de Thanks, Anatolij -- 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 2/2] V4L: soc_camera: disable I2C subdev streamon for mpc52xx_csi
Hi Guennadi, On Fri, 28 Sep 2012 13:26:03 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... +#if !defined(CONFIG_VIDEO_MPC52xx_CSI) \ +!defined(CONFIG_VIDEO_MPC52xx_CSI_MODULE) No, we're not adding any preprocessor or run-time hardware dependencies to soc-camera or to any other generic code. I have no idea what those IFM O2D cameras are. If it's their common feature, that they cannot take any further I2C commands, while streaming, their drivers have to do that themselves. I'm not sure I understand you. To do what themselves? Thanks, Anatolij -- 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 1/2] V4L: soc_camera: add driver for IFM camera sensor interface on mpc5200
IFM O2D cameras use special sensor bus interface glue-logic to
connect camera sensors to mpc5200 LocalPlus bus. Add camera
sensor driver for this mpc5200 camera interface.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/platform/soc_camera/Kconfig |7 +
drivers/media/platform/soc_camera/Makefile |1 +
.../media/platform/soc_camera/mpc5200-csi-camera.c | 1212
3 files changed, 1220 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/platform/soc_camera/mpc5200-csi-camera.c
diff --git a/drivers/media/platform/soc_camera/Kconfig
b/drivers/media/platform/soc_camera/Kconfig
index 9afe1e7..4d6c74d 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -85,3 +85,10 @@ config VIDEO_ATMEL_ISI
This module makes the ATMEL Image Sensor Interface available
as a v4l2 device.
+config VIDEO_MPC52xx_CSI
+ tristate IFM MPC5200 Camera Sensor Interface driver
+ depends on SOC_CAMERA PPC_MPC52xx
+ select PPC_BESTCOMM_GEN_BD
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a driver for IFM camera sensor interface on mpc5200.
diff --git a/drivers/media/platform/soc_camera/Makefile
b/drivers/media/platform/soc_camera/Makefile
index 136b7f8..79e6339 100644
--- a/drivers/media/platform/soc_camera/Makefile
+++ b/drivers/media/platform/soc_camera/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
# soc-camera host drivers have to be linked after camera drivers
obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
+obj-$(CONFIG_VIDEO_MPC52xx_CSI)+= mpc5200-csi-camera.o
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
diff --git a/drivers/media/platform/soc_camera/mpc5200-csi-camera.c
b/drivers/media/platform/soc_camera/mpc5200-csi-camera.c
new file mode 100644
index 000..84746c1
--- /dev/null
+++ b/drivers/media/platform/soc_camera/mpc5200-csi-camera.c
@@ -0,0 +1,1212 @@
+/*
+ * Driver for image sensor/fpga interface on mpc5200 LPB found
+ * on IFM o2d based boards
+ *
+ * Code base taken from i.MX3x camera host driver
+ * Copyright (C) 2008
+ * Guennadi Liakhovetski, DENX Software Engineering, l...@denx.de
+ *
+ * Copyright (C) 2012
+ * Anatolij Gustschin ag...@denx.de, DENX Software Engineering
+ *
+ * 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.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/string.h
+#include linux/delay.h
+#include linux/errno.h
+#include linux/unistd.h
+#include linux/slab.h
+#include linux/interrupt.h
+#include linux/init.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/of_gpio.h
+#include linux/dma-mapping.h
+#include asm/mpc52xx.h
+
+#include linux/i2c.h
+#include linux/videodev2.h
+#include linux/sched.h
+#include media/v4l2-common.h
+#include media/v4l2-dev.h
+#include media/videobuf2-dma-contig.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+
+#define O2XXX_CAM_DRV_NAME o2d_csi
+
+#define MAX_VIDEO_MEM 2 /* Video memory limit in megabytes */
+
+#define DEFAULT_IMAGE_WIDTH688 /* Default image width */
+#define DEFAULT_IMAGE_HEIGHT 480 /* Default image height */
+#define DEFAULT_IMAGE_LENGTH (DEFAULT_IMAGE_WIDTH * DEFAULT_IMAGE_HEIGHT)
+
+enum o2xxx_buffer_state {
+ BUF_NEEDS_INIT,
+ BUF_PREPARED,
+};
+
+struct o2xxx_camera_buffer {
+ /* v4l2_buffer must be first */
+ struct vb2_buffer vb;
+ dma_addr_t paddr;
+ size_t bsize;
+ enum o2xxx_buffer_state state;
+ struct list_headqueue;
+};
+
+struct o2d_csi_priv {
+ /* sensor control gpios */
+ int imag_capture;
+ int imag_reset;
+ int imag_master_en;
+
+ struct device_node *gpt_np;
+ struct mpc52xx_gpt __iomem *gpt;
+ struct mpc52xx_intr __iomem *intr;
+ int irq;
+ int chip_select;
+
+ /* LocalPlus Bus camera CS phys addr */
+ resource_size_t lpb_cs_phys;
+
+ resource_size_t lpbfifo_regs_phys;
+ void __iomem *lpbfifo_regs;
+
+ /* soc_camera and v4l2 interface */
+ struct platform_device *soc_cam_pdev;
+ struct soc_camera_device *icd;
+ struct soc_camera_host soc_host;
+ size_t buf_total;
+ int sequence;
+ struct vb2_alloc_ctx *alloc_ctx;
+
+ unsigned long image_length;
+
+ struct o2xxx_camera_buffer *active;
+ spinlock_t lock;/* Protects video buffer
[PATCH 2/2] V4L: soc_camera: disable I2C subdev streamon for mpc52xx_csi
With mpc52xx_csi interface I2C subdev streamon after vb2_streamon()
doesn't work due to mpc52xx sensor interface glue-logic restrictions.
Since mpc5200 doesn't have a camera sensor interface, the sensor on
O2D cameras is connected to the LocalPlus bus by special glue-logic.
While sensor read-out the sensor will be clocked with the bus chip-
select signal as the sensor clock so that the read-out is synchronous
with the data accesses on the bus. Therefore, I2C access can't be
performed when the glue-logic is setup for sensor read-out.
mpc52xx_csi driver for O2D cameras performs I2C subdev streamon in
its start_streaming() operation and then disables the I2C bus access
by configuring the interface glue-logic for sensor read-out.
For above-mentioned reasons we disable this subdev call here.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/platform/soc_camera/soc_camera.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index f6b1c1f..64e0abb 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -809,7 +809,7 @@ static int soc_camera_streamon(struct file *file, void
*priv,
{
struct soc_camera_device *icd = file-private_data;
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
- struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ struct v4l2_subdev __maybe_unused *sd = soc_camera_to_subdev(icd);
int ret;
WARN_ON(priv != file-private_data);
@@ -826,8 +826,11 @@ static int soc_camera_streamon(struct file *file, void
*priv,
else
ret = vb2_streamon(icd-vb2_vidq, i);
+#if !defined(CONFIG_VIDEO_MPC52xx_CSI) \
+!defined(CONFIG_VIDEO_MPC52xx_CSI_MODULE)
if (!ret)
v4l2_subdev_call(sd, video, s_stream, 1);
+#endif
return ret;
}
--
1.7.1
--
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] mt9v022: support required register settings in snapshot mode
Hi Guennadi,
On Fri, 28 Sep 2012 14:33:34 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
...
@@ -235,12 +238,32 @@ static int mt9v022_s_stream(struct v4l2_subdev *sd,
int enable)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct mt9v022 *mt9v022 = to_mt9v022(client);
- if (enable)
+ if (enable) {
/* Switch to master normal mode */
mt9v022-chip_control = ~0x10;
- else
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+* Unset snapshot mode specific settings: clear bit 9
+* and bit 2 in reg. 0x20 when in normal mode.
+*/
+ if (reg_clear(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ } else {
/* Switch to snapshot mode */
mt9v022-chip_control |= 0x10;
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+* Required settings for snapshot mode: set bit 9
+* (RST enable) and bit 2 (CR enable) in reg. 0x20
+* See TechNote TN0960 or TN-09-225.
+*/
+ if (reg_set(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ }
Do I understand it right, that now on mt9v022 rev.3 and mt9v024 you
unconditionally added using REG32 for leaving the snapshot mode on
streamon and entering it on streamoff. This should be ok in principle,
since that's also what we're trying to do, using the CHIP_CONTROL
register. But in your comment you say, that on some _systems_ you can only
_operate_ in snapshot mode. I.e. the snapshot mode enabled during running
streaming, right? Then how does this patch help you with that?
Yes. But i.e. the driver calling the sub-device stream control function
on streamon knows that the normal mode is not supported and therefore it
calls this function with argument enable == 0, effectively setting the
snapshot mode.
Thanks,
Anatolij
--
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] mt9v022: support required register settings in snapshot mode
On Fri, 28 Sep 2012 15:30:33 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... Yes. But i.e. the driver calling the sub-device stream control function on streamon knows that the normal mode is not supported and therefore it calls this function with argument enable == 0, effectively setting the snapshot mode. Right, I thought you could be doing that... Well, on the one hand I should be happy, that the problem is solved without driver modifications, OTOH this isn't pretty... In fact this shouldn't work at all. After a stream-off the buffer queue should be stopped too. Yes, the capture driver stops its buffer queue on stream-off. Thanks, Anatolij -- 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 1/3] mt9v022: add v4l2 controls for blanking and other register settings
Hi Guennadi, On Tue, 11 Sep 2012 10:24:23 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Anatolij On Tue, 28 Aug 2012, Anatolij Gustschin wrote: Hi Guennadi, On Fri, 24 Aug 2012 23:23:37 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... Every time the sensor is reset, it resets this register. Without setting the register after sensor reset to the needed value I only get garbage data from the sensor. Since the possibility to reset the sensor is provided on the hardware and also used, the register has to be set after each sensor reset. Only the instance controlling the reset gpio pin knows the time, when the register should be initialized again, so it is asynchronously and not related to the standard camera activities. But since the stuff is _not_ documented, I can only speculate. Maybe it can be set to different values to achieve different things, currently I do not know. How about adding that register write (if required by platform data) to mt9v022_s_power() in the on case? This is called (on soc-camera hosts at least) on each first open(), would this suffice? This would suffice. But now I found some more info for this register. Rev3. errata Yes, I've found that one too. But I don't understand the table they present there: have only default values of various registers changed, or have actually new features been added in Rev.3? If the latter we'd have to find out which revision we're running on. Some issues have been fixed in Rev3 so that these register settings can work. I've found the technical note describing the snapshot mode and it says that register 0x20 bit 2 and bit 9 must be set in the snapshot mode. This applies to mt9v022 rev3 and mt9v024, so it should be configured dependent on revision, yes. I'll remove register 0x20 setting control entirely and provide separate patch configuring required settings in snapshot mode. mentions that the bit 9 of the register should be set when in snapshot mode (in my case this is the only mode that we can use). Currently the snapshot mode is used in the mt9v022 driver to stop streaming. This means you've got more local changes in your driver to enable capture in the snapshot mode? Yes, in my case the capture driver sets this mode in its start_streaming function. I'll submit the driver, too. Additionally the errata recommends to set bit 2 when the high dynamic range mode is used. The HiDy mode is also not used so far in the driver. Yes. I think support for it could be added as V4L2_CID_WIDE_DYNAMIC_RANGE control. Now I'm not sure how to realise these settings. The bit 9 should be set/unset when configuring the master/snapshot mode in mt9v022_s_stream(), I think. As mentioned above, currently the snapshot mode is used by the driver to stop continuous data read-out by the sensor, so, unless we begin supporting capture in the snapshot mode, setting any further configuration parameters seems pretty useless to me. We need the snapshot mode, our camera doesn't work in normal mode, only external triggering is supported on it. I'll add required configuration by a separate patch. For setting bit 2 we could add V4L2_CID_WIDE_DYNAMIC_RANGE control which primarily configures the HiDy mode in register 0x0f and additionally sets/unsets bit 2 in register 0x20. But setting this bit 2 seems to be needed also in linear mode when manual exposure control is used. With the recommended register value 0x03D1 in linear mode the image quality is really bad when manual exposure mode is used, independent of the configured exposure time. Using 0x03D5 in linear mode however gives good image quality here. Doesn't this switch on the HiDy mode? What happens if you also set 0x0f:6 to 1? No, it doesn't. It is supposed to lower pixel-wise FPN. If I configure HiDy mode by setting 0x0f:6 to 1, I get better image quality, the loss of detail in very bright or dark areas of a picture is reduced, as expected. So setting bit 2 should be independent of HiDy control. The errata states the register setting recommendations are based on the characterization of the image sensor only and that camera module makers should test these recommendations on their module and evaluate the overall performance. These settings should be configurable independently of each other, I think. Maybe we need some noise (PFN) related control? Maybe. Thanks, Anatolij -- 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 1/3] mt9v022: add v4l2 controls for blanking
Add controls for horizontal and vertical blanking. Also add an error
message for case that the control handler init failed. Since setting
the blanking registers is done by controls now, we shouldn't change
these registers outside of the control function. Use v4l2_ctrl_s_ctrl()
to set them.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Changes since first version:
- drop analog and reg32 setting controls
- use more descriptive error message for handler init error
- revise commit log
- rebase on staging/for_v3.7 branch
drivers/media/i2c/soc_camera/mt9v022.c | 49 +--
1 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/mt9v022.c
b/drivers/media/i2c/soc_camera/mt9v022.c
index 350d0d8..3cb23c6 100644
--- a/drivers/media/i2c/soc_camera/mt9v022.c
+++ b/drivers/media/i2c/soc_camera/mt9v022.c
@@ -71,6 +71,13 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_COLUMN_SKIP1
#define MT9V022_ROW_SKIP 4
+#define MT9V022_HORIZONTAL_BLANKING_MIN43
+#define MT9V022_HORIZONTAL_BLANKING_MAX1023
+#define MT9V022_HORIZONTAL_BLANKING_DEF94
+#define MT9V022_VERTICAL_BLANKING_MIN 2
+#define MT9V022_VERTICAL_BLANKING_MAX 3000
+#define MT9V022_VERTICAL_BLANKING_DEF 45
+
#define is_mt9v024(id) (id == 0x1324)
/* MT9V022 has only one fixed colorspace per pixelcode */
@@ -136,6 +143,8 @@ struct mt9v022 {
struct v4l2_ctrl *autogain;
struct v4l2_ctrl *gain;
};
+ struct v4l2_ctrl *hblank;
+ struct v4l2_ctrl *vblank;
struct v4l2_rect rect; /* Sensor window */
const struct mt9v022_datafmt *fmt;
const struct mt9v022_datafmt *fmts;
@@ -277,11 +286,10 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
* Default 94, Phytec driver says:
* width + horizontal blank = 660
*/
- ret = reg_write(client, MT9V022_HORIZONTAL_BLANKING,
- rect.width 660 - 43 ? 43 :
- 660 - rect.width);
+ ret = v4l2_ctrl_s_ctrl(mt9v022-hblank,
+ rect.width 660 - 43 ? 43 : 660 - rect.width);
if (!ret)
- ret = reg_write(client, MT9V022_VERTICAL_BLANKING, 45);
+ ret = v4l2_ctrl_s_ctrl(mt9v022-vblank, 45);
if (!ret)
ret = reg_write(client, MT9V022_WINDOW_WIDTH, rect.width);
if (!ret)
@@ -504,6 +512,18 @@ static int mt9v022_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
range = exp-maximum - exp-minimum;
exp-val = ((data - 1) * range + 239) / 479 + exp-minimum;
return 0;
+ case V4L2_CID_HBLANK:
+ data = reg_read(client, MT9V022_HORIZONTAL_BLANKING);
+ if (data 0)
+ return -EIO;
+ ctrl-val = data;
+ return 0;
+ case V4L2_CID_VBLANK:
+ data = reg_read(client, MT9V022_VERTICAL_BLANKING);
+ if (data 0)
+ return -EIO;
+ ctrl-val = data;
+ return 0;
}
return -EINVAL;
}
@@ -585,6 +605,16 @@ static int mt9v022_s_ctrl(struct v4l2_ctrl *ctrl)
return -EIO;
}
return 0;
+ case V4L2_CID_HBLANK:
+ if (reg_write(client, MT9V022_HORIZONTAL_BLANKING,
+ ctrl-val) 0)
+ return -EIO;
+ return 0;
+ case V4L2_CID_VBLANK:
+ if (reg_write(client, MT9V022_VERTICAL_BLANKING,
+ ctrl-val) 0)
+ return -EIO;
+ return 0;
}
return -EINVAL;
}
@@ -852,10 +882,21 @@ static int mt9v022_probe(struct i2c_client *client,
mt9v022-exposure = v4l2_ctrl_new_std(mt9v022-hdl, mt9v022_ctrl_ops,
V4L2_CID_EXPOSURE, 1, 255, 1, 255);
+ mt9v022-hblank = v4l2_ctrl_new_std(mt9v022-hdl, mt9v022_ctrl_ops,
+ V4L2_CID_HBLANK, MT9V022_HORIZONTAL_BLANKING_MIN,
+ MT9V022_HORIZONTAL_BLANKING_MAX, 1,
+ MT9V022_HORIZONTAL_BLANKING_DEF);
+
+ mt9v022-vblank = v4l2_ctrl_new_std(mt9v022-hdl, mt9v022_ctrl_ops,
+ V4L2_CID_VBLANK, MT9V022_VERTICAL_BLANKING_MIN,
+ MT9V022_VERTICAL_BLANKING_MAX, 1,
+ MT9V022_VERTICAL_BLANKING_DEF);
+
mt9v022-subdev.ctrl_handler = mt9v022-hdl;
if (mt9v022-hdl.error) {
int err = mt9v022-hdl.error;
+ dev_err(client-dev, control initialisation err %d\n, err);
kfree(mt9v022);
return err;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media
[PATCH v2 2/3] mt9v022: fix the V4L2_CID_EXPOSURE control
Since the MT9V022_TOTAL_SHUTTER_WIDTH register is controlled in manual mode by V4L2_CID_EXPOSURE control, it shouldn't be written directly in mt9v022_s_crop(). In manual mode this register should be set to the V4L2_CID_EXPOSURE control value. Changing this register directly and outside of the actual control function means that the register value is not in sync with the corresponding control value. Thus, the following problem is observed: - setting this control initially succeeds - VIDIOC_S_CROP ioctl() overwrites the MT9V022_TOTAL_SHUTTER_WIDTH register - setting this control to the same value again doesn't result in setting the register since the control value was previously cached and doesn't differ Remove MT9V022_TOTAL_SHUTTER_WIDTH register setting in mt9v022_s_crop() and add a comment explaining why it is not needed in manual mode. Signed-off-by: Anatolij Gustschin ag...@denx.de --- Changes since first version: - remove setting total shutter width register in mt9v022_s_crop() if in manual exposure mode and add a comment explaining why it is not needed - revise commit log - rebase on staging/for_v3.7 branch drivers/media/i2c/soc_camera/mt9v022.c | 11 --- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/media/i2c/soc_camera/mt9v022.c b/drivers/media/i2c/soc_camera/mt9v022.c index 3cb23c6..e0f4cb4 100644 --- a/drivers/media/i2c/soc_camera/mt9v022.c +++ b/drivers/media/i2c/soc_camera/mt9v022.c @@ -272,9 +272,14 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a) if (ret 1) /* Autoexposure */ ret = reg_write(client, mt9v022-reg-max_total_shutter_width, rect.height + mt9v022-y_skip_top + 43); - else - ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, - rect.height + mt9v022-y_skip_top + 43); + /* +* If autoexposure is off, there is no need to set +* MT9V022_TOTAL_SHUTTER_WIDTH here. Autoexposure can be off +* only if the user has set exposure manually, using the +* V4L2_CID_EXPOSURE_AUTO with the value V4L2_EXPOSURE_MANUAL. +* In this case the register MT9V022_TOTAL_SHUTTER_WIDTH +* already contains the correct value. +*/ } /* Setup frame format: defaults apart from width and height */ if (!ret) -- 1.7.1 -- 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 3/3] mt9v022: set y_skip_top field to zero as default
Set y_skip_top to zero and revise comment as I do not see this line
corruption on two different mt9v022 setups. The first read-out line
is perfectly fine. Add mt9v022 platform data configuring y_skip_top
for platforms that have issues with the first read-out line. Set
y_skip_top to 1 for pcm990 board.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Changes since first version:
- add platform data to mt9v022 with only one parameter to initialise
y_skip_top, use 0 as default and set it to 1 on pcm990-baseboard.c
- revise commit log
- rebase on staging/for_v3.7 branch
arch/arm/mach-pxa/pcm990-baseboard.c |6 ++
drivers/media/i2c/soc_camera/mt9v022.c |8 +---
include/media/mt9v022.h| 16
3 files changed, 27 insertions(+), 3 deletions(-)
create mode 100644 include/media/mt9v022.h
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index cb723e8..e2973f2 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -26,6 +26,7 @@
#include linux/i2c/pxa-i2c.h
#include linux/pwm_backlight.h
+#include media/mt9v022.h
#include media/soc_camera.h
#include mach/camera.h
@@ -468,6 +469,10 @@ static struct i2c_board_info __initdata
pcm990_i2c_devices[] = {
},
};
+static struct mt9v022_platform_data mt9v022_pdata = {
+ .y_skip_top = 1,
+};
+
static struct i2c_board_info pcm990_camera_i2c[] = {
{
I2C_BOARD_INFO(mt9v022, 0x48),
@@ -480,6 +485,7 @@ static struct soc_camera_link iclink[] = {
{
.bus_id = 0, /* Must match with the camera ID */
.board_info = pcm990_camera_i2c[0],
+ .priv = mt9v022_pdata,
.i2c_adapter_id = 0,
.query_bus_param= pcm990_camera_query_bus_param,
.set_bus_param = pcm990_camera_set_bus_param,
diff --git a/drivers/media/i2c/soc_camera/mt9v022.c
b/drivers/media/i2c/soc_camera/mt9v022.c
index e0f4cb4..8feaddc 100644
--- a/drivers/media/i2c/soc_camera/mt9v022.c
+++ b/drivers/media/i2c/soc_camera/mt9v022.c
@@ -15,6 +15,7 @@
#include linux/log2.h
#include linux/module.h
+#include media/mt9v022.h
#include media/soc_camera.h
#include media/soc_mediabus.h
#include media/v4l2-subdev.h
@@ -849,6 +850,7 @@ static int mt9v022_probe(struct i2c_client *client,
struct mt9v022 *mt9v022;
struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
+ struct mt9v022_platform_data *pdata = icl-priv;
int ret;
if (!icl) {
@@ -912,10 +914,10 @@ static int mt9v022_probe(struct i2c_client *client,
mt9v022-chip_control = MT9V022_CHIP_CONTROL_DEFAULT;
/*
-* MT9V022 _really_ corrupts the first read out line.
-* TODO: verify on i.MX31
+* On some platforms the first read out line is corrupted.
+* Workaround it by skipping if indicated by platform data.
*/
- mt9v022-y_skip_top = 1;
+ mt9v022-y_skip_top = pdata ? pdata-y_skip_top : 0;
mt9v022-rect.left = MT9V022_COLUMN_SKIP;
mt9v022-rect.top = MT9V022_ROW_SKIP;
mt9v022-rect.width = MT9V022_MAX_WIDTH;
diff --git a/include/media/mt9v022.h b/include/media/mt9v022.h
new file mode 100644
index 000..4056180
--- /dev/null
+++ b/include/media/mt9v022.h
@@ -0,0 +1,16 @@
+/*
+ * mt9v022 sensor
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __MT9V022_H__
+#define __MT9V022_H__
+
+struct mt9v022_platform_data {
+ unsigned short y_skip_top; /* Lines to skip at the top */
+};
+
+#endif
--
1.7.1
--
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] mt9v022: support required register settings in snapshot mode
Some camera systems cannot operate mt9v022 in normal mode and use
only the snapshot mode. The TechNote for mt9v022 (TN0960) and mt9v024
(TN-09-225) describes required register settings when configuring the
snapshot operation. The snapshot mode requires that certain automatic
functions of the image sensor should be disabled or set to fixed values.
According to the TechNote bit 2 and bit 9 in the register 0x20 must be
set in snapshot mode and unset for normal operation. This applies for
mt9v022 Rev.3 and mt9v024. Add required reg. 0x20 settings dependent on
sensor chip version.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/i2c/soc_camera/mt9v022.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/mt9v022.c
b/drivers/media/i2c/soc_camera/mt9v022.c
index 8feaddc..2abe999 100644
--- a/drivers/media/i2c/soc_camera/mt9v022.c
+++ b/drivers/media/i2c/soc_camera/mt9v022.c
@@ -51,6 +51,7 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_PIXEL_OPERATION_MODE 0x0f
#define MT9V022_LED_OUT_CONTROL0x1b
#define MT9V022_ADC_MODE_CONTROL 0x1c
+#define MT9V022_REG32 0x20
#define MT9V022_ANALOG_GAIN0x35
#define MT9V022_BLACK_LEVEL_CALIB_CTRL 0x47
#define MT9V022_PIXCLK_FV_LV 0x74
@@ -79,7 +80,8 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_VERTICAL_BLANKING_MAX 3000
#define MT9V022_VERTICAL_BLANKING_DEF 45
-#define is_mt9v024(id) (id == 0x1324)
+#define is_mt9v022_rev3(id)(id == 0x1313)
+#define is_mt9v024(id) (id == 0x1324)
/* MT9V022 has only one fixed colorspace per pixelcode */
struct mt9v022_datafmt {
@@ -153,6 +155,7 @@ struct mt9v022 {
int num_fmts;
int model; /* V4L2_IDENT_MT9V022* codes from v4l2-chip-ident.h */
u16 chip_control;
+ u16 chip_version;
unsigned short y_skip_top; /* Lines to skip at the top */
};
@@ -235,12 +238,32 @@ static int mt9v022_s_stream(struct v4l2_subdev *sd, int
enable)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct mt9v022 *mt9v022 = to_mt9v022(client);
- if (enable)
+ if (enable) {
/* Switch to master normal mode */
mt9v022-chip_control = ~0x10;
- else
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+* Unset snapshot mode specific settings: clear bit 9
+* and bit 2 in reg. 0x20 when in normal mode.
+*/
+ if (reg_clear(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ } else {
/* Switch to snapshot mode */
mt9v022-chip_control |= 0x10;
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+* Required settings for snapshot mode: set bit 9
+* (RST enable) and bit 2 (CR enable) in reg. 0x20
+* See TechNote TN0960 or TN-09-225.
+*/
+ if (reg_set(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ }
if (reg_write(client, MT9V022_CHIP_CONTROL, mt9v022-chip_control) 0)
return -EIO;
@@ -652,6 +675,8 @@ static int mt9v022_video_probe(struct i2c_client *client)
goto ei2c;
}
+ mt9v022-chip_version = data;
+
mt9v022-reg = is_mt9v024(data) ? mt9v024_register :
mt9v022_register;
--
1.7.1
--
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 3/3] mt9v022: set y_skip_top field to zero
Hi Guennadi, On Tue, 11 Sep 2012 10:55:31 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... On what systems have you checked this? On camera systems from ifm, both using mt9v022. Ok, I agree, this was a hack in the beginning, and, probably, there was a reason for the problem, that we've seen, that we didn't find a proper solution to, but I wouldn't like to punish those systems now. The y_skip_top field is only taken into account by the pxa driver, and there is only one pxa270 system, using mt9v022: pcm990-baseboard.c. Could you, please, add platform data to mt9v022 with only one parameter to initialise y_skip_top, use 0 as default and set it to 1 on pcm990-baseboard.c? Yes, I've reworked this patch as suggested and will resubmit. Thanks, Anatolij -- 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 2/3] mt9v022: fix the V4L2_CID_EXPOSURE control
On Fri, 24 Aug 2012 16:32:57 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... But why do we have to write it here at all then? Autoexposure can be off only if the user has set exposure manually, using V4L2_CID_EXPOSURE_AUTO. In this case MT9V022_TOTAL_SHUTTER_WIDTH already contains the correct value. Why do we have to set it again? Maybe just adding a comment, explaining the above, would suffice? Actually we do not have to write it here, yes. Should I remove the shutter register setting here entirely? And add a comment explaining, why? Remove it from the else clause, yes, please. And a comment would be good! Ok, I'll resubmit a reworked patch. Thanks, Anatolij -- 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 1/3] mt9v022: add v4l2 controls for blanking and other register settings
Hi Guennadi, On Fri, 24 Aug 2012 23:23:37 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... Every time the sensor is reset, it resets this register. Without setting the register after sensor reset to the needed value I only get garbage data from the sensor. Since the possibility to reset the sensor is provided on the hardware and also used, the register has to be set after each sensor reset. Only the instance controlling the reset gpio pin knows the time, when the register should be initialized again, so it is asynchronously and not related to the standard camera activities. But since the stuff is _not_ documented, I can only speculate. Maybe it can be set to different values to achieve different things, currently I do not know. How about adding that register write (if required by platform data) to mt9v022_s_power() in the on case? This is called (on soc-camera hosts at least) on each first open(), would this suffice? This would suffice. But now I found some more info for this register. Rev3. errata mentions that the bit 9 of the register should be set when in snapshot mode (in my case this is the only mode that we can use). Additionally the errata recommends to set bit 2 when the high dynamic range mode is used. Now I'm not sure how to realise these settings. The bit 9 should be set/unset when configuring the master/snapshot mode in mt9v022_s_stream(), I think. For setting bit 2 we could add V4L2_CID_WIDE_DYNAMIC_RANGE control which primarily configures the HiDy mode in register 0x0f and additionally sets/unsets bit 2 in register 0x20. But setting this bit 2 seems to be needed also in linear mode when manual exposure control is used. With the recommended register value 0x03D1 in linear mode the image quality is really bad when manual exposure mode is used, independent of the configured exposure time. Using 0x03D5 in linear mode however gives good image quality here. So setting bit 2 should be independent of HiDy control. The errata states the register setting recommendations are based on the characterization of the image sensor only and that camera module makers should test these recommendations on their module and evaluate the overall performance. These settings should be configurable independently of each other, I think. Thanks, Anatolij -- 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 1/3] mt9v022: add v4l2 controls for blanking and other register settings
Add controls for horizontal and vertical blanking, analog control
and control for undocumented register 32. Also add an error message
for case that the control handler init failed. Since setting the
blanking registers is done by controls now, we should't change these
registers outside of the control function. Use v4l2_ctrl_s_ctrl()
to set them.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/i2c/soc_camera/mt9v022.c | 105 ++--
1 files changed, 100 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/mt9v022.c
b/drivers/media/i2c/soc_camera/mt9v022.c
index 350d0d8..d13c8c4 100644
--- a/drivers/media/i2c/soc_camera/mt9v022.c
+++ b/drivers/media/i2c/soc_camera/mt9v022.c
@@ -50,12 +50,14 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_PIXEL_OPERATION_MODE 0x0f
#define MT9V022_LED_OUT_CONTROL0x1b
#define MT9V022_ADC_MODE_CONTROL 0x1c
+#define MT9V022_REG32 0x20
#define MT9V022_ANALOG_GAIN0x35
#define MT9V022_BLACK_LEVEL_CALIB_CTRL 0x47
#define MT9V022_PIXCLK_FV_LV 0x74
#define MT9V022_DIGITAL_TEST_PATTERN 0x7f
#define MT9V022_AEC_AGC_ENABLE 0xAF
#define MT9V022_MAX_TOTAL_SHUTTER_WIDTH0xBD
+#define MT9V022_ANALOG_CONTROL 0xC2
/* mt9v024 partial list register addresses changes with respect to mt9v022 */
#define MT9V024_PIXCLK_FV_LV 0x72
@@ -71,6 +73,13 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_COLUMN_SKIP1
#define MT9V022_ROW_SKIP 4
+#define MT9V022_HORIZONTAL_BLANKING_MIN43
+#define MT9V022_HORIZONTAL_BLANKING_MAX1023
+#define MT9V022_HORIZONTAL_BLANKING_DEF94
+#define MT9V022_VERTICAL_BLANKING_MIN 2
+#define MT9V022_VERTICAL_BLANKING_MAX 3000
+#define MT9V022_VERTICAL_BLANKING_DEF 45
+
#define is_mt9v024(id) (id == 0x1324)
/* MT9V022 has only one fixed colorspace per pixelcode */
@@ -136,6 +145,8 @@ struct mt9v022 {
struct v4l2_ctrl *autogain;
struct v4l2_ctrl *gain;
};
+ struct v4l2_ctrl *hblank;
+ struct v4l2_ctrl *vblank;
struct v4l2_rect rect; /* Sensor window */
const struct mt9v022_datafmt *fmt;
const struct mt9v022_datafmt *fmts;
@@ -277,11 +288,10 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
* Default 94, Phytec driver says:
* width + horizontal blank = 660
*/
- ret = reg_write(client, MT9V022_HORIZONTAL_BLANKING,
- rect.width 660 - 43 ? 43 :
- 660 - rect.width);
+ ret = v4l2_ctrl_s_ctrl(mt9v022-hblank,
+ rect.width 660 - 43 ? 43 : 660 - rect.width);
if (!ret)
- ret = reg_write(client, MT9V022_VERTICAL_BLANKING, 45);
+ ret = v4l2_ctrl_s_ctrl(mt9v022-vblank, 45);
if (!ret)
ret = reg_write(client, MT9V022_WINDOW_WIDTH, rect.width);
if (!ret)
@@ -476,6 +486,9 @@ static int mt9v022_s_power(struct v4l2_subdev *sd, int on)
return soc_camera_set_power(client-dev, icl, on);
}
+#define V4L2_CID_REG32 (V4L2_CTRL_CLASS_CAMERA | 0x1001)
+#define V4L2_CID_ANALOG_CONTROLS (V4L2_CTRL_CLASS_CAMERA | 0x1002)
+
static int mt9v022_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
{
struct mt9v022 *mt9v022 = container_of(ctrl-handler,
@@ -504,6 +517,30 @@ static int mt9v022_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
range = exp-maximum - exp-minimum;
exp-val = ((data - 1) * range + 239) / 479 + exp-minimum;
return 0;
+ case V4L2_CID_HBLANK:
+ data = reg_read(client, MT9V022_HORIZONTAL_BLANKING);
+ if (data 0)
+ return -EIO;
+ ctrl-val = data;
+ return 0;
+ case V4L2_CID_VBLANK:
+ data = reg_read(client, MT9V022_VERTICAL_BLANKING);
+ if (data 0)
+ return -EIO;
+ ctrl-val = data;
+ return 0;
+ case V4L2_CID_REG32:
+ data = reg_read(client, MT9V022_REG32);
+ if (data 0)
+ return -EIO;
+ ctrl-val = data;
+ return 0;
+ case V4L2_CID_ANALOG_CONTROLS:
+ data = reg_read(client, MT9V022_ANALOG_CONTROL);
+ if (data 0)
+ return -EIO;
+ ctrl-val = data;
+ return 0;
}
return -EINVAL;
}
@@ -585,6 +622,26 @@ static int mt9v022_s_ctrl(struct v4l2_ctrl *ctrl)
return -EIO;
}
return 0;
+ case V4L2_CID_HBLANK:
+ if (reg_write(client, MT9V022_HORIZONTAL_BLANKING
[PATCH 0/3] various updates for mt9v022 driver
Anatolij Gustschin (3): mt9v022: add v4l2 controls for blanking and other register settings mt9v022: fix the V4L2_CID_EXPOSURE control mt9v022: set y_skip_top field to zero drivers/media/i2c/soc_camera/mt9v022.c | 117 1 files changed, 104 insertions(+), 13 deletions(-) -- 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 3/3] mt9v022: set y_skip_top field to zero
Set y_skip_top to zero and remove comment as I do not see this line corruption on two different mt9v022 setups. The first read-out line is perfectly fine. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/media/i2c/soc_camera/mt9v022.c |6 +- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/drivers/media/i2c/soc_camera/mt9v022.c b/drivers/media/i2c/soc_camera/mt9v022.c index d26c071..e41d738 100644 --- a/drivers/media/i2c/soc_camera/mt9v022.c +++ b/drivers/media/i2c/soc_camera/mt9v022.c @@ -960,11 +960,7 @@ static int mt9v022_probe(struct i2c_client *client, mt9v022-chip_control = MT9V022_CHIP_CONTROL_DEFAULT; - /* -* MT9V022 _really_ corrupts the first read out line. -* TODO: verify on i.MX31 -*/ - mt9v022-y_skip_top = 1; + mt9v022-y_skip_top = 0; mt9v022-rect.left = MT9V022_COLUMN_SKIP; mt9v022-rect.top = MT9V022_ROW_SKIP; mt9v022-rect.width = MT9V022_MAX_WIDTH; -- 1.7.1 -- 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 2/3] mt9v022: fix the V4L2_CID_EXPOSURE control
Since the MT9V022_TOTAL_SHUTTER_WIDTH register is controlled in manual mode by V4L2_CID_EXPOSURE control, it shouldn't be written directly in mt9v022_s_crop(). In manual mode this register should be set to the V4L2_CID_EXPOSURE control value. Changing this register directly and outside of the actual control function means that the register value is not in sync with the corresponding control value. Thus, the following problem is observed: - setting this control initially succeeds - VIDIOC_S_CROP ioctl() overwrites the MT9V022_TOTAL_SHUTTER_WIDTH register - setting this control to the same value again doesn't result in setting the register since the control value was previously cached and doesn't differ Fix it by always setting the register to the controlled value, when in manual mode. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/media/i2c/soc_camera/mt9v022.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/i2c/soc_camera/mt9v022.c b/drivers/media/i2c/soc_camera/mt9v022.c index d13c8c4..d26c071 100644 --- a/drivers/media/i2c/soc_camera/mt9v022.c +++ b/drivers/media/i2c/soc_camera/mt9v022.c @@ -274,9 +274,9 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a) if (ret 1) /* Autoexposure */ ret = reg_write(client, mt9v022-reg-max_total_shutter_width, rect.height + mt9v022-y_skip_top + 43); - else - ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, - rect.height + mt9v022-y_skip_top + 43); + else /* Set to the manually controlled value */ + ret = v4l2_ctrl_s_ctrl(mt9v022-exposure, + mt9v022-exposure-val); } /* Setup frame format: defaults apart from width and height */ if (!ret) -- 1.7.1 -- 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] V4L: soc_camera: allow reading from video device if supported
Try reading on video device. If the camera bus driver supports reading
we can try it and return the result. Also add a debug line.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
v2: - rebased on current staging/for_v3.7 branch
drivers/media/platform/soc_camera/soc_camera.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index 10b57f8..d591a42 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -645,9 +645,16 @@ static ssize_t soc_camera_read(struct file *file, char
__user *buf,
size_t count, loff_t *ppos)
{
struct soc_camera_device *icd = file-private_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
int err = -EINVAL;
- dev_err(icd-pdev, camera device read not implemented\n);
+ dev_dbg(icd-pdev, read called, buf %p\n, buf);
+
+ if (ici-ops-init_videobuf2 icd-vb2_vidq.io_modes VB2_READ)
+ err = vb2_read(icd-vb2_vidq, buf, count, ppos,
+ file-f_flags O_NONBLOCK);
+ else
+ dev_err(icd-pdev, camera device read not implemented\n);
return err;
}
--
1.7.1
--
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 1/3] mt9v022: add v4l2 controls for blanking and other register settings
Hi Guennadi,
On Fri, 24 Aug 2012 13:08:52 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
...
+#define MT9V022_HORIZONTAL_BLANKING_MIN43
+#define MT9V022_HORIZONTAL_BLANKING_MAX1023
+#define MT9V022_HORIZONTAL_BLANKING_DEF94
+#define MT9V022_VERTICAL_BLANKING_MIN 2
Interesting, in my datasheet min is 4. Maybe 4 would be a safer bet then.
The legal range in the datasheet here is 2-3000. The datasheet
states that the minimal value must be 4 only if show dark rows
control bit is set (it is unset by default).
...
+#define V4L2_CID_REG32 (V4L2_CTRL_CLASS_CAMERA |
0x1001)
+#define V4L2_CID_ANALOG_CONTROLS (V4L2_CTRL_CLASS_CAMERA | 0x1002)
Sorry, no again. The MT9V022_ANALOG_CONTROL register contains two fields:
anti-eclipse and anti-eclipse reference voltage control, don't think
they should be set as a single control value. IIUC, controls are supposed
to control logical parameters of the system. In this case you could
introduce an anti-eclipse reference voltage control with values in the
range between 0 and 2250mV, setting it to anything below 1900mV would turn
the enable bit off. Would such a control make sense? Then you might want
to ask on the ML, whether this control would make sense as a generic one,
not mt9v022 specific.
It probably makes sense since other sensors also have anti-eclipse control
registers.
...
if (mt9v022-hdl.error) {
int err = mt9v022-hdl.error;
+ dev_err(client-dev, hdl init err %d\n, err);
That's not very clear IMHO. hdl isn't too specific, just control
initialisation?
Ok, I'll fix it.
Thanks,
Anatolij
--
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 3/3] mt9v022: set y_skip_top field to zero
On Fri, 24 Aug 2012 13:23:22 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Fri, 24 Aug 2012, Anatolij Gustschin wrote: Set y_skip_top to zero and remove comment as I do not see this line corruption on two different mt9v022 setups. The first read-out line is perfectly fine. On what systems have you checked this? On camera systems from ifm, both using mt9v022. Anatolij -- 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 2/3] mt9v022: fix the V4L2_CID_EXPOSURE control
Hi Guennadi, On Fri, 24 Aug 2012 13:22:18 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... --- a/drivers/media/i2c/soc_camera/mt9v022.c +++ b/drivers/media/i2c/soc_camera/mt9v022.c @@ -274,9 +274,9 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a) if (ret 1) /* Autoexposure */ ret = reg_write(client, mt9v022-reg-max_total_shutter_width, rect.height + mt9v022-y_skip_top + 43); - else - ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, - rect.height + mt9v022-y_skip_top + 43); + else /* Set to the manually controlled value */ + ret = v4l2_ctrl_s_ctrl(mt9v022-exposure, + mt9v022-exposure-val); But why do we have to write it here at all then? Autoexposure can be off only if the user has set exposure manually, using V4L2_CID_EXPOSURE_AUTO. In this case MT9V022_TOTAL_SHUTTER_WIDTH already contains the correct value. Why do we have to set it again? Maybe just adding a comment, explaining the above, would suffice? Actually we do not have to write it here, yes. Should I remove the shutter register setting here entirely? And add a comment explaining, why? Thanks, Anatolij -- 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 v3] V4L: soc_camera: allow reading from video device if supported
Try reading on video device. If the camera bus driver supports reading
we can try it and return the result. Also add a debug line.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
v3: - simplified as suggested by Guennadi
v2: - rebased on current staging/for_v3.7 branch
drivers/media/platform/soc_camera/soc_camera.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index 10b57f8..1dd3997 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -645,11 +645,17 @@ static ssize_t soc_camera_read(struct file *file, char
__user *buf,
size_t count, loff_t *ppos)
{
struct soc_camera_device *icd = file-private_data;
- int err = -EINVAL;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+
+ dev_dbg(icd-pdev, read called, buf %p\n, buf);
+
+ if (ici-ops-init_videobuf2 icd-vb2_vidq.io_modes VB2_READ)
+ return vb2_read(icd-vb2_vidq, buf, count, ppos,
+ file-f_flags O_NONBLOCK);
dev_err(icd-pdev, camera device read not implemented\n);
- return err;
+ return -EINVAL;
}
static int soc_camera_mmap(struct file *file, struct vm_area_struct *vma)
--
1.7.1
--
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 1/3] mt9v022: add v4l2 controls for blanking and other register settings
Hi Guennadi, On Fri, 24 Aug 2012 15:35:59 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... Below I asked to provide details about how you have to change this register value: toggle dynamically at run-time or just set once at initialisation? Even if toggle: are this certain moments, related to standard camera activities (e.g., starting and stopping streaming, changing geometry etc.) or you have to set this absolutely asynchronously at moments of time, that only your application knows about? Every time the sensor is reset, it resets this register. Without setting the register after sensor reset to the needed value I only get garbage data from the sensor. Since the possibility to reset the sensor is provided on the hardware and also used, the register has to be set after each sensor reset. Only the instance controlling the reset gpio pin knows the time, when the register should be initialized again, so it is asynchronously and not related to the standard camera activities. But since the stuff is _not_ documented, I can only speculate. Maybe it can be set to different values to achieve different things, currently I do not know. Thanks, Anatolij -- 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] V4L: soc_camera: allow reading from video device if supported
Try reading on video device. If the camera bus driver supports reading
we can try it and return the result. Also add a debug line.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/platform/soc_camera.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/soc_camera.c
b/drivers/media/platform/soc_camera.c
index 10b57f8..d591a42 100644
--- a/drivers/media/platform/soc_camera.c
+++ b/drivers/media/platform/soc_camera.c
@@ -645,9 +645,16 @@ static ssize_t soc_camera_read(struct file *file, char
__user *buf,
size_t count, loff_t *ppos)
{
struct soc_camera_device *icd = file-private_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
int err = -EINVAL;
- dev_err(icd-pdev, camera device read not implemented\n);
+ dev_dbg(icd-pdev, read called, buf %p\n, buf);
+
+ if (ici-ops-init_videobuf2 icd-vb2_vidq.io_modes VB2_READ)
+ err = vb2_read(icd-vb2_vidq, buf, count, ppos,
+ file-f_flags O_NONBLOCK);
+ else
+ dev_err(icd-pdev, camera device read not implemented\n);
return err;
}
--
1.7.1
--
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] media: fsl_viu: fix bug in streamon routine
Currently video capturing using streaming I/O method
doesn't work if capturing to overlay buffer took place
before.
When enabling the stream we have to check the overlay
enable driver flag and reset it so that the interrupt
handler won't execute the overlay interrupt path after
enabling DMA in streamon routine. Otherwise the capture
interrupt won't be handled correctly causing non working
VIDIOC_DQBUF ioctl.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/video/fsl-viu.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/fsl-viu.c b/drivers/media/video/fsl-viu.c
index 031af16..4b2bba8 100644
--- a/drivers/media/video/fsl-viu.c
+++ b/drivers/media/video/fsl-viu.c
@@ -911,12 +911,16 @@ static int vidioc_dqbuf(struct file *file, void *priv,
struct v4l2_buffer *p)
static int vidioc_streamon(struct file *file, void *priv, enum v4l2_buf_type i)
{
struct viu_fh *fh = priv;
+ struct viu_dev *dev = fh-dev;
if (fh-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
if (fh-type != i)
return -EINVAL;
+ if (dev-ovenable)
+ dev-ovenable = 0;
+
viu_start_dma(fh-dev);
return videobuf_streamon(fh-vb_vidq);
--
1.7.1
--
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] fsl-viu: replace .ioctl by .unlocked_ioctl
Use the core-assisted locking in fsl-viu driver and switch
to .unlocked_ioctl.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/video/fsl-viu.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/fsl-viu.c b/drivers/media/video/fsl-viu.c
index e4bba88..a20b166 100644
--- a/drivers/media/video/fsl-viu.c
+++ b/drivers/media/video/fsl-viu.c
@@ -825,13 +825,11 @@ static int vidioc_s_fmt_overlay(struct file *file, void
*priv,
if (err)
return err;
- mutex_lock(dev-lock);
fh-win = f-fmt.win;
spin_lock_irqsave(dev-slock, flags);
viu_start_preview(dev, fh);
spin_unlock_irqrestore(dev-slock, flags);
- mutex_unlock(dev-lock);
return 0;
}
@@ -1311,7 +1309,8 @@ static int viu_open(struct file *file)
videobuf_queue_dma_contig_init(fh-vb_vidq, viu_video_qops,
dev-dev, fh-vbq_lock,
fh-type, V4L2_FIELD_INTERLACED,
- sizeof(struct viu_buf), fh, NULL);
+ sizeof(struct viu_buf), fh,
+ fh-dev-lock);
return 0;
}
@@ -1401,7 +1400,7 @@ static struct v4l2_file_operations viu_fops = {
.release= viu_release,
.read = viu_read,
.poll = viu_poll,
- .ioctl = video_ioctl2, /* V4L2 ioctl handler */
+ .unlocked_ioctl = video_ioctl2, /* V4L2 ioctl handler */
.mmap = viu_mmap,
};
@@ -1499,9 +1498,6 @@ static int __devinit viu_of_probe(struct platform_device
*op,
INIT_LIST_HEAD(viu_dev-vidq.active);
INIT_LIST_HEAD(viu_dev-vidq.queued);
- /* initialize locks */
- mutex_init(viu_dev-lock);
-
snprintf(viu_dev-v4l2_dev.name,
sizeof(viu_dev-v4l2_dev.name), %s, VIU);
ret = v4l2_device_register(viu_dev-dev, viu_dev-v4l2_dev);
@@ -1532,8 +1528,15 @@ static int __devinit viu_of_probe(struct platform_device
*op,
viu_dev-vdev = vdev;
+ /* initialize locks */
+ mutex_init(viu_dev-lock);
+ viu_dev-vdev-lock = viu_dev-lock;
+ spin_lock_init(viu_dev-slock);
+
video_set_drvdata(viu_dev-vdev, viu_dev);
+ mutex_lock(viu_dev-lock);
+
ret = video_register_device(viu_dev-vdev, VFL_TYPE_GRABBER, -1);
if (ret 0) {
video_device_release(viu_dev-vdev);
@@ -1560,6 +1563,8 @@ static int __devinit viu_of_probe(struct platform_device
*op,
goto err_irq;
}
+ mutex_unlock(viu_dev-lock);
+
dev_info(op-dev, Freescale VIU Video Capture Board\n);
return ret;
@@ -1569,6 +1574,7 @@ err_irq:
err_clk:
video_unregister_device(viu_dev-vdev);
err_vdev:
+ mutex_unlock(viu_dev-lock);
i2c_put_adapter(ad);
v4l2_device_unregister(viu_dev-v4l2_dev);
err:
--
1.7.1
--
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 2/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
On Mon, 7 Feb 2011 12:09:15 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... I can't try mplayer since I don't have mplayer setup for this. But looking at the mplayer source I don't see why it should behave differently. Depending on mode mplayer queues 2 or 6 buffers. Testing with my test app with 6 queued buffers shows no issues, here the buffer numbers toggle correctly, too. Ok, I've done a couple more tests. With larger frames, and, therefore lower fps - yes, with your patch buffers toggle correctly. Whereas in my tests with smaller frames and higher fps either only one buffer is used, or one is used much more often, than the other, e.g., 0 0 0 1 0 0 0 1 0... Could you try to verify? Without your patch with any fps buffers toggle consistently. How small are the frames in you test? What is the highest fps value in your test? Thanks, Anatolij -- 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 2/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
On Mon, 7 Feb 2011 12:35:44 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Mon, 7 Feb 2011, Anatolij Gustschin wrote: On Mon, 7 Feb 2011 12:09:15 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... I can't try mplayer since I don't have mplayer setup for this. But looking at the mplayer source I don't see why it should behave differently. Depending on mode mplayer queues 2 or 6 buffers. Testing with my test app with 6 queued buffers shows no issues, here the buffer numbers toggle correctly, too. Ok, I've done a couple more tests. With larger frames, and, therefore lower fps - yes, with your patch buffers toggle correctly. Whereas in my tests with smaller frames and higher fps either only one buffer is used, or one is used much more often, than the other, e.g., 0 0 0 1 0 0 0 1 0... Could you try to verify? Without your patch with any fps buffers toggle consistently. How small are the frames in you test? What is the highest fps value in your test? QVGA, don't know fps exactly, pretty high, between 20 and 60fps, I think. Just try different frams sizes, go down to 64x48 or something. Testing of 960x243 frames at 30 fps has been done during all my previous tests. I didn't see any issues at 30 fps. Anatolij -- 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 2/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
Hi Guennadi,
On Thu, 3 Feb 2011 11:09:54 +0100 (CET)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
Hi Anatolij
On Mon, 31 Jan 2011, Anatolij Gustschin wrote:
I'm afraid there seems to be a problem with your patch. I have no idea
what is causing it, but I'm just observing some wrong behaviour, that is
not there without it. Namely, I added a debug print to the IDMAC interrupt
handler
curbuf = idmac_read_ipureg(ipu_data, IPU_CHA_CUR_BUF);
err = idmac_read_ipureg(ipu_data, IPU_INT_STAT_4);
+ printk(KERN_DEBUG %s(): IDMAC irq %d, buf %d, current %d\n, __func__,
+irq, ichan-active_buffer, (curbuf chan_id) 1);
if (err (1 chan_id)) {
idmac_write_ipureg(ipu_data, 1 chan_id, IPU_INT_STAT_4);
and without your patch I see buffer numbers correctly toggling all the
time like
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 0, current 1
idmac_interrupt(): IDMAC irq 177, buf 1, current 0
idmac_interrupt(): IDMAC irq 177, buf 0, current 1
idmac_interrupt(): IDMAC irq 177, buf 1, current 0
idmac_interrupt(): IDMAC irq 177, buf 0, current 1
...
Yes, the first interrupt is different, that's where I'm dropping /
postponing it. With your patch only N (equal to the number of buffers
used, I think) first interrupts toggle, then always only one buffer is
used:
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
...
Verified with both capture.c and mplayer. Could you, please, verify
whether you get the same behaviour and what the problem could be?
Now I did some further testing with idmac patch applied and with
added debug print in the IDMAC interrupt handler. There is no problem.
Testing with capture.c (4 buffers used as default) shows that buffer
numbers toggle correctly for all 100 captured frames:
...
mx3-camera mx3-camera.0: MX3 Camera driver attached to camera 0
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
...
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
mx3-camera mx3-camera.0: MX3 Camera driver detached from camera 0
Also testing with my test application didn't show any problem.
When using more than 1 buffer (tested with 2, 3 and 4 queued
buffers) double buffering works as expected and frame numbers
toggle correctly. Capturing 30 frames produce:
mx3-camera mx3-camera.0: MX3 Camera driver attached to camera 0
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
idmac_interrupt(): IDMAC irq 177, buf 0, current 0
idmac_interrupt(): IDMAC irq 177, buf 1, current 1
mx3-camera mx3-camera.0: MX3 Camera driver detached from camera 0
Anatolij
--
To unsubscribe from this list: send the line
Re: [PATCH 2/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
On Sat, 5 Feb 2011 17:36:37 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... Verified with both capture.c and mplayer. Could you, please, verify whether you get the same behaviour and what the problem could be? Now I did some further testing with idmac patch applied and with added debug print in the IDMAC interrupt handler. There is no problem. Testing with capture.c (4 buffers used as default) shows that buffer numbers toggle correctly for all 100 captured frames: Hm, interesting, I'll have to look at my testing in more detail then (once back from FOSDEM). Could you maybe try mplayer too? I can't try mplayer since I don't have mplayer setup for this. But looking at the mplayer source I don't see why it should behave differently. Depending on mode mplayer queues 2 or 6 buffers. Testing with my test app with 6 queued buffers shows no issues, here the buffer numbers toggle correctly, too. Anatolij -- 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 2/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
Hi all, On Thu, 3 Feb 2011 11:09:54 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... Yes, the first interrupt is different, that's where I'm dropping / postponing it. With your patch only N (equal to the number of buffers used, I think) first interrupts toggle, then always only one buffer is used: idmac_interrupt(): IDMAC irq 177, buf 0, current 0 idmac_interrupt(): IDMAC irq 177, buf 1, current 1 idmac_interrupt(): IDMAC irq 177, buf 0, current 0 idmac_interrupt(): IDMAC irq 177, buf 1, current 1 idmac_interrupt(): IDMAC irq 177, buf 0, current 0 idmac_interrupt(): IDMAC irq 177, buf 1, current 1 idmac_interrupt(): IDMAC irq 177, buf 0, current 0 idmac_interrupt(): IDMAC irq 177, buf 0, current 0 idmac_interrupt(): IDMAC irq 177, buf 0, current 0 ... Verified with both capture.c and mplayer. Could you, please, verify whether you get the same behaviour and what the problem could be? Currently I'm quite busy, but I'll look at it this week end. Thanks, Anatolij -- 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 1/2 v2] v4l: soc-camera: start stream after queueing the buffers
Some camera systems have strong requirement for capturing an exact number of frames after starting the stream and do not tolerate losing captured frames. By starting the stream after the videobuf has queued the buffers, we ensure that no frame will be lost. Signed-off-by: Anatolij Gustschin ag...@denx.de --- v2: Check for return value of videobuf_streamon() before starting the stream, as suggested by Guennadi. drivers/media/video/soc_camera.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c index a66811b..e09bec0 100644 --- a/drivers/media/video/soc_camera.c +++ b/drivers/media/video/soc_camera.c @@ -646,11 +646,12 @@ static int soc_camera_streamon(struct file *file, void *priv, if (icd-streamer != file) return -EBUSY; - v4l2_subdev_call(sd, video, s_stream, 1); - /* This calls buf_queue from host driver's videobuf_queue_ops */ ret = videobuf_streamon(icd-vb_vidq); + if (!ret) + v4l2_subdev_call(sd, video, s_stream, 1); + return ret; } -- 1.7.1 -- 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 2/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
Currently when two or more buffers are queued by the camera driver
and so the double buffering is enabled in the idmac, we lose one
frame comming from CSI since the reporting of arrival of the first
frame is deferred by the DMAIC_7_EOF interrupt handler and reporting
of the arrival of the last frame is not done at all. So when requesting
N frames from the image sensor we actually receive N - 1 frames in
user space.
The reason for this behaviour is that the DMAIC_7_EOF interrupt
handler misleadingly assumes that the CUR_BUF flag is pointing to the
buffer used by the IDMAC. Actually it is not the case since the
CUR_BUF flag will be flipped by the FSU when the FSU is sending the
TASK_NEW_FRM_RDY signal when new frame data is delivered by the CSI.
When sending this singal, FSU updates the DMA_CUR_BUF and the
DMA_BUFx_RDY flags: the DMA_CUR_BUF is flipped, the DMA_BUFx_RDY
is cleared, indicating that the frame data is beeing written by
the IDMAC to the pointed buffer. DMA_BUFx_RDY is supposed to be
set to the ready state again by the MCU, when it has handled the
received data. DMAIC_7_CUR_BUF flag won't be flipped here by the
IPU, so waiting for this event in the EOF interrupt handler is wrong.
Actually there is no spurious interrupt as described in the comments,
this is the valid DMAIC_7_EOF interrupt indicating reception of the
frame from CSI.
The patch removes code that waits for flipping of the DMAIC_7_CUR_BUF
flag in the DMAIC_7_EOF interrupt handler. As the comment in the
current code denotes, this waiting doesn't help anyway. As a result
of this removal the reporting of the first arrived frame is not
deferred to the time of arrival of the next frame and the drivers
software flag 'ichan-active_buffer' is in sync with DMAIC_7_CUR_BUF
flag, so the reception of all requested frames works.
This has been verified on the hardware which is triggering the
image sensor by the programmable state machine, allowing to
obtain exact number of frames. On this hardware we do not tolerate
losing frames.
This patch also removes resetting the DMA_BUFx_RDY flags of
all channels in ipu_disable_channel() since transfers on other
DMA channels might be triggered by other running tasks and the
buffers should always be ready for data sending or reception.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
v2:
Revise the commit message to provide more and correct
information about the observed problem and proposed fix
drivers/dma/ipu/ipu_idmac.c | 50 ---
1 files changed, 0 insertions(+), 50 deletions(-)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index cb26ee9..c1a125e 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1145,29 +1145,6 @@ static int ipu_disable_channel(struct idmac *idmac,
struct idmac_channel *ichan,
reg = idmac_read_icreg(ipu, IDMAC_CHA_EN);
idmac_write_icreg(ipu, reg ~chan_mask, IDMAC_CHA_EN);
- /*
-* Problem (observed with channel DMAIC_7): after enabling the channel
-* and initialising buffers, there comes an interrupt with current still
-* pointing at buffer 0, whereas it should use buffer 0 first and only
-* generate an interrupt when it is done, then current should already
-* point to buffer 1. This spurious interrupt also comes on channel
-* DMASDC_0. With DMAIC_7 normally, is we just leave the ISR after the
-* first interrupt, there comes the second with current correctly
-* pointing to buffer 1 this time. But sometimes this second interrupt
-* doesn't come and the channel hangs. Clearing BUFx_RDY when disabling
-* the channel seems to prevent the channel from hanging, but it doesn't
-* prevent the spurious interrupt. This might also be unsafe. Think
-* about the IDMAC controller trying to switch to a buffer, when we
-* clear the ready bit, and re-enable it a moment later.
-*/
- reg = idmac_read_ipureg(ipu, IPU_CHA_BUF0_RDY);
- idmac_write_ipureg(ipu, 0, IPU_CHA_BUF0_RDY);
- idmac_write_ipureg(ipu, reg ~(1UL channel), IPU_CHA_BUF0_RDY);
-
- reg = idmac_read_ipureg(ipu, IPU_CHA_BUF1_RDY);
- idmac_write_ipureg(ipu, 0, IPU_CHA_BUF1_RDY);
- idmac_write_ipureg(ipu, reg ~(1UL channel), IPU_CHA_BUF1_RDY);
-
spin_unlock_irqrestore(ipu-lock, flags);
return 0;
@@ -1246,33 +1223,6 @@ static irqreturn_t idmac_interrupt(int irq, void *dev_id)
/* Other interrupts do not interfere with this channel */
spin_lock(ichan-lock);
- if (unlikely(chan_id != IDMAC_SDC_0 chan_id != IDMAC_SDC_1
-((curbuf chan_id) 1) == ichan-active_buffer
-!list_is_last(ichan-queue.next, ichan-queue))) {
- int i = 100;
-
- /* This doesn't help. See comment in ipu_disable_channel() */
- while (--i) {
- curbuf
[PATCH] v4l: mx3_camera: fix NULL pointer dereference if debug output enabled
Running with enabled debug output in the mx3_camera driver results
in a kernel crash:
...
mx3-camera mx3-camera.0: Providing format Bayer BGGR (sRGB) 8 bit using code 11
Unable to handle kernel NULL pointer dereference at virtual address 0004
...
Fix it by incrementing 'xlate' after usage.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/video/mx3_camera.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index b9cb4a4..7bcaaf7 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -734,9 +734,9 @@ static int mx3_camera_get_formats(struct soc_camera_device
*icd, unsigned int id
if (xlate) {
xlate-host_fmt = fmt;
xlate-code = code;
- xlate++;
dev_dbg(dev, Providing format %x in pass-through mode\n,
xlate-host_fmt-fourcc);
+ xlate++;
}
return formats;
--
1.7.1
--
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] v4l: mx3_camera.c: correct 'sizeimage' value reporting
The 'pix-width' field may be updated in mx3_camera_set_fmt() to fulfill the IPU stride line alignment requirements. If this update takes place, the 'fmt.pix.sizeimage' field in the struct v4l2_format stucture returned by VIDIOC_S_FMT is wrong. We need to update the 'pix-sizeimage' field in the mx3_camera_set_fmt() function to fix this issue. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/media/video/mx3_camera.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c index 7bcaaf7..6b0b25d 100644 --- a/drivers/media/video/mx3_camera.c +++ b/drivers/media/video/mx3_camera.c @@ -918,6 +918,12 @@ static int mx3_camera_set_fmt(struct soc_camera_device *icd, pix-colorspace = mf.colorspace; icd-current_fmt= xlate; + pix-bytesperline = soc_mbus_bytes_per_line(pix-width, + xlate-host_fmt); + if (pix-bytesperline 0) + return pix-bytesperline; + pix-sizeimage = pix-height * pix-bytesperline; + dev_dbg(icd-dev.parent, Sensor set %dx%d\n, pix-width, pix-height); return ret; -- 1.7.1 -- 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 1/2] v4l: soc-camera: start stream after queueing the buffers
On Sat, 29 Jan 2011 20:16:42 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... --- a/drivers/media/video/soc_camera.c +++ b/drivers/media/video/soc_camera.c @@ -646,11 +646,11 @@ static int soc_camera_streamon(struct file *file, void *priv, if (icd-streamer != file) return -EBUSY; - v4l2_subdev_call(sd, video, s_stream, 1); - /* This calls buf_queue from host driver's videobuf_queue_ops */ ret = videobuf_streamon(icd-vb_vidq); + v4l2_subdev_call(sd, video, s_stream, 1); + After a bit more testing I'll make this to + if (!ret) + v4l2_subdev_call(sd, video, s_stream, 1); + Ok? Or you can submit a v2 yourself, if you like - when you fix the comment in the other patch from this series. I'll submit a v2 patch since I have to resubmit the other patch, too. Thanks, Anatolij -- 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 2/2] dma: ipu_idmac: do not lose valid received data in the irq handler
Reading the commit message again I now realize that there is a mistake. On Wed, 26 Jan 2011 09:49:49 +0100 Anatolij Gustschin ag...@denx.de wrote: ... received data. DMA_BUFx_RDY won't be set by the IPU, so waiting for this event in the interrupt handler is wrong. This should read 'DMAIC_x_CUR_BUF flag won't be flipped here by the IPU, so waiting for this event in the EOF interrupt handler is wrong.' I'll submit another patch fixing the commit message. Anatolij -- 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 0/2] Fix issues with frame reception from CSI on i.MX31
On Wed, 26 Jan 2011 09:49:47 +0100 Anatolij Gustschin ag...@denx.de wrote: On some camera systems we do not tolerate the losing of captured frames. We observed losing of the first frame from CSI when double buffering is used (multiple buffers queued by the mx3-camera driver). The patches provide fixes for the observed problem. Anatolij Gustschin (2): v4l: soc-camera: start stream after queueing the buffers dma: ipu_idmac: do not lose valid received data in the irq handler drivers/dma/ipu/ipu_idmac.c | 50 -- drivers/media/video/soc_camera.c |4 +- 2 files changed, 2 insertions(+), 52 deletions(-) Here I provide some more information on what has been done to analyse the observed problem with one lost frame when capturing an exact number of frames. To be able to see whether some errors by hardware problems or channel or image sensor parameters miss-configuration appear or not and to catch such potential errors we added new IRQ handlers for IPU error interrupts. The patch for these handlers is inlined below, if someone is interested in it. This extension requires setting CONFIG_MX3_IPU_IRQS=10 in the kernel configuration. Also debug output has been activated in the mx3_camera driver. Two buffers are queued by the test application, so double buffering will be used. To simplify matters the image sensor is triggered to deliver only 3 frames. Here is the resulting debug log from the drivers. It is quoted, so I can add comments on related places: ... [ 66.56] mx3-camera mx3-camera.0: Set SENS_CONF to b00, rate 45314285 [ 66.56] mx3-camera mx3-camera.0: MX3 Camera driver attached to camera 0 [ 66.56] mx3-camera mx3-camera.0: Set format 960x243 [ 66.56] ipu-core ipu-core: timeout = 0 * 10ms [ 66.56] ipu-core ipu-core: init channel = 7 [ 66.56] ipu-core ipu-core: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x4000, IDMAC_CHA_PRI 0x4000, IDMAC_CHA_BUSY 0x0 [ 66.56] ipu-core ipu-core: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 [ 66.56] dma dma0chan7: Found channel 0x7, irq 177 [ 66.57] Got SOF IRQ 179 on Channel 7 [ 66.57] ipu-core ipu-core: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x4000, IDMAC_CHA_PRI 0x4000, IDMAC_CHA_BUSY 0x4000 [ 66.57] ipu-core ipu-core: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 [ 66.57] __ [ 66.57] mx3-camera mx3-camera.0: Sensor set 960x243 [ 66.57] mx3-camera mx3-camera.0: requested bus width 10 bit: 0 [ 66.57] mx3-camera mx3-camera.0: Flags cam: 0x7215 host: 0xf2fd common: 0x7215 [ 66.57] mx3-camera mx3-camera.0: Set SENS_CONF to 700 [ 66.57] mx3-camera mx3-camera.0: Set format 2056x1547 [ 66.58] ipu-core ipu-core: timeout = 0 * 10ms [ 66.58] ipu-core ipu-core: init channel = 7 [ 66.58] ipu-core ipu-core: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x4000, IDMAC_CHA_PRI 0x4000, IDMAC_CHA_BUSY 0x4000 [ 66.58] ipu-core ipu-core: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 [ 66.58] dma dma0chan7: Found channel 0x7, irq 177 [ 66.59] mx3-camera mx3-camera.0: Sensor set 2056x1547 [ 66.59] mx3-camera mx3-camera.0: requested bus width 10 bit: 0 [ 66.59] mx3-camera mx3-camera.0: Flags cam: 0x7215 host: 0xf2fd common: 0x7215 [ 66.59] mx3-camera mx3-camera.0: Set SENS_CONF to 700 [ 66.87] ipu-core ipu-core: write param mem - addr = 0x00010070, data = 0x [ 66.87] ipu-core ipu-core: write param mem - addr = 0x00010071, data = 0x4000 [ 66.87] ipu-core ipu-core: write param mem - addr = 0x00010072, data = 0x [ 66.87] ipu-core ipu-core: write param mem - addr = 0x00010073, data = 0x0A807000 [ 66.87] ipu-core ipu-core: write param mem - addr = 0x00010074, data = 0x0006 [ 66.87] ipu-core ipu-core: write param mem - addr = 0x00010078, data = 0x8680 [ 66.87] ipu-core ipu-core: write param mem - addr = 0x00010079, data = 0x [ 66.87] ipu-core ipu-core: write param mem - addr = 0x0001007A, data = 0x3E0E403B [ 66.87] ipu-core ipu-core: write param mem - addr = 0x0001007B, data = 0x0002 [ 66.87] ipu-core ipu-core: write param mem - addr = 0x0001007C, data = 0x [ 66.87] dma dma0chan7: Submitting sg c798a7ac [ 66.87] dma dma0chan7: Updated sg c798a7ac on channel 0x7 buffer 0 [ 66.87] ipu-core ipu-core: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x4000, IDMAC_CHA_PRI 0x4000, IDMAC_CHA_BUSY 0x4000 [ 66.87] ipu-core ipu-core: BUF0_RDY 0x80, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 [ 66.87] ipu-core ipu-core: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x4000, IDMAC_CHA_PRI 0x4080, IDMAC_CHA_BUSY 0x4000 [ 66.87] ipu-core ipu-core: BUF0_RDY
[PATCH 0/2] Fix issues with frame reception from CSI on i.MX31
On some camera systems we do not tolerate the losing of captured frames. We observed losing of the first frame from CSI when double buffering is used (multiple buffers queued by the mx3-camera driver). The patches provide fixes for the observed problem. Anatolij Gustschin (2): v4l: soc-camera: start stream after queueing the buffers dma: ipu_idmac: do not lose valid received data in the irq handler drivers/dma/ipu/ipu_idmac.c | 50 -- drivers/media/video/soc_camera.c |4 +- 2 files changed, 2 insertions(+), 52 deletions(-) -- 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 1/2] v4l: soc-camera: start stream after queueing the buffers
Some camera systems have strong requirement for capturing an exact number of frames after starting the stream and do not tolerate losing captured frames. By starting the stream after the videobuf has queued the buffers, we ensure that no frame will be lost. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/media/video/soc_camera.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c index a66811b..7299de0 100644 --- a/drivers/media/video/soc_camera.c +++ b/drivers/media/video/soc_camera.c @@ -646,11 +646,11 @@ static int soc_camera_streamon(struct file *file, void *priv, if (icd-streamer != file) return -EBUSY; - v4l2_subdev_call(sd, video, s_stream, 1); - /* This calls buf_queue from host driver's videobuf_queue_ops */ ret = videobuf_streamon(icd-vb_vidq); + v4l2_subdev_call(sd, video, s_stream, 1); + return ret; } -- 1.7.1 -- 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 2/2] dma: ipu_idmac: do not lose valid received data in the irq handler
Currently when two or more buffers are queued by the camera driver
and so the double buffering is enabled in the idmac, we lose the
first frame comming from CSI since it is just dropped by the
interrupt handler. The reason for this dropping is that the interrupt
handler misleadingly assumes that the cur_buf flag is pointing to the
buffer used by the IDMAC. Actually it is not the case since the
CUR_BUF flag will be flipped by the FSU when the FSU is sending the
TASK_NEW_FRM_RDY signal when new frame data is delivered by the CSI.
When sending this singal, FSU updates the DMA_CUR_BUF and the
DMA_BUFx_RDY flags: the DMA_CUR_BUF is flipped, the DMA_BUFx_RDY
is cleared, indicating that the frame data is beeing written by
the IDMAC to the pointed buffer. DMA_BUFx_RDY is supposed to be
set to the ready state again by the MCU, when it has handled the
received data. DMA_BUFx_RDY won't be set by the IPU, so waiting
for this event in the interrupt handler is wrong. Actually there
is no spurious interrupt as described in the comments, this
is the valid DMAIC_7_EOF interrupt indicating reception of the
frame from CSI.
This has been verified on the hardware which is triggering the
image sensor by the programmable state machine, allowing to
obtain exact number of frames. On this hardware we do not tolerate
losing frames.
This patch also removes resetting the DMA_BUFx_RDY flags of
all channels in ipu_disable_channel() since transfers on other
DMA channels might be triggered by other running tasks and the
buffers should always be ready for data sending or reception.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/dma/ipu/ipu_idmac.c | 50 ---
1 files changed, 0 insertions(+), 50 deletions(-)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index cb26ee9..c1a125e 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1145,29 +1145,6 @@ static int ipu_disable_channel(struct idmac *idmac,
struct idmac_channel *ichan,
reg = idmac_read_icreg(ipu, IDMAC_CHA_EN);
idmac_write_icreg(ipu, reg ~chan_mask, IDMAC_CHA_EN);
- /*
-* Problem (observed with channel DMAIC_7): after enabling the channel
-* and initialising buffers, there comes an interrupt with current still
-* pointing at buffer 0, whereas it should use buffer 0 first and only
-* generate an interrupt when it is done, then current should already
-* point to buffer 1. This spurious interrupt also comes on channel
-* DMASDC_0. With DMAIC_7 normally, is we just leave the ISR after the
-* first interrupt, there comes the second with current correctly
-* pointing to buffer 1 this time. But sometimes this second interrupt
-* doesn't come and the channel hangs. Clearing BUFx_RDY when disabling
-* the channel seems to prevent the channel from hanging, but it doesn't
-* prevent the spurious interrupt. This might also be unsafe. Think
-* about the IDMAC controller trying to switch to a buffer, when we
-* clear the ready bit, and re-enable it a moment later.
-*/
- reg = idmac_read_ipureg(ipu, IPU_CHA_BUF0_RDY);
- idmac_write_ipureg(ipu, 0, IPU_CHA_BUF0_RDY);
- idmac_write_ipureg(ipu, reg ~(1UL channel), IPU_CHA_BUF0_RDY);
-
- reg = idmac_read_ipureg(ipu, IPU_CHA_BUF1_RDY);
- idmac_write_ipureg(ipu, 0, IPU_CHA_BUF1_RDY);
- idmac_write_ipureg(ipu, reg ~(1UL channel), IPU_CHA_BUF1_RDY);
-
spin_unlock_irqrestore(ipu-lock, flags);
return 0;
@@ -1246,33 +1223,6 @@ static irqreturn_t idmac_interrupt(int irq, void *dev_id)
/* Other interrupts do not interfere with this channel */
spin_lock(ichan-lock);
- if (unlikely(chan_id != IDMAC_SDC_0 chan_id != IDMAC_SDC_1
-((curbuf chan_id) 1) == ichan-active_buffer
-!list_is_last(ichan-queue.next, ichan-queue))) {
- int i = 100;
-
- /* This doesn't help. See comment in ipu_disable_channel() */
- while (--i) {
- curbuf = idmac_read_ipureg(ipu_data, IPU_CHA_CUR_BUF);
- if (((curbuf chan_id) 1) != ichan-active_buffer)
- break;
- cpu_relax();
- }
-
- if (!i) {
- spin_unlock(ichan-lock);
- dev_dbg(dev,
- IRQ on active buffer on channel %x, active
- %d, ready %x, %x, current %x!\n, chan_id,
- ichan-active_buffer, ready0, ready1, curbuf);
- return IRQ_NONE;
- } else
- dev_dbg(dev,
- Buffer deactivated on channel %x, active
- %d, ready %x, %x, current %x, rest %d!\n,
chan_id
[PATCH v2 1/2] media: saa7115: allow input standard autodetection for more chips
Autodetect input's standard using field frequency detection
feature (FIDT in status byte at 0x1F) of the chips saa7111/
saa7111a/saa7113/saa7114/saa7118.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Changes since first patch version:
- reworked for chips other than saa7115
- fixed to return V4L2_STD_525_60 / V4L2_STD_625_50
instead of V4L2_STD_NTSC / V4L2_STD_PAL
- adapted the commit message
drivers/media/video/saa7115.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/saa7115.c b/drivers/media/video/saa7115.c
index 301c62b..f35459d 100644
--- a/drivers/media/video/saa7115.c
+++ b/drivers/media/video/saa7115.c
@@ -1348,8 +1348,17 @@ static int saa711x_querystd(struct v4l2_subdev *sd,
v4l2_std_id *std)
int reg1e;
*std = V4L2_STD_ALL;
- if (state-ident != V4L2_IDENT_SAA7115)
+ if (state-ident != V4L2_IDENT_SAA7115) {
+ int reg1f = saa711x_read(sd, R_1F_STATUS_BYTE_2_VD_DEC);
+
+ if (reg1f 0x20)
+ *std = V4L2_STD_525_60;
+ else
+ *std = V4L2_STD_625_50;
+
return 0;
+ }
+
reg1e = saa711x_read(sd, R_1E_STATUS_BYTE_1_VD_DEC);
switch (reg1e 0x03) {
--
1.7.1
--
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 2/2] media: fsl_viu: add VIDIOC_QUERYSTD and VIDIOC_G_STD support
VIDIOC_QUERYSTD and VIDIOC_G_STD ioctls are currently not
supported in the FSL VIU driver. The decoder subdevice
driver saa7115 extended by previous patch supports QUERYSTD
for saa711x, so we add the appropriate ioctls to the VIU
driver to be able to determine the video input's standard.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Changes since first patch version:
- fixed the commit message and rebased
drivers/media/video/fsl-viu.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/fsl-viu.c b/drivers/media/video/fsl-viu.c
index 693e9c0..e4bba88 100644
--- a/drivers/media/video/fsl-viu.c
+++ b/drivers/media/video/fsl-viu.c
@@ -194,6 +194,8 @@ struct viu_dev {
/* decoder */
struct v4l2_subdev *decoder;
+
+ v4l2_std_id std;
};
struct viu_fh {
@@ -937,14 +939,31 @@ static int vidioc_streamoff(struct file *file, void
*priv, enum v4l2_buf_type i)
#define decoder_call(viu, o, f, args...) \
v4l2_subdev_call(viu-decoder, o, f, ##args)
+static int vidioc_querystd(struct file *file, void *priv, v4l2_std_id *std_id)
+{
+ struct viu_fh *fh = priv;
+
+ decoder_call(fh-dev, video, querystd, std_id);
+ return 0;
+}
+
static int vidioc_s_std(struct file *file, void *priv, v4l2_std_id *id)
{
struct viu_fh *fh = priv;
+ fh-dev-std = *id;
decoder_call(fh-dev, core, s_std, *id);
return 0;
}
+static int vidioc_g_std(struct file *file, void *priv, v4l2_std_id *std_id)
+{
+ struct viu_fh *fh = priv;
+
+ *std_id = fh-dev-std;
+ return 0;
+}
+
/* only one input in this driver */
static int vidioc_enum_input(struct file *file, void *priv,
struct v4l2_input *inp)
@@ -1402,7 +1421,9 @@ static const struct v4l2_ioctl_ops viu_ioctl_ops = {
.vidioc_querybuf = vidioc_querybuf,
.vidioc_qbuf = vidioc_qbuf,
.vidioc_dqbuf = vidioc_dqbuf,
+ .vidioc_g_std = vidioc_g_std,
.vidioc_s_std = vidioc_s_std,
+ .vidioc_querystd = vidioc_querystd,
.vidioc_enum_input= vidioc_enum_input,
.vidioc_g_input = vidioc_g_input,
.vidioc_s_input = vidioc_s_input,
--
1.7.1
--
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] media: fsl-viu: fix support for streaming with mmap method
Streaming using mmap didn't work in the VIU driver. We need to start/stop DMA in streamon/streamoff and free the buffers on release. Add appropriate driver extension now. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/media/video/fsl-viu.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/fsl-viu.c b/drivers/media/video/fsl-viu.c index c9eb161..483a5ed 100644 --- a/drivers/media/video/fsl-viu.c +++ b/drivers/media/video/fsl-viu.c @@ -917,6 +917,8 @@ static int vidioc_streamon(struct file *file, void *priv, enum v4l2_buf_type i) if (fh-type != i) return -EINVAL; + viu_start_dma(fh-dev); + return videobuf_streamon(fh-vb_vidq); } @@ -929,6 +931,8 @@ static int vidioc_streamoff(struct file *file, void *priv, enum v4l2_buf_type i) if (fh-type != i) return -EINVAL; + viu_stop_dma(fh-dev); + return videobuf_streamoff(fh-vb_vidq); } @@ -1350,6 +1354,7 @@ static int viu_release(struct file *file) viu_stop_dma(dev); videobuf_stop(fh-vb_vidq); + videobuf_mmap_free(fh-vb_vidq); kfree(fh); -- 1.7.1 -- 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 1/2] media: saa7115: allow input standard autodetection for SAA7113
Autodetect input's standard using field frequency detection
feature (FIDT in status byte at 0x1F) of the SAA7113.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/video/saa7115.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/saa7115.c b/drivers/media/video/saa7115.c
index 301c62b..f28a4c7 100644
--- a/drivers/media/video/saa7115.c
+++ b/drivers/media/video/saa7115.c
@@ -1348,6 +1348,18 @@ static int saa711x_querystd(struct v4l2_subdev *sd,
v4l2_std_id *std)
int reg1e;
*std = V4L2_STD_ALL;
+
+ if (state-ident == V4L2_IDENT_SAA7113) {
+ int reg1f = saa711x_read(sd, R_1F_STATUS_BYTE_2_VD_DEC);
+
+ if (reg1f 0x20)
+ *std = V4L2_STD_NTSC;
+ else
+ *std = V4L2_STD_PAL;
+
+ return 0;
+ }
+
if (state-ident != V4L2_IDENT_SAA7115)
return 0;
reg1e = saa711x_read(sd, R_1E_STATUS_BYTE_1_VD_DEC);
--
1.7.1
--
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 2/2] media: fsl_viu: add VIDIOC_QUERYSTD and VIDIOC_G_STD support
VIDIOC_QUERYSTD and VIDIOC_G_STD ioctls are currently not
supported in the FSL VIU driver. The decoder subdevice
driver saa7115 extended by previous patch supports QUERYSTD
for saa7113, so we add the appropriate ioctls to the VIU
driver to be able to determine the video input's standard.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/video/fsl-viu.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/fsl-viu.c b/drivers/media/video/fsl-viu.c
index b8faff2..04be6eb 100644
--- a/drivers/media/video/fsl-viu.c
+++ b/drivers/media/video/fsl-viu.c
@@ -194,6 +194,8 @@ struct viu_dev {
/* decoder */
struct v4l2_subdev *decoder;
+
+ v4l2_std_id std;
};
struct viu_fh {
@@ -933,14 +935,31 @@ static int vidioc_streamoff(struct file *file, void
*priv, enum v4l2_buf_type i)
#define decoder_call(viu, o, f, args...) \
v4l2_subdev_call(viu-decoder, o, f, ##args)
+static int vidioc_querystd(struct file *file, void *priv, v4l2_std_id *std_id)
+{
+ struct viu_fh *fh = priv;
+
+ decoder_call(fh-dev, video, querystd, std_id);
+ return 0;
+}
+
static int vidioc_s_std(struct file *file, void *priv, v4l2_std_id *id)
{
struct viu_fh *fh = priv;
+ fh-dev-std = *id;
decoder_call(fh-dev, core, s_std, *id);
return 0;
}
+static int vidioc_g_std(struct file *file, void *priv, v4l2_std_id *std_id)
+{
+ struct viu_fh *fh = priv;
+
+ *std_id = fh-dev-std;
+ return 0;
+}
+
/* only one input in this driver */
static int vidioc_enum_input(struct file *file, void *priv,
struct v4l2_input *inp)
@@ -1397,7 +1416,9 @@ static const struct v4l2_ioctl_ops viu_ioctl_ops = {
.vidioc_querybuf = vidioc_querybuf,
.vidioc_qbuf = vidioc_qbuf,
.vidioc_dqbuf = vidioc_dqbuf,
+ .vidioc_g_std = vidioc_g_std,
.vidioc_s_std = vidioc_s_std,
+ .vidioc_querystd = vidioc_querystd,
.vidioc_enum_input= vidioc_enum_input,
.vidioc_g_input = vidioc_g_input,
.vidioc_s_input = vidioc_s_input,
--
1.7.1
--
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] V4L/DVB: v4l: fsl-viu.c: add slab.h include to fix compile breakage
mpc512x kernel configurations without SPI support do not build: drivers/media/video/fsl-viu.c: In function 'viu_open': drivers/media/video/fsl-viu.c:1248: error: implicit declaration of function 'kzalloc' drivers/media/video/fsl-viu.c:1248: warning: assignment makes pointer from integer without a cast drivers/media/video/fsl-viu.c: In function 'viu_release': drivers/media/video/fsl-viu.c:1335: error: implicit declaration of function 'kfree' If CONFIG_SPI is enabled, the slab.h will be included in linux/spi/spi.h which is included by media/v4l2-common.h and the fsl_viu.c driver builds. Let's incluce linux/slab.h directly to fix the build breakage. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/media/video/fsl-viu.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/fsl-viu.c b/drivers/media/video/fsl-viu.c index 43d208f..0b318be 100644 --- a/drivers/media/video/fsl-viu.c +++ b/drivers/media/video/fsl-viu.c @@ -22,6 +22,7 @@ #include linux/interrupt.h #include linux/io.h #include linux/of_platform.h +#include linux/slab.h #include linux/version.h #include media/v4l2-common.h #include media/v4l2-device.h -- 1.7.0.4 -- 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] v4l: Add MPC5121e VIU video capture driver
Adds support for Video-In (VIU) unit of Freescale
MPC5121e. The driver supports RGB888/RGB565 formats,
capture and overlay on MPC5121e DIU frame buffer.
Signed-off-by: Hongjun Chen hong-jun.c...@freescale.com
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Please review and consider for inclusion in 2.6.36. Thanks!
Changes since first patch version:
- fixed problems with DMA auto-deinterlace while capturing
- reworked and simplified interrupt handler
- moved a number of global variables into driver's private
structure
- reworked and simplified overlay enable code
- reworked viu_dma_stop() to ensure the DMA transfer really
stops after calling
drivers/media/video/Kconfig | 12 +
drivers/media/video/Makefile |1 +
drivers/media/video/fsl-viu.c | 1632 +
3 files changed, 1645 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/fsl-viu.c
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index bdbc9d3..45bef41 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -557,6 +557,18 @@ config VIDEO_DAVINCI_VPIF
To compile this driver as a module, choose M here: the
module will be called vpif.
+config VIDEO_VIU
+ tristate Freescale VIU Video Driver
+ depends on VIDEO_V4L2 PPC_MPC512x
+ select VIDEOBUF_DMA_CONTIG
+ default y
+ ---help---
+ Support for Freescale VIU video driver. This device captures
+ video data, or overlays video on DIU frame buffer.
+
+ Say Y here if you want to enable VIU device on MPC5121e Rev2+.
+ In doubt, say N.
+
config VIDEO_VIVI
tristate Virtual Video Driver
depends on VIDEO_DEV VIDEO_V4L2 !SPARC32 !SPARC64 FONTS
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index cc93859..542d786 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -151,6 +151,7 @@ obj-$(CONFIG_USB_S2255) += s2255drv.o
obj-$(CONFIG_VIDEO_IVTV) += ivtv/
obj-$(CONFIG_VIDEO_CX18) += cx18/
+obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
obj-$(CONFIG_VIDEO_VIVI) += vivi.o
obj-$(CONFIG_VIDEO_MEM2MEM_TESTDEV) += mem2mem_testdev.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
diff --git a/drivers/media/video/fsl-viu.c b/drivers/media/video/fsl-viu.c
new file mode 100644
index 000..8f1c94f
--- /dev/null
+++ b/drivers/media/video/fsl-viu.c
@@ -0,0 +1,1632 @@
+/*
+ * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Freescale VIU video driver
+ *
+ * Authors: Hongjun Chen hong-jun.c...@freescale.com
+ * Porting to 2.6.35 by DENX Software Engineering,
+ * Anatolij Gustschin ag...@denx.de
+ *
+ * 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.
+ *
+ */
+
+#include linux/module.h
+#include linux/clk.h
+#include linux/kernel.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/of_platform.h
+#include linux/version.h
+#include media/v4l2-common.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/videobuf-dma-contig.h
+
+#define DRV_NAME fsl_viu
+#define VIU_MAJOR_VERSION 0
+#define VIU_MINOR_VERSION 5
+#define VIU_RELEASE0
+#define VIU_VERSIONKERNEL_VERSION(VIU_MAJOR_VERSION, \
+ VIU_MINOR_VERSION, \
+ VIU_RELEASE)
+
+#define BUFFER_TIMEOUT msecs_to_jiffies(500) /* 0.5 seconds */
+
+#defineVIU_VID_MEM_LIMIT 4 /* Video memory limit, in Mb */
+
+/* I2C address of video decoder chip is 0x4A */
+#define VIU_VIDEO_DECODER_ADDR 0x25
+
+/* supported controls */
+static struct v4l2_queryctrl viu_qctrl[] = {
+ {
+ .id= V4L2_CID_BRIGHTNESS,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Brightness,
+ .minimum = 0,
+ .maximum = 255,
+ .step = 1,
+ .default_value = 127,
+ .flags = 0,
+ }, {
+ .id= V4L2_CID_CONTRAST,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Contrast,
+ .minimum = 0,
+ .maximum = 255,
+ .step = 0x1,
+ .default_value = 0x10,
+ .flags = 0,
+ }, {
+ .id= V4L2_CID_SATURATION,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Saturation,
+ .minimum = 0,
+ .maximum = 255
[PATCH] V4L/DVB: v4l2-dev: fix memory leak
Since commit b4028437876866aba4747a655ede00f892089e14 the 'driver_data' field resides in device's struct device_private which may be allocated by dev_set_drvdata() if device_private struct was not allocated previously. dev_set_drvdata() is used in video_set_drvdata() to set the driver's private data pointer in v4l2 drivers. Setting the private data _before_ registering the v4l2 device results in a memory leak since __video_register_device() also calls video_set_drvdata(), but after zeroing the device structure. Thus, the reference to the previously allocated device_private struct goes lost and a new device_private will be allocated. All v4l drivers which call video_set_drvdata() _before_ calling video_register_device() are affected. The patch fixes __video_register_device() to preserve previously allocated device_private reference. Caught by kmemleak. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/media/video/v4l2-dev.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c index 0ca7ec9..9e89bf6 100644 --- a/drivers/media/video/v4l2-dev.c +++ b/drivers/media/video/v4l2-dev.c @@ -410,7 +410,7 @@ static int __video_register_device(struct video_device *vdev, int type, int nr, int minor_offset = 0; int minor_cnt = VIDEO_NUM_DEVICES; const char *name_base; - void *priv = video_get_drvdata(vdev); + void *priv = vdev-dev.p; /* A minor value of -1 marks this video device as never having been registered */ @@ -536,9 +536,9 @@ static int __video_register_device(struct video_device *vdev, int type, int nr, /* Part 4: register the device with sysfs */ memset(vdev-dev, 0, sizeof(vdev-dev)); - /* The memset above cleared the device's drvdata, so + /* The memset above cleared the device's device_private, so put back the copy we made earlier. */ - video_set_drvdata(vdev, priv); + vdev-dev.p = priv; vdev-dev.class = video_class; vdev-dev.devt = MKDEV(VIDEO_MAJOR, vdev-minor); if (vdev-parent) -- 1.7.0.4 -- 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] v4l: Add MPC5121e VIU video capture driver
From: Hongjun Chen hong-jun.c...@freescale.com
Adds support for Video-In (VIU) unit of MPC5121e.
The driver supports RGB888/RGB565 formats, capture
and overlay on MPC5121e DIU frame buffer.
Signed-off-by: Hongjun Chen hong-jun.c...@freescale.com
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Please consider this driver for inclusion in 2.6.36. Thanks!
drivers/media/video/Kconfig | 12 +
drivers/media/video/Makefile |1 +
drivers/media/video/fsl-viu.c | 1620 +
3 files changed, 1633 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/fsl-viu.c
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index bdbc9d3..45bef41 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -557,6 +557,18 @@ config VIDEO_DAVINCI_VPIF
To compile this driver as a module, choose M here: the
module will be called vpif.
+config VIDEO_VIU
+ tristate Freescale VIU Video Driver
+ depends on VIDEO_V4L2 PPC_MPC512x
+ select VIDEOBUF_DMA_CONTIG
+ default y
+ ---help---
+ Support for Freescale VIU video driver. This device captures
+ video data, or overlays video on DIU frame buffer.
+
+ Say Y here if you want to enable VIU device on MPC5121e Rev2+.
+ In doubt, say N.
+
config VIDEO_VIVI
tristate Virtual Video Driver
depends on VIDEO_DEV VIDEO_V4L2 !SPARC32 !SPARC64 FONTS
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index cc93859..542d786 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -151,6 +151,7 @@ obj-$(CONFIG_USB_S2255) += s2255drv.o
obj-$(CONFIG_VIDEO_IVTV) += ivtv/
obj-$(CONFIG_VIDEO_CX18) += cx18/
+obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
obj-$(CONFIG_VIDEO_VIVI) += vivi.o
obj-$(CONFIG_VIDEO_MEM2MEM_TESTDEV) += mem2mem_testdev.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
diff --git a/drivers/media/video/fsl-viu.c b/drivers/media/video/fsl-viu.c
new file mode 100644
index 000..efec0a0
--- /dev/null
+++ b/drivers/media/video/fsl-viu.c
@@ -0,0 +1,1620 @@
+/*
+ * Copyright 2008 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Freescale VIU video driver
+ *
+ * Authors: Hongjun Chen hong-jun.c...@freescale.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.
+ *
+ */
+
+#include linux/module.h
+#include linux/clk.h
+#include linux/kernel.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/of_platform.h
+#include linux/version.h
+#include media/v4l2-common.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/videobuf-dma-contig.h
+
+#define BUFFER_TIMEOUT msecs_to_jiffies(500) /* 0.5 seconds */
+
+static struct viu_reg reg_val;
+static char first = 1, dma_done;
+
+#define DRV_NAME fsl_viu
+#define VIU_MAJOR_VERSION 0
+#define VIU_MINOR_VERSION 4
+#define VIU_RELEASE0
+#define VIU_VERSIONKERNEL_VERSION(VIU_MAJOR_VERSION, \
+ VIU_MINOR_VERSION, \
+ VIU_RELEASE)
+
+#defineVIU_VID_MEM_LIMIT 4 /* Video memory limit, in Mb */
+
+/* I2C address of video decoder chip is 0x4A */
+#define VIU_VIDEO_DECODER_ADDR 0x25
+
+/* supported controls */
+static struct v4l2_queryctrl viu_qctrl[] = {
+ {
+ .id= V4L2_CID_BRIGHTNESS,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Brightness,
+ .minimum = 0,
+ .maximum = 255,
+ .step = 1,
+ .default_value = 127,
+ .flags = 0,
+ }, {
+ .id= V4L2_CID_CONTRAST,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Contrast,
+ .minimum = 0,
+ .maximum = 255,
+ .step = 0x1,
+ .default_value = 0x10,
+ .flags = 0,
+ }, {
+ .id= V4L2_CID_SATURATION,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Saturation,
+ .minimum = 0,
+ .maximum = 255,
+ .step = 0x1,
+ .default_value = 127,
+ .flags = 0,
+ }, {
+ .id= V4L2_CID_HUE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Hue,
+ .minimum = -128,
+ .maximum = 127,
+ .step
