RE: Question about tput constraint on zoom2 camera
From: Paul Walmsley [p...@pwsan.com] Sent: Saturday, August 01, 2009 9:57 PM To: Curran, Dominic Cc: Kevin Hilman; linux-omap@vger.kernel.org; Subramaniam, Muthu Subject: Re: Question about tput constraint on zoom2 camera Hello Dominic, On Fri, 31 Jul 2009, Curran, Dominic wrote: I have been testing the zoom2 camera streaming while using different OPP's. Following table provides summary of what OPP's caused to happen: Streaming Vdd1(OPP)Vdd2(OPP) P/F VGA @ 30fps 12 Pass 8MP @ 7.5fps 12 Fails (stop streaming) 8MP @ 7.5fps 13 Pass So table shows that locking Vdd2 to OPP=3 when streaming 8MPixel works, but at OPP=2 then streaming fails (stops). So I thought the tput constraint made the most sense for camera. The Zoom2 camera sensor has a max tput of: 3280 x 2464 x 2bpp x 7.5fps = 121228800 bytes/s = 118387 KB/s However, this calculated value doesn't constrain Vdd2 to OPP3 (DVFS enabled). Experimentation shows that a tput value of 35 KB/s is required to constrain Vdd2 to OPP=3. Can you explain why the practical tput constraint is so much greater than the theoretical value ? Probably it is mostly due to two reasons: 1. most other L3 initiator drivers (eg., for DSS, SDMA, USB, etc) don't currently set bus throughput constraints, so we aren't currently adding in their interconnect usage; and 2. the interconnect throughput model in omap-pm-srf.c is optimistic. A couple of questions for you: (please forgive my ignorance of the camera subsystem): A. What other L3 initiators are active during the test? Presumably DSS, MPU? IVA2? B. I am assuming you are using the CCP2. What do you have CCP2_CTRL.BURST set to? This could impact interconnect utilization. - Paul Hi Paul No DSS (i'm just printing a '.' when i dequeue a frame). No IVA2. No per pixel processing by the ARM. I was trying to keep me testing as simple as possible. HOWEVER, your questions have made me think of something else which i think _may_ explain everything. The camera pipe should look like this: Sensor -- CSI2 Receiver -- CCDC -- PREVIEWER -- RESIZER -- MEM But because of a hardware bug, data has to be written to memory by Previewer and then read by Resizer. Thus a 'workaround' buffer is allocated for this purpose. Its not pretty but its the only way we can have Preview Resizer in the pipe at the same time. So the pipeline actually looks like this: Sensor -- CSI2 Receiver -- CCDC -- PREVIEWER -- Workaround MEM -- RESIZER -- MEM Thus in order to get a single pixel through the pipe there has to be three L3 operations: 1) Write to workaround mem 2) Read from workaround mem 3) Write to final memory This seems to me like it actually increases the tput by 3x. 118387 KB/s x 3 = 355161 KB/s Which looks like it is very close to the number I found in practice (35). Does this seem like a reasonable explanation to you ? Thanks dom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Question about tput constraint on zoom2 camera
Hi Kevin
I have been testing the zoom2 camera streaming while using different OPP's.
Following table provides summary of what OPP's caused to happen:
Streaming Vdd1(OPP)Vdd2(OPP) P/F
VGA @ 30fps 12 Pass
8MP @ 7.5fps 12 Fails (stop streaming)
8MP @ 7.5fps 13 Pass
So table shows that locking Vdd2 to OPP=3 when streaming 8MPixel works, but at
OPP=2 then streaming fails (stops).
So I thought the tput constraint made the most sense for camera.
The Zoom2 camera sensor has a max tput of:
3280 x 2464 x 2bpp x 7.5fps = 121228800 bytes/s
= 118387 KB/s
However, this calculated value doesn't constrain Vdd2 to OPP3 (DVFS enabled).
Experimentation shows that a tput value of 35 KB/s is required to constrain
Vdd2 to OPP=3.
Can you explain why the practical tput constraint is so much greater than the
theoretical value ?
Thanks
dom
NOTE: Following patch was created against 2.6.29 APG kernel.
From: Dominic Curran dcur...@ti.com
Subject: ZOOM2: Add OMAP3 power constraints for Sony camera.
Adds power constraints for the Zoom2 camera sensor (Sony IMX046).
If no constraint was applied then ISP stopped working if Vdd2 went
to OPP2 when streaming 8MPixel at 7.5fps.
Thus Vdd2 needs to be kept at OPP3 while streaming with this sensor.
In theory the following throughput constraint should be sufficient:
3280 x 2464 x 2bpp x 7.5fps = 118387 KByte/sec
However, in practice it was found that a tput value of 35 KB/s
was required in order to constrain Vdd2 to OPP3.
This constraint still allowed Vdd1 to goto OPP1 while streaming
without causing problems.
Signed-off-by: Dominic Curran dcur...@ti.com
---
arch/arm/mach-omap2/board-zoom2-camera.c |9 -
drivers/media/video/imx046.c |2 +-
include/media/imx046.h |2 +-
3 files changed, 10 insertions(+), 3 deletions(-)
Index: google/arch/arm/mach-omap2/board-zoom2-camera.c
===
--- google.orig/arch/arm/mach-omap2/board-zoom2-camera.c
+++ google/arch/arm/mach-omap2/board-zoom2-camera.c
@@ -24,6 +24,7 @@
#include asm/io.h
#include mach/gpio.h
+#include mach/omap-pm.h
static int cam_inited;
#include media/v4l2-int-device.h
@@ -165,7 +166,7 @@ static struct isp_interface_config imx04
};
-static int imx046_sensor_power_set(enum v4l2_power power)
+static int imx046_sensor_power_set(struct device *dev, enum v4l2_power power)
{
struct isp_csi2_lanes_cfg lanecfg;
struct isp_csi2_phy_cfg phyconfig;
@@ -176,6 +177,9 @@ static int imx046_sensor_power_set(enum
case V4L2_POWER_ON:
/* Power Up Sequence */
printk(KERN_DEBUG imx046_sensor_power_set(ON)\n);
+
+ omap_pm_set_min_bus_tput(dev, OCP_INITIATOR_AGENT, 35);
+
isp_csi2_reset();
lanecfg.clk.pol = IMX046_CSI2_CLOCK_POLARITY;
@@ -245,10 +249,13 @@ static int imx046_sensor_power_set(enum
twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
VAUX_DEV_GRP_NONE, TWL4030_VAUX2_DEV_GRP);
gpio_free(IMX046_RESET_GPIO);
+
+ omap_pm_set_min_bus_tput(dev, OCP_INITIATOR_AGENT, 0);
break;
case V4L2_POWER_STANDBY:
printk(KERN_DEBUG imx046_sensor_power_set(STANDBY)\n);
/*TODO*/
+ omap_pm_set_min_bus_tput(dev, OCP_INITIATOR_AGENT, 0);
break;
}
Index: google/drivers/media/video/imx046.c
===
--- google.orig/drivers/media/video/imx046.c
+++ google/drivers/media/video/imx046.c
@@ -1439,7 +1439,7 @@ static int ioctl_s_power(struct v4l2_int
else
sensor-pdata-set_xclk(xclk_current, hw_config.u.sensor.xclk);
- rval = sensor-pdata-power_set(on);
+ rval = sensor-pdata-power_set(client-dev, on);
if (rval 0) {
v4l_err(client, Unable to set the power state:
IMX046_DRIVER_NAME sensor\n);
Index: google/include/media/imx046.h
===
--- google.orig/include/media/imx046.h
+++ google/include/media/imx046.h
@@ -28,7 +28,7 @@
* @priv_data_set: device private data (pointer) access function
*/
struct imx046_platform_data {
- int (*power_set)(enum v4l2_power power);
+ int (*power_set)(struct device*, enum v4l2_power power);
int (*ifparm)(struct v4l2_ifparm *p);
int (*priv_data_set)(void *);
u32 (*set_xclk)(u32 xclk, u8 xclksel);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Oops with /sys/power/vdd1_lock
Hi Kevin I'm seeing a oops when I try to write to /sys/power/vdd1_lock. I am working on 2.6.29 kernel on zoom2. I have tried to reproduce oops on your latest pm tree but when I build for zoom2 the kernel gets as far as: Starting kernel ... And then freezes. Another Tier just clone Tony's tree and reported seeing this with zoom2 also. Anyway the vdd1_lock Oops is below. Does this ring any bells ? I think the oops is caused here: if (resp-curr_level == target_level) return 0; because resp is NULL, presumably because resp = vdd1_resp; vdd1_resp is Null also. vdd1_resp gets setup in init_opp(), which gets called as a func ptr, but I don't know where from. I added printk's and I'm not seeing init_opp() get called with a struct shared_resource for vdd1-opp at boot. I know this is an old kernel for you. Still, do you have any pointers ? Thanks dom # echo 1 /sys/power/vdd1_lock Unable to handle kernel NULL pointer dereference at virtual address 0008 1pgd = c68d8000 pgd = c68d8000 1[0008] *pgd=8562c031[0008] *pgd=8562c031, *pte=, *pte=000 0. fps=29.762939, *ppte=, *ppte= Internal error: Oops: 17 [#1] PREEMPT Internal error: Oops: 17 [#1] PREEMPT Modules linked in:Modules linked in: CPU: 0Not tainted (2.6.29-omap1-g70195fc-dirty #15) CPU: 0Not tainted (2.6.29-omap1-g70195fc-dirty #15) PC is at resource_set_opp_level+0x3c/0x16c PC is at resource_set_opp_level+0x3c/0x16c LR is at vdd_opp_store+0x148/0x184 LR is at vdd_opp_store+0x148/0x184 pc : [c004311c]lr : [c003efbc]psr: 6013 sp : c5653ea8 ip : c5653ee0 fp : c5653edc pc : [c004311c]lr : [c003efbc]psr: 6013 sp : c5653ea8 ip : c5653ee0 fp : c5653edc r10: c5653f70 r9 : c55d7238 r8 : 0001 r10: c5653f70 r9 : c55d7238 r8 : 0001 r7 : r6 : c0468c58 r5 : 0001 r4 : 0001 r7 : r6 : c0468c58 r5 : 0001 r4 : 0001 r3 : c0469158 r2 : 0001 r1 : 0001 r0 : 0001 r3 : c0469158 r2 : 0001 r1 : 0001 r0 : 0001 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5307d Table: 868d8019 DAC: 0015 Control: 10c5307d Table: 868d8019 DAC: 0015 Process ash (pid: 537, stack limit = 0xc56522e0) Process ash (pid: 537, stack limit = 0xc56522e0) Stack: (0xc5653ea8 to 0xc5654000) Stack: (0xc5653ea8 to 0xc5654000) 3ea0: 3ea0: c5653ed0 c5653ed0 c5653eb8 c5653 eb8 c01a55e4 c01a55e4 c01a5050 c01a5050 0010 0010 0001 0001 3ec0: 3ec0: 0001 0001 c0468c58 c0468c58 0002 0002 c04500c4 c0450 0c4 c5653f04 c5653f04 c5653ee0 c5653ee0 c003efbc c003efbc c00430ec c00430ec 3ee0: 3ee0: 40001000 40001000 00017220 00017220 0002 0002 c55eaae8 c55ea ae8 c55d7220 c55d7220 c681dd60 c681dd60 c5653f14 c5653f14 c5653f08 c5653f08 3f00: 3f00: c01a060c c01a060c c003ee80 c003ee80 c5653f44 c5653f44 c5653f18 c5653 f18 c01035d4 c01035d4 c01a05f8 c01a05f8 c5653f70 c5653f70 c68332c0 c68332c0 3f20: 3f20: 40001000 40001000 c5653f70 c5653f70 0002 0002 40001000 40001 000 c5652000 c5652000 c5653f6c c5653f6c c5653f48 c5653f48 3f40: 3f40: c00b7188 c00b7188 c01034d0 c01034d0 c68332c0 c68332c0 0 000 c68332c0 c68332c0 0002 0002 3f60: 3f60: c5653fa4 c5653fa4 c5653f70 c5653f70 c00b72dc c00b72dc c00b70dc c00b7 0dc c5653fa4 c5653fa4 3f80: 3f80: c00c3c2c c00c3c2c 0002 0002 40001000 40001000 001d41f8 001d4 1f8 0004 0004 c0031028 c0031028 c5653fa8 c5653fa8 3fa0: 3fa0: c0030e80 c0030e80 c00b72a4 c00b72a4 0002 0002 40001000 40001 000 0001 0001 40001000 40001000 0002 0002 3fc0: 3fc0: 0002 0002 40001000 40001000 001d41f8 001d41f8 0004 0 004 0002 0002 001db23c 001db23c 3fe0: 3fe0: 40001000 40001000 bef47600 bef47600 000f6f6c 000f6f6c 8e2c 8 e2c 6010 6010 0001 0001 ffff ffff ff0004ff ff0004ff Backtrace: Backtrace: [c00430e0] [c00430e0] (resource_set_opp_level+0x0/0x16c) (resource_set_opp_l evel+0x0/0x16c) from [c003efbc] from [c003efbc] (vdd_opp_store+0x148/0x184) (vdd_opp_store+0x148/0x184) r8:c04500c4 r8:c04500c4 r7:0002 r7:0002 r6:c0468c58 r6:c0468c58 r5: 0001 r5:0001 r4:0001 r4:0001 [c003ee74] [c003ee74] (vdd_opp_store+0x0/0x184) (vdd_opp_store+0x0/0x184) fr om [c01a060c] from [c01a060c] (kobj_attr_store+0x20/0x24) (kobj_attr_store+0x20/0x24) r7:c681dd60 r7:c681dd60 r6:c55d7220 r6:c55d7220 r5:c55eaae8 r5:c55eaae8 r4: 0002 r4:0002 [c01a05ec] [c01a05ec] (kobj_attr_store+0x0/0x24) (kobj_attr_store+0x0/0x24) from [c01035d4] from [c01035d4] (sysfs_write_file+0x110/0x144) (sysfs_write_file+0x110/0x144) [c01034c4] [c01034c4]
RE: Script for applying a set of patches from a folder
On Friday 05 June 2009 12:55:41 Elvis Dowson wrote: HI, Does anyone have a script that will allow me to apply all the patches that are contained in a folder, using the git apply command? You need to use git am for that, with the dir as parameter. git am will apply each patch from the dir. If they are in a quilt series then you can use: $ git quiltimport -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3
Hi Kim -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of DongSoo(Nathaniel) Kim Sent: Wednesday, March 04, 2009 8:58 PM To: Aguirre Rodriguez, Sergio Alberto Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth Subject: Re: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3 Hi Sergio, On Wed, Mar 4, 2009 at 5:44 AM, Aguirre Rodriguez, Sergio Alberto saagui...@ti.com wrote: + /* turn on analog power */ + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, + VAUX_2_8_V, TWL4030_VAUX2_DEDICATED); + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, + VAUX_DEV_GRP_P1, TWL4030_VAUX2_DEV_GRP); + + /* out of standby */ + gpio_set_value(MT9P012_STANDBY_GPIO, 0); + udelay(1000); It seems better using msleep rather than udelay for 1000us much. Just to be safe :) How about you? Why is msleep safer than udelay ? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3
-Original Message- From: Alexey Klimov [mailto:klimov.li...@gmail.com] Sent: Thursday, March 05, 2009 4:05 PM To: Curran, Dominic Cc: DongSoo(Nathaniel) Kim; Aguirre Rodriguez, Sergio Alberto; linux- me...@vger.kernel.org; linux-omap@vger.kernel.org; Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth Subject: Re: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3 + /* out of standby */ + gpio_set_value(MT9P012_STANDBY_GPIO, 0); + udelay(1000); It seems better using msleep rather than udelay for 1000us much. Just to be safe :) How about you? Why is msleep safer than udelay ? I have small guess that he is wondering why you are using big delays with help of udelay(). (It's may be obvious but as we know udelay uses cpu loops to make delay and msleep calls to scheduler) So, msleep is more flexible and softer but if you need precise time or you can't sleep in code you need udelay. Sometimes using udelay is reasonably required. Ah, I did not know that msleep() called scheduler. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/5] LDP: Add support for built-in camera
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
Sent: Tuesday, March 03, 2009 2:44 PM
To: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim;
MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth
Subject: [PATCH 5/5] LDP: Add support for built-in camera
This patch adds support for the LDP builtin camera sensor:
- Primary sensor (/dev/video4): OV3640 (CSI2).
It introduces also a new file for storing all camera sensors board
specific related functions, like other platforms do (N800 for example).
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-ldp-camera.c | 203
+++
arch/arm/mach-omap2/board-ldp.c | 17 +++
arch/arm/plat-omap/include/mach/board-ldp.h |1 +
4 files changed, 223 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-ldp-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ee6..097bc58 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -63,7 +63,8 @@ obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-
omap3beagle.o \
mmc-twl4030.o \
twl4030-generic-scripts.o
obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o \
-mmc-twl4030.o
+mmc-twl4030.o \
+board-ldp-camera.o
obj-$(CONFIG_MACH_OMAP_APOLLON) += board-apollon.o \
board-apollon-mmc.o \
board-apollon-keys.o
diff --git a/arch/arm/mach-omap2/board-ldp-camera.c b/arch/arm/mach-
omap2/board-ldp-camera.c
new file mode 100644
index 000..0db085c
--- /dev/null
+++ b/arch/arm/mach-omap2/board-ldp-camera.c
@@ -0,0 +1,203 @@
+/*
+ * linux/arch/arm/mach-omap2/board-ldp0-camera.c
Minor typo, should be:
linux/arch/arm/mach-omap2/board-ldp-camera.c
+ *
+ * Copyright (C) 2009 Texas Instruments Inc.
+ * Sergio Aguirre saagui...@ti.com
+ *
+ * Modified from mach-omap2/board-ldp.c
+ *
+ * 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.
+ */
+
+#ifdef CONFIG_TWL4030_CORE
+
+#include linux/clk.h
+#include linux/platform_device.h
+#include linux/delay.h
+
+#include linux/i2c/twl4030.h
+
+#include asm/io.h
+
+#include mach/gpio.h
+
+static int cam_inited;
+#include media/v4l2-int-device.h
+#include ../drivers/media/video/omap34xxcam.h
+#include ../drivers/media/video/isp/ispreg.h
+
+#define LDPCAM_USE_XCLKB 1
+
+#define VAUX_1_8_V 0x05
+#define VAUX_DEV_GRP_P1 0x20
+#define VAUX_DEV_GRP_NONE0x00
+
+#if defined(CONFIG_VIDEO_OV3640) || defined(CONFIG_VIDEO_OV3640_MODULE)
+#define OV3640_RESET_GPIO98
+#define OV3640_STANDBY_GPIO 7
+#include media/ov3640.h
+#include ../drivers/media/video/isp/ispcsi2.h
+static struct omap34xxcam_hw_config *hwc;
+#define OV3640_CSI2_CLOCK_POLARITY 0 /* +/- pin order */
+#define OV3640_CSI2_DATA0_POLARITY 0 /* +/- pin order */
+#define OV3640_CSI2_DATA1_POLARITY 0 /* +/- pin order */
+#define OV3640_CSI2_CLOCK_LANE 1/* Clock lane
position: 1 */
+#define OV3640_CSI2_DATA0_LANE 2/* Data0 lane
position: 2 */
+#define OV3640_CSI2_DATA1_LANE 3/* Data1 lane
position: 3 */
+#define OV3640_CSI2_PHY_THS_TERM 4
+#define OV3640_CSI2_PHY_THS_SETTLE 14
+#define OV3640_CSI2_PHY_TCLK_TERM0
+#define OV3640_CSI2_PHY_TCLK_MISS1
+#define OV3640_CSI2_PHY_TCLK_SETTLE 14
+
+static struct omap34xxcam_sensor_config ov3640_hwc = {
+ .sensor_isp = 0,
+ .xclk = OMAP34XXCAM_XCLK_B,
+ .capture_mem = 2592 * 1944 * 2 * 2,
Should this be 2048 * 1536 * 2 * 2 ?
Ack-by: Dominic Curran dcur...@ti.com
+ .ival_default = { 1, 15 },
+};
+
+static struct isp_interface_config ov3640_if_config = {
+ .ccdc_par_ser = ISP_CSIA,
+ .dataline_shift = 0x0,
+ .hsvs_syncdetect = ISPCTRL_SYNC_DETECT_VSRISE,
+ .strobe = 0x0,
+ .prestrobe = 0x0,
+ .shutter = 0x0,
+ .prev_sph = 2,
+ .prev_slv = 1,
+ .wenlog = ISPCCDC_CFG_WENLOG_AND,
+ .wait_hs_vs = 2,
+ .u.csi.crc = 0x0,
+ .u.csi.mode = 0x0,
+ .u.csi.edge = 0x0,
+ .u.csi.signalling = 0x0,
+ .u.csi.strobe_clock_inv = 0x0,
+ .u.csi.vs_edge = 0x0,
+ .u.csi.channel = 0x1,
+ .u.csi.vpclk = 0x1,
+
RE: [PATCH 1/2] OMAP3430SDP: Remove unneded extern line
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
Sent: Wednesday, February 25, 2009 4:03 PM
To: linux-omap@vger.kernel.org
Cc: Syed Mohammed, Khasim
Subject: [PATCH 1/2] OMAP3430SDP: Remove unneded extern line
From 9ec9fef55a7fbfc9f813a521bed6158db1aad46f Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Wed, 25 Feb 2009 15:26:35 -0600
Subject: [PATCH 1/2] OMAP3430SDP: Remove unneded extern line
This patch removes a duplicate extern on board-3430sdp.c
file, as it is present already on
arch/arm/plat-omap/include/mach/board-3430sdp.h
Found by doing a checkpatch.pl run with board-3430sdp.c
Signed-off-by: Sergio Aguirre saagui...@ti.com
Acked-by: Dominic Curran dcur...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-
3430sdp.c
index 758183c..ab0aa7d 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -623,8 +623,6 @@ static int __init omap3430_i2c_init(void)
return 0;
}
-extern void __init sdp3430_flash_init(void);
-
static void __init omap_3430sdp_init(void)
{
omap3430_i2c_init();
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3430SDP: Get rid of checkpatch.pl warnings with includes
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto Sent: Wednesday, February 25, 2009 4:03 PM To: linux-omap@vger.kernel.org Cc: Syed Mohammed, Khasim Subject: [PATCH 2/2] OMAP3430SDP: Get rid of checkpatch.pl warnings with includes From bd4df7db454add3f679456a1e7f4c814f297cc71 Mon Sep 17 00:00:00 2001 From: Sergio Aguirre saagui...@ti.com Date: Wed, 25 Feb 2009 15:55:56 -0600 Subject: [PATCH 2/2] OMAP3430SDP: Get rid of checkpatch.pl warnings with includes Signed-off-by: Sergio Aguirre saagui...@ti.com Acked-by: Dominic Curran dcur...@ti.com --- arch/arm/mach-omap2/board-3430sdp.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board- 3430sdp.c index ab0aa7d..867f5f6 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -24,6 +24,7 @@ #include linux/spi/ads7846.h #include linux/i2c/twl4030.h #include linux/regulator/machine.h +#include linux/io.h #include mach/hardware.h #include asm/mach-types.h @@ -39,8 +40,6 @@ #include mach/dma.h #include mach/gpmc.h -#include asm/io.h -#include asm/delay.h #include mach/control.h #include sdram-qimonda-hyb18m512160af-6.h -- 1.5.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [OMAPZOOM][PATCH] Testing for TWL4030 in board file change.
-Original Message- From: Nishanth Menon [mailto:menon.nisha...@gmail.com] Sent: Tuesday, February 17, 2009 2:12 AM To: Curran, Dominic Cc: linux-omap; Aguirre Rodriguez, Sergio Alberto Subject: Re: [OMAPZOOM][PATCH] Testing for TWL4030 in board file change. Dominic Curran said the following on 02/17/2009 02:15 AM: From: Dominic Curran dcur...@ti.com Subject: [OMAPZOOM][PATCH] Testing for TWL4030 in board file change. This patch changes the method of testing for TWL4030 in the sensor portion of the board file. Previously, if TWL4030 was not built into kernel then the build would be stopped by code in the board file simular to: #ifndef CONFIG_TWL4030_CORE #error no power companion board defined! #endif However for debugging purposes it maybe required to build without TWL4030. Therefore this patch allows the kernel to be compiled without a build error when TWL4030 is not present. In such a case the sensor power function will build, but when called immediately return a -ENODEV error (so initilization of sensor will go no further). This change is targeted at all camera sensors within the board files for SDP, Zoom1 Zoom2. Alternative fixes to this problem like changes to Kconfig were considered, but rejected as inappropriate solutions. Would a solution as follows be appropriate? in arch/arm/mach-omap2/Kconfig: config MACH_OMAP_ZOOM2 bool OMAP3 ZOOM2 board depends on ARCH_OMAP3 ARCH_OMAP34XX +select TWL4030_CORE if VIDEO_OMAP3 A similar strategy has been implemented for N800, albeit for other peripherals. Regards, Nishanth Menon If 'reverse dependencies' set the symbol and its dependencies I would say this would be a good solution, but unfortunately it does not. The documentation for reverse dependencies warns: 107 select should be used with care. select will force 108 a symbol to a value without visiting the dependencies. 109 By abusing select you are able to select a symbol FOO even 110 if FOO depends on BAR that is not set. 111 In general use select only for non-visible symbols Since TWL4030 has dependencies then I don't think this is appropriate. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [OMAPZOOM][PATCH] Testing for TWL4030 in board file change.
-Original Message- From: Aguirre Rodriguez, Sergio Alberto Sent: Tuesday, February 17, 2009 10:03 AM To: Nishanth Menon; Curran, Dominic Cc: linux-omap Subject: RE: [OMAPZOOM][PATCH] Testing for TWL4030 in board file change. -Original Message- From: Nishanth Menon [mailto:menon.nisha...@gmail.com] Sent: Tuesday, February 17, 2009 9:33 AM To: Curran, Dominic Cc: linux-omap; Aguirre Rodriguez, Sergio Alberto Subject: Re: [OMAPZOOM][PATCH] Testing for TWL4030 in board file change. Curran, Dominic said the following on 02/17/2009 04:27 PM: -Original Message- From: Nishanth Menon [mailto:menon.nisha...@gmail.com] Sent: Tuesday, February 17, 2009 2:12 AM To: Curran, Dominic Cc: linux-omap; Aguirre Rodriguez, Sergio Alberto Subject: Re: [OMAPZOOM][PATCH] Testing for TWL4030 in board file change. Would a solution as follows be appropriate? in arch/arm/mach-omap2/Kconfig: config MACH_OMAP_ZOOM2 bool OMAP3 ZOOM2 board depends on ARCH_OMAP3 ARCH_OMAP34XX +select TWL4030_CORE if VIDEO_OMAP3 A similar strategy has been implemented for N800, albeit for other peripherals. If 'reverse dependencies' set the symbol and its dependencies I would say this would be a good solution, but unfortunately it does not. The documentation for reverse dependencies warns: 107 select should be used with care. select will force 108 a symbol to a value without visiting the dependencies. 109 By abusing select you are able to select a symbol FOO even 110 if FOO depends on BAR that is not set. 111 In general use select only for non-visible symbols Since TWL4030 has dependencies then I don't think this is appropriate Mach-omap video_omap3 depends on twl4030 and twl4030 is not reverse dependent on mach-omap. twl4030 is dependent on i2c - I believe based on drivers/mfd/Kconfig how do we handle this? Maybe a select of i2c is appropriate there? or how about: +select TWL4030_CORE if VIDEO_OMAP3 +select I2C if TWL4030_CORE You may want to see arch/arm/mach-omap2/Kconfig - MACH_NOKIA_N800. I think we have a similar condition there with CBUS and VIDEO_TCM825X I think.. Honestly, I'm a bit lost about the goal of this. I don't see how this is solving our problem. - 3430SDP and Zoom1/2 uses TWL4030 for power handling the camera sensors - Current Omap3 camera driver can be used in other platforms than the above that uses OMAP3x30 chip, so we cannot add dependencies on camera driver to platform specific powering methods. - On above platforms, there exists the need for compiling without T2 support sometimes and you don't want a broken build because of this How is above helping for solving this out? my 2cents: i like select better than #ifdef ;).. but then, that is just me :).. Regards, Nishanth Menon Fyi, This didn't seem to work: $ make menuconfig scripts/kconfig/mconf arch/arm/Kconfig drivers/media/Kconfig:35:error: found recursive dependency: VIDEO_V4L2_COMMON - VIDEO_V4L2 - VIDEO_CAPTURE_DRIVERS - VIDEO_OMAP3 - TWL4030_CORE - I2C - VIDEO_V4L2_COMMON make[1]: *** [menuconfig] Error 1 make: *** [menuconfig] Error 2 [gro...@gromit omapzoom04]$ Sergio told me you had discussed a different approach anyway... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [OMAPZOOM][PATCH v2 2/6] Increase isp workaround buffer size for 8MP sensor.
From: Alexey Klimov [klimov.li...@gmail.com]
Sent: Saturday, January 31, 2009 9:08 AM
To: Curran, Dominic
Cc: linux-me...@vger.kernel.org; linux-omap; greg.ho...@hp.com
Subject: Re: [OMAPZOOM][PATCH v2 2/6] Increase isp workaround buffer size for
8MP sensor.
Hello, Dominic
May i ask few questions ?
Well, looks like it's unrelated to your patch. Lines that don't looks
okay to me appear in your patch.
On Fri, 2009-01-30 at 17:45 -0600, Dominic Curran wrote:
From: Dominic Curran dcur...@ti.com
Subject: [OMAPZOOM][PATCH v2 2/6] Increase isp workaround buffer size for 8MP
sensor.
A temporary buffer is created to hold the image while it is written by
Previewer module and then read by Resizer module. This is called LSC
Workaround. To take into account the Sony IMX046 8MP sensor that buffer
needs to be increased in size.
Changed the #defines to be upper case.
Patch also fixes the initialization of a couple of CCDC values.
Signed-off-by: Dominic Curran dcur...@ti.com
---
drivers/media/video/isp/isp.c | 10 +-
drivers/media/video/isp/isp.h |7 +--
drivers/media/video/isp/ispccdc.c |2 ++
drivers/media/video/isp/ispmmu.h |3 +++
4 files changed, 15 insertions(+), 7 deletions(-)
Index: omapzoom04/drivers/media/video/isp/isp.c
===
--- omapzoom04.orig/drivers/media/video/isp/isp.c
+++ omapzoom04/drivers/media/video/isp/isp.c
@@ -1172,20 +1172,20 @@ void omapisp_unset_callback()
**/
u32 isp_buf_allocation(void)
{
- buff_addr = (void *) vmalloc(buffer_size);
+ buff_addr = (void *) vmalloc(ISP_BUFFER_MAX_SIZE);
if (!buff_addr) {
printk(KERN_ERR Cannot allocate memory );
Will user understand what module (or system of kernel) provide this
printk message ? Should module name be here ?
[DC] Agree.
return -ENOMEM;
}
- sglist_alloc = videobuf_vmalloc_to_sg(buff_addr, no_of_pages);
+ sglist_alloc = videobuf_vmalloc_to_sg(buff_addr, ISP_BUFFER_MAX_PAGES);
if (!sglist_alloc) {
printk(KERN_ERR videobuf_vmalloc_to_sg error);
Well, may be here too..
By the way, why there is no \n in the end of messages in this
function ?
[DC] Agree.
return -ENOMEM;
}
- num_sc = dma_map_sg(NULL, sglist_alloc, no_of_pages, 1);
- buff_addr_mapped = ispmmu_map_sg(sglist_alloc, no_of_pages);
+ num_sc = dma_map_sg(NULL, sglist_alloc, ISP_BUFFER_MAX_PAGES, 1);
+ buff_addr_mapped = ispmmu_map_sg(sglist_alloc, ISP_BUFFER_MAX_PAGES);
if (!buff_addr_mapped) {
printk(KERN_ERR ispmmu_map_sg mapping failed );
Probably the same thing here.
May be someone can correct sitation if necessary..
[DC] Agree.
Thanks Alexey. I will create an extra patch to cleanup those printk's.
return -ENOMEM;
@@ -1217,7 +1217,7 @@ void isp_buf_free(void)
{
if (alloc_done == 1) {
ispmmu_unmap(buff_addr_mapped);
- dma_unmap_sg(NULL, sglist_alloc, no_of_pages, 1);
+ dma_unmap_sg(NULL, sglist_alloc, ISP_BUFFER_MAX_PAGES, 1);
kfree(sglist_alloc);
vfree(buff_addr);
alloc_done = 0;
Index: omapzoom04/drivers/media/video/isp/isp.h
===
--- omapzoom04.orig/drivers/media/video/isp/isp.h
+++ omapzoom04/drivers/media/video/isp/isp.h
@@ -26,6 +26,9 @@
#define OMAP_ISP_TOP_H
#include media/videobuf-dma-sg.h
#include linux/videodev2.h
+
+#include ispmmu.h
+
#define OMAP_ISP_CCDC(1 0)
#define OMAP_ISP_PREVIEW (1 1)
#define OMAP_ISP_RESIZER (1 2)
@@ -69,8 +72,8 @@
#define NUM_ISP_CAPTURE_FORMATS (sizeof(isp_formats) /\
sizeof(isp_formats[0]))
#define ISP_WORKAROUND 1
-#define buffer_size (1024 * 1024 * 10)
-#define no_of_pages (buffer_size / (4 * 1024))
+#define ISP_BUFFER_MAX_SIZE (1024 * 1024 * 16)
+#define ISP_BUFFER_MAX_PAGES (ISP_BUFFER_MAX_SIZE / ISPMMU_PAGE_SIZE)
typedef int (*isp_vbq_callback_ptr) (struct videobuf_buffer *vb);
typedef void (*isp_callback_t) (unsigned long status,
Index: omapzoom04/drivers/media/video/isp/ispccdc.c
===
--- omapzoom04.orig/drivers/media/video/isp/ispccdc.c
+++ omapzoom04/drivers/media/video/isp/ispccdc.c
@@ -1265,6 +1265,8 @@ int ispccdc_config_size(u32 input_w, u32
}
if (ispccdc_obj.ccdc_outfmt == CCDC_OTHERS_VP) {
+ ispccdc_obj.ccdcin_woffset = 0;
+ ispccdc_obj.ccdcin_hoffset = 0;
omap_writel((ispccdc_obj.ccdcin_woffset
ISPCCDC_FMT_HORZ_FMTSPH_SHIFT) |
(ispccdc_obj.ccdcin_w
Index: omapzoom04/drivers/media/video/isp/ispmmu.h
RE: [OMAPZOOM][PATCH 4/6] Add support for Sony imx046 to OMAP3430 SDP board.
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, January 29, 2009 9:50 PM
To: Curran, Dominic; linux-omap; video4linux-l...@redhat.com
Cc: greg.ho...@hp.com
Subject: RE: [OMAPZOOM][PATCH 4/6] Add support for Sony imx046 to OMAP3430 SDP
board.
Thanks,
Vaibhav Hiremath
-Original Message-
From: video4linux-list-boun...@redhat.com [mailto:video4linux-list-
boun...@redhat.com] On Behalf Of Curran, Dominic
Sent: Friday, January 30, 2009 6:24 AM
To: linux-omap; video4linux-l...@redhat.com
Cc: greg.ho...@hp.com
Subject: [OMAPZOOM][PATCH 4/6] Add support for Sony imx046 to
OMAP3430 SDP board.
From: Dominic Curran dcur...@ti.com
Subject: [OMAPZOOM][PATCH 4/6] Add support for Sony imx046 to
OMAP3430 SDP board.
Support for the Sony IMX046 sensor on the OMAP3430 SDP board.
Signed-off-by: Greg Hofer greg.ho...@hp.com
Signed-off-by: Dominic Curran dcur...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 197
1 file changed, 197 insertions(+)
Index: omapzoom04/arch/arm/mach-omap2/board-3430sdp.c
===
--- omapzoom04.orig/arch/arm/mach-omap2/board-3430sdp.c
+++ omapzoom04/arch/arm/mach-omap2/board-3430sdp.c
@@ -45,6 +45,9 @@
#include ti-compat.h
Hi Vaibhav
Thank you for your comments.
I've taken all your comments, apart from two:
#ifdef CONFIG_VIDEO_OMAP3
+#ifndef CONFIG_TWL4030_CORE
+#error no power companion board defined!
+#endif
[Hiremath, Vaibhav] Do we really required to do this?
Well its not required, but my feeling is that it could be useful.
It was originally around every instance of the twl4030_i2c_write_u8() function
and that was quite ugly.
So I moved it to the top here to cover all the sensors that the SDP supports.
I will reconsider if you feel it's a big issue.
I will resubmit shortly.
Thanks
dom
#include media/v4l2-int-device.h
#include ../drivers/media/video/omap34xxcam.h
#include ../drivers/media/video/isp/ispreg.h
@@ -52,9 +55,11 @@
#define FPGA_SPR_GPIO1_3v3 (0x1 14)
#define FPGA_GPIO6_DIR_CTRL(0x1 6)
static void __iomem *fpga_map_addr;
+
#if defined(CONFIG_VIDEO_MT9P012) ||
defined(CONFIG_VIDEO_MT9P012_MODULE)
#include ../drivers/media/video/mt9p012.h
#endif
+
#if defined(CONFIG_VIDEO_OV3640) ||
defined(CONFIG_VIDEO_OV3640_MODULE)
#include ../drivers/media/video/ov3640.h
#include ../drivers/media/video/isp/ispcsi2.h
@@ -71,6 +76,22 @@ static struct omap34xxcam_hw_config *hwc
#define OV3640_CSI2_PHY_TCLK_MISS 1
#define OV3640_CSI2_PHY_TCLK_SETTLE14
#endif
+
+#if defined(CONFIG_VIDEO_IMX046) ||
defined(CONFIG_VIDEO_IMX046_MODULE)
+#include ../drivers/media/video/imx046.h
+#include ../drivers/media/video/isp/ispcsi2.h
+#define IMX046_CSI2_CLOCK_POLARITY 0 /* +/- pin order */
+#define IMX046_CSI2_DATA0_POLARITY 0 /* +/- pin order */
+#define IMX046_CSI2_DATA1_POLARITY 0 /* +/- pin order */
+#define IMX046_CSI2_CLOCK_LANE 1/* Clock lane
position: 1 */
+#define IMX046_CSI2_DATA0_LANE 2/* Data0 lane
position: 2 */
+#define IMX046_CSI2_DATA1_LANE 3/* Data1 lane
position: 3 */
+#define IMX046_CSI2_PHY_THS_TERM 2
+#define IMX046_CSI2_PHY_THS_SETTLE 23
+#define IMX046_CSI2_PHY_TCLK_TERM 0
+#define IMX046_CSI2_PHY_TCLK_MISS 1
+#define IMX046_CSI2_PHY_TCLK_SETTLE14
+#endif
#endif
#ifdef CONFIG_VIDEO_DW9710
@@ -926,6 +947,176 @@ static struct ov3640_platform_data sdp34
#endif
+
+#if defined(CONFIG_VIDEO_IMX046) ||
defined(CONFIG_VIDEO_IMX046_MODULE)
+
+static struct omap34xxcam_sensor_config imx046_hwc = {
+ .sensor_isp = 0,
+ .xclk = OMAP34XXCAM_XCLK_B,
+ .capture_mem = PAGE_ALIGN(3280 * 2464 * 2) * 2,
+};
+
[Hiremath, Vaibhav] You may want to align the structure, same comment I had
also received from Tony on MMDC support patch.
+static int imx046_sensor_set_prv_data(void *priv)
+{
+ struct omap34xxcam_hw_config *hwc = priv;
+
+ hwc-u.sensor.xclk = imx046_hwc.xclk;
+ hwc-u.sensor.sensor_isp = imx046_hwc.sensor_isp;
+ hwc-dev_index = 2;
+ hwc-dev_minor = 5;
+ hwc-dev_type = OMAP34XXCAM_SLAVE_SENSOR;
+ hwc-interface_type = ISP_CSIA;
+
+ hwc-csi2.hw_csi2.lanes.clock.polarity =
IMX046_CSI2_CLOCK_POLARITY;
+ hwc-csi2.hw_csi2.lanes.clock.position =
IMX046_CSI2_CLOCK_LANE;
+ hwc-csi2.hw_csi2.lanes.data[0].polarity =
IMX046_CSI2_DATA0_POLARITY;
+ hwc-csi2.hw_csi2.lanes.data[0].position =
IMX046_CSI2_DATA0_LANE;
+ hwc-csi2.hw_csi2.lanes.data[1].polarity =
IMX046_CSI2_DATA1_POLARITY;
+ hwc-csi2.hw_csi2.lanes.data[1].position =
IMX046_CSI2_DATA1_LANE;
+ hwc-csi2.hw_csi2.phy.ths_term = IMX046_CSI2_PHY_THS_TERM;
+ hwc-csi2.hw_csi2.phy.ths_settle = IMX046_CSI2_PHY_THS_SETTLE
RE: [OMAPZOOM][PATCH 5/6] ZOOM2: Rename the zoom2 i2c struct.
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, January 29, 2009 9:52 PM
To: Curran, Dominic; linux-omap; video4linux-l...@redhat.com
Cc: greg.ho...@hp.com
Subject: RE: [OMAPZOOM][PATCH 5/6] ZOOM2: Rename the zoom2 i2c struct.
Thanks,
Vaibhav Hiremath
-Original Message-
From: video4linux-list-boun...@redhat.com [mailto:video4linux-list-
boun...@redhat.com] On Behalf Of Curran, Dominic
Sent: Friday, January 30, 2009 6:24 AM
To: linux-omap; video4linux-l...@redhat.com
Cc: greg.ho...@hp.com
Subject: [OMAPZOOM][PATCH 5/6] ZOOM2: Rename the zoom2 i2c struct.
From: Dominic Curran dcur...@ti.com
Subject: [OMAPZOOM][PATCH 5/6] ZOOM2: Rename the zoom2 i2c struct.
Rename i2c structures to something sensible.
This patch is not specific for imx046 sensor.
Do this in preparation for i2c changes for imx046 sensor.
Signed-off-by: Greg Hofer greg.ho...@hp.com
Signed-off-by: Dominic Curran dcur...@ti.com
---
arch/arm/mach-omap2/board-zoom2.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Index: omapzoom04/arch/arm/mach-omap2/board-zoom2.c
===
--- omapzoom04.orig/arch/arm/mach-omap2/board-zoom2.c
+++ omapzoom04/arch/arm/mach-omap2/board-zoom2.c
@@ -472,7 +472,7 @@ static struct twl4030_platform_data ldp_
.keypad = ldp_kp_twl4030_data,
};
-static struct i2c_board_info __initdata ldp_i2c_boardinfo[] = {
+static struct i2c_board_info __initdata zoom2_i2c_bus1_info[] = {
[Hiremath, Vaibhav] I think zoom2_i2c1_info should be sufficient, since
i2c1,2,3 itself indicates bus.
I also didn't take this.
As a 'newbie' I was a little confused what this structure was about when I
first came across it, and having the word 'bus' there would have helped me.
Again, I will reconsider if you feel it's a big issue.
Thanks
dom
{
I2C_BOARD_INFO(twl4030, 0x48),
.flags = I2C_CLIENT_WAKE,
@@ -507,7 +507,7 @@ static struct synaptics_i2c_rmi_platform
.power = synaptics_power,
};
-static struct i2c_board_info __initdata ldp3430_i2c_board_info[] =
{
+static struct i2c_board_info __initdata zoom2_i2c_bus2_info[] = {
{
I2C_BOARD_INFO(SYNAPTICS_I2C_RMI_NAME,
SYNAPTICS_I2C_ADDR),
.platform_data = ldp3430_synaptics_platform_data,
@@ -518,12 +518,12 @@ static struct i2c_board_info __initdata
static int __init omap_i2c_init(void)
{
- omap_register_i2c_bus(1, 2600, ldp_i2c_boardinfo,
- ARRAY_SIZE(ldp_i2c_boardinfo));
+ omap_register_i2c_bus(1, 2600, zoom2_i2c_bus1_info,
+ ARRAY_SIZE(zoom2_i2c_bus1_info));
#ifdef CONFIG_TOUCHSCREEN_SYNAPTICS
- ldp3430_i2c_board_info[0].irq =
OMAP_GPIO_IRQ(OMAP_SYNAPTICS_GPIO);
- omap_register_i2c_bus(2, 100, ldp3430_i2c_board_info,
- ARRAY_SIZE(ldp3430_i2c_board_info));
+ zoom2_i2c_bus2_info[0].irq =
OMAP_GPIO_IRQ(OMAP_SYNAPTICS_GPIO);
+ omap_register_i2c_bus(2, 100, zoom2_i2c_bus2_info,
+ ARRAY_SIZE(zoom2_i2c_bus2_info));
#endif
omap_register_i2c_bus(3, 400, NULL, 0);
return 0;
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-
requ...@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [OMAPZOOM][PATCH 3/6] IMX046: Add support for Sony imx046 sensor.
-Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Friday, January 30, 2009 2:54 AM To: video4linux-l...@redhat.com Cc: Curran, Dominic; linux-omap; greg.ho...@hp.com Subject: Re: [OMAPZOOM][PATCH 3/6] IMX046: Add support for Sony imx046 sensor. Hi Dominic! First a small thing: please post to the new linux-media list in the future as this list is being phased out. [DC] OK, I have now subscribed to that list and will post to it when I resubmit. Thanks. On Friday 30 January 2009 01:53:38 Dominic Curran wrote: From: Dominic Curran dcur...@ti.com Subject: [OMAPZOOM][PATCH 3/6] IMX046: Add support for Sony imx046 sensor. This patch adds the driver files for the Sony IMX046 8MP camera sensor. Driver sets up the sensor to send frame data via the MIPI CSI2 i/f. Sensor is setup to output the following base sizes: - 3280 x 2464 (8MP) - 3280 x 616 (2MP) - 820 x 616 Sensor's output image format is Bayer10 (GrR/BGb). Driver has V4L2 controls for: - Exposure - Analog Gain Signed-off-by: Greg Hofer greg.ho...@hp.com Signed-off-by: Dominic Curran dcur...@ti.com --- drivers/media/video/Kconfig |8 drivers/media/video/Makefile |1 drivers/media/video/imx046.c | 1635 +++ drivers/media/video/imx046.h | 326 4 files changed, 1970 insertions(+) create mode 100644 drivers/media/video/imx046.c create mode 100644 drivers/media/video/imx046.h Index: omapzoom04/drivers/media/video/Kconfig === --- omapzoom04.orig/drivers/media/video/Kconfig +++ omapzoom04/drivers/media/video/Kconfig @@ -334,6 +334,14 @@ config VIDEO_OV3640_CSI2 This enables the use of the CSI2 serial bus for the ov3640 camera. +config VIDEO_IMX046 + tristate Sony IMX046 sensor driver (8MP) + depends on I2C VIDEO_V4L2 + ---help--- + This is a Video4Linux2 sensor-level driver for the Sony + IMX046 camera. It is currently working with the TI OMAP3 + camera controller. + Does this need an OMAP3 dependency? Or is it fully independent from omap? [DC] OK, I have removed the text concerning OMAP3. Yes, the driver 'should' be independent of OMAP. config VIDEO_SAA7110 tristate Philips SAA7110 video decoder depends on VIDEO_V4L1 I2C Index: omapzoom04/drivers/media/video/Makefile === --- omapzoom04.orig/drivers/media/video/Makefile +++ omapzoom04/drivers/media/video/Makefile @@ -115,6 +115,7 @@ obj-$(CONFIG_VIDEO_OV9640) += ov9640.o obj-$(CONFIG_VIDEO_MT9P012)+= mt9p012.o obj-$(CONFIG_VIDEO_DW9710) += dw9710.o obj-$(CONFIG_VIDEO_OV3640) += ov3640.o +obj-$(CONFIG_VIDEO_IMX046) += imx046.o obj-$(CONFIG_USB_DABUSB)+= dabusb.o obj-$(CONFIG_USB_OV511) += ov511.o Index: omapzoom04/drivers/media/video/imx046.c === --- /dev/null +++ omapzoom04/drivers/media/video/imx046.c @@ -0,0 +1,1635 @@ +/* + * drivers/media/video/imx046.c + * + * Sony imx046 sensor driver + * + * + * Copyright (C) 2008 Hewlett Packard + * + * Leverage mt9p012.c + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed as is without any warranty of any + * kind, whether express or implied. + */ + +#include linux/i2c.h +#include linux/delay.h +#include media/v4l2-int-device.h A general note on the usage of v4l2-int-device.h: this will be phased out soon in favor of v4l2-subdev (see Documentation/video4linux/v4l2-framework.txt, introduced in 2.6.29). You might want to discuss this with Vaibhav Hiremath regarding the timescale of this conversion and whether it is better to wait until omap has been converted before merging this driver. I'm willing to accept the driver using the v4l2-int-device interface as long as I get the assurance that it will be converted later. [DC] Yes I certainly would like for the driver to be accepted into the V4L2 tree. However, my first goal is to: 1) run by v4l2 list and get comments. 2) get it accepted into omapzoom tree. I believe omapzoom will move to 2.6.29 in near future. At which stage I will patch this driver as appropriate for v4l2-framework and then resubmit to linux-media. Thanks dom Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH omapzoom tree] Fix keypad for LDP
Hi Vikram,
This patch fixes the keypad for LDP on the OMAPZOOM tree.
- Adds dependency on MACH_LDP for TWL4030 KEYPAD menuconfig option.
- Adds correct keypad IRQ to LDP board file.
- Adds the struct omap_keypad to GPIO part of the T2 keypad driver.
Regards,
dom
Signed-off-by: Dominic Curran [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-ldp.c|1 +
drivers/input/keyboard/Kconfig |2 +-
drivers/input/keyboard/omap-twl4030keypad.c| 25
3 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 175668e..58f56a2 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -286,6 +286,7 @@ static struct omap_kp_platform_data ldp_kp_data = {
.keymap = ldp_twl4030_keymap,
.keymapsize = ARRAY_SIZE(ldp_twl4030_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
/* Use row_gpios as a way to pass the OMAP GPIO keymap pointer */
.row_gpios = ldp_omap_gpio_keymap,
};
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index e4d0436..c8abf13 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -261,7 +261,7 @@ config KEYBOARD_OMAP
config KEYBOARD_TWL4030
tristate TI TWL4030 keypad support
- depends on TWL4030_CORE (MACH_OMAP_2430SDP || MACH_OMAP2EVM ||
MACH_OMAP_3430SDP || MACH_OMAP3EVM)
+ depends on TWL4030_CORE (MACH_OMAP_2430SDP || MACH_OMAP2EVM ||
MACH_OMAP_3430SDP || MACH_OMAP3EVM || MACH_OMAP_LDP)
help
Say Y here if you want to use the OMAP TWL4030 keypad.
diff --git a/drivers/input/keyboard/omap-twl4030keypad.c
b/drivers/input/keyboard/omap-twl4030keypad.c
index 1ca2987..87ee1dd 100644
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -38,6 +38,7 @@
#include linux/i2c.h
#include linux/i2c/twl4030.h
#include linux/irq.h
+#include mach/gpio.h
#include mach/keypad.h
#include twl4030-keypad.h
@@ -241,7 +242,7 @@ static irqreturn_t do_kp_irq(int irq, void *_kp)
}
#ifdef CONFIG_MACH_OMAP_LDP
-static void omap_gpio_kp_scan(void)
+static void omap_gpio_kp_scan(struct omap_keypad *kp)
{
unsigned int new_gpio;
int idx = 0, chg = 0, key, state;
@@ -254,7 +255,7 @@ static void omap_gpio_kp_scan(void)
if (chg) {
key = GET_KEY(omap_gpios[idx]);
state = (new_gpio == 0);
- input_report_key(omap_twl4030kp, key, state);
+ input_report_key(kp-omap_twl4030kp, key, state);
}
if (!new_gpio)
@@ -281,10 +282,12 @@ static void omap_gpio_kp_scan(void)
/*
* Keypad interrupt handler for OMAP GPIO's.
*/
-static irqreturn_t do_kp_gpio_irq(int irq, void *dev_id)
+static irqreturn_t do_kp_gpio_irq(int irq, void *_kp)
{
+ struct omap_keypad *kp = _kp;
+
/* Scan keypad for any changes in GPIO keys. */
- omap_gpio_kp_scan();
+ omap_gpio_kp_scan(kp);
return IRQ_HANDLED;
}
@@ -292,10 +295,12 @@ static irqreturn_t do_kp_gpio_irq(int irq, void *dev_id)
static void omap_gpio_kp_timer(unsigned long arg)
{
- omap_gpio_kp_scan();
+ struct omap_keypad *kp = (struct omap_keypad*)arg;
+ omap_gpio_kp_scan(kp);
}
-static int omap_gpio_kp_probe(unsigned int *gpio_keymap)
+static int
+omap_gpio_kp_probe(struct omap_keypad *kp, unsigned int *gpio_keymap)
{
int i, idx = 0, irq_idx = 0;
@@ -321,18 +326,18 @@ static int omap_gpio_kp_probe(unsigned int *gpio_keymap)
while (omap_gpios[irq_idx] != 0) {
if (request_irq(OMAP_GPIO_IRQ(GET_GPIO(omap_gpios[irq_idx])),
do_kp_gpio_irq, IRQF_TRIGGER_FALLING,
- omap-keypad, NULL) 0)
+ omap-keypad, kp) 0)
goto err2;
irq_idx++;
}
/* Initialize GPIO timer */
gpio_timer.function = omap_gpio_kp_timer;
- gpio_timer.data = (unsigned long)NULL;
+ gpio_timer.data = (unsigned long)kp;
init_timer(gpio_timer);
/* scan current key state */
- omap_gpio_kp_scan();
+ omap_gpio_kp_scan(kp);
return 0;
@@ -503,7 +508,7 @@ static int __init omap_kp_probe(struct platform_device
*pdev)
goto err4;
#ifdef CONFIG_MACH_OMAP_LDP
- omap_gpio_kp_probe(pdata-row_gpios);
+ omap_gpio_kp_probe(kp, pdata-row_gpios);
#endif
return ret;
--
1.5.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
