Re: S3C244X/S3C64XX SoC camera host interface driver questions
Hi.
Just have time to test. I apologize for delay.
I'd like to squash all the s3c-camif patches before sending upstream,
if you don't mind. And to add your Signed-off at the final patch.
Ok. Squash.
I might have introduced bugs in the image effects handling, hopefully
there is none. I couldn't test it though. Could you test that on your
side with s3c64xx ?
Got some error. Seems effect updated only when I set new CrCb value.
Seems it's incorrect:
case V4L2_CID_COLORFX:
if (camif-ctrl_colorfx_cbcr-is_new) {
camif-colorfx = camif-ctrl_colorfx-val;
/* Set Cb, Cr */
switch (ctrl-val) {
case V4L2_COLORFX_SEPIA:
camif-ctrl_colorfx_cbcr-val = 0x7391;
break;
case V4L2_COLORFX_SET_CBCR: /* noop */
break;
default:
/* for V4L2_COLORFX_BW and others */
camif-ctrl_colorfx_cbcr-val = 0x8080;
}
}
camif-colorfx_cb = camif-ctrl_colorfx_cbcr-val 0xff;
camif-colorfx_cr = camif-ctrl_colorfx_cbcr-val 8;
break;
Moving camif-colorfx = camif-ctrl_colorfx-val; out of condition
fixes the problem, but setting CrCb value control affect all effects
(sepia and BW), not only V4L2_COLORFX_SET_CBCR. Seems condition should
be removed and colorfx value should be checked set on every effect
change.
diff --git a/drivers/media/platform/s3c-camif/camif-capture.c
b/drivers/media/platform/s3c-camif/camif-capture.c
index ceab03a..9c01f4f 100644
--- a/drivers/media/platform/s3c-camif/camif-capture.c
+++ b/drivers/media/platform/s3c-camif/camif-capture.c
@@ -1526,19 +1526,17 @@ static int s3c_camif_subdev_s_ctrl(struct
v4l2_ctrl *ctrl)
switch (ctrl-id) {
case V4L2_CID_COLORFX:
- if (camif-ctrl_colorfx_cbcr-is_new) {
- camif-colorfx = camif-ctrl_colorfx-val;
- /* Set Cb, Cr */
- switch (ctrl-val) {
- case V4L2_COLORFX_SEPIA:
- camif-ctrl_colorfx_cbcr-val = 0x7391;
- break;
- case V4L2_COLORFX_SET_CBCR: /* noop */
- break;
- default:
- /* for V4L2_COLORFX_BW and others */
- camif-ctrl_colorfx_cbcr-val = 0x8080;
- }
+ camif-colorfx = camif-ctrl_colorfx-val;
+ /* Set Cb, Cr */
+ switch (ctrl-val) {
+ case V4L2_COLORFX_SEPIA:
+ camif-ctrl_colorfx_cbcr-val = 0x7391;
+ break;
+ case V4L2_COLORFX_SET_CBCR: /* noop */
+ break;
+ default:
+ /* for V4L2_COLORFX_BW and others */
+ camif-ctrl_colorfx_cbcr-val = 0x8080;
}
camif-colorfx_cb = camif-ctrl_colorfx_cbcr-val 0xff;
camif-colorfx_cr = camif-ctrl_colorfx_cbcr-val 8;
With this modification got another issue: set CRCB effect, set CRCB
value, set BW effect, set CRCB effect back cause CRCB-value to be
reseted to default 0x8080. Is it correct?
--
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: S3C244X/S3C64XX SoC camera host interface driver questions
Hi,
On 11/17/2012 01:07 PM, Andrey Gusakov wrote:
Hi.
Just have time to test. I apologize for delay.
No problem, thanks for the feedback.
I'd like to squash all the s3c-camif patches before sending upstream,
if you don't mind. And to add your Signed-off at the final patch.
Ok. Squash.
I might have introduced bugs in the image effects handling, hopefully
there is none. I couldn't test it though. Could you test that on your
side with s3c64xx ?
Got some error. Seems effect updated only when I set new CrCb value.
Seems it's incorrect:
case V4L2_CID_COLORFX:
if (camif-ctrl_colorfx_cbcr-is_new) {
Uh, copy/paste error, this should have been
if (camif-ctrl_colorfx-is_new) {
camif-colorfx = camif-ctrl_colorfx-val;
/* Set Cb, Cr */
switch (ctrl-val) {
case V4L2_COLORFX_SEPIA:
camif-ctrl_colorfx_cbcr-val = 0x7391;
break;
case V4L2_COLORFX_SET_CBCR: /* noop */
break;
default:
/* for V4L2_COLORFX_BW and others */
camif-ctrl_colorfx_cbcr-val = 0x8080;
}
}
camif-colorfx_cb = camif-ctrl_colorfx_cbcr-val 0xff;
camif-colorfx_cr = camif-ctrl_colorfx_cbcr-val 8;
break;
Moving camif-colorfx = camif-ctrl_colorfx-val; out of condition
fixes the problem, but setting CrCb value control affect all effects
(sepia and BW), not only V4L2_COLORFX_SET_CBCR. Seems condition should
be removed and colorfx value should be checked set on every effect
change.
diff --git a/drivers/media/platform/s3c-camif/camif-capture.c
b/drivers/media/platform/s3c-camif/camif-capture.c
index ceab03a..9c01f4f 100644
--- a/drivers/media/platform/s3c-camif/camif-capture.c
+++ b/drivers/media/platform/s3c-camif/camif-capture.c
@@ -1526,19 +1526,17 @@ static int s3c_camif_subdev_s_ctrl(struct
v4l2_ctrl *ctrl)
switch (ctrl-id) {
case V4L2_CID_COLORFX:
- if (camif-ctrl_colorfx_cbcr-is_new) {
- camif-colorfx = camif-ctrl_colorfx-val;
- /* Set Cb, Cr */
- switch (ctrl-val) {
- case V4L2_COLORFX_SEPIA:
- camif-ctrl_colorfx_cbcr-val = 0x7391;
- break;
- case V4L2_COLORFX_SET_CBCR: /* noop */
- break;
- default:
- /* for V4L2_COLORFX_BW and others */
- camif-ctrl_colorfx_cbcr-val = 0x8080;
- }
+ camif-colorfx = camif-ctrl_colorfx-val;
+ /* Set Cb, Cr */
+ switch (ctrl-val) {
+ case V4L2_COLORFX_SEPIA:
+ camif-ctrl_colorfx_cbcr-val = 0x7391;
+ break;
+ case V4L2_COLORFX_SET_CBCR: /* noop */
+ break;
+ default:
+ /* for V4L2_COLORFX_BW and others */
+ camif-ctrl_colorfx_cbcr-val = 0x8080;
}
camif-colorfx_cb = camif-ctrl_colorfx_cbcr-val 0xff;
camif-colorfx_cr = camif-ctrl_colorfx_cbcr-val 8;
With this modification got another issue: set CRCB effect, set CRCB
value, set BW effect, set CRCB effect back cause CRCB-value to be
reseted to default 0x8080. Is it correct?
We could do better. The control values are already cached twice - in
struct v4l2_ctrl and struct camif_dev.
It seems more intuitive to save CB/CR coefficients for V4L2_COLORFX_SET_CBCR
and then restore them as needed. There is probably not much use of letting
user space know that the driver uses CBCR for V4L2_COLORFX_SEPIA and
V4L2_COLORFX_BW internally.
I propose change as below, it includes disabling the control for SoCs that
don't support it and a fixed cbcr order, to match documentation:
V4L2_CID_COLORFX_CBCR integer Determines the Cb and Cr coefficients for
V4L2_COLORFX_SET_CBCR color effect. Bits [7:0] of the supplied 32 bit
value are
interpreted as Cr component, bits [15:8] as Cb component and bits
[31:16] must
be zero.
I have pushed it all to the testing/s3c-camif branch. Please let me know
if you find any further issues.
-8---
diff --git a/drivers/media/platform/s3c-camif/camif-capture.c
b/drivers/media/platform/s3c-camif/camif-capture.c
index 6401fdb..b52cc59 100644
--- a/drivers/media/platform/s3c-camif/camif-capture.c
+++ b/drivers/media/platform/s3c-camif/camif-capture.c
@@ -1520,22 +1520,22 @@ static int s3c_camif_subdev_s_ctrl(struct
v4l2_ctrl *ctrl)
switch (ctrl-id) {
case V4L2_CID_COLORFX:
- if (camif-ctrl_colorfx_cbcr-is_new)
Re: S3C244X/S3C64XX SoC camera host interface driver questions
Hi Andrey, On 11/11/2012 02:26 PM, Andrey Gusakov wrote: Hi. Patch v2 attached. Comments taken into account. Thanks, I had to rework the S3C-CAMIF subdev controls handling to avoid races when the control's value is modified in the control framwework and accessed from interrupt context in the driver. I've pushed all patches to branch s3c-camif-for-v3.8 at git://linuxtv.org/snawrocki/media.git I'd like to squash all the s3c-camif patches before sending upstream, if you don't mind. And to add your Signed-off at the final patch. Please let me know if you'd rather keep your patch separate. I might have introduced bugs in the image effects handling, hopefully there is none. I couldn't test it though. Could you test that on your side with s3c64xx ? I'm planning to send a pull request for the CAMIF driver this week. I often get VIDIOC_QUERYCAP: failed: Inappropriate ioctl for device This is an issue in the v4l2-ctl, it is going to be fixed by adding VIDIOC_SUBDEV_QUERYCAP ioctl for subdevs. It has been just discussed today. I guess you get it when running v4l2-ctl on /dev/v4l-subdev* ? Yes. or system error: Inappropriate ioctl for device I think this one is caused by unimplemented VIDIOC_G/S_PARM ioctls at the s3c-camif driver. Is it because of not implemented set/get framerate func? How this Yes, I think so. ioctls as above. Ok. I'll implement this ioctls and see what happens. They are not supposed to be implemented in the s3c-camif driver. Instead they should be emulated by a user-space library, based on the sensor subdev operations. should work? I mean framerate heavy depend of sensor's settings. So set/get framerate call to fimc should get/set framerate from sensor. What is mechanism of such things? With user space subdev API one should control frame interval directly on the sensor subdev device node [1]. For Gstreamer to work with VIDIOC_G/S_PARM ioctls we need a dedicated v4l2 library (possibly with a plugin for s3c-camif, but that shouldn't be needed since it is very simple driver) that will translate those video node ioctls into the subdev node ioctls [2]. Unfortunately such library is still not available. And same question about synchronizing format of sensor and FIMC pads. I make ov2640 work, but if did not call media-ctl for sensor, format of FIMC sink pad and format of sensor source pad different. I think I missed something, but reading other sources did not help. As I explained previously, s3c-fimc is supposed to synchronize format with the sensor subdev. Have you got pad level get_fmt callback implemented in the ov2640 driver ? Yes. Could you post your 'media-ctl -p' output, run right after the system boot ? Looks like I messed up, after starting formats are the same: Opening media device /dev/media0ov2640: ov2640_open:1381 Enumerating entities Found 4 entities Enumerating pads and links Media controller API version 0.0.0 Media device information driver s3c-camif model SAMSUNG S3C6410 CAMIF serial bus infoplatform:%s I've removed this stray %s already. hw revision 0x32 driver version 0.0.0 Device topology - entity 1: ov2640 (1 pad, 1 link) type V4L2 subdev subtype Sensor device node name /dev/v4l-subdev0 pad0: Source [YUYV2X8 176x144] - S3C-CAMIF:0 [ENABLED,IMMUTABLE] - entity 2: S3C-CAMIF (3 pads, 3 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Sink [YUYV2X8 176x144 (0,0)/176x144] - ov2640:0 [ENABLED,IMMUTABLE] pad1: Source [YUYV2X8 176x144] - camif-codec:0 [ENABLED,IMMUTABLE] pad2: Source [YUYV2X8 176x144] - camif-preview:0 [ENABLED,IMMUTABLE] - entity 3: camif-codec (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Sink - S3C-CAMIF:1 [ENABLED,IMMUTABLE] - entity 4: camif-preview (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Sink - S3C-CAMIF:2 [ENABLED,IMMUTABLE] Looks fine, thanks. -- 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: S3C244X/S3C64XX SoC camera host interface driver questions
Hi. Patch v2 attached. Comments taken into account. I often get VIDIOC_QUERYCAP: failed: Inappropriate ioctl for device This is an issue in the v4l2-ctl, it is going to be fixed by adding VIDIOC_SUBDEV_QUERYCAP ioctl for subdevs. It has been just discussed today. I guess you get it when running v4l2-ctl on /dev/v4l-subdev* ? Yes. or system error: Inappropriate ioctl for device I think this one is caused by unimplemented VIDIOC_G/S_PARM ioctls at the s3c-camif driver. Is it because of not implemented set/get framerate func? How this Yes, I think so. ioctls as above. Ok. I'll implement this ioctls and see what happens. should work? I mean framerate heavy depend of sensor's settings. So set/get framerate call to fimc should get/set framerate from sensor. What is mechanism of such things? With user space subdev API one should control frame interval directly on the sensor subdev device node [1]. For Gstreamer to work with VIDIOC_G/S_PARM ioctls we need a dedicated v4l2 library (possibly with a plugin for s3c-camif, but that shouldn't be needed since it is very simple driver) that will translate those video node ioctls into the subdev node ioctls [2]. Unfortunately such library is still not available. And same question about synchronizing format of sensor and FIMC pads. I make ov2640 work, but if did not call media-ctl for sensor, format of FIMC sink pad and format of sensor source pad different. I think I missed something, but reading other sources did not help. As I explained previously, s3c-fimc is supposed to synchronize format with the sensor subdev. Have you got pad level get_fmt callback implemented in the ov2640 driver ? Yes. Could you post your 'media-ctl -p' output, run right after the system boot ? Looks like I messed up, after starting formats are the same: Opening media device /dev/media0ov2640: ov2640_open:1381 Enumerating entities Found 4 entities Enumerating pads and links Media controller API version 0.0.0 Media device information driver s3c-camif model SAMSUNG S3C6410 CAMIF serial bus infoplatform:%s hw revision 0x32 driver version 0.0.0 Device topology - entity 1: ov2640 (1 pad, 1 link) type V4L2 subdev subtype Sensor device node name /dev/v4l-subdev0 pad0: Source [YUYV2X8 176x144] - S3C-CAMIF:0 [ENABLED,IMMUTABLE] - entity 2: S3C-CAMIF (3 pads, 3 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Sink [YUYV2X8 176x144 (0,0)/176x144] - ov2640:0 [ENABLED,IMMUTABLE] pad1: Source [YUYV2X8 176x144] - camif-codec:0 [ENABLED,IMMUTABLE] pad2: Source [YUYV2X8 176x144] - camif-preview:0 [ENABLED,IMMUTABLE] - entity 3: camif-codec (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Sink - S3C-CAMIF:1 [ENABLED,IMMUTABLE] - entity 4: camif-preview (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Sink - S3C-CAMIF:2 [ENABLED,IMMUTABLE] 0001-ARM-S3C-CAMIF-add-image-effect-controls.patch Description: Binary data
Re: S3C244X/S3C64XX SoC camera host interface driver questions
Hi, On 11/08/2012 07:47 PM, Andrey Gusakov wrote: Ok, thanks. I will add the missing CONFIG_PM_RUNTIME dependency in Kconfig. The driver has to have PM_RUNTIME enabled since on s3c64xx SoCs there are power domains and the camera power domain needs to be enabled for the CAMIF operation. The pm_runtime_* calls in the driver are supposed to ensure that. I wonder why it works for you without PM_RUNTIME, i.e. how comes the power domain is enabled. It is supposed to be off by default. DS says that all power domaint are on after reset. My bootloader did not switch then off. So when linux start everything is on. CONFIG_PM_RUNTIME was disabled, so nothing switch them off in linux too. Yes, indeed. But there was a PM code added that is supposed to disable all unused power domains on the system boot. I noticed that one needs to call explicitly s3c64xx_pm_init() function from machine_init() callback within the board file. So far this function is called only in mach-crag6410.c. I'm not sure it it won't kill the display if you use it though. Probably PM domain state should be read from a respective register and this information passed to pm_genpd_init() function within s3c64_pm_init(). I hope to eventually prepare the ov9650 sensor driver for mainline. Your help in making it ready for VER=0x52 would be very much appreciated. :-) I'll try to helpful. Next step is to make ov2460 work. For now I can only recommend you to make the ov2460 driver more similar to the ov9650 one. Thanks, I'll try. P.S. I add support of image effects just for fun. And found in DS that s3c2450 also support effects. It's FIMC in-between of 2440 and 6400/6410. Does anyone have s3c2450 hardware to test it? Patches adding image effect are welcome. I'm bit to busy to play with these things, other than I don't have hardware to test it. I wasn't really aware of CAMIF in s3c2450. I think a separate variant data structure would need to be defined for s3c2450. If anyone ever needs it it could be added easily. For now I'll pretend this version doesn't exist. :-) Attached. I often get VIDIOC_QUERYCAP: failed: Inappropriate ioctl for device This is an issue in the v4l2-ctl, it is going to be fixed by adding VIDIOC_SUBDEV_QUERYCAP ioctl for subdevs. It has been just discussed today. I guess you get it when running v4l2-ctl on /dev/v4l-subdev* ? or system error: Inappropriate ioctl for device I think this one is caused by unimplemented VIDIOC_G/S_PARM ioctls at the s3c-camif driver. Is it because of not implemented set/get framerate func? How this Yes, I think so. ioctls as above. should work? I mean framerate heavy depend of sensor's settings. So set/get framerate call to fimc should get/set framerate from sensor. What is mechanism of such things? With user space subdev API one should control frame interval directly on the sensor subdev device node [1]. For Gstreamer to work with VIDIOC_G/S_PARM ioctls we need a dedicated v4l2 library (possibly with a plugin for s3c-camif, but that shouldn't be needed since it is very simple driver) that will translate those video node ioctls into the subdev node ioctls [2]. Unfortunately such library is still not available. And same question about synchronizing format of sensor and FIMC pads. I make ov2640 work, but if did not call media-ctl for sensor, format of FIMC sink pad and format of sensor source pad different. I think I missed something, but reading other sources did not help. As I explained previously, s3c-fimc is supposed to synchronize format with the sensor subdev. Have you got pad level get_fmt callback implemented in the ov2640 driver ? Could you post your 'media-ctl -p' output, run right after the system boot ? [1] http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-subdev-g-frame-interval.html [2] http://git.linuxtv.org/v4l-utils.git/tree/ - From 04b88737f65f772f8b375234a92c7cdd481eac1b Mon Sep 17 00:00:00 2001 From: Andrey Gusakov dron_...@mail.ru Date: Mon, 5 Nov 2012 15:50:23 +0400 Subject: [PATCH] S3C-FIMC: add effect controls SN: I prefer using s3c-camif name, FIMC appears only in later version of the SoCs. Also would be nice to put at least some brief description why this patch is needed. Signed-off-by: Andrey Gusakov dron_...@mail.ru --- drivers/media/platform/s3c-camif/camif-capture.c | 58 -- drivers/media/platform/s3c-camif/camif-core.h|5 ++ drivers/media/platform/s3c-camif/camif-regs.c| 38 ++ drivers/media/platform/s3c-camif/camif-regs.h|6 ++- 4 files changed, 89 insertions(+), 18 deletions(-) diff --git a/drivers/media/platform/s3c-camif/camif-capture.c b/drivers/media/platform/s3c-camif/camif-capture.c index ca31c45..046ebf6 100644 --- a/drivers/media/platform/s3c-camif/camif-capture.c +++ b/drivers/media/platform/s3c-camif/camif-capture.c @@ -81,6 +81,9 @@ static int s3c_camif_hw_init(struct camif_dev *camif,
Re: S3C244X/S3C64XX SoC camera host interface driver questions
Hi. On Thu, Nov 8, 2012 at 1:57 AM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: On 11/06/2012 10:34 PM, Andrey Gusakov wrote: Hi. Does the sensor still hang after 0x2f is written to REG_GRCOM instead ? Work! I'm looking at drivers/media/usb/gspca/m5602/m5602_ov9650.h It use significantly different init sequence. Some of settings described in Application note for ov9650, some look like magic. I guess there are many ways the sensor can be configured initially. I'd like to keep this initialization sequence as thin as possible, and to move relevant settings to corresponding v4l2 controls. Then after v4l2_control_handler_setup() is called, following the initial register list write, the sensor would be configured into some known state. I realize it might be more difficult in practice than it sounds now. :-) Do you have CONFIG_PM_RUNTIME enabled ? Can you try and see it works if you enable it, without additional changes to the clock handling ? Work. With CONFIG_PM_RUNTIME and without enabling CLK_GATE at probe. Ok, thanks. I will add the missing CONFIG_PM_RUNTIME dependency in Kconfig. The driver has to have PM_RUNTIME enabled since on s3c64xx SoCs there are power domains and the camera power domain needs to be enabled for the CAMIF operation. The pm_runtime_* calls in the driver are supposed to ensure that. I wonder why it works for you without PM_RUNTIME, i.e. how comes the power domain is enabled. It is supposed to be off by default. DS says that all power domaint are on after reset. My bootloader did not switch then off. So when linux start everything is on. CONFIG_PM_RUNTIME was disabled, so nothing switch them off in linux too. I hope to eventually prepare the ov9650 sensor driver for mainline. Your help in making it ready for VER=0x52 would be very much appreciated. :-) I'll try to helpful. Next step is to make ov2460 work. For now I can only recommend you to make the ov2460 driver more similar to the ov9650 one. Thanks, I'll try. P.S. I add support of image effects just for fun. And found in DS that s3c2450 also support effects. It's FIMC in-between of 2440 and 6400/6410. Does anyone have s3c2450 hardware to test it? Patches adding image effect are welcome. I'm bit to busy to play with these things, other than I don't have hardware to test it. I wasn't really aware of CAMIF in s3c2450. I think a separate variant data structure would need to be defined for s3c2450. If anyone ever needs it it could be added easily. For now I'll pretend this version doesn't exist. :-) Attached. I often get VIDIOC_QUERYCAP: failed: Inappropriate ioctl for device or system error: Inappropriate ioctl for device Is it because of not implemented set/get framerate func? How this should work? I mean framerate heavy depend of sensor's settings. So set/get framerate call to fimc should get/set framerate from sensor. What is mechanism of such things? And same question about synchronizing format of sensor and FIMC pads. I make ov2640 work, but if did not call media-ctl for sensor, format of FIMC sink pad and format of sensor source pad different. I think I missed something, but reading other sources did not help. Thanks. Best regards. 0001-S3C-FIMC-add-effect-controls.patch Description: Binary data
Re: S3C244X/S3C64XX SoC camera host interface driver questions
On 11/06/2012 10:34 PM, Andrey Gusakov wrote: Hi. Does the sensor still hang after 0x2f is written to REG_GRCOM instead ? Work! I'm looking at drivers/media/usb/gspca/m5602/m5602_ov9650.h It use significantly different init sequence. Some of settings described in Application note for ov9650, some look like magic. I guess there are many ways the sensor can be configured initially. I'd like to keep this initialization sequence as thin as possible, and to move relevant settings to corresponding v4l2 controls. Then after v4l2_control_handler_setup() is called, following the initial register list write, the sensor would be configured into some known state. I realize it might be more difficult in practice than it sounds now. :-) Do you have CONFIG_PM_RUNTIME enabled ? Can you try and see it works if you enable it, without additional changes to the clock handling ? Work. With CONFIG_PM_RUNTIME and without enabling CLK_GATE at probe. Ok, thanks. I will add the missing CONFIG_PM_RUNTIME dependency in Kconfig. The driver has to have PM_RUNTIME enabled since on s3c64xx SoCs there are power domains and the camera power domain needs to be enabled for the CAMIF operation. The pm_runtime_* calls in the driver are supposed to ensure that. I wonder why it works for you without PM_RUNTIME, i.e. how comes the power domain is enabled. It is supposed to be off by default. I hope to eventually prepare the ov9650 sensor driver for mainline. Your help in making it ready for VER=0x52 would be very much appreciated. :-) I'll try to helpful. Next step is to make ov2460 work. For now I can only recommend you to make the ov2460 driver more similar to the ov9650 one. Thanks, I'll try. P.S. I add support of image effects just for fun. And found in DS that s3c2450 also support effects. It's FIMC in-between of 2440 and 6400/6410. Does anyone have s3c2450 hardware to test it? Patches adding image effect are welcome. I'm bit to busy to play with these things, other than I don't have hardware to test it. I wasn't really aware of CAMIF in s3c2450. I think a separate variant data structure would need to be defined for s3c2450. If anyone ever needs it it could be added easily. For now I'll pretend this version doesn't exist. :-) -- Regards, Sylwester -- 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: S3C244X/S3C64XX SoC camera host interface driver questions
Hi. Does the sensor still hang after 0x2f is written to REG_GRCOM instead ? Work! I'm looking at drivers/media/usb/gspca/m5602/m5602_ov9650.h It use significantly different init sequence. Some of settings described in Application note for ov9650, some look like magic. Do you have CONFIG_PM_RUNTIME enabled ? Can you try and see it works if you enable it, without additional changes to the clock handling ? Work. With CONFIG_PM_RUNTIME and without enabling CLK_GATE at probe. I hope to eventually prepare the ov9650 sensor driver for mainline. Your help in making it ready for VER=0x52 would be very much appreciated. :-) I'll try to helpful. Next step is to make ov2460 work. For now I can only recommend you to make the ov2460 driver more similar to the ov9650 one. Thanks, I'll try. P.S. I add support of image effects just for fun. And found in DS that s3c2450 also support effects. It's FIMC in-between of 2440 and 6400/6410. Does anyone have s3c2450 hardware to test it? -- 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: S3C244X/S3C64XX SoC camera host interface driver questions
Hi. But documentation on ov9650 is too conflicting and did not cover all registers used in driver. Do you mean the OV9650 datasheet, version 1.3, from September 24, 2004 ? Yes. Also I have datasheet version 1.91 from January 28, 2005 and Application note 1.1 from 7 December 2004 All can be found here [1]. It seems there is different versions of sensor exist. With VER=0x50 and 0x52. I have second one. What resolution are you testing with ? 320x240. Are you using media-ctl to configure resolution on the camif and sensor subdev ? I'm using GStreamer: gst-launch -v v4l2src device=/dev/video0 \ ! video/x-raw-yuv, width=320, height=240 \ ! ffmpegcolorspace \ ! fbdevsink AFAIR, in the s3c-camif-v3.5 branch there was a bug that the CAMIF input resolution was not being properly set to what was reported by the sensor driver (default s3c-camif resolution is 640 x 480). The s3c-camif driver is supposed to get format from a sensor subdev and set it on the S3C-CAMIF subdev, upon image sensor subdev registration. Please see function camif_register_sensor() for details. The above issue should be fixed in this branch: [1] http://git.linuxtv.org/snawrocki/media.git/shortlog/refs/heads/s3c-camif Also, it could be verified by setting the formats with media-ctl manually, before running gst-launch, i.e. media-ctl --set-v4l2 'OV9650:0 [fmt: YUYV2X8/320x240]' media-ctl --set-v4l2 'S3C-CAMIF:0 [fmt: YUYV2X8/320x240]' with your current kernel and the s3c-camif driver. media-ctl was integrated in the OSELAS mini2440 BSP and probably is also in the mini6440 version. Thanks. I'll try it. media-ctl from OpenEmbedded for some reason don't like this params. And what kernel version is it ? 3.6.0-rc3 with some modifications for mini6410 devboard. Have no time to move my stuff to last samsung kernel. OK, it's recent enough. The patches from s3c-camif branch should apply cleanly. Can you measure the frequency of the master clock that CAMIF provides to the sensor ? 16.67 MHz. As i understand this is limitation of divider. Min clock is HCLKx2 (266) / 16 = 16.67 in my case. PCLK is near 4 MHz. Looks fine (16.625). :) I spend two days trying to fix it, and now I'm out of ideas. May be you can help me. I have some questions. Did you have to invert some of camera signals (VSYNC, HREF, PCLK)? Maybe you had to make some hardware modifications? (i use CAM130 module from FriendlyARM). I'm also using CAM130, attached to mini2440 board without any hardware modifications. Tomasz, (added at Cc) tested the driver on mini6410 and it worked with same camera module. VSYNC, PCLK, etc. configuration is specified in the board patch (as in the below branch). Are you using this version of patches: http://git.linuxtv.org/snawrocki/media.git/shortlog/refs/heads/s3c-camif ? I'm using patches from https://github.com/snawrocki/linux/commits/s3c-camif-v3.5 wich was in your mail to samsung maillist. I suggest you to update to the s3c-camif branch as above, it includes some bug fixes. Sorry, I don't have exact patch for your issue handy right now. I just try this branch. No luck. Now it fails on __ov965x_set_params while writing some registers: ... OV9650: i2c_write: 0x40 : 0xc1. ret: 2 OV9650: i2c_write: 0x29 : 0x3f. ret: 2 OV9650: i2c_write: 0x0F : 0x43. ret: -6 ... If I comment out exits on this errors, following writes in sensors give -6 (ENXIO) or -111 (ECONNREFUSED) erros. Seems sensors hung after write to some registers. I've also added at Cc In-Bae Jeong, who had successfully used the driver on s3c6410 based board. However I'm not really sure now which board exactly was it. I'm using mini6410. But i think there is only one way sensor can be connected to FIMC. Some differents may be in Reset and Power-down signals, but not in interface. Yes, right. But since I2C communication works, the GPIOs and the clock should be fine. It looks like there is a mismatch in the sensor and the CAMIF registers configuration. P.S. Try to connect ov2640, but seems it need some modifications in FIMC driver to be connected thrue soc_camera_link. Hmm, this is a general problem in the v4l2 core code. The are two slightly incompatible interfaces that sensor subdevs are using. There were attempts to make soc_camera subdevs usable with non-soc_camera host drivers, but it is not finished yet. I could try to look at that, but I can't promise when that happens. There are pad level ops needed in the ov2640 driver - in addition to or instead of g/s/try_mbus_fmt. Regulator supply names are not supposed to be passed through platform data, those should be defined with fixed names as specified in the sensor datasheet and board code should be providing required regulator supply names or the dummy regulator should be used. IMO passing regulator supply names through platform data is the regulator API misuse. We need to resolve this issue at the v4l2 core
Re: S3C244X/S3C64XX SoC camera host interface driver questions
Hi, On 11/05/2012 10:44 AM, Andrey Gusakov wrote: But documentation on ov9650 is too conflicting and did not cover all registers used in driver. Do you mean the OV9650 datasheet, version 1.3, from September 24, 2004 ? Yes. Also I have datasheet version 1.91 from January 28, 2005 and Application note 1.1 from 7 December 2004 All can be found here [1]. It seems there is different versions of sensor exist. With VER=0x50 and 0x52. I have second one. Hmm, in my case VER was 0x50. PID, VER = 0x96, 0x50. And this a default value after reset according to the datasheet, ver. 1.3. For ver. 1.91 it is PID, VER = 0x96, 0x52. Perhaps it just indicates ov9652 sensor ov9652. Obviously I didn't test the driver with this one. Possibly the differences can be resolved by comparing the documentation. Not sure if those are significant and how much it makes sense to have single driver for both sensor versions. I'll try to have a look at that. ... Are you using media-ctl to configure resolution on the camif and sensor subdev ? I'm using GStreamer: gst-launch -v v4l2src device=/dev/video0 \ ! video/x-raw-yuv, width=320, height=240 \ ! ffmpegcolorspace \ ! fbdevsink AFAIR, in the s3c-camif-v3.5 branch there was a bug that the CAMIF input resolution was not being properly set to what was reported by the sensor driver (default s3c-camif resolution is 640 x 480). The s3c-camif driver is supposed to get format from a sensor subdev and set it on the S3C-CAMIF subdev, upon image sensor subdev registration. Please see function camif_register_sensor() for details. The above issue should be fixed in this branch: [1] http://git.linuxtv.org/snawrocki/media.git/shortlog/refs/heads/s3c-camif Also, it could be verified by setting the formats with media-ctl manually, before running gst-launch, i.e. media-ctl --set-v4l2 'OV9650:0 [fmt: YUYV2X8/320x240]' media-ctl --set-v4l2 'S3C-CAMIF:0 [fmt: YUYV2X8/320x240]' with your current kernel and the s3c-camif driver. media-ctl was integrated in the OSELAS mini2440 BSP and probably is also in the mini6440 version. Thanks. I'll try it. media-ctl from OpenEmbedded for some reason don't like this params. As you might know the development version can be found here: http://git.ideasonboard.org/?p=media-ctl.git;a=summary There has been some change in the command line semantics recently. ... I suggest you to update to the s3c-camif branch as above, it includes some bug fixes. Sorry, I don't have exact patch for your issue handy right now. I just try this branch. No luck. Now it fails on __ov965x_set_params while writing some registers: ... OV9650: i2c_write: 0x40 : 0xc1. ret: 2 OV9650: i2c_write: 0x29 : 0x3f. ret: 2 OV9650: i2c_write: 0x0F : 0x43. ret: -6 ... If I comment out exits on this errors, following writes in sensors give -6 (ENXIO) or -111 (ECONNREFUSED) erros. Seems sensors hung after write to some registers. Hmm, that looks bad. The driver wasn't tested with VER=0x52 and there must be some differences that need to get sorted out. [1] http://roboforum.ru/forum36/topic7835.html -- Regards, Sylwester -- 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: S3C244X/S3C64XX SoC camera host interface driver questions
Hi.
Thanks all!
I make it work! Have to comment out write { REG_GRCOM, 0x3f }, /*
Analog BLC regulator */ and have to enable gate clock for fimc at
probe.
Hmm, in my case VER was 0x50. PID, VER = 0x96, 0x50. And this a default
value
after reset according to the datasheet, ver. 1.3. For ver. 1.91 it is
PID, VER = 0x96, 0x52. Perhaps it just indicates ov9652 sensor ov9652.
Obviously I didn't test the driver with this one. Possibly the differences
can be resolved by comparing the documentation. Not sure if those are
significant and how much it makes sense to have single driver for both
sensor versions. I'll try to have a look at that.
Ok. I also try to compate init sequenses from different sources on web.
Next step is to make ov2460 work.
Best regards.
Andrey.
--
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: S3C244X/S3C64XX SoC camera host interface driver questions
Hi Andrey,
On 11/05/2012 12:11 PM, Andrey Gusakov wrote:
Hi.
Thanks all!
I make it work! Have to comment out write { REG_GRCOM, 0x3f }, /*
Great news!
Does the sensor still hang after 0x2f is written to REG_GRCOM instead ?
Analog BLC regulator */ and have to enable gate clock for fimc at
probe.
Do you have CONFIG_PM_RUNTIME enabled ? Can you try and see it works
if you enable it, without additional changes to the clock handling ?
I hope to eventually prepare the ov9650 sensor driver for mainline. Your
help in making it ready for VER=0x52 would be very much appreciated. :-)
Hmm, in my case VER was 0x50. PID, VER = 0x96, 0x50. And this a default
value
after reset according to the datasheet, ver. 1.3. For ver. 1.91 it is
PID, VER = 0x96, 0x52. Perhaps it just indicates ov9652 sensor ov9652.
Obviously I didn't test the driver with this one. Possibly the differences
can be resolved by comparing the documentation. Not sure if those are
significant and how much it makes sense to have single driver for both
sensor versions. I'll try to have a look at that.
Ok. I also try to compate init sequenses from different sources on web.
Next step is to make ov2460 work.
For now I can only recommend you to make the ov2460 driver more similar
to the ov9650 one.
--
Regards,
Sylwester
--
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: S3C244X/S3C64XX SoC camera host interface driver questions
Hi Andrey, Cc: LMML On 11/04/2012 09:43 PM, Andrey Gusakov wrote: Hi all. I'm testing your FIMC driver on S3C6410 hardware with OV9650 (in plans OV2640). I fixed some register definition, gpio init, fixed IRQ handling for S3C6410. So now i can get test frames from internal pattern generator. But when i try to read from external sensor i got blue or green trash. Does it change when external light conditions change ? Or is it completely random ? Yes. When it's dark - almost all picture is green. when I light on sensor, picture become more noisy with more blue pixels. If i comment out ov965x_init_regs write to sensor, I get black and white noise, like on TV when no signal. My opinion is there is some mistmatch in formats between sensor and FIMC. Yes, I also suspect this is the root cause. But documentation on ov9650 is too conflicting and did not cover all registers used in driver. Do you mean the OV9650 datasheet, version 1.3, from September 24, 2004 ? What resolution are you testing with ? 320x240. Are you using media-ctl to configure resolution on the camif and sensor subdev ? I'm using GStreamer: gst-launch -v v4l2src device=/dev/video0 \ ! video/x-raw-yuv, width=320, height=240 \ ! ffmpegcolorspace \ ! fbdevsink AFAIR, in the s3c-camif-v3.5 branch there was a bug that the CAMIF input resolution was not being properly set to what was reported by the sensor driver (default s3c-camif resolution is 640 x 480). The s3c-camif driver is supposed to get format from a sensor subdev and set it on the S3C-CAMIF subdev, upon image sensor subdev registration. Please see function camif_register_sensor() for details. The above issue should be fixed in this branch: [1] http://git.linuxtv.org/snawrocki/media.git/shortlog/refs/heads/s3c-camif Also, it could be verified by setting the formats with media-ctl manually, before running gst-launch, i.e. media-ctl --set-v4l2 'OV9650:0 [fmt: YUYV2X8/320x240]' media-ctl --set-v4l2 'S3C-CAMIF:0 [fmt: YUYV2X8/320x240]' with your current kernel and the s3c-camif driver. media-ctl was integrated in the OSELAS mini2440 BSP and probably is also in the mini6440 version. And what kernel version is it ? 3.6.0-rc3 with some modifications for mini6410 devboard. Have no time to move my stuff to last samsung kernel. OK, it's recent enough. The patches from s3c-camif branch should apply cleanly. Can you measure the frequency of the master clock that CAMIF provides to the sensor ? 16.67 MHz. As i understand this is limitation of divider. Min clock is HCLKx2 (266) / 16 = 16.67 in my case. PCLK is near 4 MHz. Looks fine (16.625). :) I spend two days trying to fix it, and now I'm out of ideas. May be you can help me. I have some questions. Did you have to invert some of camera signals (VSYNC, HREF, PCLK)? Maybe you had to make some hardware modifications? (i use CAM130 module from FriendlyARM). I'm also using CAM130, attached to mini2440 board without any hardware modifications. Tomasz, (added at Cc) tested the driver on mini6410 and it worked with same camera module. VSYNC, PCLK, etc. configuration is specified in the board patch (as in the below branch). Are you using this version of patches: http://git.linuxtv.org/snawrocki/media.git/shortlog/refs/heads/s3c-camif ? I'm using patches from https://github.com/snawrocki/linux/commits/s3c-camif-v3.5 wich was in your mail to samsung maillist. I suggest you to update to the s3c-camif branch as above, it includes some bug fixes. Sorry, I don't have exact patch for your issue handy right now. I've also added at Cc In-Bae Jeong, who had successfully used the driver on s3c6410 based board. However I'm not really sure now which board exactly was it. I'm using mini6410. But i think there is only one way sensor can be connected to FIMC. Some differents may be in Reset and Power-down signals, but not in interface. Yes, right. But since I2C communication works, the GPIOs and the clock should be fine. It looks like there is a mismatch in the sensor and the CAMIF registers configuration. P.S. Try to connect ov2640, but seems it need some modifications in FIMC driver to be connected thrue soc_camera_link. Hmm, this is a general problem in the v4l2 core code. The are two slightly incompatible interfaces that sensor subdevs are using. There were attempts to make soc_camera subdevs usable with non-soc_camera host drivers, but it is not finished yet. I could try to look at that, but I can't promise when that happens. There are pad level ops needed in the ov2640 driver - in addition to or instead of g/s/try_mbus_fmt. Regulator supply names are not supposed to be passed through platform data, those should be defined with fixed names as specified in the sensor datasheet and board code should be providing required regulator supply names or the dummy regulator should be used. IMO passing regulator supply names through platform data is the regulator API misuse. We need to resolve this issue
Re: S3C244X/S3C64XX SoC camera host interface driver questions
Hi Andrey, On Sunday 04 of November 2012 23:14:47 Sylwester Nawrocki wrote: Are you using this version of patches: http://git.linuxtv.org/snawrocki/media.git/shortlog/refs/heads/s3c-cam if ? I'm using patches from https://github.com/snawrocki/linux/commits/s3c-camif-v3.5 wich was in your mail to samsung maillist. I suggest you to update to the s3c-camif branch as above, it includes some bug fixes. Sorry, I don't have exact patch for your issue handy right now. Yes, you should definitely try the branch pointed by Sylwester, because the one you originally tested does not contain my fixes for S3C6410. Best regards, Tomasz Figa -- 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
