Re: [early RFC] Device Tree bindings for OMAP3 Camera Subsystem
013/11/3 Sebastian Reichel s...@debian.org:
Hi,
This is an early RFC for omap3isp DT support. For now i just created a
potential DT
binding documentation based on the existing platform data:
Binding for the OMAP3 Camera subsystem with the image signal processor (ISP)
feature.
This is very interesting, I am in the process of transforming an (out
of tree) machine board file into
a device tree description, and I was precisely searching for oma3isp
dt when I saw your mail.
I would be happy to test or help develop any patch aiming at DT
support for omap3isp. I am new to DT, so I
will leave the DT bindings review to people that actually have a clue.
I am looking forward to testing patches and bugging you when things break ;)
Regards,
Jean-Philippe François
omap3isp node
-
Required properties:
- compatible: should be ti,omap3isp for OMAP3;
- reg : physical addresses and length of the registers set;
- clocks: list of clock specifiers, corresponding to entries in
clock-names property;
- clock-names : must contain cam_ick, cam_mclk, csi2_96m_fck,
l3_ick entries, matching entries in the clocks property;
- interrupts: must contain mmu interrupt;
- ti,iommu : phandle to isp mmu;
Optional properties:
- VDD_CSIPHY1-supply: regulator for csi phy1
- VDD_CSIPHY2-supply: regulator for csi phy2
- ti,isp-xclk-1 : device(s) attached to ISP's first external clock
- ti,isp-xclk-2 : device(s) attached to ISP's second external clock
device-group subnode
Required properties:
- ti,isp-interface-type : Integer describing the interface type, one of the
following
* 0 = ISP_INTERFACE_PARALLEL
* 1 = ISP_INTERFACE_CSI2A_PHY2
* 2 = ISP_INTERFACE_CCP2B_PHY1
* 3 = ISP_INTERFACE_CCP2B_PHY2
* 4 = ISP_INTERFACE_CSI2C_PHY1
- ti,isp-devices: Array of phandles to devices connected via the
interface
- One of the following configuration nodes (depending on
ti,isp-interface-type)
- ti,ccp2-bus-cfg : CCP2 bus configuration (needed for
ISP_INTERFACE_CCP*)
- ti,parallel-bus-cfg : PARALLEL bus configuration (needed for
ISP_INTERFACE_PARALLEL)
- ti,csi2-bus-cfg : CSI bus configuration (needed for
ISP_INTERFACE_CSI*)
ccp2-bus-cfg subnode
Required properties:
- ti,video-port-clock-divisor : integer; used for video port output clock
control
Optional properties:
- ti,inverted-clock : boolean; clock/strobe signal is inverted
- ti,enable-crc : boolean; enable crc checking
- ti,ccp2-mode-mipi : boolean; port is used in MIPI-CSI1 mode
(default: CCP2 mode)
- ti,phy-layer-is-strobe: boolean; use data/strobe physical layer
(default: data/clock physical layer)
- ti,data-lane-configuration: integer array with position and polarity
information for lane 1 and 2
- ti,clock-lane-configuration : integer array with position and polarity
information for clock lane
parallel-bus-cfg subnode
Required properties:
- ti,data-lane-shift: integer; shift data lanes
by this amount
Optional properties:
- ti,clock-falling-edge : boolean; sample on falling
edge (default: rising edge)
- ti,horizontal-synchronization-active-low : boolean; default: active
high
- ti,vertical-synchronization-active-low: boolean; default: active
high
- ti,data-polarity-ones-complement : boolean; data polarity is
one's complement
csi2-bus-cfg subnode
Required properties:
- ti,video-port-clock-divisor : integer; used for video port output clock
control
Optional properties:
- ti,data-lane-configuration: integer array with position and polarity
information for lane 1 and 2
- ti,clock-lane-configuration : integer array with position and polarity
information for clock lane
- ti,enable-crc : boolean; enable crc checking
Example for Nokia N900
--
omap3isp: isp@480BC000 {
compatible = ti,omap3isp;
reg =
/* OMAP3430+ */
0x480BC000 0x070/* base */
0x480BC100 0x078/* cbuf */
0x480BC400 0x1F0/* cpp2 */
0x480BC600 0x0A8/* ccdc */
0x480BCA00 0x048/* hist */
0x480BCC00 0x060/* h3a */
0x480BCE00 0x0A0/* prev */
0x480BD000 0x0AC/* resz */
0x480BD200 0x0FC/* sbl */
0x480BD400 0x070/* mmu */
;
clocks = cam_ick cam_mclk csi2_96m_fck l3_ick ;
clock-names = cam_ick, cam_mclk, csi2_96m_fck, l3_ick;
interrupts = 24;
ti,iommu = mmu_isp;
ti,isp-xclk-1 =
[RFC] omap3isp : fix image corruption after underrun when using resizer
Hi Laurent, I was able to reliably get corrupted image when placing the pipeline in underrun condition. The pipeline looks like this : YUYV sensor - CCDC - Resizer - V4L output It seems that triggering 'frame sync event' before last line leads to possible corrupted images when using the resizer. With current code, ISP resizer is always configured in oneshot, and must be restarted after each frame. However, has stated by a comment in ispresizer.c, restarting the resizer while a frame is sent to the ccdc leads to corrupted images. The current resizer code takes care of this restart in two places : - in normal situation, when the 'resizer done' IRQ is triggered, a buffer is available and the resizer is restarted in the resizer_isr_buffer function - in underrun situation, no buffer is available when the resizer done irq triggers. After a buffer has eventually been queued, the resizer is restarted on the following frame sync. However, the frame sync event is not generated by the hardware frame sync, but by the VD0 interrupt of the CCDC. But VD0 event is triggered a bit early, since it is configured to trigger after height - 1 lines. It is therefore possible to restart the resizer while a frame's last line is being sent. The following patch configures VD0 to trigger after the last line, and solves the image corruption issue. However, the previous value does not look like an off by one error. What are the reasons to configure VD0 before the last line ? What are the possible issues triggered by a change like this ? Thank you for your comments, Jean-Philippe François Index: b/drivers/media/platform/omap3isp/ispccdc.c === --- a/drivers/media/platform/omap3isp/ispccdc.c +++ b/drivers/media/platform/omap3isp/ispccdc.c @@ -1196,7 +1196,7 @@ /* Generate VD0 on the last line of the image and VD1 on the * 2/3 height line. */ - isp_reg_writel(isp, ((format-height - 2) ISPCCDC_VDINT_0_SHIFT) | + isp_reg_writel(isp, ((format-height - 1) ISPCCDC_VDINT_0_SHIFT) | ((format-height * 2 / 3) ISPCCDC_VDINT_1_SHIFT), OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT); -- 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: OMAP3 ISP change image format
It is my understanding that you should set up the format with media-ctl, and only check the result in your application. In other words, using G/S/TRY_FMT ioctl on the video output nodes won't work. You can try the following pipeline : ov3640 - ccdc - previewer - previewer V4L2 output and set previewer sink pad to bayer and previewer src pad to yuv I don't think you can output rgb565 however. It is only an input format for the CCDC. Anyway, when you use G/S/TRY_FMT ioctl, always check the returned format. 2013/8/20 Tom bassai_...@gmx.net: Hello, I try from my own application out to grab an image with a ov3640 sensor. For this I need to understand the media-api and the isp pipeline correctly. I had problems with the use of media-ctl so I implemented the functionality into my application and it seems to work fine. Without an error I grabbed an image, but it was black. So maybe my format settings are not correctly set. My Question is: For example I want to grab a rgb565 image from my camera sensor and display it on a webpage. my pipeline looks like this: ov3640-ccdc-memory Would it be enough to just set a raw bayer format on the source and sink pads and just the format of the video device (/dev/video2) as rgb565? Regards, Tom -- 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 -- 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] ov10635: Add OmniVision ov10635 SoC camera driver
2013/6/5 Guennadi Liakhovetski g.liakhovet...@gmx.de:
Hi Phil
Thanks for the patch. I'll look at it in more detail hopefully soon
enough... One remark so far to Jean-Philippe's comment:
On Tue, 4 Jun 2013, jean-philippe francois wrote:
2013/6/3 Phil Edworthy phil.edwor...@renesas.com:
Signed-off-by: Phil Edworthy phil.edwor...@renesas.com
---
v2:
- Simplified flow in ov10635_s_ctrl.
- Removed chip ident code - build tested only
drivers/media/i2c/soc_camera/Kconfig |6 +
drivers/media/i2c/soc_camera/Makefile |1 +
drivers/media/i2c/soc_camera/ov10635.c | 1141
3 files changed, 1148 insertions(+)
create mode 100644 drivers/media/i2c/soc_camera/ov10635.c
[snip]
diff --git a/drivers/media/i2c/soc_camera/ov10635.c
b/drivers/media/i2c/soc_camera/ov10635.c
new file mode 100644
index 000..bf08aae
--- /dev/null
+++ b/drivers/media/i2c/soc_camera/ov10635.c
@@ -0,0 +1,1141 @@
[snip]
+/* default register setup */
+static const struct ov10635_reg ov10635_regs_default[] = {
+ { 0x0103, 0x01 }, { 0x301b, 0xff }, { 0x301c, 0xff }, { 0x301a,
0xff },
+ { 0x3011, 0x02 }, /* drive strength reduced to x1 */
+ { 0x6900, 0x0c }, { 0x6901, 0x11 }, { 0x3503, 0x10 }, { 0x3025,
0x03 },
+ { 0x3005, 0x20 }, { 0x3006, 0x91 }, { 0x3600, 0x74 }, { 0x3601,
0x2b },
+ { 0x3612, 0x00 }, { 0x3611, 0x67 }, { 0x3633, 0xca }, { 0x3602,
0x2f },
+ { 0x3603, 0x00 }, { 0x3630, 0x28 }, { 0x3631, 0x16 }, { 0x3714,
0x10 },
+ { 0x371d, 0x01 }, { 0x4300, 0x38 }, { 0x3007, 0x01 }, { 0x3024,
0x01 },
+ { 0x3020, 0x0b }, { 0x3702, 0x0d }, { 0x3703, 0x20 }, { 0x3704,
0x15 },
+ { 0x3709, 0xa8 }, { 0x370c, 0xc7 }, { 0x370d, 0x80 }, { 0x3712,
0x00 },
+ { 0x3713, 0x20 }, { 0x3715, 0x04 }, { 0x381d, 0x40 }, { 0x381c,
0x00 },
+ { 0x3822, 0x50 }, { 0x3824, 0x10 }, { 0x3815, 0x8c }, { 0x3804,
0x05 },
+ { 0x3805, 0x1f }, { 0x3800, 0x00 }, { 0x3801, 0x00 }, { 0x3806,
0x02 },
+ { 0x3807, 0xfd }, { 0x3802, 0x00 }, { 0x3803, 0x2c }, { 0x3808,
0x05 },
+ { 0x3809, 0x00 }, { 0x380a, 0x02 }, { 0x380b, 0xd0 }, { 0x380c,
0x06 },
+ { 0x380d, 0xf6 }, { 0x380e, 0x02 }, { 0x380f, 0xec }, { 0x3813,
0x02 },
+ { 0x3811, 0x08 }, { 0x381f, 0x0c }, { 0x3819, 0x04 }, { 0x3804,
0x01 },
+ { 0x3805, 0x00 }, { 0x3828, 0x03 }, { 0x3829, 0x10 }, { 0x382a,
0x10 },
+ { 0x3621, 0x63 }, { 0x5005, 0x08 }, { 0x56d5, 0x00 }, { 0x56d6,
0x80 },
+ { 0x56d7, 0x00 }, { 0x56d8, 0x00 }, { 0x56d9, 0x00 }, { 0x56da,
0x80 },
+ { 0x56db, 0x00 }, { 0x56dc, 0x00 }, { 0x56e8, 0x00 }, { 0x56e9,
0x7f },
+ { 0x56ea, 0x00 }, { 0x56eb, 0x7f }, { 0x5100, 0x00 }, { 0x5101,
0x80 },
+ { 0x5102, 0x00 }, { 0x5103, 0x80 }, { 0x5104, 0x00 }, { 0x5105,
0x80 },
+ { 0x5106, 0x00 }, { 0x5107, 0x80 }, { 0x5108, 0x00 }, { 0x5109,
0x00 },
+ { 0x510a, 0x00 }, { 0x510b, 0x00 }, { 0x510c, 0x00 }, { 0x510d,
0x00 },
+ { 0x510e, 0x00 }, { 0x510f, 0x00 }, { 0x5110, 0x00 }, { 0x5111,
0x80 },
+ { 0x5112, 0x00 }, { 0x5113, 0x80 }, { 0x5114, 0x00 }, { 0x5115,
0x80 },
+ { 0x5116, 0x00 }, { 0x5117, 0x80 }, { 0x5118, 0x00 }, { 0x5119,
0x00 },
+ { 0x511a, 0x00 }, { 0x511b, 0x00 }, { 0x511c, 0x00 }, { 0x511d,
0x00 },
+ { 0x511e, 0x00 }, { 0x511f, 0x00 }, { 0x56d0, 0x00 }, { 0x5006,
0x24 },
+ { 0x5608, 0x0b }, { 0x52d7, 0x06 }, { 0x528d, 0x08 }, { 0x5293,
0x12 },
+ { 0x52d3, 0x12 }, { 0x5288, 0x06 }, { 0x5289, 0x20 }, { 0x52c8,
0x06 },
+ { 0x52c9, 0x20 }, { 0x52cd, 0x04 }, { 0x5381, 0x00 }, { 0x5382,
0xff },
+ { 0x5589, 0x76 }, { 0x558a, 0x47 }, { 0x558b, 0xef }, { 0x558c,
0xc9 },
+ { 0x558d, 0x49 }, { 0x558e, 0x30 }, { 0x558f, 0x67 }, { 0x5590,
0x3f },
+ { 0x5591, 0xf0 }, { 0x5592, 0x10 }, { 0x55a2, 0x6d }, { 0x55a3,
0x55 },
+ { 0x55a4, 0xc3 }, { 0x55a5, 0xb5 }, { 0x55a6, 0x43 }, { 0x55a7,
0x38 },
+ { 0x55a8, 0x5f }, { 0x55a9, 0x4b }, { 0x55aa, 0xf0 }, { 0x55ab,
0x10 },
+ { 0x5581, 0x52 }, { 0x5300, 0x01 }, { 0x5301, 0x00 }, { 0x5302,
0x00 },
+ { 0x5303, 0x0e }, { 0x5304, 0x00 }, { 0x5305, 0x0e }, { 0x5306,
0x00 },
+ { 0x5307, 0x36 }, { 0x5308, 0x00 }, { 0x5309, 0xd9 }, { 0x530a,
0x00 },
+ { 0x530b, 0x0f }, { 0x530c, 0x00 }, { 0x530d, 0x2c }, { 0x530e,
0x00 },
+ { 0x530f, 0x59 }, { 0x5310, 0x00 }, { 0x5311, 0x7b }, { 0x5312,
0x00 },
+ { 0x5313, 0x22 }, { 0x5314, 0x00 }, { 0x5315, 0xd5 }, { 0x5316,
0x00 },
+ { 0x5317, 0x13 }, { 0x5318, 0x00 }, { 0x5319, 0x18 }, { 0x531a,
0x00 },
+ { 0x531b, 0x26 }, { 0x531c, 0x00 }, { 0x531d, 0xdc }, { 0x531e,
0x00 },
+ { 0x531f, 0x02 }, { 0x5320, 0x00 }, { 0x5321, 0x24 }, { 0x5322,
0x00 },
+ { 0x5323, 0x56
Re: [PATCH v2] ov10635: Add OmniVision ov10635 SoC camera driver
2013/6/3 Phil Edworthy phil.edwor...@renesas.com:
Signed-off-by: Phil Edworthy phil.edwor...@renesas.com
---
v2:
- Simplified flow in ov10635_s_ctrl.
- Removed chip ident code - build tested only
drivers/media/i2c/soc_camera/Kconfig |6 +
drivers/media/i2c/soc_camera/Makefile |1 +
drivers/media/i2c/soc_camera/ov10635.c | 1141
3 files changed, 1148 insertions(+)
create mode 100644 drivers/media/i2c/soc_camera/ov10635.c
diff --git a/drivers/media/i2c/soc_camera/Kconfig
b/drivers/media/i2c/soc_camera/Kconfig
index 23d352f..db97ee6 100644
--- a/drivers/media/i2c/soc_camera/Kconfig
+++ b/drivers/media/i2c/soc_camera/Kconfig
@@ -74,6 +74,12 @@ config SOC_CAMERA_OV9740
help
This is a ov9740 camera driver
+config SOC_CAMERA_OV10635
+ tristate ov10635 camera support
+ depends on SOC_CAMERA I2C
+ help
+ This is an OmniVision ov10635 camera driver
+
config SOC_CAMERA_RJ54N1
tristate rj54n1cb0c support
depends on SOC_CAMERA I2C
diff --git a/drivers/media/i2c/soc_camera/Makefile
b/drivers/media/i2c/soc_camera/Makefile
index d0421fe..f3d3403 100644
--- a/drivers/media/i2c/soc_camera/Makefile
+++ b/drivers/media/i2c/soc_camera/Makefile
@@ -10,5 +10,6 @@ obj-$(CONFIG_SOC_CAMERA_OV6650) += ov6650.o
obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o
obj-$(CONFIG_SOC_CAMERA_OV9640)+= ov9640.o
obj-$(CONFIG_SOC_CAMERA_OV9740)+= ov9740.o
+obj-$(CONFIG_SOC_CAMERA_OV10635) += ov10635.o
obj-$(CONFIG_SOC_CAMERA_RJ54N1)+= rj54n1cb0c.o
obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o
diff --git a/drivers/media/i2c/soc_camera/ov10635.c
b/drivers/media/i2c/soc_camera/ov10635.c
new file mode 100644
index 000..bf08aae
--- /dev/null
+++ b/drivers/media/i2c/soc_camera/ov10635.c
@@ -0,0 +1,1141 @@
+/*
+ * OmniVision OV10635 Camera Driver
+ *
+ * Copyright (C) 2013 Phil Edworthy
+ * Copyright (C) 2013 Renesas Electronics
+ *
+ * This driver has been tested at QVGA, VGA and 720p, and 1280x800 at up to
+ * 30fps and it should work at any resolution in between and any frame rate
+ * up to 30fps.
+ *
+ * FIXME:
+ * Horizontal flip (mirroring) does not work correctly. The image is
flipped,
+ * but the colors are wrong.
+ *
+ * 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.
+ *
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/v4l2-mediabus.h
+#include linux/videodev2.h
+
+#include media/soc_camera.h
+#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
+
+/* Register definitions */
+#defineOV10635_VFLIP 0x381c
+#define OV10635_VFLIP_ON (0x3 6)
+#define OV10635_VFLIP_SUBSAMPLE0x1
+#defineOV10635_HMIRROR 0x381d
+#define OV10635_HMIRROR_ON 0x3
+#define OV10635_PID0x300a
+#define OV10635_VER0x300b
+
+/* IDs */
+#define OV10635_VERSION_REG0xa635
+#define OV10635_VERSION(pid, ver) (((pid) 8) | ((ver) 0xff))
+
+#define OV10635_SENSOR_WIDTH 1312
+#define OV10635_SENSOR_HEIGHT 814
+
+#define OV10635_MAX_WIDTH 1280
+#define OV10635_MAX_HEIGHT 800
+
+struct ov10635_color_format {
+ enum v4l2_mbus_pixelcode code;
+ enum v4l2_colorspace colorspace;
+};
+
+struct ov10635_reg {
+ u16 reg;
+ u8 val;
+};
+
+struct ov10635_priv {
+ struct v4l2_subdev subdev;
+ struct v4l2_ctrl_handlerhdl;
+ int xvclk;
+ int fps_numerator;
+ int fps_denominator;
+ const struct ov10635_color_format *cfmt;
+ int width;
+ int height;
+};
+
+/* default register setup */
+static const struct ov10635_reg ov10635_regs_default[] = {
+ { 0x0103, 0x01 }, { 0x301b, 0xff }, { 0x301c, 0xff }, { 0x301a, 0xff
},
+ { 0x3011, 0x02 }, /* drive strength reduced to x1 */
+ { 0x6900, 0x0c }, { 0x6901, 0x11 }, { 0x3503, 0x10 }, { 0x3025, 0x03
},
+ { 0x3005, 0x20 }, { 0x3006, 0x91 }, { 0x3600, 0x74 }, { 0x3601, 0x2b
},
+ { 0x3612, 0x00 }, { 0x3611, 0x67 }, { 0x3633, 0xca }, { 0x3602, 0x2f
},
+ { 0x3603, 0x00 }, { 0x3630, 0x28 }, { 0x3631, 0x16 }, { 0x3714, 0x10
},
+ { 0x371d, 0x01 }, { 0x4300, 0x38 }, { 0x3007, 0x01 }, { 0x3024, 0x01
},
+ { 0x3020, 0x0b }, { 0x3702, 0x0d }, { 0x3703, 0x20 }, { 0x3704, 0x15
},
+ { 0x3709, 0xa8 }, { 0x370c, 0xc7 }, { 0x370d, 0x80
Re: omap3 : isp clock a : Difference between dmesg frequency and actual frequency with 3.9
2013/5/15 jean-philippe francois jp.franc...@cynove.com: Hi, I am working on a dm3730 based camera. The sensor input clock is provided by the cpu via the CAM_XCLK pin. Here is the corresponding log : [9.115966] Entering cam_set_xclk [9.119781] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz [9.121337] ov10x33 1-0010: sensor id : 0xa630 [ 10.293640] Entering cam_set_xclk [ 10.297149] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz [ 10.393920] Entering cam_set_xclk [ 10.397979] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz However, when mesured on the actual pin, the frequency is around 30 MHz The crystal clock is 19.2 MHz All this was correct with 3.6.11. It seems the dpll4_m5_ck is not correctly set, 3.6.11 code in isp.c (without error handling) r = clk_set_rate(isp-clock[ISP_CLK_DPLL4_M5_CK], CM_CAM_MCLK_HZ/divisor); ... r = clk_enable(isp-clock[ISP_CLK_CAM_MCLK]); 3.9 code in isp.c (without error handling) r = clk_set_rate(isp-clock[ISP_CLK_CAM_MCLK], CM_CAM_MCLK_HZ/divisor); Jean-Philippe Francois -- 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: omap3 : isp clock a : Difference between dmesg frequency and actual frequency with 3.9
2013/5/15 jean-philippe francois jp.franc...@cynove.com: Hi, I am working on a dm3730 based camera. The sensor input clock is provided by the cpu via the CAM_XCLK pin. Here is the corresponding log : [9.115966] Entering cam_set_xclk [9.119781] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz [9.121337] ov10x33 1-0010: sensor id : 0xa630 [ 10.293640] Entering cam_set_xclk [ 10.297149] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz [ 10.393920] Entering cam_set_xclk [ 10.397979] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz However, when mesured on the actual pin, the frequency is around 30 MHz The crystal clock is 19.2 MHz All this was correct with 3.6.11. Sorry for the resend, wrong tab and enter key sequence in gmail ... It seems the dpll4_m5_ck is not correctly set, 3.6.11 code in isp.c (without error handling) r = clk_set_rate(isp-clock[ISP_CLK_DPLL4_M5_CK], CM_CAM_MCLK_HZ/divisor); ... r = clk_enable(isp-clock[ISP_CLK_CAM_MCLK]); 3.9 code in isp.c (without error handling) r = clk_set_rate(isp-clock[ISP_CLK_CAM_MCLK], CM_CAM_MCLK_HZ/divisor); r = clk_prepare_enable(isp-clock[ISP_CLK_CAM_MCLK]); The PLL settings ie multiplier and divisor are the same in each case, but the dmesg output differ : Here is what happens when isp_enable_clock is called on 3.6 3.6 [ 10.133697] Entering cam_set_xclk [ 10.137573] clock: clksel_round_rate_div: dpll4_m5_ck target_rate 17280 [ 10.137573] clock: new_div = 5, new_rate = 17280 [ 10.137603] clock: dpll4_m5_ck: set rate to 17280 [ 10.138061] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz 3.9 [9.095581] Entering cam_set_xclk [9.102661] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz So the frequency setting register are correctly set, but the actual output frequency is not. maybe dpll4 is not correctly locked ? I will also check isp_enable_clock is really called. But I suppose it is, because except for the frequency, everything is working correctly. -- 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: omap3 : isp clock a : Difference between dmesg frequency and actual frequency with 3.9
2013/5/16 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Jean-Philippe,
On Thursday 16 May 2013 10:21:14 jean-philippe francois wrote:
2013/5/15 jean-philippe francois jp.franc...@cynove.com:
Hi,
I am working on a dm3730 based camera.
The sensor input clock is provided by the cpu via the CAM_XCLK pin.
Here is the corresponding log :
[9.115966] Entering cam_set_xclk
[9.119781] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to
24685714 Hz
[9.121337] ov10x33 1-0010: sensor id : 0xa630
[ 10.293640] Entering cam_set_xclk
[ 10.297149] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz
[ 10.393920] Entering cam_set_xclk
[ 10.397979] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to
24685714 Hz
However, when mesured on the actual pin, the frequency is around 30 MHz
The crystal clock is 19.2 MHz
All this was correct with 3.6.11.
Sorry for the resend, wrong tab and enter key sequence in gmail ...
It seems the dpll4_m5_ck is not correctly set,
3.6.11 code in isp.c (without error handling)
r = clk_set_rate(isp-clock[ISP_CLK_DPLL4_M5_CK],
CM_CAM_MCLK_HZ/divisor);
...
r = clk_enable(isp-clock[ISP_CLK_CAM_MCLK]);
3.9 code in isp.c (without error handling)
r = clk_set_rate(isp-clock[ISP_CLK_CAM_MCLK],
CM_CAM_MCLK_HZ/divisor);
r = clk_prepare_enable(isp-clock[ISP_CLK_CAM_MCLK]);
The PLL settings ie multiplier and divisor are the same in each case,
but the dmesg output differ :
Here is what happens when isp_enable_clock is called on 3.6
3.6
[ 10.133697] Entering cam_set_xclk
[ 10.137573] clock: clksel_round_rate_div: dpll4_m5_ck
target_rate 17280
[ 10.137573] clock: new_div = 5, new_rate = 17280
[ 10.137603] clock: dpll4_m5_ck: set rate to 17280
[ 10.138061] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to
24685714 Hz
3.9
[9.095581] Entering cam_set_xclk
[9.102661] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to
24685714 Hz
So the frequency setting register are correctly set, but the actual
output frequency is not.
maybe dpll4 is not correctly locked ? I will also check
isp_enable_clock is really called.
But I suppose it is, because except for the frequency, everything is
working correctly.
Does the following patch fix the issue ?
Hi Laurent, thank you for your help.
I am on a dm3730, si I already had the back propagation thing.
I tried the patch anyway, but it did not solve the issue.
If I look at the registers, on both version :
0x48004d44 contains 0x04816807 whiche gives a dpll4 frequency of 864 MHz
0x48004f40 contains 0x5 which gives a cam_mclk frequency of 172,8 MHz
0x480bc050 (ISP.TCTRL_CTRL) contains 0x7 which should give a 24 MHz frequency
In my dmesg output, I never see a message like the following but for dpll4_ck.
omap3_noncore_dpll_set_rate: dpll5_ck: set rate: locking rate to 12000.
I wonder why.
commit 577f8ea9ba7b1276096713b8148b3a8fca96d805
Author: Laurent Pinchart laurent.pinch...@ideasonboard.com
Date: Thu May 16 13:15:40 2013 +0200
ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to dpll4_m5
on all OMAP3 platforms
Commit 7b2e1277598e4187c9be3e61fd9b0f0423f97986 (ARM: OMAP3: clock:
Back-propagate rate change from cam_mclk to dpll4_m5) enabled clock
rate back-propagation from cam_mclk do dpll4_m5 on OMAP3630 only.
Perform back-propagation on other OMAP3 platforms as well.
Reported-by: Jean-Philippe François jp.franc...@cynove.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..c21065a 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -418,7 +418,8 @@ static struct clk_hw_omap dpll4_m5x2_ck_hw = {
.clkdm_name = dpll4_clkdm,
};
-DEFINE_STRUCT_CLK(dpll4_m5x2_ck, dpll4_m5x2_ck_parent_names,
dpll4_m5x2_ck_ops);
+DEFINE_STRUCT_CLK_FLAGS(dpll4_m5x2_ck, dpll4_m5x2_ck_parent_names,
+ dpll4_m5x2_ck_ops, CLK_SET_RATE_PARENT);
static struct clk dpll4_m5x2_ck_3630 = {
.name = dpll4_m5x2_ck,
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
omap3 : isp clock a : Difference between dmesg frequency and actual frequency with 3.9
Hi, I am working on a dm3730 based camera. The sensor input clock is provided by the cpu via the CAM_XCLK pin. Here is the corresponding log : [9.115966] Entering cam_set_xclk [9.119781] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz [9.121337] ov10x33 1-0010: sensor id : 0xa630 [ 10.293640] Entering cam_set_xclk [ 10.297149] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz [ 10.393920] Entering cam_set_xclk [ 10.397979] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 24685714 Hz However, when mesured on the actual pin, the frequency is around 30 MHz The crystal clock is 19.2 MHz All this was correct with 3.6.11. Jean-Philippe Francois -- 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: omap3-isp : panic using previewer from V4L input
Hi Laurent, I have a beagle xm board, but no sensor board. Is it possible to have the omap3-isp initialised ? I would like to try my program on a beagle board to eliminate any hardware related problem. From the board file in mainline kernel, it seems omap3_init_camera is not called, do you know any kernel tree where isp is initialized for beagle board ? Thank you, Jean-Philippe François 2013/5/7 jean-philippe francois jp.franc...@cynove.com: 2013/5/7 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Jean-Philippe, (CC'ed linux-omap) On Monday 06 May 2013 10:59:07 jean-philippe francois wrote: Hi, I am trying to use the previewer to debayer pictures coming from the filesystem instead of the capture hardware. The media-ctl links are as follows : preview V4L input - preview pad 0 (sink), preview pad 1(src) -preview V4L output. Input output format is set via media-ctl for the preview element, and via the V4L2 api for the V4L2 file descriptors. I am using USERPTR buffer allocated via memalign, and the application goes like this : REQBUFS 1 buf on on input REQBUFS 1 buf on output alloc buffers QBUF on input QBUF on output STREAMON on output STREAMON on input DQBUF on output. The board either panics or hangs (though HUNG_TASK_DETECTION and SOFT_LOCKUP_DETECTION is set) Does it happen every time you run the application, including on the first run after a cold boot ? Yes, every time. Previewer usage in device to memory mode works fine. Tested on 3.6.11 and 3.9 with the same results. The only difference observed so far between runs is that sometimes the board hangs without anything printed on the console. Please find attached the panic log, and the application code. (log inlined) omap3isp omap3isp: can't find source, failing now omap3isp omap3isp: can't find source, failing now Those are harmless warnings. I have a fix for them, I'll repost it. [ cut here ] Kernel BUG at c019bb1c [verbose debug info unavailable] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM Modules linked in: omap3_isp ov10630(O) CPU: 0Tainted: G O (3.9.0 #3) PC is at omap3_l3_app_irq+0x3c/0xbc L3 APP interconnect timeout errors are not supposed to happen. This is the first time I see one. Maybe someone on the linux-omap list will have some clues regarding how to debug this. LR is at handle_irq_event_percpu+0x28/0x10c pc : [c019bb1c]lr : [c006b354]psr: 2193 sp : c0507e58 ip : 0006 fp : r10: cf804dc0 r9 : 9e65 r8 : 0020 r7 : r6 : 1000 r5 : r4 : cf87f3c0 r3 : r2 : 1000 r1 : cf8ffc80 r0 : 1000 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 8fa80019 DAC: 0015 Process swapper (pid: 0, stack limit = 0xc0506230) Stack: (0xc0507e58 to 0xc0508000) 7e40: 0002 cf87f3c0 7e60:001a c006b354 cf804dc0 cf87f3c0 cf804dc0 c0506000 7e80:cf87f3c0 c0507f0c 0020 9e65 c054d640 c006b490 cf804dc0 c0507f80 7ea0: c006da68 001a c006ac44 001a c000ebc8 000a c0507ed8 7ec0:001a c0008594 c054d600 c003400c 6113 c000df00 0001 c054d600 7ee0:0101 c0506000 0002 c0507fb4 0020 9e65 7f00:c054d640 c0526f28 c0507f20 c054d600 c003400c 6113 7f20:cf805c40 c0506000 c0511c98 c0507fb4 80004059 0035 7f40:c0507fb4 80004059 413fc082 c003440c 0035 c000ebcc 7f60:0025 c0507f80 0035 c0008594 c0506008 c000ed78 2013 c000df00 7f80:c0547548 c050fb50 0001 c0506000 c050e0d8 c04fb954 c0510844 7fa0:80004059 413fc082 c0507fc8 c0506008 c000ed78 7fc0:2013 c036c958 c04da7a8 c04da344 7fe0:c04fb958 271ae41c 10c53c7d c050e028 80008070 [c019bb1c] (omap3_l3_app_irq+0x3c/0xbc) from [c006b354] (handle_irq_event_percpu+0x28/0x10c) [c006b354] (handle_irq_event_percpu+0x28/0x10c) from [c006b490] (handle_irq_event+0x58/0x74) [c006b490] (handle_irq_event+0x58/0x74) from [c006da68] (handle_level_irq+0xd8/0x110) [c006da68] (handle_level_irq+0xd8/0x110) from [c006ac44] (generic_handle_irq+0x20/0x30) [c006ac44] (generic_handle_irq+0x20/0x30) from [c000ebc8] (handle_IRQ+0x60/0x84) [c000ebc8] (handle_IRQ+0x60/0x84) from [c0008594] (omap3_intc_handle_irq+0x58/0x6c) [c0008594] (omap3_intc_handle_irq+0x58/0x6c) from [c000df00] (__irq_svc+0x40/0x70) Exception stack(0xc0507ed8 to 0xc0507f20) 7ec0: 0001 c054d600 7ee0:0101 c0506000 0002 c0507fb4 0020 9e65 7f00:c054d640 c0526f28 c0507f20 c054d600 c003400c 6113 [c000df00] (__irq_svc+0x40/0x70) from [c003400c] (__do_softirq+0x60/0x184) [c003400c] (__do_softirq+0x60
Re: omap3-isp : panic using previewer from V4L input
2013/5/7 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Jean-Philippe, (CC'ed linux-omap) On Monday 06 May 2013 10:59:07 jean-philippe francois wrote: Hi, I am trying to use the previewer to debayer pictures coming from the filesystem instead of the capture hardware. The media-ctl links are as follows : preview V4L input - preview pad 0 (sink), preview pad 1(src) -preview V4L output. Input output format is set via media-ctl for the preview element, and via the V4L2 api for the V4L2 file descriptors. I am using USERPTR buffer allocated via memalign, and the application goes like this : REQBUFS 1 buf on on input REQBUFS 1 buf on output alloc buffers QBUF on input QBUF on output STREAMON on output STREAMON on input DQBUF on output. The board either panics or hangs (though HUNG_TASK_DETECTION and SOFT_LOCKUP_DETECTION is set) Does it happen every time you run the application, including on the first run after a cold boot ? Yes, every time. Previewer usage in device to memory mode works fine. Tested on 3.6.11 and 3.9 with the same results. The only difference observed so far between runs is that sometimes the board hangs without anything printed on the console. Please find attached the panic log, and the application code. (log inlined) omap3isp omap3isp: can't find source, failing now omap3isp omap3isp: can't find source, failing now Those are harmless warnings. I have a fix for them, I'll repost it. [ cut here ] Kernel BUG at c019bb1c [verbose debug info unavailable] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM Modules linked in: omap3_isp ov10630(O) CPU: 0Tainted: G O (3.9.0 #3) PC is at omap3_l3_app_irq+0x3c/0xbc L3 APP interconnect timeout errors are not supposed to happen. This is the first time I see one. Maybe someone on the linux-omap list will have some clues regarding how to debug this. LR is at handle_irq_event_percpu+0x28/0x10c pc : [c019bb1c]lr : [c006b354]psr: 2193 sp : c0507e58 ip : 0006 fp : r10: cf804dc0 r9 : 9e65 r8 : 0020 r7 : r6 : 1000 r5 : r4 : cf87f3c0 r3 : r2 : 1000 r1 : cf8ffc80 r0 : 1000 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 8fa80019 DAC: 0015 Process swapper (pid: 0, stack limit = 0xc0506230) Stack: (0xc0507e58 to 0xc0508000) 7e40: 0002 cf87f3c0 7e60:001a c006b354 cf804dc0 cf87f3c0 cf804dc0 c0506000 7e80:cf87f3c0 c0507f0c 0020 9e65 c054d640 c006b490 cf804dc0 c0507f80 7ea0: c006da68 001a c006ac44 001a c000ebc8 000a c0507ed8 7ec0:001a c0008594 c054d600 c003400c 6113 c000df00 0001 c054d600 7ee0:0101 c0506000 0002 c0507fb4 0020 9e65 7f00:c054d640 c0526f28 c0507f20 c054d600 c003400c 6113 7f20:cf805c40 c0506000 c0511c98 c0507fb4 80004059 0035 7f40:c0507fb4 80004059 413fc082 c003440c 0035 c000ebcc 7f60:0025 c0507f80 0035 c0008594 c0506008 c000ed78 2013 c000df00 7f80:c0547548 c050fb50 0001 c0506000 c050e0d8 c04fb954 c0510844 7fa0:80004059 413fc082 c0507fc8 c0506008 c000ed78 7fc0:2013 c036c958 c04da7a8 c04da344 7fe0:c04fb958 271ae41c 10c53c7d c050e028 80008070 [c019bb1c] (omap3_l3_app_irq+0x3c/0xbc) from [c006b354] (handle_irq_event_percpu+0x28/0x10c) [c006b354] (handle_irq_event_percpu+0x28/0x10c) from [c006b490] (handle_irq_event+0x58/0x74) [c006b490] (handle_irq_event+0x58/0x74) from [c006da68] (handle_level_irq+0xd8/0x110) [c006da68] (handle_level_irq+0xd8/0x110) from [c006ac44] (generic_handle_irq+0x20/0x30) [c006ac44] (generic_handle_irq+0x20/0x30) from [c000ebc8] (handle_IRQ+0x60/0x84) [c000ebc8] (handle_IRQ+0x60/0x84) from [c0008594] (omap3_intc_handle_irq+0x58/0x6c) [c0008594] (omap3_intc_handle_irq+0x58/0x6c) from [c000df00] (__irq_svc+0x40/0x70) Exception stack(0xc0507ed8 to 0xc0507f20) 7ec0: 0001 c054d600 7ee0:0101 c0506000 0002 c0507fb4 0020 9e65 7f00:c054d640 c0526f28 c0507f20 c054d600 c003400c 6113 [c000df00] (__irq_svc+0x40/0x70) from [c003400c] (__do_softirq+0x60/0x184) [c003400c] (__do_softirq+0x60/0x184) from [c003440c] (irq_exit+0x70/0xc4) [c003440c] (irq_exit+0x70/0xc4) from [c000ebcc] (handle_IRQ+0x64/0x84) [c000ebcc] (handle_IRQ+0x64/0x84) from [c0008594] (omap3_intc_handle_irq+0x58/0x6c) [c0008594] (omap3_intc_handle_irq+0x58/0x6c) from [c000df00] (__irq_svc+0x40/0x70) Exception stack(0xc0507f80 to 0xc0507fc8) 7f80:c0547548 c050fb50 0001 c0506000 c050e0d8 c04fb954 c0510844 7fa0:80004059 413fc082
omap3-isp : panic using previewer from V4L input
Hi,
I am trying to use the previewer to debayer pictures coming from the
filesystem instead of the capture hardware. The media-ctl links are as
follows :
preview V4L input - preview pad 0 (sink), preview pad 1(src)
-preview V4L output.
Input output format is set via media-ctl for the preview element, and
via the V4L2 api for the V4L2 file descriptors. I am using USERPTR
buffer allocated via memalign, and the application goes like this :
REQBUFS 1 buf on on input
REQBUFS 1 buf on output
alloc buffers
QBUF on input
QBUF on output
STREAMON on output
STREAMON on input
DQBUF on output.
The board either panics or hangs (though HUNG_TASK_DETECTION and
SOFT_LOCKUP_DETECTION is set)
Please find attached the panic log, and the application code.
session.log
Description: Binary data
#include stdio.h
#include stdlib.h
#include string.h
#include errno.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include sys/ioctl.h
#include linux/videodev2.h
#include malloc.h
#include videobuf.h
#define WIDTH 3664
#define HEIGHT 2752
const char * v4l2_input = /dev/video3;
const char * v4l2_output = /dev/video4;
vbuf_desc ibuf;
vbuf_desc obuf;
#define XIOCTL(fd, name, data) do {\
int rc; \
rc = ioctl(fd, name, data);\
if(rc 0) { \
perror(#name); \
exit(EXIT_FAILURE); \
} \
} while(0)
static long filesize(FILE * stream)
{
long offs;
fseek(stream, 0, SEEK_END);
offs = ftell(stream);
rewind(stream);
return offs;
}
int main(int argc, char **argv)
{
int ifd, ofd;
FILE * istream, * ostream;
struct v4l2_format fmt;
struct v4l2_pix_format ipfmt;
struct v4l2_pix_format opfmt;
struct v4l2_requestbuffers req;
struct v4l2_buffer v4l2buf;
unsigned char * line;
char * fname;
long fsize;
int l;
// open video fds
ifd = open(v4l2_input, O_RDWR);
if(ifd 0) {
perror(v4l2_input);
exit(EXIT_FAILURE);
}
ofd = open(v4l2_output, O_RDWR);
if(ofd 0) {
perror(v4l2_output);
exit(EXIT_FAILURE);
}
// get / set input pixel format at SBGGR10
fmt.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
ipfmt.width = WIDTH;
ipfmt.height = HEIGHT;
fmt.fmt.pix = ipfmt;
XIOCTL(ifd, VIDIOC_TRY_FMT, fmt);
ipfmt = fmt.fmt.pix;
printf(input is %d x %d\n, ipfmt.width, ipfmt.height);
XIOCTL(ifd, VIDIOC_S_FMT, fmt);
printf(bytesperline is %d\n,ipfmt.bytesperline);
printf(sizeimage is %d\n,ipfmt.sizeimage);
// allocate input buffer
// allocate output buffer via malloc
ibuf.length = ipfmt.sizeimage;
ibuf.usrptr = memalign(32, ibuf.length);
line = malloc(ipfmt.width);
// request buffer in driver
req.count = 1;
req.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
req.memory = V4L2_MEMORY_USERPTR;
XIOCTL(ifd, VIDIOC_REQBUFS, req);
// get / set output pixel format
fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
XIOCTL(ofd, VIDIOC_TRY_FMT, fmt);
opfmt = fmt.fmt.pix;
printf(output is %d x %d\n, opfmt.width, opfmt.height);
printf(bytesperline is %d\n,opfmt.bytesperline);
printf(sizeimage is %d\n,opfmt.sizeimage);
XIOCTL(ofd, VIDIOC_S_FMT, fmt);
// allocate output buffer via malloc
obuf.length = fmt.fmt.pix.sizeimage;
obuf.usrptr = memalign(32, obuf.length);
req.count = 1;
req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
req.memory = V4L2_MEMORY_USERPTR;
XIOCTL(ofd, VIDIOC_REQBUFS, req);
// open input file
if(argc 2) {
printf(please provide a input file to debayer);
}
fname = argv[1];
printf(Opening %s for debayering\n, fname);
istream = fopen(fname, r);
if(!istream) {
perror(fname);
exit(EXIT_FAILURE);
}
fsize = filesize(istream);
if(fsize != ipfmt.width * ipfmt.height) {
if(fsize ipfmt.width * ipfmt.height) {
printf(File is too short fot current input : %d %d\n, fsize, ipfmt.width * ipfmt.height);
exit(EXIT_FAILURE);
} else {
printf(Warning : too many data in input file\n);
}
}
// read 8 bit pixel line
for(l = 0; l ipfmt.height; l++) {
int idx;
fread(line, 1, ipfmt.width, istream);
// transform and store 8 bit input line to 10 bit in input buffer
for(idx = 0; idx ipfmt.width; idx++) {
unsigned short * pix;
pix = (unsigned short *)ibuf.usrptr[l * ipfmt.bytesperline + idx * 2];
*pix = line[idx] * 4;
}
}
// queue input buf, queue output buf
v4l2buf.index = 0;
v4l2buf.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
v4l2buf.memory = V4L2_MEMORY_USERPTR;
v4l2buf.m.userptr = ibuf.usrptr;
v4l2buf.length = ibuf.length;
printf(usrptr = 0x%x \n, v4l2buf.m.userptr);
printf(v4l2buf.length = %d\n,ibuf.length);
XIOCTL(ifd, VIDIOC_QBUF, v4l2buf);
printf(input buffer queued\n);
v4l2buf.index = 0;
v4l2buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
v4l2buf.memory = V4L2_MEMORY_USERPTR;
v4l2buf.m.userptr = obuf.usrptr;
v4l2buf.length = obuf.length;
XIOCTL(ofd, VIDIOC_QBUF, v4l2buf);
printf(output buffer queued\n);
// streamon
XIOCTL(ofd, VIDIOC_STREAMON, v4l2buf.type);
//printf(output streamon\n);
v4l2buf.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
XIOCTL(ifd, VIDIOC_STREAMON, v4l2buf.type);
//printf(input
Re: Lockup on second streamon with omap3-isp
2012/12/17 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Julien, On Friday 14 December 2012 15:18:29 Julien BERAUD wrote: Hi Jean-Philippe, I have had exactly the same problem and the following workaround has caused no regression on our board yet. I can't explain exactly why it works and I think that it is internal to the isp. In function ccdc_set_stream, don't disable the ccdc_subclk when stopping capture: ret = ccdc_disable(ccdc); if (ccdc-output CCDC_OUTPUT_MEMORY) omap3isp_sbl_disable(isp, OMAP3_ISP_SBL_CCDC_WRITE); - omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_CCDC); + //omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_CCDC); I know that it is still a workaround but I hope that maybe it will help someone to understand the real cause of this issue. Do you get CCDC stop timeouts ? They are reported in the kernel log as CCDC stop timeout!. Le 13/12/2012 15:14, jean-philippe francois a écrit : Hi, I have news on the IRQ storm on second streamon problem. Reminder : Given a perfectly fine HSYNC / VSYNC / PIXELCLOK configuration, the omap3-isp (at least until 3.4) will go into an interrupt storm when streamon is called for the second time, unless you are able to stop the sensor when not streaming. I have reproduced this on three different board, with three different sensor. On board 1, the problem disappeared by itself (in fact not by itself, see below) and the board is not in my possession anymore. On board 2, I implemented a working s_stream operation in the subdev driver, so the problem was solved because the sensor would effectively stop streaming when told to, keeping the ISP + CCDC happy On board 3, I can't stop the streaming, or I did not figure out how to make it stop yet. I tried to disable the HS_VS_IRQ, but it did not help, so I came back looking at the code of board 1, which was running fine with a 3.4 kernel. And I discovered the problem doesn't happen if I break the pipeline between two consecutive streamon. In other word if I do the following : media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta yavta ... - board locks up, soft lockup is fired But if I do this instead : media-ctl -l '16:0-5:0[0], 5:1-6:0[0]' media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta media-ctl -l '16:0-5:0[0], 5:1-6:0[0]' media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta ... - image are acquired, board doesn't lock up anymore Now this really doesn't make much sense to me. Both sequences should produce the exact same hardware accesses. Could you add a printk in isp_reg_writel (drivers/media/platform/omap3isp/isp.h) and compare the register writes for both sequences ? And you are right, it was pure coincidence, the issue is still there. Sorry for the inaccurate report. Regards, Jean-Philippe François It would be interesting to go from this workaround to the elimination of the root cause. What can I do / test next to stop this bug from hapenning ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Lockup on second streamon with omap3-isp
Hi, I have news on the IRQ storm on second streamon problem. Reminder : Given a perfectly fine HSYNC / VSYNC / PIXELCLOK configuration, the omap3-isp (at least until 3.4) will go into an interrupt storm when streamon is called for the second time, unless you are able to stop the sensor when not streaming. I have reproduced this on three different board, with three different sensor. On board 1, the problem disappeared by itself (in fact not by itself, see below) and the board is not in my possession anymore. On board 2, I implemented a working s_stream operation in the subdev driver, so the problem was solved because the sensor would effectively stop streaming when told to, keeping the ISP + CCDC happy On board 3, I can't stop the streaming, or I did not figure out how to make it stop yet. I tried to disable the HS_VS_IRQ, but it did not help, so I came back looking at the code of board 1, which was running fine with a 3.4 kernel. And I discovered the problem doesn't happen if I break the pipeline between two consecutive streamon. In other word if I do the following : media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta yavta ... - board locks up, soft lockup is fired But if I do this instead : media-ctl -l '16:0-5:0[0], 5:1-6:0[0]' media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta media-ctl -l '16:0-5:0[0], 5:1-6:0[0]' media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta ... - image are acquired, board doesn't lock up anymore It would be interesting to go from this workaround to the elimination of the root cause. What can I do / test next to stop this bug from hapenning ? Regards, Jean-Philippe François -- 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 0/6] omap3isp: preview: Add support for non-GRBG Bayer patterns
2012/7/6 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi everybody, Here's the second version of the non-GRBG Bayer patterns support for the OMAP3 ISP preview engine. Compared to v1, the CFA table can be reconfigured at runtime, which resulted in several cleanup patches. The first patch is a v3.5 regression fix, I'll send a separate pull request. Jean-Philippe, could you please test this patch set on your hardware ? It's based on top of the latest linuxtv/staging/for_v3.6 branch. Hi Laurent, Sorry for the delay, but I was on vacation last week, and will be next week, so I won't be able to test anything before July 23rd. I will report here when tested. Regards, Jean-Philippe François Laurent Pinchart (6): omap3isp: preview: Fix contrast and brightness handling omap3isp: preview: Remove lens shading compensation support omap3isp: preview: Pass a prev_params pointer to configuration functions omap3isp: preview: Reorder configuration functions omap3isp: preview: Merge gamma correction and gamma bypass omap3isp: preview: Add support for non-GRBG Bayer patterns drivers/media/video/omap3isp/isppreview.c | 706 ++--- drivers/media/video/omap3isp/isppreview.h |1 + 2 files changed, 346 insertions(+), 361 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3isp: preview: Add support for non-GRBG Bayer patterns
2012/6/22 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Jean-Philippe, On Thursday 21 June 2012 15:35:52 jean-philippe francois wrote: 2012/6/18 Laurent Pinchart laurent.pinch...@ideasonboard.com: Rearrange the CFA interpolation coefficients table based on the Bayer pattern. Modifying the table during streaming isn't supported anymore, but didn't make sense in the first place anyway. Support for non-Bayer CFA patterns is dropped as they were not correctly supported, and have never been tested. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/omap3isp/isppreview.c | 118 ++-- 1 files changed, 67 insertions(+), 51 deletions(-) Jean-Philippe, Could you please test this patch on your hardware ? Hi, I have applied it on top of your omap3isp-next branch, but my board is oopsing right after the boot. I will try to get rid of this oops, but if you eventually now another tree that includes the changes necessary for this patch to apply, it could perhaps save me some time. The patch should apply on top of the omap3isp-omap3isp-next branch that I've just pushed to my linuxtv tree. Turns out some work was necessary to do to have a bootable board with vanilla 3.4. I successfully tested your patch on top of omap3isp-omap3isp-next with SRGGB and SBGGR sources. I tested it on top of your tree as it was 4 days ago, ie with the last commit being 5472d3f17845c4 Jean-Philippe François -- 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] omap3isp: preview: Add support for non-GRBG Bayer patterns
2012/6/18 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Rearrange the CFA interpolation coefficients table based on the Bayer
pattern. Modifying the table during streaming isn't supported anymore,
but didn't make sense in the first place anyway.
Support for non-Bayer CFA patterns is dropped as they were not correctly
supported, and have never been tested.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/isppreview.c | 118
1 files changed, 67 insertions(+), 51 deletions(-)
Jean-Philippe,
Could you please test this patch on your hardware ?
Hi,
I have applied it on top of your omap3isp-next branch, but my board is
oopsing right after the boot. I will try to get rid of this oops,
but if you eventually now another tree that includes the changes necessary
for this patch to apply, it could perhaps save me some time.
Here is a oops, in case somebody can point me to a patch, but the oops
is not very specific :
6Total of 96 interrupts on 1 active controller
4omap_hwmod: arm_fck: missing clockdomain for arm_fck.
4omap_hwmod: gpt1_fck: missing clockdomain for gpt1_fck.
6OMAP clockevent source: GPTIMER1 at 32768 Hz
6sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
1Unable to handle kernel NULL pointer dereference at virtual address
1pgd = c0004000
1[] *pgd=
0Internal error: Oops: 8005 [#1] PREEMPT ARM
dModules linked in:
CPU: 0Not tainted (3.4.0-rc3 #2)
PC is at 0x0
LR is at __irq_svc+0x40/0x70
pc : []lr : [c000e280]psr: 01d3
sp : c0461f88 ip : 000f fp :
r10: r9 : 413fc082 r8 : 80004059
r7 : c0461fbc r6 : r5 : 0153 r4 : c04367e0
r3 : c0010108 r2 : c0461fd0 r1 : c046b00c r0 : c0461f88
Flags: nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 80004019 DAC: 0015
0Process swapper (pid: 0, stack limit = 0xc04602e8)
0Stack: (0xc0461f88 to 0xc0462000)
01f80: 7735 01d3 01ff c0468118 c046808c
01fa0: c0456ec0 c046b004 80004059 413fc082 000f c0461fd0
01fc0: c0010108 c04367e0 0153 c04364fc
01fe0: c0456ec4 10c53c7d c046808c 8000803c
[c000e280] (__irq_svc+0x40/0x70) from [c04367e0] (start_kernel+0x138/0x254)
[c04367e0] (start_kernel+0x138/0x254) from [8000803c] (0x8000803c)
0Code: bad PC value
diff --git a/drivers/media/video/omap3isp/isppreview.c
b/drivers/media/video/omap3isp/isppreview.c
index 8a4935e..bfa3107 100644
--- a/drivers/media/video/omap3isp/isppreview.c
+++ b/drivers/media/video/omap3isp/isppreview.c
@@ -309,36 +309,6 @@ preview_config_dcor(struct isp_prev_device *prev, const
void *prev_dcor)
}
/*
- * preview_config_cfa - Configures the CFA Interpolation parameters.
- * @prev_cfa: Structure containing the CFA interpolation table, CFA format
- * in the image, vertical and horizontal gradient threshold.
- */
-static void
-preview_config_cfa(struct isp_prev_device *prev, const void *prev_cfa)
-{
- struct isp_device *isp = to_isp_device(prev);
- const struct omap3isp_prev_cfa *cfa = prev_cfa;
- unsigned int i;
-
- isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_PREV, ISPPRV_PCR,
- ISPPRV_PCR_CFAFMT_MASK,
- cfa-format ISPPRV_PCR_CFAFMT_SHIFT);
-
- isp_reg_writel(isp,
- (cfa-gradthrs_vert ISPPRV_CFA_GRADTH_VER_SHIFT) |
- (cfa-gradthrs_horz ISPPRV_CFA_GRADTH_HOR_SHIFT),
- OMAP3_ISP_IOMEM_PREV, ISPPRV_CFA);
-
- isp_reg_writel(isp, ISPPRV_CFA_TABLE_ADDR,
- OMAP3_ISP_IOMEM_PREV, ISPPRV_SET_TBL_ADDR);
-
- for (i = 0; i OMAP3ISP_PREV_CFA_TBL_SIZE; i++) {
- isp_reg_writel(isp, cfa-table[i],
- OMAP3_ISP_IOMEM_PREV, ISPPRV_SET_TBL_DATA);
- }
-}
-
-/*
* preview_config_gammacorrn - Configures the Gamma Correction table values
* @gtable: Structure containing the table for red, blue, green gamma table.
*/
@@ -813,7 +783,7 @@ static const struct preview_update update_attrs[] = {
FIELD_SIZEOF(struct prev_params, hmed),
offsetof(struct omap3isp_prev_update_config, hmed),
}, /* OMAP3ISP_PREV_CFA */ {
- preview_config_cfa,
+ NULL,
NULL,
offsetof(struct prev_params, cfa),
FIELD_SIZEOF(struct prev_params, cfa),
@@ -1043,42 +1013,88 @@ preview_config_ycpos(struct isp_prev_device *prev,
static void preview_config_averager(struct isp_prev_device *prev, u8 average)
{
struct isp_device *isp = to_isp_device(prev);
- struct prev_params *params;
- int reg = 0;
- params = (prev-params.active OMAP3ISP_PREV_CFA)
- ?
Re: [RFC PATCH] omap3isp : fix cfa demosaicing for format other than GRBG
2012/5/29 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Jean-Philippe,
On Tuesday 29 May 2012 10:24:45 jean-philippe francois wrote:
Hi,
omap3 ISP previewer block can convert a raw bayer image into a UYVY image.
Debayering coefficient are stored in an undocumented table. In the current
form, only GRBG format are converted correctly.
However, the other CFA arrangement can be transformed in GRBG arrangement by
shifting the image window one pixel to the left or to the bottom.
Here is a patch against vanilla 3.2.17, that was only tested with a BGGR
arrangement.
Is it the right way to fix this issue ?
That's really a hack. I'd much rather support other Bayer orders properly by
modifying the CFA coefficients table.
The table is arranged as 4 blocks of 144 coefficients. If I'm not mistaken (I
haven't tested it), the blocks should be arranged as follows:
GRBG 0 1 2 3
RGGB 1 0 3 2
BGGR 2 3 0 1
GBRG 3 2 1 0
Would you be able to test that with your BGGR sensor ?
It is indeed working for BGGR.
If that's correct, it shouldn't be too difficult to modify the order
dynamically based on the format.
What about something like the patch below ?
(It is easier for me to build images using mainline kernel + patch queue,
but should this patch be a good start, I would switch to a git workflow)
Index: b/drivers/media/video/omap3isp/isppreview.c
===
--- a/drivers/media/video/omap3isp/isppreview.c
+++ b/drivers/media/video/omap3isp/isppreview.c
@@ -308,6 +308,19 @@
dcor-couplet_mode_en ? ISPPRV_PCR_DCCOUP : 0);
}
+
+/* cfa table is organised in four blocks.
+ * Default ordering is for GRBG arrangement, but changing
+ * the block order allows to interpolate other cfa arrangement
+ */
+static unsigned int cfa_coef_order[4][4] = {
+ { 0, 1, 2, 3 }, /* GRBG */
+ { 1, 0, 3, 2 }, /* RGGB */
+ { 2, 3, 0, 1 }, /* BGGR */
+ { 3, 2, 1, 0 }, /* GBRG */
+};
+#define CFA_BLK_SIZE (OMAP3ISP_PREV_CFA_TBL_SIZE / 4)
+
/*
* preview_config_cfa - Configures the CFA Interpolation parameters.
* @prev_cfa: Structure containing the CFA interpolation table, CFA format
@@ -319,6 +332,7 @@
struct isp_device *isp = to_isp_device(prev);
const struct omap3isp_prev_cfa *cfa = prev_cfa;
unsigned int i;
+ unsigned int * block_order;
isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_PREV, ISPPRV_PCR,
ISPPRV_PCR_CFAFMT_MASK,
@@ -332,8 +346,30 @@
isp_reg_writel(isp, ISPPRV_CFA_TABLE_ADDR,
OMAP3_ISP_IOMEM_PREV, ISPPRV_SET_TBL_ADDR);
+
+ switch(prev-formats[PREV_PAD_SINK].code) {
+ case V4L2_MBUS_FMT_SRGGB10_1X10 :
+ block_order = cfa_coef_order[1];
+ break;
+
+ case V4L2_MBUS_FMT_SBGGR10_1X10 :
+ block_order = cfa_coef_order[2];
+ break;
+
+ case V4L2_MBUS_FMT_SGBRG10_1X10 :
+ block_order = cfa_coef_order[3];
+ break;
+
+ default :
+ block_order = cfa_coef_order[0];
+ }
+
+
for (i = 0; i OMAP3ISP_PREV_CFA_TBL_SIZE; i++) {
- isp_reg_writel(isp, cfa-table[i],
+ unsigned int base, offset;
+ base = block_order[i / CFA_BLK_SIZE]*CFA_BLK_SIZE;
+ offset = i % CFA_BLK_SIZE;
+ isp_reg_writel(isp, cfa-table[base + offset],
OMAP3_ISP_IOMEM_PREV, ISPPRV_SET_TBL_DATA);
}
}
@@ -1344,7 +1380,8 @@
preview_adjust_bandwidth(prev);
preview_config_input_size(prev);
-
+ preview_config_cfa(prev, prev-params.cfa);
+
if (prev-input == PREVIEW_INPUT_CCDC)
preview_config_inlineoffset(prev, 0);
else
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FW: OMAP 3 ISP
2012/5/29 Alex Gershgorin al...@meprolight.com: Hi Ritesh, Please send in the future CC to laurent.pinch...@ideasonboard.com and linux-media@vger.kernel.org Hi Alex, I also started working with OMAP35x torpedo kit, I successful compile Linux 3.0 and ported on the board. Device is booting correctly but probe function in omap3isp module not getting called. Please help me You have relevant Kernel boot messages? You can also find information in media archives OMAP 3 ISP thread. Regards, Alex Hi, I had a similar problem with a 2.6.39 kernel, that was solved with a 3.2 kernel. When compiled as a module, the probe function was called, but was failing later. The single message I would see was ISP revision x.y found [1] When compiled in the kernel image, everything was fine. [1] http://lxr.linux.no/linux+v2.6.39.4/drivers/media/video/omap3isp/isp.c#L2103 Jean-Philippe François -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] omap3isp : fix cfa demosaicing for format other than GRBG
Hi,
omap3 ISP previewer block can convert a raw bayer image
into a UYVY image. Debayering coefficient are stored in
an undocumented table. In the current form, only
GRBG format are converted correctly.
However, the other CFA arrangement can be transformed
in GRBG arrangement by shifting the image window one pixel
to the left or to the bottom.
Here is a patch against vanilla 3.2.17, that was only tested with a
BGGR arrangement.
Is it the right way to fix this issue ?
Thank you,
Jean-Philippe François
Index: b/drivers/media/video/omap3isp/isppreview.c
===
--- a/drivers/media/video/omap3isp/isppreview.c
+++ b/drivers/media/video/omap3isp/isppreview.c
@@ -96,21 +96,26 @@
* 2 lines in other modes
* Color suppression 2 pixels
* or luma enhancement
+ *
+ * Bayer pattern shifting 2 pixels, 1 line
* -
- * Maximum total 14 pixels, 8 lines
+ * Maximum total 18 pixels, 9 lines
*
* The color suppression and luma enhancement filters are applied
after bayer to
* YUV conversion. They thus can crop one pixel on the left and one
pixel on the
* right side of the image without changing the color pattern. When both those
* filters are disabled, the driver must crop the two pixels on the
same side of
- * the image to avoid changing the bayer pattern. The left margin is
thus set to
- * 8 pixels and the right margin to 6 pixels.
+ * the image to avoid changing the bayer pattern.
+ *
+ * Bayer pattern shifting is needed for some bayer pattern. Shifting
+ * will be in the right and bottom direction.
+ * The left margin is thus set to 8 pixels and the right margin to 10 pixels.
*/
#define PREV_MARGIN_LEFT 8
-#define PREV_MARGIN_RIGHT 6
+#define PREV_MARGIN_RIGHT 10
#define PREV_MARGIN_TOP4
-#define PREV_MARGIN_BOTTOM 4
+#define PREV_MARGIN_BOTTOM 5
#define PREV_MIN_IN_WIDTH 64
#define PREV_MIN_IN_HEIGHT 8
@@ -1038,6 +1043,34 @@
eph += 2;
slv -= 2;
elv += 2;
+ /* CFA table coef only handle GRBG format. Other format
+* can be transformed in GRBG by shifting the pattern :
+* BGGR - GRBG is obtained by a 1 row shift
+* RGGB - GRBG is obtained by a 1 column shift
+* GBRG - GRBG is obtained by a row and column shift
+*/
+ switch(prev-formats[PREV_PAD_SINK].code) {
+ case V4L2_MBUS_FMT_SRGGB10_1X10:
+ sph += 1;
+ eph += 1;
+ break;
+
+ case V4L2_MBUS_FMT_SBGGR10_1X10:
+ slv += 1;
+ elv += 1;
+ break;
+
+ case V4L2_MBUS_FMT_SGBRG10_1X10:
+ sph += 1;
+ eph += 1;
+ slv += 1;
+ elv += 1;
+ break;
+
+ default:
+ break;
+ }
+
}
if (params-features (PREV_DEFECT_COR | PREV_NOISE_FILTER)) {
sph -= 2;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC Patch] omap3isp : support CFA pattern when not GRBG
Hi, omap3 ISP previewer block can convert a raw bayer image into a UYVY image. Debayering coefficient are stored in an undocumented table. In the current form, only GRBG format are converted correctly. However, the other CFA arrangement can be transformed in GRBG arrangement by shifting the image window one pixel to the left or to the bottom. Here is a patch against vanilla 3.2.17. If such a patch can find it's way into mainline, I will try to port it against a suitable git tree. This was only tested with a BGGR arrangement. Thank you, Jean-Philippe François isppreview_bayer.patch Description: Binary data
Re: [PATCH v3 05/10] v4l: Add support for ov5640 sensor
2012/5/2 Sergio Aguirre saagui...@ti.com:
This adds a very limited driver for ov5640, which
only supports:
- 2592x1944 @ ~7.5 fps
- 1920x1080 @ ~15 fps,
- 1280x720 @ ~24 fps,
- 640x480 @ ~24 fps,
- 320x240 @ ~24 fps,
All in YUV422i format, using 1 CSI2 datalane @ 333 MHz.
There is already a limited driver in mainline for ov5642.
How does the 5642 differ from 5640 ?
Can a single driver handle both chip ?
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig | 6 +
drivers/media/video/Makefile | 1 +
drivers/media/video/ov5640.c | 948
++
include/media/ov5640.h | 10 +
4 files changed, 965 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ov5640.c
create mode 100644 include/media/ov5640.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 4482ac4..cc76652 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -480,6 +480,12 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_OV5640
+ tristate OmniVision OV5640 sensor support
+ depends on I2C VIDEO_V4L2
+ help
+ This is a ov5640 camera driver
+
config VIDEO_VS6624
tristate ST VS6624 sensor support
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index c95cc0d..da40ab3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_CX25840) += cx25840/
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/video/ov5640.c b/drivers/media/video/ov5640.c
new file mode 100644
index 000..2a64d50
--- /dev/null
+++ b/drivers/media/video/ov5640.c
@@ -0,0 +1,948 @@
+/*
+ * OmniVision OV5640 sensor driver
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.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 version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/videodev2.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/delay.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+#include media/v4l2-ctrls.h
+
+#include media/ov5640.h
+
+/* OV5640 has only one fixed colorspace per pixelcode */
+struct ov5640_datafmt {
+ enum v4l2_mbus_pixelcode code;
+ enum v4l2_colorspace colorspace;
+};
+
+struct ov5640_timing_cfg {
+ u16 x_addr_start;
+ u16 y_addr_start;
+ u16 x_addr_end;
+ u16 y_addr_end;
+ u16 h_output_size;
+ u16 v_output_size;
+ u16 h_total_size;
+ u16 v_total_size;
+ u16 isp_h_offset;
+ u16 isp_v_offset;
+ u8 h_odd_ss_inc;
+ u8 h_even_ss_inc;
+ u8 v_odd_ss_inc;
+ u8 v_even_ss_inc;
+};
+
+enum ov5640_size {
+ OV5640_SIZE_QVGA,
+ OV5640_SIZE_VGA,
+ OV5640_SIZE_720P,
+ OV5640_SIZE_1080P,
+ OV5640_SIZE_5MP,
+ OV5640_SIZE_LAST,
+};
+
+static const struct v4l2_frmsize_discrete ov5640_frmsizes[OV5640_SIZE_LAST]
= {
+ { 320, 240 },
+ { 640, 480 },
+ { 1280, 720 },
+ { 1920, 1080 },
+ { 2592, 1944 },
+};
+
+/* Find a frame size in an array */
+static int ov5640_find_framesize(u32 width, u32 height)
+{
+ int i;
+
+ for (i = 0; i OV5640_SIZE_LAST; i++) {
+ if ((ov5640_frmsizes[i].width = width)
+ (ov5640_frmsizes[i].height = height))
+ break;
+ }
+
+ /* If not found, select biggest */
+ if (i = OV5640_SIZE_LAST)
+ i = OV5640_SIZE_LAST - 1;
+
+ return i;
+}
+
+struct ov5640 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt format;
+
+ struct v4l2_ctrl_handler ctrl_handler;
+
+ const struct ov5640_platform_data *pdata;
+
+ struct v4l2_ctrl *pixel_rate;
+};
+
+static inline struct ov5640 *to_ov5640(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ov5640, subdev);
+}
+
+/**
+ * struct ov5640_reg - ov5640 register format
+ * @reg: 16-bit
subdev_pad_ops vs video_ops
subdev_pad_ops and video_ops both contains operation related to format, crop and bus format. When should one or the other be used ? For example mt9p031 implement everything using pad_ops, but other drivers use video_ops functions. -- 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
OMAP3 previewer bayer pattern selection
Hi, I am trying to get a working preview from a CMOS sensor with a CFA bayer pattern. Does the CCDC_COLPTN register have any effect on previewer CFA interpolation ? From my experience it does not. I can set BGGR or GRBG, but the output is always the same. When doing raw capture, I get nice image if I use a BGGR pattern for my software bayer to rgb interpolation. When using previewer, the output looks like BGGR interpreted as GRBG, ie blue and red are green, and green turns into purple. Looking at the driver code (mainline), there is nothing about bayer order in the previewer code. Looking at the TRM, theres is also nothing in the previewer part about bayer order. How are we supposed to debayer something different from GRBG ? By modifying the cfa_coef_table table ? Cropping at the previewer output to start on an odd line ? Thank you for any pointer on this issue. Jean-Philippe François -- 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 MT9P031 digital sensor
Le 26 mars 2012 18:32, Gary Thomas g...@mlbassoc.com a écrit : On 2012-03-26 09:37, Joshua Hintze wrote: Gary, I'm using linux branch from 2.6.39 Fetch URL: git://www.sakoman.com/git/linux-omap-2.6 branch: omap-2.6.39 I'm using an overo board so I figured I should follow Steve Sakoman's repository. Which brings up another question, would you recommend going off of one of Laurent's repo's and if so which one? The last time I tried Laurent's repo, it did not have the UYVY support in the OMAP3ISP/CCDC merged in. I don't know if that has changed recently. I think you are talking about UYVY/YUYV sensor input to the CDCD which was not working. However, the previewer part is working, ie Bayer input and YUV output. UYVY input is present in one of Laurent's tree. I did not test it. Jean-Philippe François On Mon, Mar 26, 2012 at 9:25 AM, Gary Thomasg...@mlbassoc.com wrote: On 2012-03-25 23:13, Joshua Hintze wrote: Alright I made some progress on this. I can access the Mt9p031 registers that are exposed using a command such as ./yavta -l /dev/v4l-subdev8 to list the available controls. Then I can set the exposure and analog gain with ./yavta --set-control '0x00980911 1500' /dev/v4l-subdev8--- This seems to give the desired effect. Note that ./yavta -w (short option for --set-control) gives a seg fault for me. Possible bug in yavta?? Now I'm working on fixing the white balance. In my office the incandescent light bulbs give off a yellowish tint late at night. I've been digging through the omap3isp code to figure out how to enable the automatic white balance. I was able to find the private IOCTLs for the previewer and I was able to use VIDIOC_OMAP3ISP_PRV_CFG. Using this IOCTL I adjusted the OMAP3ISP_PREV_WB, OMAP3ISP_PREV_BLKADJ, and OMAP3ISP_PREV_RGB2RGB. Since I wasn't sure where to start on adjusting these values I just set them all to the TRM's default register values. However when I did so a strange thing occurred. What I saw was all the colors went to a decent color. I'm curious if anybody can shed some light on the best way to get a high quality image. Ideally if I could just set a bit for auto white balance and auto exposure that could be good too. Just curious - what codebase (git URL) are you using? On Fri, Mar 23, 2012 at 1:01 PM, Joshua Hintzejoshua.hin...@gmail.com wrote: Sorry to bring up this old message list. I was curious when you spoke about the ISP preview engine being able to adjust the white balance. When I enumerate the previewer's available controls all I see is... root@overo:~# ./yavta -l /dev/v4l-subdev3 --- User Controls (class 0x00980001) --- control 0x00980900 `Brightness' min 0 max 255 step 1 default 0 current 0. control 0x00980901 `Contrast' min 0 max 255 step 1 default 16 current 16. 2 controls found. Is this what you are referring to? Are there other settings I can adjust to get the white balance and focus better using the OMAP3 ISP AWEB/OMAP3 ISP AF? Thanks, Josh Hi Gary, On Wednesday 30 November 2011 18:00:55 Gary Thomas wrote: On 2011-11-30 07:57, Gary Thomas wrote: On 2011-11-30 07:30, Laurent Pinchart wrote: On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote: [snip] This sort of works(*), but I'm still having issues (at least I can move frames!) When I configure the pipeline like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]' the resulting frames are 24 bytes each instead of 654720 When I tried to grab from the previewer, the frames were 9969120 instead of 9961380 Any ideas what resolution is actually being moved through? Because the OMAP3 ISP has alignment requirements. Both the preview engine and the resizer output line lenghts must be multiple of 32 bytes. The driver adds padding at end of lines when the output width isn't a multiple of 16 pixels. Any guess which resolution(s) I should change and to what? I changed the resizer output to be 672x496 and was able to capture video using ffmpeg. I don't know what to expect with this sensor (I've never seen it in use before), but the image seems to have color balance issues - it's awash in a green hue. It may be the poor lighting in my office... I did try the 9 test patterns which I was able to select via # v4l2-ctl -d /dev/v4l-subdev8 --set-ctrl=test_pattern=N and these looked OK. You can see them at http://www.mlbassoc.com/misc/mt9p031_images/ Neither
Re: [PATCH v5.1 35/35] smiapp: Add driver
Le 11 mars 2012 10:04, Sakari Ailus sakari.ai...@iki.fi a écrit : Hi François, On Thu, Mar 08, 2012 at 04:06:34PM +0100, jean-philippe francois wrote: Le 8 mars 2012 14:57, Sakari Ailus sakari.ai...@iki.fi a écrit : Add driver for SMIA++/SMIA image sensors. The driver exposes the sensor as three subdevs, pixel array, binner and scaler --- in case the device has a scaler. Currently it relies on the board code for external clock handling. There is no fast way out of this dependency before the ISP drivers (omap3isp) among others will be able to export that clock through the clock framework instead. + case V4L2_CID_EXPOSURE: + return smiapp_write( + client, + SMIAPP_REG_U16_COARSE_INTEGRATION_TIME, ctrl-val); + At this point, knowing pixel clock and line length, it is possible to get / set the exposure in useconds or millisecond value. It is possible, but still I don't think we even want that at this level. This is a fairly low level interface. The exposure time in seconds can always be constructed from horizontal and vertical blanking and the pixel rate in the user space. I think it is on the side of abstraction, not on the side of policy. If you want to sort this in userspace, then you need to decide on a common unit for the exposure control. Is it a number of pixel, a number of line, anumber of quarter of line ? If userspace does not know that, then it needs to know which kind of sensor it is driving, and then the driver somehow failed at providing abstraction. And I should not have to use a library with all the quirks for all the existing sensor out there when it could have been done at the driver level. Modularity is generally lost when you leave the solution to userspace. I think there are two orthogonal subject here : -one is abstracting sensor differences, to expose sensor capabilities in a way that is sensible or natural. Wether you set the exposure to 50 msec or 337 native unit does not change the fact that it may conflicts with a previous framerate settings of 1/30 sec, but it is much easier to understand what you do using msec. - The other subject is how to solve a particular set of constraints with a given set of conflicting controls. As you pointed it, framerate and exposure can be one of those. Let's suppose the application adjust the framerate, using hblank. Exposure will change as a consequences . If the application wants to keep the same exposure, it will either - do sensor dependant computation to compute a new native unit exposure value. - Set the exposure to it's previous value using natural, sensor independent unit. In both cases, the exposure unit has no effect on the decision making ability of the application. In both cases, if the new exposure value is out of range, a decision must be taken wether framerate should limit exposure or not. And in this particular case, the policy is clearly in the driver already, since setting vblank determine the exposure setting limits. So to sum up : - Exposure control unit has nothing to do with policy, but is rather a matter of useful abstraction - Conflicting control is another orthogonal problem. Jean-Philippe François -- 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: Lockup on second streamon with omap3-isp
Thank you, I will try this and keep you posted. With this sensor it is possible, but that is not the case for every sensor out there. Is this an ISP bug ? From my experience, the ISP doesn't handle free-running sensors very well. There are other things it doesn't handle well, such as sensors stopping in the middle of the frame. I would consider this as limitations. This shouldn't cause any interrupt storm though, but I'd like you to check just in case. Floating HS/VS signals that would happen to oscillate near the logic threshold voltage is my main guess for your problem. Unless there is a soldering problem, this is not the case. Oscilloscope traces look fine. And I would not get images out of the driver if Hsync / Vsync was garbage. Anyway, stopping / restarting the sensor removes the bug symptom, thanks a lot for this hint. It never happens on first start, ie before ccdc_configure is called for the first time. Is there a way to eventually handle this in the driver ? Let's first find out where the problam comes from exactly. If it's an interrupt storm, I should be able to printk debug it, I will keep you posted. Jean-Philippe François -- 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 v5.1 35/35] smiapp: Add driver
Le 8 mars 2012 14:57, Sakari Ailus sakari.ai...@iki.fi a écrit :
Add driver for SMIA++/SMIA image sensors. The driver exposes the sensor as
three subdevs, pixel array, binner and scaler --- in case the device has a
scaler.
Currently it relies on the board code for external clock handling. There is
no fast way out of this dependency before the ISP drivers (omap3isp) among
others will be able to export that clock through the clock framework
instead.
+ case V4L2_CID_EXPOSURE:
+ return smiapp_write(
+ client,
+ SMIAPP_REG_U16_COARSE_INTEGRATION_TIME, ctrl-val);
+
At this point, knowing pixel clock and line length, it is possible
to get / set the exposure in useconds or millisecond value.
From userspace, if for example you change the format and crop,
you can just set the expo to a value in msec or usec, and get the
same exposure after your format change.
The driver is IMO the place where we have all the info. Here is some
example code with usec. (The 522 constant is the fine integration register...)
static int mt9j_expo_to_shutter(struct usb_ovfx2 * ov, u32 expo)
{
int rc = 0;
u32 expo_pix; // exposition in pixclk unit
u16 coarse_expo;
u16 row_time;
expo_pix = expo * 96; /// pixel clock in MHz
MT9J_RREAD(ov, LINE_LENGTH_PCK, row_time);
expo_pix = expo_pix - 522;
coarse_expo = (expo_pix + row_time/2)/ row_time;
MT9J_RWRITE(ov, COARSE_EXPO_REG, coarse_expo);
return rc;
}
static int mt9j_shutter_to_expo(struct usb_ovfx2 * ov, u32 * expo)
{
int rc = 0;
u32 expo_pix; // exposition in pixclk unit
u16 coarse_expo;
u16 row_time;
MT9J_RREAD(ov, LINE_LENGTH_PCK, row_time);
MT9J_RREAD(ov, COARSE_EXPO_REG, coarse_expo);
expo_pix = row_time * coarse_expo + 522;
*expo = expo_pix / (96);
return rc;
}
Maybe you have enough on your plate for now, and this can
wait after inclusion, but it is a nice abstraction to have from
userspace point of view.
--
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: Lockup on second streamon with omap3-isp
Le 9 mars 2012 00:28, Laurent Pinchart laurent.pinch...@ideasonboard.com a écrit : On Thursday 08 March 2012 19:22:53 Sakari Ailus wrote: On Wed, Mar 07, 2012 at 03:24:29PM +0100, jean-philippe francois wrote: Le 6 mars 2012 18:08, jean-philippe francois jp.franc...@cynove.com a écrit : Hi, I have a custom dm3730 board, running a 3.2.0 kernel. The board is equipped with an aptina MT9J sensor on parallel interface. Whenever I try to run yavta twice, the second run leads to a soft lockup in omap3isp_video_queue_streamon (see below) What can I do / test to debug this issue ? Examining the offset, The code is stuck in the for_each loop, but I fail to see why. I added list manipulation and spinlock debugging, without detecting any problem. # get.vga Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 Video format: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 3 buffers requested. length: 307200 offset: 0 Buffer 0 mapped at address 0x4023e000. length: 307200 offset: 307200 Buffer 1 mapped at address 0x4034d000. length: 307200 offset: 614400 Buffer 2 mapped at address 0x40444000. 0 (0) [-] 4294967295 307200 bytes 100.397705 100.397796 7.817 fps 1 (1) [-] 4294967295 307200 bytes 100.495666 100.495788 10.208 fps 2 (2) [-] 4294967295 307200 bytes 100.593658 100.593750 10.205 fps 3 (0) [-] 4294967295 307200 bytes 100.691619 100.691741 10.208 fps 4 (1) [-] 4294967295 307200 bytes 100.789611 100.789703 10.205 fps 5 (2) [-] 4294967295 307200 bytes 100.887573 100.887695 10.208 fps 6 (0) [-] 4294967295 307200 bytes 100.985565 100.985656 10.205 fps 7 (1) [-] 4294967295 307200 bytes 101.083526 101.083709 10.208 fps 8 (2) [-] 4294967295 307200 bytes 101.181488 101.181610 10.208 fps 9 (0) [-] 4294967295 307200 bytes 101.279480 101.279571 10.205 fps Captured 10 frames in 1.009796 seconds (9.902989 fps, 3042198.137254 B/s). 3 buffers released. [1]+ Done httpd # get.vga Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 Video format: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 3 buffers requested. length: 307200 offset: 0 Buffer 0 mapped at address 0x40285000. length: 307200 offset: 307200 Buffer 1 mapped at address 0x40314000. length: 307200 offset: 614400 Buffer 2 mapped at address 0x403bb000. BUG: soft lockup - CPU#0 stuck for 22s! [yavta:495] Modules linked in: ks8851_mll omap3_isp fpgacam(O) Pid: 495, comm: yavta CPU: 0 Tainted: G O (3.2.0 #52) PC is at __do_softirq+0x50/0x110 LR is at __do_softirq+0x38/0x110 pc : [c003746c] lr : [c0037454] psr: 2113 sp : ce8e5c88 ip : cf406140 fp : r10: cee90800 r9 : 000a r8 : ce8e4000 r7 : 0002 r6 : r5 : r4 : 0025 r3 : c044e580 r2 : r1 : 0002 r0 : Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 8e858019 DAC: 0015 [c00123b0] (unwind_backtrace+0x0/0xec) from [c00646c4] (watchdog_timer_fn+0xd8/0x128) [c00646c4] (watchdog_timer_fn+0xd8/0x128) from [c004e640] (__run_hrtimer+0x68/0xe4) [c004e640] (__run_hrtimer+0x68/0xe4) from [c004e8b0] (hrtimer_interrupt+0x11c/0x2a4) [c004e8b0] (hrtimer_interrupt+0x11c/0x2a4) from [c0018f44] (omap2_gp_timer_interrupt+0x24/0x34) [c0018f44] (omap2_gp_timer_interrupt+0x24/0x34) from [c0064df8] (handle_irq_event_percpu+0x28/0x110) [c0064df8] (handle_irq_event_percpu+0x28/0x110) from [c0064f34] (handle_irq_event+0x54/0x74) [c0064f34] (handle_irq_event+0x54/0x74) from [c00676f8] (handle_level_irq+0xb4/0x100) [c00676f8] (handle_level_irq+0xb4/0x100) from [c0064a28] (generic_handle_irq+0x28/0x30) [c0064a28] (generic_handle_irq+0x28/0x30) from [c000e570] (handle_IRQ+0x60/0x84) [c000e570] (handle_IRQ+0x60/0x84) from [c000d874] (__irq_svc+0x34/0x98) [c000d874] (__irq_svc+0x34/0x98) from [c003746c] (__do_softirq+0x50/0x110) [c003746c] (__do_softirq+0x50/0x110) from [c00376f0] (irq_exit+0x48/0x9c)omap3isp_video_queue_streamon [c00376f0] (irq_exit+0x48/0x9c) from [c000e574] (handle_IRQ+0x64/0x84) [c000e574] (handle_IRQ+0x64/0x84) from [c000d874] (__irq_svc+0x34/0x98) [c000d874] (__irq_svc+0x34/0x98) from [bf007864] (+0x6c/0xa0 [omap3_isp]) As it's __irq_svc(), I'd guess it's stuck executing the ISP interrupt handler. This shouldn't happen. Is the sensor a parallel one? There have been cases where bad hs / vs signals essentially cause the ISP driver to stay in handling interrupts. Or rather to constantly re-enter the interrupt
Re: Lockup on second streamon with omap3-isp
Le 6 mars 2012 18:08, jean-philippe francois jp.franc...@cynove.com a écrit : Hi, I have a custom dm3730 board, running a 3.2.0 kernel. The board is equipped with an aptina MT9J sensor on parallel interface. Whenever I try to run yavta twice, the second run leads to a soft lockup in omap3isp_video_queue_streamon (see below) What can I do / test to debug this issue ? Examining the offset, The code is stuck in the for_each loop, but I fail to see why. I added list manipulation and spinlock debugging, without detecting any problem. # get.vga Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 Video format: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 3 buffers requested. length: 307200 offset: 0 Buffer 0 mapped at address 0x4023e000. length: 307200 offset: 307200 Buffer 1 mapped at address 0x4034d000. length: 307200 offset: 614400 Buffer 2 mapped at address 0x40444000. 0 (0) [-] 4294967295 307200 bytes 100.397705 100.397796 7.817 fps 1 (1) [-] 4294967295 307200 bytes 100.495666 100.495788 10.208 fps 2 (2) [-] 4294967295 307200 bytes 100.593658 100.593750 10.205 fps 3 (0) [-] 4294967295 307200 bytes 100.691619 100.691741 10.208 fps 4 (1) [-] 4294967295 307200 bytes 100.789611 100.789703 10.205 fps 5 (2) [-] 4294967295 307200 bytes 100.887573 100.887695 10.208 fps 6 (0) [-] 4294967295 307200 bytes 100.985565 100.985656 10.205 fps 7 (1) [-] 4294967295 307200 bytes 101.083526 101.083709 10.208 fps 8 (2) [-] 4294967295 307200 bytes 101.181488 101.181610 10.208 fps 9 (0) [-] 4294967295 307200 bytes 101.279480 101.279571 10.205 fps Captured 10 frames in 1.009796 seconds (9.902989 fps, 3042198.137254 B/s). 3 buffers released. [1]+ Done httpd # get.vga Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 Video format: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 3 buffers requested. length: 307200 offset: 0 Buffer 0 mapped at address 0x40285000. length: 307200 offset: 307200 Buffer 1 mapped at address 0x40314000. length: 307200 offset: 614400 Buffer 2 mapped at address 0x403bb000. BUG: soft lockup - CPU#0 stuck for 22s! [yavta:495] Modules linked in: ks8851_mll omap3_isp fpgacam(O) Pid: 495, comm: yavta CPU: 0 Tainted: G O (3.2.0 #52) PC is at __do_softirq+0x50/0x110 LR is at __do_softirq+0x38/0x110 pc : [c003746c] lr : [c0037454] psr: 2113 sp : ce8e5c88 ip : cf406140 fp : r10: cee90800 r9 : 000a r8 : ce8e4000 r7 : 0002 r6 : r5 : r4 : 0025 r3 : c044e580 r2 : r1 : 0002 r0 : Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 8e858019 DAC: 0015 [c00123b0] (unwind_backtrace+0x0/0xec) from [c00646c4] (watchdog_timer_fn+0xd8/0x128) [c00646c4] (watchdog_timer_fn+0xd8/0x128) from [c004e640] (__run_hrtimer+0x68/0xe4) [c004e640] (__run_hrtimer+0x68/0xe4) from [c004e8b0] (hrtimer_interrupt+0x11c/0x2a4) [c004e8b0] (hrtimer_interrupt+0x11c/0x2a4) from [c0018f44] (omap2_gp_timer_interrupt+0x24/0x34) [c0018f44] (omap2_gp_timer_interrupt+0x24/0x34) from [c0064df8] (handle_irq_event_percpu+0x28/0x110) [c0064df8] (handle_irq_event_percpu+0x28/0x110) from [c0064f34] (handle_irq_event+0x54/0x74) [c0064f34] (handle_irq_event+0x54/0x74) from [c00676f8] (handle_level_irq+0xb4/0x100) [c00676f8] (handle_level_irq+0xb4/0x100) from [c0064a28] (generic_handle_irq+0x28/0x30) [c0064a28] (generic_handle_irq+0x28/0x30) from [c000e570] (handle_IRQ+0x60/0x84) [c000e570] (handle_IRQ+0x60/0x84) from [c000d874] (__irq_svc+0x34/0x98) [c000d874] (__irq_svc+0x34/0x98) from [c003746c] (__do_softirq+0x50/0x110) [c003746c] (__do_softirq+0x50/0x110) from [c00376f0] (irq_exit+0x48/0x9c)omap3isp_video_queue_streamon [c00376f0] (irq_exit+0x48/0x9c) from [c000e574] (handle_IRQ+0x64/0x84) [c000e574] (handle_IRQ+0x64/0x84) from [c000d874] (__irq_svc+0x34/0x98) [c000d874] (__irq_svc+0x34/0x98) from [bf007864] (+0x6c/0xa0 [omap3_isp]) [bf007864] (omap3isp_video_queue_streamon+0x6c/0xa0 [omap3_isp]) from [bf0096cc] (isp_video_streamon+0x178/0x258 [omap3_isp]) [bf0096cc] (isp_video_streamon+0x178/0x258 [omap3_isp]) from [c022cae4] (__video_do_ioctl+0x1b9c/0x4894) [c022cae4] (__video_do_ioctl+0x1b9c/0x4894) from [c022ae08] (video_usercopy+0x1b8/0x298) [c022ae08] (video_usercopy+0x1b8/0x298) from [c0229d48] (v4l2_ioctl+0x68/0x114) [c0229d48] (v4l2_ioctl+0x68/0x114) from [c00a2514] (vfs_ioctl+0x20/0x3c) [c00a2514] (vfs_ioctl+0x20/0x3c) from [c00a2d9c] (do_vfs_ioctl+0x1ac/0x1c4) [c00a2d9c] (do_vfs_ioctl+0x1ac/0x1c4) from [c00a2de8] (sys_ioctl+0x34/0x54) [c00a2de8] (sys_ioctl+0x34/0x54) from [c000dcc0] (ret_fast_syscall+0x0/0x30
Lockup on second streamon with omap3-isp
Hi, I have a custom dm3730 board, running a 3.2.0 kernel. The board is equipped with an aptina MT9J sensor on parallel interface. Whenever I try to run yavta twice, the second run leads to a soft lockup in omap3isp_video_queue_streamon (see below) What can I do / test to debug this issue ? # get.vga Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 Video format: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 3 buffers requested. length: 307200 offset: 0 Buffer 0 mapped at address 0x4023e000. length: 307200 offset: 307200 Buffer 1 mapped at address 0x4034d000. length: 307200 offset: 614400 Buffer 2 mapped at address 0x40444000. 0 (0) [-] 4294967295 307200 bytes 100.397705 100.397796 7.817 fps 1 (1) [-] 4294967295 307200 bytes 100.495666 100.495788 10.208 fps 2 (2) [-] 4294967295 307200 bytes 100.593658 100.593750 10.205 fps 3 (0) [-] 4294967295 307200 bytes 100.691619 100.691741 10.208 fps 4 (1) [-] 4294967295 307200 bytes 100.789611 100.789703 10.205 fps 5 (2) [-] 4294967295 307200 bytes 100.887573 100.887695 10.208 fps 6 (0) [-] 4294967295 307200 bytes 100.985565 100.985656 10.205 fps 7 (1) [-] 4294967295 307200 bytes 101.083526 101.083709 10.208 fps 8 (2) [-] 4294967295 307200 bytes 101.181488 101.181610 10.208 fps 9 (0) [-] 4294967295 307200 bytes 101.279480 101.279571 10.205 fps Captured 10 frames in 1.009796 seconds (9.902989 fps, 3042198.137254 B/s). 3 buffers released. [1]+ Done httpd # get.vga Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 Video format: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 3 buffers requested. length: 307200 offset: 0 Buffer 0 mapped at address 0x40285000. length: 307200 offset: 307200 Buffer 1 mapped at address 0x40314000. length: 307200 offset: 614400 Buffer 2 mapped at address 0x403bb000. BUG: soft lockup - CPU#0 stuck for 22s! [yavta:495] Modules linked in: ks8851_mll omap3_isp fpgacam(O) Pid: 495, comm:yavta CPU: 0Tainted: G O (3.2.0 #52) PC is at __do_softirq+0x50/0x110 LR is at __do_softirq+0x38/0x110 pc : [c003746c]lr : [c0037454]psr: 2113 sp : ce8e5c88 ip : cf406140 fp : r10: cee90800 r9 : 000a r8 : ce8e4000 r7 : 0002 r6 : r5 : r4 : 0025 r3 : c044e580 r2 : r1 : 0002 r0 : Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 8e858019 DAC: 0015 [c00123b0] (unwind_backtrace+0x0/0xec) from [c00646c4] (watchdog_timer_fn+0xd8/0x128) [c00646c4] (watchdog_timer_fn+0xd8/0x128) from [c004e640] (__run_hrtimer+0x68/0xe4) [c004e640] (__run_hrtimer+0x68/0xe4) from [c004e8b0] (hrtimer_interrupt+0x11c/0x2a4) [c004e8b0] (hrtimer_interrupt+0x11c/0x2a4) from [c0018f44] (omap2_gp_timer_interrupt+0x24/0x34) [c0018f44] (omap2_gp_timer_interrupt+0x24/0x34) from [c0064df8] (handle_irq_event_percpu+0x28/0x110) [c0064df8] (handle_irq_event_percpu+0x28/0x110) from [c0064f34] (handle_irq_event+0x54/0x74) [c0064f34] (handle_irq_event+0x54/0x74) from [c00676f8] (handle_level_irq+0xb4/0x100) [c00676f8] (handle_level_irq+0xb4/0x100) from [c0064a28] (generic_handle_irq+0x28/0x30) [c0064a28] (generic_handle_irq+0x28/0x30) from [c000e570] (handle_IRQ+0x60/0x84) [c000e570] (handle_IRQ+0x60/0x84) from [c000d874] (__irq_svc+0x34/0x98) [c000d874] (__irq_svc+0x34/0x98) from [c003746c] (__do_softirq+0x50/0x110) [c003746c] (__do_softirq+0x50/0x110) from [c00376f0] (irq_exit+0x48/0x9c)omap3isp_video_queue_streamon [c00376f0] (irq_exit+0x48/0x9c) from [c000e574] (handle_IRQ+0x64/0x84) [c000e574] (handle_IRQ+0x64/0x84) from [c000d874] (__irq_svc+0x34/0x98) [c000d874] (__irq_svc+0x34/0x98) from [bf007864] (+0x6c/0xa0 [omap3_isp]) [bf007864] (omap3isp_video_queue_streamon+0x6c/0xa0 [omap3_isp]) from [bf0096cc] (isp_video_streamon+0x178/0x258 [omap3_isp]) [bf0096cc] (isp_video_streamon+0x178/0x258 [omap3_isp]) from [c022cae4] (__video_do_ioctl+0x1b9c/0x4894) [c022cae4] (__video_do_ioctl+0x1b9c/0x4894) from [c022ae08] (video_usercopy+0x1b8/0x298) [c022ae08] (video_usercopy+0x1b8/0x298) from [c0229d48] (v4l2_ioctl+0x68/0x114) [c0229d48] (v4l2_ioctl+0x68/0x114) from [c00a2514] (vfs_ioctl+0x20/0x3c) [c00a2514] (vfs_ioctl+0x20/0x3c) from [c00a2d9c] (do_vfs_ioctl+0x1ac/0x1c4) [c00a2d9c] (do_vfs_ioctl+0x1ac/0x1c4) from [c00a2de8] (sys_ioctl+0x34/0x54) [c00a2de8] (sys_ioctl+0x34/0x54) from [c000dcc0] (ret_fast_syscall+0x0/0x30) Kernel panic - not syncing: softlockup: hung tasks -- 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
