* [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging support
From: hvaibhav at ti.com @ 2011-09-20 14:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Afzal Mohammed <afzal@ti.com>
Add support for low level debugging on AM335X EVM (AM33XX family).
Currently only support for UART1 console, which is used on AM335X EVM
is added.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
---
arch/arm/mach-omap2/include/mach/debug-macro.S | 22 ++++++++++++++++++++++
arch/arm/plat-omap/include/plat/serial.h | 4 ++++
arch/arm/plat-omap/include/plat/uncompress.h | 6 ++++++
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 48adfe9..f649973 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -78,6 +78,8 @@ omap_uart_lsr: .word 0
beq 82f @ configure UART2
cmp \rp, #TI816XUART3 @ ti816x UART offsets different
beq 83f @ configure UART3
+ cmp \rp, #AM33XXUART1 @ AM33XX UART offsets different
+ beq 84f @ configure UART1
cmp \rp, #ZOOM_UART @ only on zoom2/3
beq 95f @ configure ZOOM_UART
@@ -106,6 +108,9 @@ omap_uart_lsr: .word 0
b 98f
83: mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
b 98f
+84: ldr \rp, =AM33XX_UART1_BASE
+ and \rp, \rp, #0x00ffffff
+ b 97f
95: ldr \rp, =ZOOM_UART_BASE
mrc p15, 0, \rv, c1, c0
tst \rv, #1 @ MMU enabled?
@@ -121,6 +126,23 @@ omap_uart_lsr: .word 0
b 10b
/* Store both phys and virt address for the uart */
+97: add \rp, \rp, #0x44000000 @ phys base
+ mrc p15, 0, \rv, c1, c0
+ tst \rv, #1 @ MMU enabled?
+ ldreq \rv, =omap_uart_v2p(omap_uart_phys) @ MMU disabled
+ ldrne \rv, =omap_uart_phys @ MMU enabled
+ str \rp, [\rv, #0]
+ sub \rp, \rp, #0x44000000 @ phys base
+ add \rp, \rp, #0xf9000000 @ virt base
+ add \rv, \rv, #4 @ omap_uart_virt
+ str \rp, [\rv, #0]
+ mov \rp, #(UART_LSR << OMAP_PORT_SHIFT)
+ add \rv, \rv, #4 @ omap_uart_lsr
+ str \rp, [\rv, #0]
+
+ b 10b
+
+ /* Store both phys and virt address for the uart */
98: add \rp, \rp, #0x48000000 @ phys base
mrc p15, 0, \rv, c1, c0
tst \rv, #1 @ MMU enabled?
diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-omap/include/plat/serial.h
index de3b10c..ad19377 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -59,6 +59,9 @@
/* AM3505/3517 UART4 */
#define AM35XX_UART4_BASE 0x4809E000 /* Only on AM3505/3517 */
+/* AM33XX serial port */
+#define AM33XX_UART1_BASE 0x44E09000
+
/* External port on Zoom2/3 */
#define ZOOM_UART_BASE 0x10000000
#define ZOOM_UART_VIRT 0xfa400000
@@ -92,6 +95,7 @@
#define TI816XUART1 81
#define TI816XUART2 82
#define TI816XUART3 83
+#define AM33XXUART1 84
#define ZOOM_UART 95 /* Only on zoom2/3 */
/* This is only used by 8250.c for omap1510 */
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h
index a067484..bd1e051 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -97,6 +97,10 @@ static inline void flush(void)
_DEBUG_LL_ENTRY(mach, TI816X_UART##p##_BASE, OMAP_PORT_SHIFT, \
TI816XUART##p)
+#define DEBUG_LL_AM33XX(p, mach) \
+ _DEBUG_LL_ENTRY(mach, AM33XX_UART##p##_BASE, OMAP_PORT_SHIFT, \
+ AM33XXUART##p)
+
static inline void __arch_decomp_setup(unsigned long arch_id)
{
int port = 0;
@@ -173,6 +177,8 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
/* TI8168 base boards using UART3 */
DEBUG_LL_TI816X(3, ti8168evm);
+ /* AM33XX base boards using UART1 */
+ DEBUG_LL_AM33XX(1, am335xevm);
} while (0);
}
--
1.7.0.4
^ permalink raw reply related
* DT vs ARM static mappings
From: Rob Herring @ 2011-09-20 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316527365.4611.354.camel@hornet.cambridge.arm.com>
Pawel,
On 09/20/2011 09:02 AM, Pawel Moll wrote:
>>> Of course the simplest solution would be to define two different
>>> compatible values, eg. "arm,vexpress-legacy" would execute the current
>>> map_io implementation, while "arm,vexpress-rs1" would use different one,
>>> setting up the other map_desc (the MMIO_P2V macro must die of course,
>>> replaced with a runtime-defined virtual base address for the
>>> peripherals).
>>>
>>> If you believe that's what I should do, say it and stop reading :-)
>>
>> Yes. Different tiles are fundamentally different boards, so they should
>> have different DTs. Using includes should help minimize duplication though.
>
> You've misunderstood me or (most likely ;-) probably I wasn't clear
> enough.
>
> There is no doubt the DTs will be different across the "portfolio".
>
> We already have (patches soon) vexpress-v2p-ca9.dts that includes
> vexpress-v2m-legacy.dtsi.
>
> A5 will be vexpress-v2p-ca5p.dts+vexpress-v2m-rs1.dtsi, A15
> vexpress-v2p-ca15.dts+vexpress-v2m-rs1.dtsi (notice that the A5/A15 are
> sharing the v2m bit, as the motherboard is common).
>
> My point is that we should be able to handle _all_ of them using one
> DT_MACHINE_START with a single compat value "arm,vexpress". The only
> problem with this (so far) is the mapping.
>
Yes, you should have 1 DT_MACHINE_START, but arm,vexpress is too
generic. You can and should have a list of compatible strings for each
board/machine.
>> Think about it this way. How would you solve this without DT? You
>> would have a bunch of duplicated data in the kernel for the different
>> configs. So you're not any worse off in this regard and still have the
>> other advantages of DT.
>
> Exactly my point :-) I want to have as little duplication as possible.
> And the static mapping issue is in the way.
>
>>> To my mind it looked like the whole mechanism was not flexible enough,
>>> so I wanted to explore other options...
>>>
>>> The obvious one was to describe the required static mapping in the DTS.
>>> I don't like this idea, though. It can hardly be called "hardware
>>> description". Besides, what node would carry such data? "chosen"?
>>> Hardly...
>>>
>>> Would it contain a "regs" property with the physical address and
>>> "virtual-reg" with the virtual one? Again, doesn't sound right to me
>>> (especially the virtual bit, however the virtual address could be common
>>> between different variants and be defined in the board support code, not
>>> the DTS).
>>>
>>> I have considered a reference (phandle or an alias?) to the node to be
>>> mapped ("peripherals" in my case), but where to define this reference?
>>> Any ideas?
>>
>> In "chosen" like the kernel command line would be the place, but I don't
>> think that is the right approach. Chosen is really for things that
>> change frequently and this doesn't really fall in that category.
>
> Again, no argument from me here :-)
>
> The question is - where should it be?
>
Nowhere. It's an OS specific issue, not a h/w issue.
>>> There is an additional problem here... The "map_io" is executed before
>>> the tree is un-flattened, so:
>>>
>>> 1. One can't simply use "of_find_matching_node()" (as in the latest l2x0
>>> patches) to find the interesting nodes - the only way of going through
>>> the tree is raw of_scan_flat_dt() function. Therefore any conditions
>>> more complex then string comparison with the (full) node name are
>>> problematic.
>>>
>>> 2. The tree mappings (ranges) are not resolved yet, so one can't simply
>>> get the effective address of a node. Only "raw" properties are
>>> available, so all one can get scanning for "peripherals at 7" node is "0 7
>>> 0 0x20000" array, instead of the "0x10000000 0x00020000" that is really
>>> important.
>>
>> If you add a compatible field to "motherboard" node, then you can read
>> the ranges.
>
> ... and then and then scan for the sysregs, and add the offset and base
> together... Sounds to me like duplication of the of_translate_*()?
>
>>> Initially I wanted to find the mentioned devices and create individual
>>> mappings for them, so the MMIO_P2V would be still valid (if slightly
>>> "abused"), but I failed due to the problems mentioned above. And I can't
>>> delay this operation till the tree is un-flattened, as the core tile
>>> must be probed (via sysreg) in map_io (tile's specific code must be able
>>> to create its own mappings):
>>
>> Do you really need MMIO_P2V? If you have fixed virtual addresses in the
>> kernel and can pull the phys addresses from DT to populate the iotable,
>> is that sufficient?
>
> For the third time, 100% agree :-) Well, 90%.
>
> What I need is:
>
> 1. Get the phys address from DT. But how? This is getting as back to my
> complaints about still-flat tree and ranges, the node to be used to
> describe the mapping.
>
> 2. The offset inside the mapping will be different (for sysregs it will
> be 0 for old mapping, 0x10000 for the new one), so I have to work it out
> from the tree as well. And as we are in map_io, the tree is still flat
> and... read 1 :-)
So create a mapping per peripheral rather than per chip select. Then the
virtual address can always be the same.
>
>> Generally, the trend is to get rid of static mappings as much as
>> possible. Doing that first might simplify things.
>
> You can't do ioremap() before kmalloc() is up and running (correct me if
> I am wrong), at least you can't do this in map_io. So the static mapping
> is a must sometimes. And actually, with the latest Nico's changes:
>
Correct. You can't do ioremap until init_irq. map_io and init_early are
too early. My point was if you can delay h/w access then you can remove
the static mappings. But yes, we generally can't remove them all. SCU
and LL debug uart are 2 examples.
For the short term, I would just have 2 static iotables and select the
right one based on the board's (or motherboard's) compatible string.
Long term, we should look into implementing a common early DT address
parsing function.
Rob
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/132762
>
> it may even be preferred for peripherals (one mapping shared across all
> users).
>
> Cheers!
>
> Pawe?
>
>
^ permalink raw reply
* [PATCH 1/3] include: fb: Add definiton for window positioning structure
From: Ajay kumar @ 2011-09-20 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316517021.1949.13.camel@deskari>
Hi Tomi,
On Tue, Sep 20, 2011 at 4:40 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Tue, 2011-09-20 at 11:30 -0400, Ajay Kumar wrote:
>> This patch adds a data structure definiton to hold framebuffer windows/planes.
>> An ioctl number is also added to provide user access
>> to change window position dynamically.
>>
>> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
>> Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> ---
>> ?include/linux/fb.h | ? ?7 +++++++
>> ?1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/fb.h b/include/linux/fb.h
>> index 1d6836c..2141941 100644
>> --- a/include/linux/fb.h
>> +++ b/include/linux/fb.h
>> @@ -39,6 +39,7 @@
>> ?#define FBIOPUT_MODEINFO ? ? ? ?0x4617
>> ?#define FBIOGET_DISPINFO ? ? ? ?0x4618
>> ?#define FBIO_WAITFORVSYNC ? ?_IOW('F', 0x20, __u32)
>> +#define FBIOPOS_OVERLAY_WIN ?_IOW('F', 0x21, struct fb_overlay_win_pos)
>>
>> ?#define FB_TYPE_PACKED_PIXELS ? ? ? ? ? ? ? ?0 ? ? ? /* Packed Pixels ? ? ? ?*/
>> ?#define FB_TYPE_PLANES ? ? ? ? ? ? ? ? ? ? ? 1 ? ? ? /* Non interleaved planes */
>> @@ -366,6 +367,12 @@ struct fb_image {
>> ? ? ? struct fb_cmap cmap; ? ?/* color map info */
>> ?};
>>
>> +/* Window overlaying */
>> +struct fb_overlay_win_pos {
>> + ? ? __u32 win_pos_x; ? ? ? ?/* x-offset from LCD(0,0) where window starts */
>> + ? ? __u32 win_pos_y; ? ? ? ?/* y-offset from LCD(0,0) where window starts */
>> +};
>
> Shouldn't this also include the window size (in case scaling is
> supported)?
The "xres" and "yres" fields in fb_var_screeninfo are being used to
represent the size of the window (visible resolution). So we have,
win_pos_x: x-offset from LCD(0,0) where window starts.
win_pos_y: y-offset from LCD(0,0) where window starts.
(win_pos_x + xres) : x-offset from LCD(0,0) where window ends.
(win_pos_y + yres) : y-offset from LCD(0,0) where window ends.
> This also won't work for setups where the same framebuffer is used by
> multiple overlays. For example, this is the case on OMAP when the same
> content is cloned to, say, LCD and TV, each of which is showing an
> overlay.
These x and y position are used to configure the display controller
(for LCD only) and not to alter the data in physical buffer
(framebuffer). Could you elaborate the above use case you have
mentioned and how adding the x and y offsets would not meet that
requirement.
> ?Tomi
>
Ajay
^ permalink raw reply
* [PATCH 0/5] OMAP3EVM: Add support for MT9T111 sensor
From: Deepthy Ravi @ 2011-09-20 14:56 UTC (permalink / raw)
To: linux-arm-kernel
This patchset
-adds support for MT9T111 sensor on omap3evm.
Currently the sensor driver supports only
VGA resolution.
-enables MT9T111 sensor in omap2plus_defconfig.
This is applied on top of the following patchset
http://www.spinics.net/lists/linux-media/msg37270.html
which adds YUYV input support for OMAP3ISP.
---
Deepthy Ravi (2):
ispccdc: Configure CCDC_SYN_MODE register for UYVY8_2X8 and
YUYV8_2X8 formats
omap2plus_defconfig: Enable omap3isp and MT9T111 sensor drivers
Vaibhav Hiremath (3):
omap3evm: Enable regulators for camera interface
[media] v4l: Add mt9t111 sensor driver
omap3evm: Add Camera board init/hookup file
arch/arm/configs/omap2plus_defconfig | 10 +
arch/arm/mach-omap2/Makefile | 5 +
arch/arm/mach-omap2/board-omap3evm-camera.c | 185 ++++
arch/arm/mach-omap2/board-omap3evm.c | 25 +
drivers/media/video/Kconfig | 7 +
drivers/media/video/Makefile | 1 +
drivers/media/video/mt9t111.c | 793 ++++++++++++++++
drivers/media/video/mt9t111_reg.h | 1367 +++++++++++++++++++++++++++
drivers/media/video/omap3isp/ispccdc.c | 11 +-
include/media/mt9t111.h | 45 +
10 files changed, 2446 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
create mode 100644 drivers/media/video/mt9t111.c
create mode 100644 drivers/media/video/mt9t111_reg.h
create mode 100644 include/media/mt9t111.h
^ permalink raw reply
* [PATCH 1/5] omap3evm: Enable regulators for camera interface
From: Deepthy Ravi @ 2011-09-20 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316530612-23075-1-git-send-email-deepthy.ravi@ti.com>
From: Vaibhav Hiremath <hvaibhav@ti.com>
Enabled 1v8 and 2v8 regulator output, which is being used by
camera module.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Deepthy Ravi <deepthy.ravi@ti.com>
---
arch/arm/mach-omap2/board-omap3evm.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index c452b3f..cf30fff 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -273,6 +273,25 @@ static struct omap_dss_board_info omap3_evm_dss_data = {
.default_device = &omap3_evm_lcd_device,
};
+static struct regulator_consumer_supply omap3evm_vaux3_supply[] = {
+ REGULATOR_SUPPLY("cam_2v8", NULL),
+};
+
+/* VAUX3 for CAM_2V8 */
+static struct regulator_init_data omap3evm_vaux3 = {
+ .constraints = {
+ .min_uV = 2800000,
+ .max_uV = 2800000,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap3evm_vaux3_supply),
+ .consumer_supplies = omap3evm_vaux3_supply,
+};
+
static struct regulator_consumer_supply omap3evm_vmmc1_supply[] = {
REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
};
@@ -433,6 +452,7 @@ static struct twl4030_keypad_data omap3evm_kp_data = {
/* ads7846 on SPI */
static struct regulator_consumer_supply omap3evm_vio_supply[] = {
REGULATOR_SUPPLY("vcc", "spi1.0"),
+ REGULATOR_SUPPLY("vio_1v8", NULL),
};
/* VIO for ads7846 */
@@ -499,6 +519,7 @@ static struct twl4030_platform_data omap3evm_twldata = {
.vio = &omap3evm_vio,
.vmmc1 = &omap3evm_vmmc1,
.vsim = &omap3evm_vsim,
+ .vaux3 = &omap3evm_vaux3,
};
static int __init omap3_evm_i2c_init(void)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/5] [media] v4l: Add mt9t111 sensor driver
From: Deepthy Ravi @ 2011-09-20 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316530612-23075-1-git-send-email-deepthy.ravi@ti.com>
From: Vaibhav Hiremath <hvaibhav@ti.com>
The MT9T111 is a 3.1Mp CMOS sensor from Aptina with
its latest image signal processing (ISP) and 1.75??m
pixel technology.
The sensor driver currently supports only VGA
resolution.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Deepthy Ravi <deepthy.ravi@ti.com>
---
drivers/media/video/Kconfig | 7 +
drivers/media/video/Makefile | 1 +
drivers/media/video/mt9t111.c | 793 +++++++++++++++++++++
drivers/media/video/mt9t111_reg.h | 1367 +++++++++++++++++++++++++++++++++++++
include/media/mt9t111.h | 45 ++
5 files changed, 2213 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9t111.c
create mode 100644 drivers/media/video/mt9t111_reg.h
create mode 100644 include/media/mt9t111.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f574dc0..ca374cb 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -482,6 +482,13 @@ config VIDEO_MT9V032
This is a Video4Linux2 sensor-level driver for the Micron
MT9V032 752x480 CMOS sensor.
+config VIDEO_MT9T111
+ tristate "Aptina MT9T111 VGA CMOS IMAGE SENSOR"
+ depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the Aptina MT9T111
+ image sensor.
+
config VIDEO_TCM825X
tristate "TCM825x camera sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 2723900..52cfef5 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
+obj-$(CONFIG_VIDEO_MT9T111) += mt9t111.o
obj-$(CONFIG_VIDEO_NOON010PC30) += noon010pc30.o
obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
obj-$(CONFIG_VIDEO_ADP1653) += adp1653.o
diff --git a/drivers/media/video/mt9t111.c b/drivers/media/video/mt9t111.c
new file mode 100644
index 0000000..5f6131a
--- /dev/null
+++ b/drivers/media/video/mt9t111.c
@@ -0,0 +1,793 @@
+/*
+ * drivers/media/video/mt9t111.c
+ *
+ * mt9t111 sensor driver
+ *
+ * Copyright (C) 2010 Texas Instruments Inc
+ * Author: Vaibhav Hiremath <hvaibhav@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/i2c.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/v4l2-mediabus.h>
+#include <linux/regulator/consumer.h>
+
+#include <media/v4l2-device.h>
+#include <media/v4l2-subdev.h>
+#include <media/v4l2-ctrls.h>
+#include <media/mt9t111.h>
+
+#include "mt9t111_reg.h"
+
+/*
+ * struct mt9t111 - main structure for storage of sensor information
+ * @subdev: V4L2 sub-device structure structure
+ * @pad: Media entity pad structure
+ * @format: Media-bus format
+ * @rect:
+ * @pix: V4L2 pixel format information structure
+ * @ctrls: v4l2 control handler
+ * @frameival: sub-dev pad frame interval
+ * @pdata: access functions and data for platform level information
+ * @ver: mt9t111 chip version
+ * @power: Turn on OR off the interface
+ * @omap3evm_1v8: pointer to the regulator used for camera interface
+ * @omap3evm_2v8: pointer to the regulator used for camera interface
+ */
+struct mt9t111 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt format;
+ struct v4l2_rect rect;
+ struct v4l2_pix_format pix;
+
+ struct v4l2_ctrl_handler ctrls;
+
+ struct mt9t111_platform_data *pdata;
+ int ver;
+ unsigned int power;
+ struct regulator *omap3evm_1v8;
+ struct regulator *omap3evm_2v8;
+};
+
+#define to_mt9t111(sd) container_of(sd, struct mt9t111, subdev)
+
+/*
+ * struct mt9t111_fmt -
+ * @mbus_code: associated media bus code
+ * @fmt: format descriptor
+ */
+struct mt9t111_fmt {
+ unsigned int mbus_code;
+ struct v4l2_fmtdesc fmt;
+};
+
+/*
+ * List of image formats supported by mt9t111
+ * Currently we are using 8 bit and 8x2 bit mode only, but can be
+ * extended to 10 bit mode.
+ */
+static const struct mt9t111_fmt mt9t111_fmt_list[] = {
+ {
+ .mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
+ .fmt = {
+ .index = 0,
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .flags = 0,
+ .description = "8-bit UYVY 4:2:2 Format",
+ .pixelformat = V4L2_PIX_FMT_UYVY,
+ },
+ },
+ {
+ .mbus_code = V4L2_MBUS_FMT_YUYV8_2X8,
+ .fmt = {
+ .index = 1,
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .flags = 0,
+ .description = "8-bit YUYV 4:2:2 Format",
+ .pixelformat = V4L2_PIX_FMT_YUYV,
+ },
+ },
+ {
+ .mbus_code = V4L2_MBUS_FMT_RGB565_2X8_LE,
+ .fmt = {
+ .index = 2,
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .flags = 0,
+ .description = "16-bit RGB565 format",
+ .pixelformat = V4L2_PIX_FMT_RGB565,
+ },
+ },
+};
+
+/*
+ * mt9t111_read_reg - Read a value from a register in an mt9t111 sensor device
+ * @client: i2c driver client structure
+ * @data_length: length of data to be read
+ * @reg: register address / offset
+ * @val: stores the value that gets read
+ *
+ * Read a value from a register in an mt9t111 sensor device.
+ * The value is returned in 'val'.
+ * Returns zero if successful, or non-zero otherwise.
+ */
+static int mt9t111_read_reg(struct i2c_client *client, u16 reg, u16 *val)
+{
+ struct i2c_msg msg[1];
+ u8 data[4];
+ int err;
+
+ msg->addr = client->addr;
+ msg->flags = 0;
+ msg->len = 2;
+ msg->buf = data;
+ data[0] = (reg & 0xff00) >> 8;
+ data[1] = (reg & 0x00ff);
+ err = i2c_transfer(client->adapter, msg, 1);
+ if (err >= 0) {
+ msg->flags = I2C_M_RD;
+ msg->len = 2; /* 2 byte read */
+ err = i2c_transfer(client->adapter, msg, 1);
+ if (err >= 0) {
+ *val = ((data[0] & 0x00ff) << 8)
+ | (data[1] & 0x00ff);
+ return 0;
+ }
+ }
+ return err;
+}
+
+/*
+ * mt9t111_write_reg - Write a value to a register in an mt9t111 sensor device
+ * @client: i2c driver client structure
+ * @data_length: length of data to be read
+ * @reg: register address / offset
+ * @val: value to be written to specified register
+ *
+ * Write a value to a register in an mt9t111 sensor device.
+ * Returns zero if successful, or non-zero otherwise.
+ */
+static int mt9t111_write_reg(struct i2c_client *client, u16 reg, u16 val)
+{
+ struct i2c_msg msg[1];
+ u8 data[20];
+ int err;
+
+ msg->addr = client->addr;
+ msg->flags = 0;
+ msg->len = 4;
+ msg->buf = data;
+ data[0] = (u8)((reg & 0xff00) >> 8);
+ data[1] = (u8)(reg & 0x00ff);
+ data[2] = (u8)((val & 0xff00) >> 8);
+ data[3] = (u8)(val & 0x00ff);
+ err = i2c_transfer(client->adapter, msg, 1);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+/*
+ * mt9t111_write_regs - Write registers to an mt9t111 sensor device
+ * @client: i2c driver client structure
+ * @reg_in: pointer to registers to write
+ * @cnt: the number of registers
+ *
+ * Write registers .
+ * Returns zero if successful, or non-zero otherwise.
+ */
+static int mt9t111_write_regs(struct i2c_client *client,
+ mt9t111_regs *reg_in, int cnt)
+{
+ int err = 0, i;
+ mt9t111_regs *reg = reg_in;
+
+ for (i = 0; i < cnt; i++) {
+ if (reg->delay_time == 0) {
+ err |= mt9t111_write_reg(client, reg->addr, reg->data);
+ } else if (reg->addr != 0 || reg->data != 0) {
+ err |= mt9t111_write_reg(client, reg->addr, reg->data);
+ mdelay(reg->delay_time);
+ } else {
+ mdelay(reg->delay_time);
+ }
+
+ if (err < 0) {
+ dev_warn(&client->dev, "write reg error, addr = 0x%x,"
+ "data = 0x%x\n",
+ reg->addr, reg->data);
+ return err;
+ }
+ reg++;
+ }
+ return err;
+}
+
+
+static int mt9t111_refresh(struct i2c_client *client)
+{
+ int i, err = 0;
+ unsigned short value;
+
+ /* MCU_ADDRESS [SEQ_CMD] -- refresh mode */
+ err = mt9t111_write_reg(client, 0x098E, 0x8400);
+ if (err)
+ return err;
+ err = mt9t111_write_reg(client, 0x0990, 0x0006);
+ if (err)
+ return err;
+
+ /* refresh command */
+ err = mt9t111_write_reg(client, 0x098E, 0x8400);
+ if (err)
+ return err;
+ err = mt9t111_write_reg(client, 0x0990, 0x0005);
+ if (err)
+ return err;
+
+ for (i = 0; i < 100; i++) {
+ err = mt9t111_write_reg(client, 0x098E, 0x8400);
+ if (err)
+ break;
+ err = mt9t111_read_reg(client, 0x0990, &value);
+ if ((value == 0) || (err))
+ break;
+ mdelay(5);
+ }
+
+ return err;
+}
+
+static int mt9t111_enable_pll(struct i2c_client *client)
+{
+ int i, err = 0;
+ unsigned short value;
+
+ err = mt9t111_write_regs(client, pll_regs1,
+ sizeof(pll_regs1) / sizeof(mt9t111_regs));
+ if (err)
+ return err;
+
+ for (i = 0; i < 100; i++) {
+ err = mt9t111_read_reg(client, 0x0014, &value);
+ if (((value & 0x8000) != 0) || (err))
+ break;
+ mdelay(2);
+ }
+ err = mt9t111_write_regs(client, pll_regs2,
+ sizeof(pll_regs2) / sizeof(mt9t111_regs));
+ return err;
+}
+
+/*
+ * mt9t111_configure - Configure the mt9t111 for the specified image mode
+ * @s: pointer to standard V4L2 device structure
+ *
+ * Configure the mt9t111 for a specified image size, pixel format, and frame
+ * period. xclk is the frequency (in Hz) of the xclk input to the mt9t111.
+ * fper is the frame period (in seconds) expressed as a fraction.
+ * Returns zero if successful, or non-zero otherwise.
+ * The actual frame period is returned in fper.
+ */
+static int mt9t111_configure(struct v4l2_subdev *subdev)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(subdev);
+ int err = 0;
+
+ err = mt9t111_write_reg(client, 0x001A, 0x001D);
+ if (err < 0)
+ return err;
+
+ msleep(1);
+
+ err = mt9t111_write_reg(client, 0x001A, 0x0018);
+ if (err < 0)
+ goto out;
+
+ err = mt9t111_enable_pll(client);
+ if (err)
+ goto out;
+
+ err = mt9t111_write_regs(client, def_regs1,
+ sizeof(def_regs1) / sizeof(mt9t111_regs));
+ if (err)
+ goto out;
+
+ err = mt9t111_write_regs(client, patch_rev6,
+ sizeof(patch_rev6) / sizeof(mt9t111_regs));
+ if (err)
+ goto out;
+
+ err = mt9t111_write_regs(client, def_regs2,
+ sizeof(def_regs2) / sizeof(mt9t111_regs));
+ if (err)
+ goto out;
+
+ err = mt9t111_refresh(client);
+out:
+ return err;
+}
+
+/*
+ * mt9t111_detect - Detect if an mt9t111 is present, and if so which revision
+ * @subdev: pointer to the V4L2 sub-device driver structure
+ *
+ * Detect if an mt9t111 is present
+ * Returns a negative error number if no device is detected, or the
+ * non-negative value of the version ID register if a device is detected.
+ */
+static int mt9t111_detect(struct v4l2_subdev *subdev)
+{
+ u16 val;
+ struct i2c_client *client = v4l2_get_subdevdata(subdev);
+
+ /* chip ID is@address 0 */
+ if (mt9t111_read_reg(client, MT9T111_CHIP_ID, &val) < 0)
+ return -ENODEV;
+
+ if (val != MT9T111_CHIP_ID_VALUE) {
+ dev_err(&client->dev, "model id mismatch received 0x%x"
+ " expecting 0x%x\n",
+ val, MT9T111_CHIP_ID_VALUE);
+ return -ENODEV;
+ }
+
+ return (int)val;
+
+}
+
+/*
+ * mt9t111_dev_init - sensor init, tries to detect the sensor
+ * @subdev: pointer to standard V4L2 subdev structure
+ */
+
+static int mt9t111_dev_init(struct v4l2_subdev *subdev)
+{
+ struct mt9t111 *mt9t111 = to_mt9t111(subdev);
+ struct i2c_client *client = v4l2_get_subdevdata(subdev);
+ int rval;
+
+ rval = mt9t111->pdata->s_power(subdev, 1);
+ if (rval)
+ return rval;
+
+ rval = mt9t111_detect(subdev);
+ if (rval < 0) {
+ v4l_err(client, "Unable to detect"
+ MT9T111_MODULE_NAME "sensor\n");
+ goto out;
+ }
+ mt9t111->ver = rval;
+ v4l_info(client, MT9T111_MODULE_NAME
+ " chip version 0x%02x detected\n", mt9t111->ver);
+ rval = 0;
+out:
+ mt9t111->pdata->s_power(subdev, 0);
+ return rval;
+}
+
+static int omap3evm_regulator_ctrl(struct mt9t111 *mt9t111, u32 on)
+{
+ if (!(mt9t111->omap3evm_1v8) || !(mt9t111->omap3evm_2v8)) {
+ printk(KERN_ERR "No regulator available\n");
+ return -ENODEV;
+ }
+ if (on) {
+ regulator_enable(mt9t111->omap3evm_1v8);
+ mdelay(1);
+ regulator_enable(mt9t111->omap3evm_2v8);
+ mdelay(50);
+ } else {
+ if (regulator_is_enabled(mt9t111->omap3evm_1v8))
+ regulator_disable(mt9t111->omap3evm_1v8);
+ if (regulator_is_enabled(mt9t111->omap3evm_2v8))
+ regulator_disable(mt9t111->omap3evm_2v8);
+ }
+ return 0;
+}
+
+/* -----------------------------------------------------------------------------
+ * V4L2 subdev core operations
+ */
+/*
+ * mt9t111_s_power - V4L2 sensor interface handler for s_power
+ * @s: pointer to standard V4L2 device structure
+ * @on: power state to which device is to be set
+ *
+ * Sets devices power state to requrested state, if possible.
+ */
+static int mt9t111_s_power(struct v4l2_subdev *subdev, int on)
+{
+ struct mt9t111 *mt9t111 = to_mt9t111(subdev);
+ struct i2c_client *client = v4l2_get_subdevdata(subdev);
+ int rval;
+
+ if (on) {
+ rval = omap3evm_regulator_ctrl(mt9t111, on);
+ if (rval)
+ goto out;
+
+ rval = mt9t111->pdata->s_power(subdev, 1);
+ if (rval)
+ goto out;
+
+ rval = mt9t111_configure(subdev);
+ if (rval) {
+ mt9t111->pdata->s_power(subdev, 0);
+ goto out;
+ }
+ } else {
+ rval = mt9t111->pdata->s_power(subdev, 0);
+ if (rval)
+ goto out;
+ }
+
+ mt9t111->power = on;
+
+out:
+ if (rval)
+ v4l_err(client, "Unable to set target power state\n");
+
+ return rval;
+}
+
+/* --------------------------------------------------------------------------
+ * V4L2 subdev internal operations
+ */
+/*
+ * mt9t111_registered - called when subdevice is registered
+ * @subdev: pointer to standard V4L2 subdev structure
+ */
+static int mt9t111_registered(struct v4l2_subdev *subdev)
+{
+
+ return mt9t111_dev_init(subdev);
+}
+
+static int mt9t111_open(struct v4l2_subdev *subdev, struct v4l2_subdev_fh *fh)
+{
+ struct v4l2_mbus_framefmt *format;
+ struct v4l2_rect *crop;
+
+ /*
+ * Default configuration -
+ * Resolution: VGA
+ * Format: UYVY
+ * crop = window
+ */
+ crop = v4l2_subdev_get_try_crop(fh, 0);
+ crop->left = 0;
+ crop->top = 0;
+ crop->width = MT9T111_IMAGE_WIDTH;
+ crop->height = MT9T111_IMAGE_HEIGHT;
+
+ format = v4l2_subdev_get_try_format(fh, 0);
+ format->code = V4L2_MBUS_FMT_UYVY8_2X8;
+ format->width = MT9T111_IMAGE_WIDTH;
+ format->height = MT9T111_IMAGE_HEIGHT;
+ format->field = V4L2_FIELD_NONE;
+ format->colorspace = V4L2_COLORSPACE_JPEG;
+
+ return 0;
+}
+
+/* --------------------------------------------------------------------------
+ * V4L2 subdev video operations
+ */
+
+static int mt9t111_s_stream(struct v4l2_subdev *subdev, int streaming)
+{
+ /*
+ * FIXME: We should put here the specific reg setting to turn on
+ * streaming in sensor.
+ */
+ return 0;
+}
+
+
+/* --------------------------------------------------------------------------
+ * V4L2 subdev pad operations
+ */
+/*
+ * mt9t111_enum_mbus_code - V4L2 sensor interface handler for pad_ops
+ * @subdev: pointer to standard V4L2 sub-device structure
+ * @qctrl: standard V4L2 VIDIOC_QUERYCTRL ioctl structure
+ *
+ * If the requested control is supported, returns the control information
+ * from the video_control[] array. Otherwise, returns -EINVAL if the
+ * control is not supported.
+ */
+static int mt9t111_enum_mbus_code(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ struct mt9t111 *mt9t111 = to_mt9t111(subdev);
+
+ if (code->index >= ARRAY_SIZE(mt9t111_fmt_list))
+ return -EINVAL;
+
+ code->code = mt9t111->format.code;
+
+ return 0;
+}
+
+static int mt9t111_enum_frame_size(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_frame_size_enum *fse)
+{
+ int i;
+
+ /* Is requested media-bus format/pixelformat not found on sensor? */
+ for (i = 0; i < ARRAY_SIZE(mt9t111_fmt_list); i++) {
+ if (fse->code == mt9t111_fmt_list[i].mbus_code)
+ goto fmt_found;
+ }
+ if (i >= ARRAY_SIZE(mt9t111_fmt_list))
+ return -EINVAL;
+
+fmt_found:
+ /*
+ * Currently only supports VGA resolution
+ */
+ fse->min_width = fse->max_width = MT9T111_IMAGE_WIDTH;
+ fse->min_height = fse->max_height = MT9T111_IMAGE_HEIGHT;
+
+ return 0;
+}
+
+
+static int mt9t111_get_pad_format(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_format *fmt)
+{
+ struct mt9t111 *mt9t111 = to_mt9t111(subdev);
+
+ fmt->format = mt9t111->format;
+ return 0;
+}
+
+static int mt9t111_set_pad_format(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_format *fmt)
+{
+ int i;
+ struct mt9t111 *mt9t111 = to_mt9t111(subdev);
+
+ for (i = 0; i < ARRAY_SIZE(mt9t111_fmt_list); i++) {
+ if (fmt->format.code == mt9t111_fmt_list[i].mbus_code)
+ goto fmt_found;
+ }
+ if (i >= ARRAY_SIZE(mt9t111_fmt_list))
+ return -EINVAL;
+
+fmt_found:
+ /*
+ * Only VGA resolution supported
+ */
+ fmt->format.width = MT9T111_IMAGE_WIDTH;
+ fmt->format.height = MT9T111_IMAGE_HEIGHT;
+ fmt->format.field = V4L2_FIELD_NONE;
+ fmt->format.colorspace = V4L2_COLORSPACE_JPEG;
+
+ mt9t111->format = fmt->format;
+
+ return 0;
+}
+
+static int mt9t111_get_crop(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_fh *fh, struct v4l2_subdev_crop *crop)
+{
+ struct mt9t111 *mt9t111 = to_mt9t111(subdev);
+
+ crop->rect = mt9t111->rect;
+ return 0;
+}
+
+static int mt9t111_set_crop(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_fh *fh, struct v4l2_subdev_crop *crop)
+{
+ struct mt9t111 *mt9t111 = to_mt9t111(subdev);
+ struct v4l2_rect rect;
+
+ /*
+ * Only VGA resolution/window is supported
+ */
+ rect.left = 0;
+ rect.top = 0;
+ rect.width = MT9T111_IMAGE_WIDTH;
+ rect.height = MT9T111_IMAGE_HEIGHT;
+
+ mt9t111->rect = rect;
+ crop->rect = rect;
+
+ return 0;
+}
+
+static const struct v4l2_subdev_core_ops mt9t111_core_ops = {
+ .s_power = mt9t111_s_power,
+};
+
+static struct v4l2_subdev_internal_ops mt9t111_subdev_internal_ops = {
+ .registered = mt9t111_registered,
+ .open = mt9t111_open,
+};
+
+static const struct v4l2_subdev_video_ops mt9t111_video_ops = {
+ .s_stream = mt9t111_s_stream,
+};
+
+static const struct v4l2_subdev_pad_ops mt9t111_pad_ops = {
+ .enum_mbus_code = mt9t111_enum_mbus_code,
+ .enum_frame_size = mt9t111_enum_frame_size,
+ .get_fmt = mt9t111_get_pad_format,
+ .set_fmt = mt9t111_set_pad_format,
+ .get_crop = mt9t111_get_crop,
+ .set_crop = mt9t111_set_crop,
+};
+
+static const struct v4l2_subdev_ops mt9t111_ops = {
+ .core = &mt9t111_core_ops,
+ .video = &mt9t111_video_ops,
+ .pad = &mt9t111_pad_ops,
+};
+
+/*
+ * mt9t111_probe - sensor driver i2c probe handler
+ * @client: i2c driver client device structure
+ *
+ * Register sensor as an i2c client device and V4L2
+ * device.
+ */
+static int mt9t111_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct mt9t111 *mt9t111;
+ int ret;
+
+ /* Check if the adapter supports the needed features */
+ if (!i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_BYTE_DATA)) {
+ v4l_err(client, "mt9t111: I2C Adapter doesn't support" \
+ " I2C_FUNC_SMBUS_WORD\n");
+ return -EIO;
+ }
+
+ if (!client->dev.platform_data) {
+ v4l_err(client, "No platform data!!\n");
+ return -ENODEV;
+ }
+
+ mt9t111 = kzalloc(sizeof(*mt9t111), GFP_KERNEL);
+ if (mt9t111 == NULL) {
+ v4l_err(client, "Could not able to alocate memory!!\n");
+ return -ENOMEM;
+ }
+
+ mt9t111->pdata = client->dev.platform_data;
+
+ /*
+ * Regulator supply required for camera interface
+ */
+ mt9t111->omap3evm_1v8 = regulator_get(NULL, "vio_1v8");
+ if (IS_ERR(mt9t111->omap3evm_1v8)) {
+ printk(KERN_ERR "vio_1v8 regulator missing\n");
+ ret = PTR_ERR(mt9t111->omap3evm_1v8);
+ goto err_1;
+ }
+ mt9t111->omap3evm_2v8 = regulator_get(NULL, "cam_2v8");
+ if (IS_ERR(mt9t111->omap3evm_2v8)) {
+ printk(KERN_ERR "cam_2v8 regulator missing\n");
+ ret = PTR_ERR(mt9t111->omap3evm_2v8);
+ goto err_2;
+ }
+
+ /*
+ * Default configuration -
+ * Resolution: VGA
+ * Format: UYVY
+ * crop = window
+ */
+
+ mt9t111->rect.left = 0;
+ mt9t111->rect.top = 0;
+ mt9t111->rect.width = MT9T111_IMAGE_WIDTH;
+ mt9t111->rect.height = MT9T111_IMAGE_HEIGHT;
+
+ mt9t111->format.code = V4L2_MBUS_FMT_UYVY8_2X8;
+ mt9t111->format.width = MT9T111_IMAGE_WIDTH;
+ mt9t111->format.height = MT9T111_IMAGE_HEIGHT;
+ mt9t111->format.field = V4L2_FIELD_NONE;
+ mt9t111->format.colorspace = V4L2_COLORSPACE_JPEG;
+
+ v4l2_i2c_subdev_init(&mt9t111->subdev, client, &mt9t111_ops);
+ mt9t111->subdev.internal_ops = &mt9t111_subdev_internal_ops;
+ mt9t111->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+
+ mt9t111->pad.flags = MEDIA_PAD_FL_SOURCE;
+ ret = media_entity_init(&mt9t111->subdev.entity, 1, &mt9t111->pad, 0);
+ if (!ret)
+ return 0;
+
+ kfree(mt9t111);
+err_2:
+ regulator_put(mt9t111->omap3evm_2v8);
+err_1:
+ regulator_put(mt9t111->omap3evm_1v8);
+
+ return ret;
+}
+
+/*
+ * mt9t111_remove - sensor driver i2c remove handler
+ * @client: i2c driver client device structure
+ *
+ * Unregister sensor as an i2c client device and V4L2
+ * device. Complement of mt9t111_probe().
+ */
+static int __exit mt9t111_remove(struct i2c_client *client)
+{
+ struct v4l2_subdev *subdev = i2c_get_clientdata(client);
+ struct mt9t111 *mt9t111 = to_mt9t111(subdev);
+
+ v4l2_device_unregister_subdev(&mt9t111->subdev);
+ media_entity_cleanup(&mt9t111->subdev.entity);
+ kfree(mt9t111);
+
+ return 0;
+}
+
+static const struct i2c_device_id mt9t111_id[] = {
+ { MT9T111_MODULE_NAME, 0 },
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, mt9t111_id);
+
+static struct i2c_driver mt9t111_i2c_driver = {
+ .driver = {
+ .name = MT9T111_MODULE_NAME,
+ .owner = THIS_MODULE,
+ },
+ .probe = mt9t111_probe,
+ .remove = __exit_p(mt9t111_remove),
+ .id_table = mt9t111_id,
+};
+
+/*
+ * mt9t111_init - sensor driver module_init handler
+ *
+ * Registers driver as an i2c client driver. Returns 0 on success,
+ * error code otherwise.
+ */
+static int __init mt9t111_init(void)
+{
+ return i2c_add_driver(&mt9t111_i2c_driver);
+}
+
+/*
+ * mt9t111_cleanup - sensor driver module_exit handler
+ *
+ * Unregisters/deletes driver as an i2c client driver.
+ * Complement of mt9t111_init.
+ */
+static void __exit mt9t111_cleanup(void)
+{
+ i2c_del_driver(&mt9t111_i2c_driver);
+}
+
+module_init(mt9t111_init);
+module_exit(mt9t111_cleanup);
+
+MODULE_AUTHOR("Texas Instruments");
+MODULE_DESCRIPTION("mt9t111 camera sensor driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/media/video/mt9t111_reg.h b/drivers/media/video/mt9t111_reg.h
new file mode 100644
index 0000000..2f610d4
--- /dev/null
+++ b/drivers/media/video/mt9t111_reg.h
@@ -0,0 +1,1367 @@
+/*
+ * drivers/media/video/mt9t111_reg.h
+ *
+ * mt9t111 sensor driver header file
+ *
+ * Copyright (C) 2009 Leopard Imaging
+ *
+ * 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.
+ */
+
+#ifndef MT9T111_REG_H
+#define MT9T111_REG_H
+
+/* register addr */
+#define MT9T111_CHIP_ID (0x0000)
+
+/* register value */
+#define MT9T111_CHIP_ID_VALUE (0x2680)
+
+#define MT9T111_IMAGE_WIDTH (640)
+#define MT9T111_IMAGE_HEIGHT (480)
+
+typedef struct {
+ u16 delay_time;
+ u16 addr;
+ u16 data;
+} mt9t111_regs;
+
+mt9t111_regs patch_rev6[] = {
+ {0, 0x0982, 0x0},
+ {0, 0x098A, 0xCE7},
+ {0, 0x0990, 0x3C3C},
+ {0, 0x0992, 0x3C3C},
+ {0, 0x0994, 0x3C5F},
+ {0, 0x0996, 0x4F30},
+ {0, 0x0998, 0xED08},
+ {0, 0x099a, 0xBD61},
+ {0, 0x099c, 0xD5CE},
+ {0, 0x099e, 0x4CD},
+ {0, 0x098A, 0xCF7},
+ {0, 0x0990, 0x1F17},
+ {0, 0x0992, 0x211},
+ {0, 0x0994, 0xCC33},
+ {0, 0x0996, 0x2E30},
+ {0, 0x0998, 0xED02},
+ {0, 0x099a, 0xCCFF},
+ {0, 0x099c, 0xFDED},
+ {0, 0x099e, 0xCC},
+ {0, 0x098A, 0xD07},
+ {0, 0x0990, 0x2},
+ {0, 0x0992, 0xBD70},
+ {0, 0x0994, 0x6D18},
+ {0, 0x0996, 0xDE1F},
+ {0, 0x0998, 0x181F},
+ {0, 0x099a, 0x8E01},
+ {0, 0x099c, 0x10CC},
+ {0, 0x099e, 0x3C52},
+ {0, 0x098A, 0xD17},
+ {0, 0x0990, 0x30ED},
+ {0, 0x0992, 0x18},
+ {0, 0x0994, 0xECA0},
+ {0, 0x0996, 0xC4FD},
+ {0, 0x0998, 0xBD70},
+ {0, 0x099a, 0x2120},
+ {0, 0x099c, 0x1ECC},
+ {0, 0x099e, 0x3C52},
+ {0, 0x098A, 0xD27},
+ {0, 0x0990, 0x30ED},
+ {0, 0x0992, 0xDE},
+ {0, 0x0994, 0x1FEC},
+ {0, 0x0996, 0xA0BD},
+ {0, 0x0998, 0x7021},
+ {0, 0x099a, 0xCC3C},
+ {0, 0x099c, 0x5230},
+ {0, 0x099e, 0xED02},
+ {0, 0x098A, 0xD37},
+ {0, 0x0990, 0xCCFF},
+ {0, 0x0992, 0xFCED},
+ {0, 0x0994, 0xCC},
+ {0, 0x0996, 0x2},
+ {0, 0x0998, 0xBD70},
+ {0, 0x099a, 0x6DFC},
+ {0, 0x099c, 0x4E1},
+ {0, 0x099e, 0x1A83},
+ {0, 0x098A, 0xD47},
+ {0, 0x0990, 0x1},
+ {0, 0x0992, 0x2720},
+ {0, 0x0994, 0x1A83},
+ {0, 0x0996, 0x4},
+ {0, 0x0998, 0x271E},
+ {0, 0x099a, 0x1A83},
+ {0, 0x099c, 0x8},
+ {0, 0x099e, 0x271C},
+ {0, 0x098A, 0xD57},
+ {0, 0x0990, 0x1A83},
+ {0, 0x0992, 0x10},
+ {0, 0x0994, 0x271A},
+ {0, 0x0996, 0x1A83},
+ {0, 0x0998, 0x20},
+ {0, 0x099a, 0x2718},
+ {0, 0x099c, 0x1A83},
+ {0, 0x099e, 0x40},
+ {0, 0x098A, 0xD67},
+ {0, 0x0990, 0x2716},
+ {0, 0x0992, 0x2019},
+ {0, 0x0994, 0xC61E},
+ {0, 0x0996, 0x2012},
+ {0, 0x0998, 0xC622},
+ {0, 0x099a, 0x200E},
+ {0, 0x099c, 0xC621},
+ {0, 0x099e, 0x200A},
+ {0, 0x098A, 0xD77},
+ {0, 0x0990, 0xC620},
+ {0, 0x0992, 0x2006},
+ {0, 0x0994, 0xC62A},
+ {0, 0x0996, 0x2002},
+ {0, 0x0998, 0xC62B},
+ {0, 0x099a, 0x30ED},
+ {0, 0x099c, 0x8CC},
+ {0, 0x099e, 0x3400},
+ {0, 0x098A, 0xD87},
+ {0, 0x0990, 0x30ED},
+ {0, 0x0992, 0x34},
+ {0, 0x0994, 0xBD6F},
+ {0, 0x0996, 0xD184},
+ {0, 0x0998, 0x330},
+ {0, 0x099a, 0xED07},
+ {0, 0x099c, 0xA60A},
+ {0, 0x099e, 0x4848},
+ {0, 0x098A, 0xD97},
+ {0, 0x0990, 0x5FED},
+ {0, 0x0992, 0x5EA},
+ {0, 0x0994, 0x8AA},
+ {0, 0x0996, 0x731},
+ {0, 0x0998, 0xBD70},
+ {0, 0x099a, 0x2130},
+ {0, 0x099c, 0xC60A},
+ {0, 0x099e, 0x3A35},
+ {0, 0x098A, 0xDA7},
+ {0, 0x0990, 0x3937},
+ {0, 0x0992, 0x3C3C},
+ {0, 0x0994, 0x3C34},
+ {0, 0x0996, 0xDE2F},
+ {0, 0x0998, 0xEE0E},
+ {0, 0x099a, 0xAD00},
+ {0, 0x099c, 0x7D13},
+ {0, 0x099e, 0xEF27},
+ {0, 0x098A, 0xDB7},
+ {0, 0x0990, 0x7CCE},
+ {0, 0x0992, 0x13E0},
+ {0, 0x0994, 0x1E05},
+ {0, 0x0996, 0x1060},
+ {0, 0x0998, 0xE60E},
+ {0, 0x099a, 0x4FC3},
+ {0, 0x099c, 0x13F0},
+ {0, 0x099e, 0x8FE6},
+ {0, 0x098A, 0xDC7},
+ {0, 0x0990, 0x30},
+ {0, 0x0992, 0xE107},
+ {0, 0x0994, 0x2216},
+ {0, 0x0996, 0xF613},
+ {0, 0x0998, 0xEE4F},
+ {0, 0x099a, 0xC313},
+ {0, 0x099c, 0xF38F},
+ {0, 0x099e, 0xE600},
+ {0, 0x098A, 0xDD7},
+ {0, 0x0990, 0x30E1},
+ {0, 0x0992, 0x725},
+ {0, 0x0994, 0x7F6},
+ {0, 0x0996, 0x13EE},
+ {0, 0x0998, 0xC103},
+ {0, 0x099a, 0x253C},
+ {0, 0x099c, 0x7F13},
+ {0, 0x099e, 0xEEF6},
+ {0, 0x098A, 0xDE7},
+ {0, 0x0990, 0x13EF},
+ {0, 0x0992, 0xE706},
+ {0, 0x0994, 0xCC13},
+ {0, 0x0996, 0xF0ED},
+ {0, 0x0998, 0x4CC},
+ {0, 0x099a, 0x13F3},
+ {0, 0x099c, 0x200F},
+ {0, 0x099e, 0x7C13},
+ {0, 0x098A, 0xDF7},
+ {0, 0x0990, 0xEEEC},
+ {0, 0x0992, 0x4C3},
+ {0, 0x0994, 0x1},
+ {0, 0x0996, 0xED04},
+ {0, 0x0998, 0xEC02},
+ {0, 0x099a, 0xC300},
+ {0, 0x099c, 0x1ED},
+ {0, 0x099e, 0x2F6},
+ {0, 0x098A, 0xE07},
+ {0, 0x0990, 0x13EE},
+ {0, 0x0992, 0xE106},
+ {0, 0x0994, 0x2412},
+ {0, 0x0996, 0xEE04},
+ {0, 0x0998, 0xE600},
+ {0, 0x099a, 0x30E1},
+ {0, 0x099c, 0x722},
+ {0, 0x099e, 0xDFEE},
+ {0, 0x098A, 0xE17},
+ {0, 0x0990, 0x2E6},
+ {0, 0x0992, 0x30},
+ {0, 0x0994, 0xE107},
+ {0, 0x0996, 0x25D6},
+ {0, 0x0998, 0xDE49},
+ {0, 0x099a, 0xEE08},
+ {0, 0x099c, 0xAD00},
+ {0, 0x099e, 0xCC13},
+ {0, 0x098A, 0xE27},
+ {0, 0x0990, 0xF630},
+ {0, 0x0992, 0xED00},
+ {0, 0x0994, 0xDE2F},
+ {0, 0x0996, 0xEE10},
+ {0, 0x0998, 0xCC13},
+ {0, 0x099a, 0xFAAD},
+ {0, 0x099c, 0x38},
+ {0, 0x099e, 0x3838},
+ {0, 0x098A, 0xE37},
+ {0, 0x0990, 0x3839},
+ {0, 0x098A, 0x1000},
+ {0, 0x0990, 0xCC10},
+ {0, 0x0992, 0x9BD},
+ {0, 0x0994, 0x4224},
+ {0, 0x0996, 0x7E10},
+ {0, 0x0998, 0x9C6},
+ {0, 0x099a, 0x1F7},
+ {0, 0x099c, 0x18A},
+ {0, 0x099e, 0xC606},
+ {0, 0x098A, 0x1010},
+ {0, 0x0990, 0xF701},
+ {0, 0x0992, 0x8BDE},
+ {0, 0x0994, 0x3F18},
+ {0, 0x0996, 0xCE0B},
+ {0, 0x0998, 0xF1CC},
+ {0, 0x099a, 0x11},
+ {0, 0x099c, 0xBDD7},
+ {0, 0x099e, 0xCC},
+ {0, 0x098A, 0x1020},
+ {0, 0x0990, 0xBF1},
+ {0, 0x0992, 0xDD3F},
+ {0, 0x0994, 0xDE35},
+ {0, 0x0996, 0x18CE},
+ {0, 0x0998, 0xC03},
+ {0, 0x099a, 0xCC00},
+ {0, 0x099c, 0x3FBD},
+ {0, 0x099e, 0xD700},
+ {0, 0x098A, 0x1030},
+ {0, 0x0990, 0xCC0C},
+ {0, 0x0992, 0x3DD},
+ {0, 0x0994, 0x35DE},
+ {0, 0x0996, 0x4718},
+ {0, 0x0998, 0xCE0C},
+ {0, 0x099a, 0x43CC},
+ {0, 0x099c, 0x15},
+ {0, 0x099e, 0xBDD7},
+ {0, 0x098A, 0x1040},
+ {0, 0x0990, 0xCC},
+ {0, 0x0992, 0xC43},
+ {0, 0x0994, 0xDD47},
+ {0, 0x0996, 0xFE00},
+ {0, 0x0998, 0x3318},
+ {0, 0x099a, 0xCE0C},
+ {0, 0x099c, 0x59CC},
+ {0, 0x099e, 0x9},
+ {0, 0x098A, 0x1050},
+ {0, 0x0990, 0xBDD7},
+ {0, 0x0992, 0xCC},
+ {0, 0x0994, 0xC59},
+ {0, 0x0996, 0xFD00},
+ {0, 0x0998, 0x33DE},
+ {0, 0x099a, 0x4118},
+ {0, 0x099c, 0xCE0C},
+ {0, 0x099e, 0x63CC},
+ {0, 0x098A, 0x1060},
+ {0, 0x0990, 0xD},
+ {0, 0x0992, 0xBDD7},
+ {0, 0x0994, 0xCC},
+ {0, 0x0996, 0xC63},
+ {0, 0x0998, 0xDD41},
+ {0, 0x099a, 0xFE00},
+ {0, 0x099c, 0x3118},
+ {0, 0x099e, 0xCE0C},
+ {0, 0x098A, 0x1070},
+ {0, 0x0990, 0x71CC},
+ {0, 0x0992, 0x29},
+ {0, 0x0994, 0xBDD7},
+ {0, 0x0996, 0xCC},
+ {0, 0x0998, 0xC71},
+ {0, 0x099a, 0xFD00},
+ {0, 0x099c, 0x31DE},
+ {0, 0x099e, 0x3918},
+ {0, 0x098A, 0x1080},
+ {0, 0x0990, 0xCE0C},
+ {0, 0x0992, 0x9BCC},
+ {0, 0x0994, 0x23},
+ {0, 0x0996, 0xBDD7},
+ {0, 0x0998, 0xCC},
+ {0, 0x099a, 0xC9B},
+ {0, 0x099c, 0xDD39},
+ {0, 0x099e, 0xDE49},
+ {0, 0x098A, 0x1090},
+ {0, 0x0990, 0x18CE},
+ {0, 0x0992, 0xCBF},
+ {0, 0x0994, 0xCC00},
+ {0, 0x0996, 0xDBD},
+ {0, 0x0998, 0xD700},
+ {0, 0x099a, 0xCC0C},
+ {0, 0x099c, 0xBFDD},
+ {0, 0x099e, 0x49CC},
+ {0, 0x098A, 0x10A0},
+ {0, 0x0990, 0x1162},
+ {0, 0x0992, 0xFD0B},
+ {0, 0x0994, 0xFDCC},
+ {0, 0x0996, 0xCE7},
+ {0, 0x0998, 0xFD0C},
+ {0, 0x099a, 0x1FCC},
+ {0, 0x099c, 0x1245},
+ {0, 0x099e, 0xFD0C},
+ {0, 0x098A, 0x10B0},
+ {0, 0x0990, 0x51CC},
+ {0, 0x0992, 0x110B},
+ {0, 0x0994, 0xFD0C},
+ {0, 0x0996, 0x5BCC},
+ {0, 0x0998, 0x1108},
+ {0, 0x099a, 0xFD0C},
+ {0, 0x099c, 0x65CC},
+ {0, 0x099e, 0x10D0},
+ {0, 0x098A, 0x10C0},
+ {0, 0x0990, 0xFD0C},
+ {0, 0x0992, 0x7BCC},
+ {0, 0x0994, 0x12DE},
+ {0, 0x0996, 0xFD0C},
+ {0, 0x0998, 0xA7CC},
+ {0, 0x099a, 0xDA8},
+ {0, 0x099c, 0xFD0C},
+ {0, 0x099e, 0xCB39},
+ {0, 0x098A, 0x10D0},
+ {0, 0x0990, 0x37DE},
+ {0, 0x0992, 0x1DEC},
+ {0, 0x0994, 0xC5F},
+ {0, 0x0996, 0x8402},
+ {0, 0x0998, 0x4416},
+ {0, 0x099a, 0x4FF7},
+ {0, 0x099c, 0xCCD},
+ {0, 0x099e, 0xE60B},
+ {0, 0x098A, 0x10E0},
+ {0, 0x0990, 0xC407},
+ {0, 0x0992, 0xF70C},
+ {0, 0x0994, 0xCE7F},
+ {0, 0x0996, 0x30C4},
+ {0, 0x0998, 0xEC25},
+ {0, 0x099a, 0xFD30},
+ {0, 0x099c, 0xC5FC},
+ {0, 0x099e, 0x6D6},
+ {0, 0x098A, 0x10F0},
+ {0, 0x0990, 0xFD30},
+ {0, 0x0992, 0xC701},
+ {0, 0x0994, 0xFC30},
+ {0, 0x0996, 0xC0FD},
+ {0, 0x0998, 0xBED},
+ {0, 0x099a, 0xFC30},
+ {0, 0x099c, 0xC2FD},
+ {0, 0x099e, 0xBEF},
+ {0, 0x098A, 0x1100},
+ {0, 0x0990, 0x30E6},
+ {0, 0x0992, 0xBD},
+ {0, 0x0994, 0x5203},
+ {0, 0x0996, 0x3139},
+ {0, 0x0998, 0x7E9E},
+ {0, 0x099a, 0x143C},
+ {0, 0x099c, 0x3C3C},
+ {0, 0x099e, 0x2101},
+ {0, 0x098A, 0x1110},
+ {0, 0x0990, 0xCC00},
+ {0, 0x0992, 0x18BD},
+ {0, 0x0994, 0x6FD1},
+ {0, 0x0996, 0xC504},
+ {0, 0x0998, 0x26F5},
+ {0, 0x099a, 0xDC25},
+ {0, 0x099c, 0x30ED},
+ {0, 0x099e, 0x420},
+ {0, 0x098A, 0x1120},
+ {0, 0x0990, 0x12EE},
+ {0, 0x0992, 0x43C},
+ {0, 0x0994, 0x1838},
+ {0, 0x0996, 0xE621},
+ {0, 0x0998, 0x18E7},
+ {0, 0x099a, 0xBE30},
+ {0, 0x099c, 0xEE04},
+ {0, 0x099e, 0xEC1D},
+ {0, 0x098A, 0x1130},
+ {0, 0x0990, 0x30ED},
+ {0, 0x0992, 0x4EC},
+ {0, 0x0994, 0x426},
+ {0, 0x0996, 0xEACC},
+ {0, 0x0998, 0x1A},
+ {0, 0x099a, 0xED02},
+ {0, 0x099c, 0xCCFB},
+ {0, 0x099e, 0xFFED},
+ {0, 0x098A, 0x1140},
+ {0, 0x0990, 0xCC},
+ {0, 0x0992, 0x400},
+ {0, 0x0994, 0xBD70},
+ {0, 0x0996, 0x6DCC},
+ {0, 0x0998, 0x1A},
+ {0, 0x099a, 0x30ED},
+ {0, 0x099c, 0x2CC},
+ {0, 0x099e, 0xFBFF},
+ {0, 0x098A, 0x1150},
+ {0, 0x0990, 0xED00},
+ {0, 0x0992, 0x5F4F},
+ {0, 0x0994, 0xBD70},
+ {0, 0x0996, 0x6D5F},
+ {0, 0x0998, 0xBD5B},
+ {0, 0x099a, 0x17BD},
+ {0, 0x099c, 0x558B},
+ {0, 0x099e, 0x3838},
+ {0, 0x098A, 0x1160},
+ {0, 0x0990, 0x3839},
+ {0, 0x0992, 0x3C3C},
+ {0, 0x0994, 0xC640},
+ {0, 0x0996, 0xF730},
+ {0, 0x0998, 0xC4FC},
+ {0, 0x099a, 0xBED},
+ {0, 0x099c, 0xFD30},
+ {0, 0x099e, 0xC0FC},
+ {0, 0x098A, 0x1170},
+ {0, 0x0990, 0xBEF},
+ {0, 0x0992, 0xFD30},
+ {0, 0x0994, 0xC2DE},
+ {0, 0x0996, 0x1DEC},
+ {0, 0x0998, 0x25FD},
+ {0, 0x099a, 0x30C5},
+ {0, 0x099c, 0x101},
+ {0, 0x099e, 0x1FC},
+ {0, 0x098A, 0x1180},
+ {0, 0x0990, 0x30C2},
+ {0, 0x0992, 0xFD06},
+ {0, 0x0994, 0xD6EC},
+ {0, 0x0996, 0xC5F},
+ {0, 0x0998, 0x8402},
+ {0, 0x099a, 0x4416},
+ {0, 0x099c, 0x4F30},
+ {0, 0x099e, 0xE703},
+ {0, 0x098A, 0x1190},
+ {0, 0x0990, 0xF10C},
+ {0, 0x0992, 0xCD27},
+ {0, 0x0994, 0x15F1},
+ {0, 0x0996, 0xCCD},
+ {0, 0x0998, 0x2309},
+ {0, 0x099a, 0xFC06},
+ {0, 0x099c, 0xD604},
+ {0, 0x099e, 0xFD06},
+ {0, 0x098A, 0x11A0},
+ {0, 0x0990, 0xD620},
+ {0, 0x0992, 0x7FC},
+ {0, 0x0994, 0x6D6},
+ {0, 0x0996, 0x5FD},
+ {0, 0x0998, 0x6D6},
+ {0, 0x099a, 0xDE1D},
+ {0, 0x099c, 0xE60B},
+ {0, 0x099e, 0xC407},
+ {0, 0x098A, 0x11B0},
+ {0, 0x0990, 0x30E7},
+ {0, 0x0992, 0x2F1},
+ {0, 0x0994, 0xCCE},
+ {0, 0x0996, 0x272C},
+ {0, 0x0998, 0x7D0C},
+ {0, 0x099a, 0xCE27},
+ {0, 0x099c, 0x275D},
+ {0, 0x099e, 0x2724},
+ {0, 0x098A, 0x11C0},
+ {0, 0x0990, 0x7F30},
+ {0, 0x0992, 0xC4FC},
+ {0, 0x0994, 0x6D6},
+ {0, 0x0996, 0xFD30},
+ {0, 0x0998, 0xC5F6},
+ {0, 0x099a, 0xCCE},
+ {0, 0x099c, 0x4FFD},
+ {0, 0x099e, 0x30C7},
+ {0, 0x098A, 0x11D0},
+ {0, 0x0990, 0xC640},
+ {0, 0x0992, 0xF730},
+ {0, 0x0994, 0xC4E6},
+ {0, 0x0996, 0x24F},
+ {0, 0x0998, 0xFD30},
+ {0, 0x099a, 0xC501},
+ {0, 0x099c, 0x101},
+ {0, 0x099e, 0xFC30},
+ {0, 0x098A, 0x11E0},
+ {0, 0x0990, 0xC2FD},
+ {0, 0x0992, 0x6D6},
+ {0, 0x0994, 0x7D06},
+ {0, 0x0996, 0xCB27},
+ {0, 0x0998, 0x2EC6},
+ {0, 0x099a, 0x40F7},
+ {0, 0x099c, 0x30C4},
+ {0, 0x099e, 0xFC06},
+ {0, 0x098A, 0x11F0},
+ {0, 0x0990, 0xC104},
+ {0, 0x0992, 0xF306},
+ {0, 0x0994, 0xD6ED},
+ {0, 0x0996, 0x5F},
+ {0, 0x0998, 0x6D00},
+ {0, 0x099a, 0x2A01},
+ {0, 0x099c, 0x5317},
+ {0, 0x099e, 0xFD30},
+ {0, 0x098A, 0x1200},
+ {0, 0x0990, 0xC0EC},
+ {0, 0x0992, 0xFD},
+ {0, 0x0994, 0x30C2},
+ {0, 0x0996, 0xFC06},
+ {0, 0x0998, 0xC1FD},
+ {0, 0x099a, 0x30C5},
+ {0, 0x099c, 0x101},
+ {0, 0x099e, 0x1FC},
+ {0, 0x098A, 0x1210},
+ {0, 0x0990, 0x30C2},
+ {0, 0x0992, 0xFD06},
+ {0, 0x0994, 0xC720},
+ {0, 0x0996, 0x227F},
+ {0, 0x0998, 0x30C4},
+ {0, 0x099a, 0xDE1D},
+ {0, 0x099c, 0xEC25},
+ {0, 0x099e, 0xFD30},
+ {0, 0x098A, 0x1220},
+ {0, 0x0990, 0xC5FC},
+ {0, 0x0992, 0x6D6},
+ {0, 0x0994, 0xFD30},
+ {0, 0x0996, 0xC701},
+ {0, 0x0998, 0xFC30},
+ {0, 0x099a, 0xC0FD},
+ {0, 0x099c, 0x6D0},
+ {0, 0x099e, 0xFC30},
+ {0, 0x098A, 0x1230},
+ {0, 0x0990, 0xC2FD},
+ {0, 0x0992, 0x6D2},
+ {0, 0x0994, 0xEC25},
+ {0, 0x0996, 0xFD06},
+ {0, 0x0998, 0xC3BD},
+ {0, 0x099a, 0x953C},
+ {0, 0x099c, 0xDE3F},
+ {0, 0x099e, 0xEE10},
+ {0, 0x098A, 0x1240},
+ {0, 0x0990, 0xAD00},
+ {0, 0x0992, 0x3838},
+ {0, 0x0994, 0x3930},
+ {0, 0x0996, 0x8FC3},
+ {0, 0x0998, 0xFFE9},
+ {0, 0x099a, 0x8F35},
+ {0, 0x099c, 0xBDAD},
+ {0, 0x099e, 0x1530},
+ {0, 0x098A, 0x1250},
+ {0, 0x0990, 0x6F16},
+ {0, 0x0992, 0x18DE},
+ {0, 0x0994, 0x1918},
+ {0, 0x0996, 0x8FC3},
+ {0, 0x0998, 0x14B},
+ {0, 0x099a, 0x188F},
+ {0, 0x099c, 0x18EC},
+ {0, 0x099e, 0xFD},
+ {0, 0x098A, 0x1260},
+ {0, 0x0990, 0x50E},
+ {0, 0x0992, 0x18EC},
+ {0, 0x0994, 0x2FD},
+ {0, 0x0996, 0x510},
+ {0, 0x0998, 0xE616},
+ {0, 0x099a, 0x4FED},
+ {0, 0x099c, 0x418},
+ {0, 0x099e, 0x8FC3},
+ {0, 0x098A, 0x1270},
+ {0, 0x0990, 0xFFCB},
+ {0, 0x0992, 0xE304},
+ {0, 0x0994, 0x8FE6},
+ {0, 0x0996, 0xF7},
+ {0, 0x0998, 0x514},
+ {0, 0x099a, 0x18DE},
+ {0, 0x099c, 0x1930},
+ {0, 0x099e, 0xE616},
+ {0, 0x098A, 0x1280},
+ {0, 0x0990, 0x4FED},
+ {0, 0x0992, 0x418},
+ {0, 0x0994, 0x8FC3},
+ {0, 0x0996, 0x119},
+ {0, 0x0998, 0xE304},
+ {0, 0x099a, 0x8FE6},
+ {0, 0x099c, 0xF7},
+ {0, 0x099e, 0x515},
+ {0, 0x098A, 0x1290},
+ {0, 0x0990, 0xFC05},
+ {0, 0x0992, 0x5BFD},
+ {0, 0x0994, 0x512},
+ {0, 0x0996, 0xDE37},
+ {0, 0x0998, 0xEE08},
+ {0, 0x099a, 0xAD00},
+ {0, 0x099c, 0x30E6},
+ {0, 0x099e, 0x164F},
+ {0, 0x098A, 0x12A0},
+ {0, 0x0990, 0x5ED},
+ {0, 0x0992, 0x48F},
+ {0, 0x0994, 0xC300},
+ {0, 0x0996, 0x630},
+ {0, 0x0998, 0xE304},
+ {0, 0x099a, 0x8FF6},
+ {0, 0x099c, 0x516},
+ {0, 0x099e, 0x4FED},
+ {0, 0x098A, 0x12B0},
+ {0, 0x0990, 0x30},
+ {0, 0x0992, 0x6C16},
+ {0, 0x0994, 0xE616},
+ {0, 0x0996, 0xC103},
+ {0, 0x0998, 0x2598},
+ {0, 0x099a, 0xCC32},
+ {0, 0x099c, 0x8EED},
+ {0, 0x099e, 0xEC},
+ {0, 0x098A, 0x12C0},
+ {0, 0x0990, 0x6BD},
+ {0, 0x0992, 0x7021},
+ {0, 0x0994, 0xCC32},
+ {0, 0x0996, 0x6C30},
+ {0, 0x0998, 0xED02},
+ {0, 0x099a, 0xCCF8},
+ {0, 0x099c, 0xED},
+ {0, 0x099e, 0xA6},
+ {0, 0x098A, 0x12D0},
+ {0, 0x0990, 0x9E3},
+ {0, 0x0992, 0xA84},
+ {0, 0x0994, 0x7BD},
+ {0, 0x0996, 0x706D},
+ {0, 0x0998, 0x30C6},
+ {0, 0x099a, 0x173A},
+ {0, 0x099c, 0x3539},
+ {0, 0x099e, 0x3CBD},
+ {0, 0x098A, 0x12E0},
+ {0, 0x0990, 0x776D},
+ {0, 0x0992, 0xCC32},
+ {0, 0x0994, 0x5C30},
+ {0, 0x0996, 0xED00},
+ {0, 0x0998, 0xFC13},
+ {0, 0x099a, 0x8683},
+ {0, 0x099c, 0x1},
+ {0, 0x099e, 0xBD70},
+ {0, 0x098A, 0x12F0},
+ {0, 0x0990, 0x21CC},
+ {0, 0x0992, 0x325E},
+ {0, 0x0994, 0x30ED},
+ {0, 0x0996, 0xFC},
+ {0, 0x0998, 0x1388},
+ {0, 0x099a, 0x8300},
+ {0, 0x099c, 0x1BD},
+ {0, 0x099e, 0x7021},
+ {0, 0x098A, 0x1300},
+ {0, 0x0990, 0x3839},
+ {0, 0x098E, 0x0010},
+ {0, 0x0990, 0x1000},
+ {0, 0x098E, 0x0003},
+ {100, 0x0990, 0x0004}
+};
+
+mt9t111_regs def_regs1[] = {
+ {0, 0x001A, 0x0218},
+ {0, 0x001E, 0x0777},
+ {0, 0x3084, 0x2409},
+ {0, 0x3092, 0x0A49},
+ {0, 0x3094, 0x4949},
+ {0, 0x3096, 0x4950},
+ {0, 0x0018, 0x402D},
+ {100, 0x0018, 0x402C},
+ {0, 0x098E, 0x6800},
+ {0, 0x0990, 0x0280},
+ {0, 0x098E, 0x6802},
+ {0, 0x0990, 0x01E0},
+ {0, 0x098E, 0xE88E},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0x68A0},
+ {0, 0x0990, 0x082D},
+ {0, 0x098E, 0x4802},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0x4804},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0x4806},
+ {0, 0x0990, 0x060D},
+ {0, 0x098E, 0x4808},
+ {0, 0x0990, 0x080D},
+ {0, 0x098E, 0x480A},
+ {0, 0x0990, 0x0111},
+ {0, 0x098E, 0x480C},
+ {0, 0x0990, 0x046C},
+ {0, 0x098E, 0x480F},
+ {0, 0x0990, 0x00CC},
+ {0, 0x098E, 0x4811},
+ {0, 0x0990, 0x0381},
+ {0, 0x098E, 0x4813},
+ {0, 0x0990, 0x024F},
+ {0, 0x098E, 0x481D},
+ {0, 0x0990, 0x05AE},
+ {0, 0x098E, 0x481F},
+ {0, 0x0990, 0x05D0},
+ {0, 0x098E, 0x4825},
+ {0, 0x0990, 0x07AC},
+ {0, 0x098E, 0x6C00},
+ {0, 0x0990, 0x0800},
+ {0, 0x098E, 0x6C02},
+ {0, 0x0990, 0x0600},
+ {0, 0x098E, 0xEC8E},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0x6CA0},
+ {0, 0x0990, 0x082D},
+ {0, 0x098E, 0x484A},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0x484C},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0x484E},
+ {0, 0x0990, 0x060D},
+ {0, 0x098E, 0x4850},
+ {0, 0x0990, 0x080D},
+ {0, 0x098E, 0x4852},
+ {0, 0x0990, 0x0111},
+ {0, 0x098E, 0x4854},
+ {0, 0x0990, 0x146C},
+ {0, 0x098E, 0x4857},
+ {0, 0x0990, 0x00CC},
+ {0, 0x098E, 0x4859},
+ {0, 0x0990, 0x0381},
+ {0, 0x098E, 0x485B},
+ {0, 0x0990, 0x024F},
+ {0, 0x098E, 0x4865},
+ {0, 0x0990, 0x05AE},
+ {0, 0x098E, 0x4867},
+ {0, 0x0990, 0x05D0},
+ {0, 0x098E, 0x486D},
+ {0, 0x0990, 0x07AC},
+ {0, 0x098E, 0xC8A5},
+ {0, 0x0990, 0x001D},
+ {0, 0x098E, 0xC8A6},
+ {0, 0x0990, 0x0020},
+ {0, 0x098E, 0xC8A7},
+ {0, 0x0990, 0x0023},
+ {0, 0x098E, 0xC8A8},
+ {0, 0x0990, 0x0026},
+ {0, 0x098E, 0xC844},
+ {0, 0x0990, 0x0091},
+ {0, 0x098E, 0xC92F},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0xC845},
+ {0, 0x0990, 0x0079},
+ {0, 0x098E, 0xC92D},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0xC88C},
+ {0, 0x0990, 0x0091},
+ {0, 0x098E, 0xC930},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0xC88D},
+ {0, 0x0990, 0x0079},
+ {0, 0x098E, 0xC92E},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0xA002},
+ {0, 0x0990, 0x0010},
+ {0, 0x098E, 0xA009},
+ {0, 0x0990, 0x0002},
+ {0, 0x098E, 0xA00A},
+ {0, 0x0990, 0x0003},
+ {0, 0x098E, 0xA00C},
+ {0, 0x0990, 0x000A},
+ {0, 0x098E, 0x4846},
+ {0, 0x0990, 0x0014},
+ {0, 0x098E, 0x68AA},
+ {0, 0x0990, 0x0278},
+ {0, 0x098E, 0x488E},
+ {0, 0x0990, 0x0014},
+ {0, 0x098E, 0x6CAA},
+ {0, 0x0990, 0x0218},
+ {0, 0x098E, 0x8400},
+ {0, 0x0990, 0x0006},
+ {0, 0x098E, 0x8400},
+ {0, 0x0990, 0x0005},
+ {0, 0x3C20, 0x0001},
+ {0, 0x364A, 0x7D2F},
+ {0, 0x364C, 0x79EB},
+ {0, 0x364E, 0x18D2},
+ {0, 0x3650, 0x9F8F},
+ {0, 0x3652, 0xA7D2},
+ {0, 0x368A, 0x460C},
+ {0, 0x368C, 0x14F0},
+ {0, 0x368E, 0x946F},
+ {0, 0x3690, 0xC471},
+ {0, 0x3692, 0x04B1},
+ {0, 0x36CA, 0x0433},
+ {0, 0x36CC, 0x680D},
+ {0, 0x36CE, 0xEEF3},
+ {0, 0x36D0, 0x4850},
+ {0, 0x36D2, 0xF233},
+ {0, 0x370A, 0xB2AF},
+ {0, 0x370C, 0x2CF0},
+ {0, 0x370E, 0x3F10},
+ {0, 0x3710, 0xC673},
+ {0, 0x3712, 0xA972},
+ {0, 0x374A, 0x0590},
+ {0, 0x374C, 0xAFB3},
+ {0, 0x374E, 0x93D7},
+ {0, 0x3750, 0x8D12},
+ {0, 0x3752, 0x2539},
+ {0, 0x3640, 0x0350},
+ {0, 0x3642, 0x322C},
+ {0, 0x3644, 0x77D1},
+ {0, 0x3646, 0xA26F},
+ {0, 0x3648, 0xC872},
+ {0, 0x3680, 0x0C4C},
+ {0, 0x3682, 0x9510},
+ {0, 0x3684, 0x110E},
+ {0, 0x3686, 0x4331},
+ {0, 0x3688, 0xC1CF},
+ {0, 0x36C0, 0x6152},
+ {0, 0x36C2, 0x038E},
+ {0, 0x36C4, 0x9AF4},
+ {0, 0x36C6, 0xE12F},
+ {0, 0x36C8, 0x09F3},
+ {0, 0x3700, 0xC5AF},
+ {0, 0x3702, 0xCA90},
+ {0, 0x3704, 0x5D0F},
+ {0, 0x3706, 0x3293},
+ {0, 0x3708, 0x2B92},
+ {0, 0x3740, 0xC590},
+ {0, 0x3742, 0x8133},
+ {0, 0x3744, 0xE0F6},
+ {0, 0x3746, 0x0254},
+ {0, 0x3748, 0x10B9},
+ {0, 0x3654, 0x7F8F},
+ {0, 0x3656, 0x6F6C},
+ {0, 0x3658, 0x5971},
+ {0, 0x365A, 0x9A0F},
+ {0, 0x365C, 0xA1B2},
+ {0, 0x3694, 0xB00C},
+ {0, 0x3696, 0xEBCF},
+ {0, 0x3698, 0x06AD},
+ {0, 0x369A, 0x4D31},
+ {0, 0x369C, 0x2A4E},
+ {0, 0x36D4, 0x4752},
+ {0, 0x36D6, 0x724D},
+ {0, 0x36D8, 0xAD34},
+ {0, 0x36DA, 0x1350},
+ {0, 0x36DC, 0x4E94},
+ {0, 0x3714, 0xA06E},
+ {0, 0x3716, 0x9152},
+ {0, 0x3718, 0x1F53},
+ {0, 0x371A, 0x3933},
+ {0, 0x371C, 0xBA94},
+ {0, 0x3754, 0x1233},
+ {0, 0x3756, 0xA032},
+ {0, 0x3758, 0xE936},
+ {0, 0x375A, 0xBE34},
+ {0, 0x375C, 0x02D9},
+ {0, 0x365E, 0x7DEF},
+ {0, 0x3660, 0x434B},
+ {0, 0x3662, 0x69F1},
+ {0, 0x3664, 0x8A0F},
+ {0, 0x3666, 0xBDB2},
+ {0, 0x369E, 0x290D},
+ {0, 0x36A0, 0x42CF},
+ {0, 0x36A2, 0xDC6D},
+ {0, 0x36A4, 0x91B1},
+ {0, 0x36A6, 0x9DE9},
+ {0, 0x36DE, 0x70B2},
+ {0, 0x36E0, 0x02AC},
+ {0, 0x36E2, 0x9714},
+ {0, 0x36E4, 0xF3CF},
+ {0, 0x36E6, 0x6BD1},
+ {0, 0x371E, 0xE42E},
+ {0, 0x3720, 0x1D32},
+ {0, 0x3722, 0xCC31},
+ {0, 0x3724, 0xAE94},
+ {0, 0x3726, 0x6413},
+ {0, 0x375E, 0xE290},
+ {0, 0x3760, 0x8F53},
+ {0, 0x3762, 0xF936},
+ {0, 0x3764, 0x4614},
+ {0, 0x3766, 0x1B59},
+ {0, 0x3784, 0x0404},
+ {0, 0x3782, 0x0304},
+ {0, 0x3210, 0x01B8},
+ {0, 0x098E, 0xC913},
+ {0, 0x0990, 0x000A},
+ {0, 0x098E, 0x686B},
+ {0, 0x0990, 0x05DC},
+ {0, 0x098E, 0x686D},
+ {0, 0x0990, 0x0BB8},
+ {0, 0x098E, 0x6C6B},
+ {0, 0x0990, 0x05DC},
+ {0, 0x098E, 0x6C6D},
+ {0, 0x0990, 0x0BB8},
+ {0, 0x098E, 0x3439},
+ {0, 0x0990, 0x05DC},
+ {0, 0x098E, 0x343B},
+ {0, 0x0990, 0x0BB8},
+ {0, 0x098E, 0x4926},
+ {0, 0x0990, 0x0001},
+ {0, 0x098E, 0x4928},
+ {0, 0x0990, 0x0002},
+ {0, 0x098E, 0x492A},
+ {0, 0x0990, 0x0656},
+ {0, 0x098E, 0x4D26},
+ {0, 0x0990, 0x0001},
+ {0, 0x098E, 0x4D28},
+ {0, 0x0990, 0x0002},
+ {0, 0x098E, 0x4D2A},
+ {0, 0x0990, 0x0656},
+ {0, 0x33F4, 0x040B},
+ {0, 0x098E, 0xC916},
+ {0, 0x0990, 0x0014},
+ {0, 0x098E, 0xC919},
+ {0, 0x0990, 0x0028},
+ {0, 0x098E, 0xC917},
+ {0, 0x0990, 0x0004},
+ {0, 0x098E, 0xC918},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0xC91A},
+ {0, 0x0990, 0x0001},
+ {0, 0x098E, 0xC91B},
+ {0, 0x0990, 0x0009},
+ {0, 0x326C, 0x0C00},
+ {0, 0x098E, 0x494B},
+ {0, 0x0990, 0x0042},
+ {0, 0x098E, 0x494D},
+ {0, 0x0990, 0x012C},
+ {0, 0x098E, 0xC91E},
+ {0, 0x0990, 0x0012},
+ {0, 0x098E, 0xC91F},
+ {0, 0x0990, 0x000A},
+ {0, 0x098E, 0xC920},
+ {0, 0x0990, 0x0012},
+ {0, 0x098E, 0xC921},
+ {0, 0x0990, 0x000A},
+ {0, 0x098E, 0xC922},
+ {0, 0x0990, 0x0026},
+ {0, 0x098E, 0xC923},
+ {0, 0x0990, 0x001E},
+ {0, 0x098E, 0xC924},
+ {0, 0x0990, 0x0026},
+ {0, 0x098E, 0xC925},
+ {0, 0x0990, 0x0026},
+ {0, 0x098E, 0xBC02},
+ {0, 0x0990, 0x0003},
+ {0, 0x098E, 0xBC05},
+ {0, 0x0990, 0x000E},
+ {0, 0x098E, 0xC950},
+ {0, 0x0990, 0x0064},
+ {0, 0x098E, 0xC94F},
+ {0, 0x0990, 0x0038},
+ {0, 0x098E, 0xC952},
+ {0, 0x0990, 0x0064},
+ {0, 0x098E, 0xC951},
+ {0, 0x0990, 0x0051},
+ {0, 0x098E, 0xC954},
+ {0, 0x0990, 0x0010},
+ {0, 0x098E, 0xC953},
+ {0, 0x0990, 0x0020},
+ {0, 0x098E, 0xC956},
+ {0, 0x0990, 0x0010},
+ {0, 0x098E, 0xC955},
+ {0, 0x0990, 0x0020},
+ {0, 0x098E, 0xC958},
+ {0, 0x0990, 0x0020},
+ {0, 0x098E, 0xC957},
+ {0, 0x0990, 0x0014},
+ {0, 0x098E, 0xC95A},
+ {0, 0x0990, 0x001D},
+ {0, 0x098E, 0xC959},
+ {0, 0x0990, 0x0020},
+ {0, 0x098E, 0xC95C},
+ {0, 0x0990, 0x000C},
+ {0, 0x098E, 0xC95B},
+ {0, 0x0990, 0x0008},
+ {0, 0x098E, 0xC95E},
+ {0, 0x0990, 0x000C},
+ {0, 0x098E, 0xC95D},
+ {0, 0x0990, 0x0008},
+ {0, 0x098E, 0xC95F},
+ {0, 0x0990, 0x0064},
+ {0, 0x098E, 0x48DC},
+ {0, 0x0990, 0x004D},
+ {0, 0x098E, 0x48DE},
+ {0, 0x0990, 0x0096},
+ {0, 0x098E, 0x48E0},
+ {0, 0x0990, 0x001D},
+ {0, 0x098E, 0x48E2},
+ {0, 0x0990, 0x004D},
+ {0, 0x098E, 0x48E4},
+ {0, 0x0990, 0x0096},
+ {0, 0x098E, 0x48E6},
+ {0, 0x0990, 0x001D},
+ {0, 0x098E, 0x48E8},
+ {0, 0x0990, 0x004D},
+ {0, 0x098E, 0x48EA},
+ {0, 0x0990, 0x0096},
+ {0, 0x098E, 0x48EC},
+ {0, 0x0990, 0x001D},
+ {0, 0x098E, 0xDC2A},
+ {0, 0x0990, 0x000B},
+ {0, 0x098E, 0xDC2B},
+ {0, 0x0990, 0x0017},
+ {0, 0x098E, 0xBC0B},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0xBC0C},
+ {0, 0x0990, 0x001B},
+ {0, 0x098E, 0xBC0D},
+ {0, 0x0990, 0x002A},
+ {0, 0x098E, 0xBC0E},
+ {0, 0x0990, 0x003E},
+ {0, 0x098E, 0xBC0F},
+ {0, 0x0990, 0x005A},
+ {0, 0x098E, 0xBC10},
+ {0, 0x0990, 0x0070},
+ {0, 0x098E, 0xBC11},
+ {0, 0x0990, 0x0081},
+ {0, 0x098E, 0xBC12},
+ {0, 0x0990, 0x0090},
+ {0, 0x098E, 0xBC13},
+ {0, 0x0990, 0x009E},
+ {0, 0x098E, 0xBC14},
+ {0, 0x0990, 0x00AB},
+ {0, 0x098E, 0xBC15},
+ {0, 0x0990, 0x00B6},
+ {0, 0x098E, 0xBC16},
+ {0, 0x0990, 0x00C1},
+ {0, 0x098E, 0xBC17},
+ {0, 0x0990, 0x00CB},
+ {0, 0x098E, 0xBC18},
+ {0, 0x0990, 0x00D5},
+ {0, 0x098E, 0xBC19},
+ {0, 0x0990, 0x00DE},
+ {0, 0x098E, 0xBC1A},
+ {0, 0x0990, 0x00E7},
+ {0, 0x098E, 0xBC1B},
+ {0, 0x0990, 0x00EF},
+ {0, 0x098E, 0xBC1C},
+ {0, 0x0990, 0x00F7},
+ {0, 0x098E, 0xBC1D},
+ {0, 0x0990, 0x00FF},
+ {0, 0x098E, 0xBC1E},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0xBC1F},
+ {0, 0x0990, 0x001B},
+ {0, 0x098E, 0xBC20},
+ {0, 0x0990, 0x002A},
+ {0, 0x098E, 0xBC21},
+ {0, 0x0990, 0x003E},
+ {0, 0x098E, 0xBC22},
+ {0, 0x0990, 0x005A},
+ {0, 0x098E, 0xBC23},
+ {0, 0x0990, 0x0070},
+ {0, 0x098E, 0xBC24},
+ {0, 0x0990, 0x0081},
+ {0, 0x098E, 0xBC25},
+ {0, 0x0990, 0x0090},
+ {0, 0x098E, 0xBC26},
+ {0, 0x0990, 0x009E},
+ {0, 0x098E, 0xBC27},
+ {0, 0x0990, 0x00AB},
+ {0, 0x098E, 0xBC28},
+ {0, 0x0990, 0x00B6},
+ {0, 0x098E, 0xBC29},
+ {0, 0x0990, 0x00C1},
+ {0, 0x098E, 0xBC2A},
+ {0, 0x0990, 0x00CB},
+ {0, 0x098E, 0xBC2B},
+ {0, 0x0990, 0x00D5},
+ {0, 0x098E, 0xBC2C},
+ {0, 0x0990, 0x00DE},
+ {0, 0x098E, 0xBC2D},
+ {0, 0x0990, 0x00E7},
+ {0, 0x098E, 0xBC2E},
+ {0, 0x0990, 0x00EF},
+ {0, 0x098E, 0xBC2F},
+ {0, 0x0990, 0x00F7},
+ {0, 0x098E, 0xBC30},
+ {0, 0x0990, 0x00FF},
+ {0, 0x098E, 0xBC31},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0xBC32},
+ {0, 0x0990, 0x000D},
+ {0, 0x098E, 0xBC33},
+ {0, 0x0990, 0x0019},
+ {0, 0x098E, 0xBC34},
+ {0, 0x0990, 0x0030},
+ {0, 0x098E, 0xBC35},
+ {0, 0x0990, 0x0056},
+ {0, 0x098E, 0xBC36},
+ {0, 0x0990, 0x0070},
+ {0, 0x098E, 0xBC37},
+ {0, 0x0990, 0x0081},
+ {0, 0x098E, 0xBC38},
+ {0, 0x0990, 0x0090},
+ {0, 0x098E, 0xBC39},
+ {0, 0x0990, 0x009E},
+ {0, 0x098E, 0xBC3A},
+ {0, 0x0990, 0x00AB},
+ {0, 0x098E, 0xBC3B},
+ {0, 0x0990, 0x00B6},
+ {0, 0x098E, 0xBC3C},
+ {0, 0x0990, 0x00C1},
+ {0, 0x098E, 0xBC3D},
+ {0, 0x0990, 0x00CB},
+ {0, 0x098E, 0xBC3E},
+ {0, 0x0990, 0x00D5},
+ {0, 0x098E, 0xBC3F},
+ {0, 0x0990, 0x00DE},
+ {0, 0x098E, 0xBC40},
+ {0, 0x0990, 0x00E7},
+ {0, 0x098E, 0xBC41},
+ {0, 0x0990, 0x00EF},
+ {0, 0x098E, 0xBC42},
+ {0, 0x0990, 0x00F7},
+ {0, 0x098E, 0xBC43},
+ {0, 0x0990, 0x00FF},
+ {0, 0x098E, 0x6865},
+ {0, 0x0990, 0x00E0},
+ {0, 0x098E, 0x6867},
+ {0, 0x0990, 0x00F4},
+ {0, 0x098E, 0x8400},
+ {0, 0x0990, 0x0006},
+ {0, 0x098E, 0xBC4A},
+ {0, 0x0990, 0x007F},
+ {0, 0x098E, 0xBC4B},
+ {0, 0x0990, 0x007F},
+ {0, 0x098E, 0xBC4C},
+ {0, 0x0990, 0x007F},
+ {0, 0x3542, 0x0010},
+ {0, 0x3544, 0x0030},
+ {0, 0x3546, 0x0040},
+ {0, 0x3548, 0x0080},
+ {0, 0x354A, 0x0100},
+ {0, 0x354C, 0x0200},
+ {0, 0x354E, 0x0300},
+ {0, 0x3550, 0x0010},
+ {0, 0x3552, 0x0030},
+ {0, 0x3554, 0x0040},
+ {0, 0x3556, 0x0080},
+ {0, 0x3558, 0x012C},
+ {0, 0x355A, 0x0320},
+ {0, 0x355C, 0x03E8},
+ {0, 0x3560, 0x0040},
+ {0, 0x3562, 0x0020},
+ {0, 0x3564, 0x0040},
+ {0, 0x3566, 0x0010},
+ {0, 0x3568, 0x0008},
+ {0, 0x356A, 0x0004},
+ {0, 0x356C, 0x0004},
+ {0, 0x356E, 0x0004},
+ {0, 0x098E, 0x3C4D},
+ {0, 0x0990, 0x0DAC},
+ {0, 0x098E, 0x3C4F},
+ {0, 0x0990, 0x148A},
+ {0, 0x098E, 0xC911},
+ {0, 0x0990, 0x00C8},
+ {0, 0x098E, 0xC8F4},
+ {0, 0x0990, 0x0004},
+ {0, 0x098E, 0xC8F5},
+ {0, 0x0990, 0x0002},
+ {0, 0x098E, 0x48F6},
+ {0, 0x0990, 0x3B4D},
+ {0, 0x098E, 0x48F8},
+ {0, 0x0990, 0x6380},
+ {0, 0x098E, 0x48FA},
+ {0, 0x0990, 0x9B18},
+ {0, 0x098E, 0x48FC},
+ {0, 0x0990, 0x5D51},
+ {0, 0x098E, 0x48FE},
+ {0, 0x0990, 0xEDE8},
+ {0, 0x098E, 0x4900},
+ {0, 0x0990, 0xE515},
+ {0, 0x098E, 0x4902},
+ {0, 0x0990, 0xBFF4},
+ {0, 0x098E, 0x4904},
+ {0, 0x0990, 0x001E},
+ {0, 0x098E, 0x4906},
+ {0, 0x0990, 0x0026},
+ {0, 0x098E, 0x4908},
+ {0, 0x0990, 0x0033},
+ {0, 0x098E, 0xE84A},
+ {0, 0x0990, 0x0083},
+ {0, 0x098E, 0xE84D},
+ {0, 0x0990, 0x0083},
+ {0, 0x098E, 0xE84C},
+ {0, 0x0990, 0x0080},
+ {0, 0x098E, 0xE84F},
+ {0, 0x0990, 0x0080},
+ {0, 0x098E, 0x8400},
+ {0, 0x0990, 0x0006},
+ {0, 0x098E, 0x48B0},
+ {0, 0x0990, 0x0180},
+ {0, 0x098E, 0x48B2},
+ {0, 0x0990, 0xFF7A},
+ {0, 0x098E, 0x48B4},
+ {0, 0x0990, 0x0018},
+ {0, 0x098E, 0x48B6},
+ {0, 0x0990, 0xFFCA},
+ {0, 0x098E, 0x48B8},
+ {0, 0x0990, 0x017C},
+ {0, 0x098E, 0x48BA},
+ {0, 0x0990, 0xFFCC},
+ {0, 0x098E, 0x48BC},
+ {0, 0x0990, 0x000C},
+ {0, 0x098E, 0x48BE},
+ {0, 0x0990, 0xFF1F},
+ {0, 0x098E, 0x48C0},
+ {0, 0x0990, 0x01E8},
+ {0, 0x098E, 0x48C2},
+ {0, 0x0990, 0x0020},
+ {0, 0x098E, 0x48C4},
+ {0, 0x0990, 0x0044},
+ {0, 0x098E, 0x48C6},
+ {0, 0x0990, 0x0079},
+ {0, 0x098E, 0x48C8},
+ {0, 0x0990, 0xFFAD},
+ {0, 0x098E, 0x48CA},
+ {0, 0x0990, 0xFFE2},
+ {0, 0x098E, 0x48CC},
+ {0, 0x0990, 0x0033},
+ {0, 0x098E, 0x48CE},
+ {0, 0x0990, 0x002A},
+ {0, 0x098E, 0x48D0},
+ {0, 0x0990, 0xFFAA},
+ {0, 0x098E, 0x48D2},
+ {0, 0x0990, 0x0017},
+ {0, 0x098E, 0x48D4},
+ {0, 0x0990, 0x004B},
+ {0, 0x098E, 0x48D6},
+ {0, 0x0990, 0xFFA5},
+ {0, 0x098E, 0x48D8},
+ {0, 0x0990, 0x0015},
+ {0, 0x098E, 0x48DA},
+ {0, 0x0990, 0xFFE2},
+ {0, 0x35A2, 0x0014},
+ {0, 0x098E, 0xC949},
+ {0, 0x0990, 0x0024},
+ {0, 0x35A4, 0x0596},
+ {0, 0x098E, 0xC94A},
+ {0, 0x0990, 0x0062},
+ {0, 0x098E, 0xC948},
+ {0, 0x0990, 0x0006},
+ {0, 0x098E, 0xC914},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0xC915},
+ {0, 0x0990, 0x00FF},
+ {0, 0x098E, 0xE86F},
+ {0, 0x0990, 0x0060},
+ {0, 0x098E, 0xE870},
+ {0, 0x0990, 0x003C},
+ {0, 0x098E, 0xEC6F},
+ {0, 0x0990, 0x0060},
+ {0, 0x098E, 0xEC70},
+ {0, 0x0990, 0x003C},
+ {0, 0x098E, 0xE883},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0xEC83},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0x8400},
+ {0, 0x0990, 0x0006},
+ {0, 0x098E, 0xE885},
+ {0, 0x0990, 0x001E},
+ {0, 0x098E, 0xE886},
+ {0, 0x0990, 0x00D8},
+ {0, 0x098E, 0xEC85},
+ {0, 0x0990, 0x001E},
+ {0, 0x098E, 0xEC86},
+ {0, 0x0990, 0x00D8},
+ {0, 0x098E, 0xE884},
+ {0, 0x0990, 0x005C},
+ {0, 0x098E, 0xEC84},
+ {0, 0x0990, 0x005C},
+ {0, 0x098E, 0x490A},
+ {0, 0x0990, 0x0666},
+ {0, 0x098E, 0x490C},
+ {0, 0x0990, 0x0140},
+ {0, 0x098E, 0x6857},
+ {0, 0x0990, 0x0014},
+ {0, 0x098E, 0x685C},
+ {0, 0x0990, 0x0005},
+ {0, 0x098E, 0x490E},
+ {0, 0x0990, 0x00A4},
+ {0, 0x098E, 0xB43D},
+ {0, 0x0990, 0x0031},
+ {0, 0x098E, 0xB43E},
+ {0, 0x0990, 0x001B},
+ {0, 0x098E, 0xB43F},
+ {0, 0x0990, 0x0028},
+ {0, 0x098E, 0xB440},
+ {0, 0x0990, 0x0003},
+ {0, 0x098E, 0xB441},
+ {0, 0x0990, 0x00CD},
+ {0, 0x098E, 0xB442},
+ {0, 0x0990, 0x0064},
+ {0, 0x098E, 0xB443},
+ {0, 0x0990, 0x000F},
+ {0, 0x098E, 0xB444},
+ {0, 0x0990, 0x0007},
+ {0, 0x098E, 0x300D},
+ {0, 0x0990, 0x000F},
+ {0, 0x098E, 0x3017},
+ {0, 0x0990, 0x0F0F},
+ {0, 0x098E, 0x8400},
+ {0, 0x0990, 0x0006},
+ {0, 0x098E, 0xE81F},
+ {0, 0x0990, 0x0020},
+ {0, 0x098E, 0x68A0},
+ {0, 0x0990, 0x082E},
+ {0, 0x098E, 0x6CA0},
+ {0, 0x0990, 0x082E},
+ {0, 0x098E, 0x70A0},
+ {0, 0x0990, 0x082E},
+ {0, 0x098E, 0x74A0},
+ {0, 0x0990, 0x082E},
+ {0, 0x3C52, 0x082E},
+ {0, 0x098E, 0x488E},
+ {0, 0x0990, 0x0020},
+ {0, 0x098E, 0xECAC},
+ {0, 0x0990, 0x0000}
+};
+
+mt9t111_regs def_regs2[] = {
+ {100, 0x0018, 0x0028},
+ {0, 0x316C, 0x350F},
+ {0, 0x098E, 0x6817},
+ {0, 0x0990, 0x000C},
+ {0, 0x0034, 0x0000}
+};
+
+mt9t111_regs pll_regs1[] = {
+ {0, 0x0014, 0x2425},
+ {0, 0x0014, 0x2425},
+ {0, 0x0014, 0x2145},
+ {0, 0x0010, 0x0219},
+ {0, 0x0012, 0x0090},
+ {0, 0x002A, 0x79DD},
+ {0, 0x0014, 0x2545},
+ {0, 0x0014, 0x2547},
+ {0, 0x0014, 0x3447},
+ {0, 0x0014, 0x3047}
+};
+
+mt9t111_regs pll_regs2[] = {
+ {0, 0x0014, 0x3046},
+ {0, 0x0022, 0x01E0},
+ {0, 0x001E, 0x0707},
+ {0, 0x3B84, 0x011D}
+};
+
+mt9t111_regs bayer_pattern_regs[] = {
+ {0, 0x098E, 0x6807},
+ {0, 0x0990, 0x0100},
+ {0, 0x098E, 0x6809},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0xE88E},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0x6C07},
+ {0, 0x0990, 0x0100},
+ {0, 0x098E, 0x6C09},
+ {0, 0x0990, 0x0000},
+ {0, 0x098E, 0xEC8E},
+ {0, 0x0990, 0x0000}
+};
+
+#endif
diff --git a/include/media/mt9t111.h b/include/media/mt9t111.h
new file mode 100644
index 0000000..1d6a583
--- /dev/null
+++ b/include/media/mt9t111.h
@@ -0,0 +1,45 @@
+/*
+ * include/media/mt9t111.h
+ *
+ * mt9t111 sensor driver
+ *
+ * Copyright (C) 2009 Leopard Imaging
+ *
+ * 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.
+ */
+
+#ifndef MT9T111_H
+#define MT9T111_H
+
+struct v4l2_subdev;
+
+/*
+ * Defines and Macros and globals
+ */
+#define MT9T111_MODULE_NAME "mt9t111"
+
+/*i2c adress for MT9T111*/
+#define MT9T111_I2C_ADDR (0x78 >> 1)
+
+#define MT9T111_CLK_MAX (96000000) /* 96MHz */
+#define MT9T111_CLK_MIN (6000000) /* 6Mhz */
+
+#define MT9T111_I2C_CONFIG (1)
+#define I2C_ONE_BYTE_TRANSFER (1)
+#define I2C_TWO_BYTE_TRANSFER (2)
+#define I2C_THREE_BYTE_TRANSFER (3)
+#define I2C_FOUR_BYTE_TRANSFER (4)
+#define I2C_TXRX_DATA_MASK (0x00FF)
+#define I2C_TXRX_DATA_MASK_UPPER (0xFF00)
+#define I2C_TXRX_DATA_SHIFT (8)
+
+struct mt9t111_platform_data {
+ int (*s_power) (struct v4l2_subdev *subdev, u32 on);
+ int (*set_xclk) (struct v4l2_subdev *subdev, u32 hz);
+ int (*configure_interface) (struct v4l2_subdev *subdev, u32 pixclk);
+};
+
+#endif /* ifndef MT9T111 */
+
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/5] omap3evm: Add Camera board init/hookup file
From: Deepthy Ravi @ 2011-09-20 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316530612-23075-1-git-send-email-deepthy.ravi@ti.com>
From: Vaibhav Hiremath <hvaibhav@ti.com>
Adds board support for MT9T111 sensor.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Deepthy Ravi <deepthy.ravi@ti.com>
---
arch/arm/mach-omap2/Makefile | 5 +
arch/arm/mach-omap2/board-omap3evm-camera.c | 185 +++++++++++++++++++++++++++
arch/arm/mach-omap2/board-omap3evm.c | 4 +
3 files changed, 194 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f343365..a19753c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -280,3 +280,8 @@ disp-$(CONFIG_OMAP2_DSS) := display.o
obj-y += $(disp-m) $(disp-y)
obj-y += common-board-devices.o twl-common.o
+
+ifeq ($(CONFIG_MACH_OMAP3EVM),y)
+evm-camera-$(CONFIG_VIDEO_OMAP3) := board-omap3evm-camera.o
+obj-y += $(evm-camera-m) $(evm-camera-y)
+endif
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c b/arch/arm/mach-omap2/board-omap3evm-camera.c
new file mode 100644
index 0000000..e762f61
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,185 @@
+/*
+ * arch/arm/mach-omap2/board-omap3evm-camera.c
+ *
+ * OMAP3EVM: Driver for Leopard Module Board
+ *
+ * Copyright (C) 2011 Texas Instruments Inc
+ * Author: Vaibhav Hiremath <hvaibhav@ti.com>
+ *
+ * This package 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/io.h>
+#include <linux/i2c.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <mach/gpio.h>
+#include <media/mt9t111.h>
+#include <media/omap3isp.h>
+#include <../drivers/media/video/omap3isp/isp.h>
+#include "devices.h"
+
+#define CAM_USE_XCLKA 0
+
+#define T2_GPIO_2 194
+#define nCAM_VD_SEL 157
+#define nCAM_VD_EN 200
+
+/* mux id to enable/disable signal routing to different peripherals */
+enum omap3evm_cam_mux {
+ MUX_EN_TVP5146 = 0,
+ MUX_EN_CAMERA_SENSOR,
+ MUX_EN_EXP_CAMERA_SENSOR,
+ MUX_INVALID,
+};
+
+/**
+ * @brief omap3evm_set_mux - Sets mux to enable/disable signal routing to
+ * different peripherals present on new EVM board
+ *
+ * @param mux_id - enum, mux id to enable/disable
+ * @param value - enum, ENABLE_MUX for enabling and DISABLE_MUX for disabling
+ *
+ */
+static void omap3evm_set_mux(enum omap3evm_cam_mux mux_id)
+{
+ switch (mux_id) {
+ /*
+ * JP1 jumper need to configure to choose between on-board
+ * camera sensor conn and on-board LI-3MC02 camera sensor.
+ */
+ case MUX_EN_CAMERA_SENSOR:
+ /* Set nCAM_VD_EN (T2_GPIO8) = 0 */
+ gpio_set_value_cansleep(nCAM_VD_EN, 0);
+ /* Set nCAM_VD_SEL (GPIO157) = 0 */
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+ case MUX_EN_EXP_CAMERA_SENSOR:
+ /* Set nCAM_VD_EN (T2_GPIO8) = 1 */
+ gpio_set_value_cansleep(nCAM_VD_EN, 1);
+ break;
+ case MUX_EN_TVP5146:
+ default:
+ /* Set nCAM_VD_EN (T2_GPIO8) = 0 */
+ gpio_set_value_cansleep(nCAM_VD_EN, 0);
+ /* Set nCAM_VD_SEL (GPIO157) = 1 */
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+ }
+}
+
+/* MT9T111: 3M sensor */
+static int omap3evm_mt9t111_s_power(struct v4l2_subdev *subdev, u32 on)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev->v4l2_dev);
+
+ omap3evm_set_mux(MUX_EN_CAMERA_SENSOR);
+
+ if (on) {
+ /* Enable EXTCLK */
+ if (isp->platform_cb.set_xclk)
+ isp->platform_cb.set_xclk(isp, 24000000, CAM_USE_XCLKA);
+ udelay(5);
+ } else {
+ if (isp->platform_cb.set_xclk)
+ isp->platform_cb.set_xclk(isp, 0, CAM_USE_XCLKA);
+ }
+
+ return 0;
+}
+
+static struct mt9t111_platform_data omap3evm_mt9t111_platform_data = {
+ .s_power = omap3evm_mt9t111_s_power,
+};
+
+
+#define MT9T111_I2C_BUS_NUM 2
+
+static struct i2c_board_info omap3evm_camera_i2c_devices[] = {
+ {
+ I2C_BOARD_INFO(MT9T111_MODULE_NAME, MT9T111_I2C_ADDR),
+ .platform_data = &omap3evm_mt9t111_platform_data,
+ }
+};
+
+static struct isp_subdev_i2c_board_info omap3evm_mt9t111_subdevs[] = {
+ {
+ .board_info = &omap3evm_camera_i2c_devices[0],
+ .i2c_adapter_id = MT9T111_I2C_BUS_NUM,
+ },
+ { NULL, 0 },
+};
+
+static struct isp_v4l2_subdevs_group omap3evm_camera_subdevs[] = {
+ {
+ .subdevs = omap3evm_mt9t111_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 1,
+ .clk_pol = 0,
+ .hs_pol = 0,
+ .vs_pol = 0,
+ .bridge = 3,
+ .bt656 = 0,
+ },
+ },
+ },
+ { NULL, 0 },
+};
+
+static struct isp_platform_data omap3evm_isp_platform_data = {
+ .subdevs = omap3evm_camera_subdevs,
+};
+
+static struct gpio omap3evm_gpios[] __initdata = {
+ /* First level GPIO enable: T2_GPIO.2 */
+ { T2_GPIO_2, GPIOF_OUT_INIT_LOW, "T2_GPIO.2" },
+ /* nCAM_VD_SEL (GPIO157) */
+ { nCAM_VD_SEL, GPIOF_OUT_INIT_HIGH, "cam_vd_sel" },
+ /*EXP_nCAM_VD_EN (T2_GPIO.8) */
+ { nCAM_VD_EN, GPIOF_OUT_INIT_LOW, "cam_vd_en" },
+};
+
+static int __init omap3evm_cam_init(void)
+{
+ int ret;
+
+ ret = gpio_request_array(omap3evm_gpios,
+ ARRAY_SIZE(omap3evm_gpios));
+ if (ret < 0) {
+ printk(KERN_ERR "Unable to get GPIO pins\n");
+ return ret;
+ }
+
+ omap3_init_camera(&omap3evm_isp_platform_data);
+
+ printk(KERN_INFO "omap3evm camera init done successfully...\n");
+ return 0;
+}
+
+static void __exit omap3evm_cam_exit(void)
+{
+ gpio_free_array(omap3evm_gpios,
+ ARRAY_SIZE(omap3evm_gpios));
+}
+
+module_init(omap3evm_cam_init);
+module_exit(omap3evm_cam_exit);
+
+MODULE_AUTHOR("Texas Instruments");
+MODULE_DESCRIPTION("OMAP3EVM: Driver for Leopard Module Board");
+MODULE_LICENSE("GPL");
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index cf30fff..be15394 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -572,6 +572,8 @@ static struct omap_board_mux omap35x_board_mux[] __initdata = {
OMAP_PIN_OFF_NONE),
OMAP3_MUX(GPMC_WAIT2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(MCBSP1_FSR, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_NONE),
#ifdef CONFIG_WL12XX_PLATFORM_DATA
/* WLAN IRQ - GPIO 149 */
OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
@@ -597,6 +599,8 @@ static struct omap_board_mux omap36x_board_mux[] __initdata = {
OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_INPUT_PULLUP | OMAP_PIN_OFF_OUTPUT_LOW |
OMAP_PIN_OFF_WAKEUPENABLE),
+ OMAP3_MUX(MCBSP1_FSR, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_NONE),
/* AM/DM37x EVM: DSS data bus muxed with sys_boot */
OMAP3_MUX(DSS_DATA18, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
OMAP3_MUX(DSS_DATA19, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
--
1.7.0.4
^ permalink raw reply related
* [PATCH 4/5] ispccdc: Configure CCDC_SYN_MODE register for UYVY8_2X8 and YUYV8_2X8 formats
From: Deepthy Ravi @ 2011-09-20 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316530612-23075-1-git-send-email-deepthy.ravi@ti.com>
Configure INPMOD and PACK8 fileds of CCDC_SYN_MODE
register for UYVY8_2X8 and YUYV8_2X8 formats.
Signed-off-by: Deepthy Ravi <deepthy.ravi@ti.com>
---
drivers/media/video/omap3isp/ispccdc.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c
index 418ba65..1dcf180 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -985,8 +985,12 @@ static void ccdc_config_sync_if(struct isp_ccdc_device *ccdc,
syn_mode &= ~ISPCCDC_SYN_MODE_INPMOD_MASK;
if (format->code == V4L2_MBUS_FMT_YUYV8_2X8 ||
- format->code == V4L2_MBUS_FMT_UYVY8_2X8)
- syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
+ format->code == V4L2_MBUS_FMT_UYVY8_2X8){
+ if (pdata && pdata->bt656)
+ syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
+ else
+ syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
+ }
else if (format->code == V4L2_MBUS_FMT_YUYV8_1X16 ||
format->code == V4L2_MBUS_FMT_UYVY8_1X16)
syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
@@ -1172,7 +1176,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
syn_mode &= ~ISPCCDC_SYN_MODE_SDR2RSZ;
/* Use PACK8 mode for 1byte per pixel formats. */
- if (omap3isp_video_format_info(format->code)->width <= 8)
+ if ((omap3isp_video_format_info(format->code)->width <= 8) &&
+ (omap3isp_video_format_info(format->code)->bpp <= 8))
syn_mode |= ISPCCDC_SYN_MODE_PACK8;
else
syn_mode &= ~ISPCCDC_SYN_MODE_PACK8;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 5/5] omap2plus_defconfig: Enable omap3isp and MT9T111 sensor drivers
From: Deepthy Ravi @ 2011-09-20 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316530612-23075-1-git-send-email-deepthy.ravi@ti.com>
Enables multimedia driver, media controller api,
v4l2-subdev-api, omap3isp and mt9t111 sensor
drivers in omap2plus_defconfig.
Signed-off-by: Deepthy Ravi <deepthy.ravi@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index d5f00d7..548823d 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -133,6 +133,16 @@ CONFIG_TWL4030_WATCHDOG=y
CONFIG_REGULATOR_TWL4030=y
CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CONTROLLER=y
+CONFIG_VIDEO_DEV=y
+CONFIG_VIDEO_V4L2_COMMON=y
+CONFIG_VIDEO_ALLOW_V4L1=y
+CONFIG_VIDEO_V4L1_COMPAT=y
+CONFIG_VIDEO_V4L2_SUBDEV_API=y
+CONFIG_VIDEO_MEDIA=y
+CONFIG_VIDEO_MT9T111=y
+CONFIG_VIDEO_OMAP3=y
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
--
1.7.0.4
^ permalink raw reply related
* [PATCH] arm: Add unwinding annotations for 64bit division functions
From: Catalin Marinas @ 2011-09-20 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1109200922281.12663@xanadu.home>
On Tue, Sep 20, 2011 at 02:27:01PM +0100, Nicolas Pitre wrote:
> On Mon, 19 Sep 2011, Laura Abbott wrote:
> > On Mon, September 19, 2011 4:22 pm, Nicolas Pitre wrote:
> > > On Mon, 19 Sep 2011, Laura Abbott wrote:
> > >> @@ -189,7 +191,12 @@ ENTRY(__do_div64)
> > >> moveq yh, xh
> > >> moveq xh, #0
> > >> moveq pc, lr
> > >> +UNWIND(.fnend)
> > >>
> > >> +UNWIND(.fnstart)
> > >> +UNWIND(.pad #4)
> > >> +UNWIND(.save {lr})
> > >> +Ldiv0_64:
> > >
> > > Why this phony fnend+fnstart here?
> >
> > If a division by 0 occurs, we need to be able to access the saved LR on
> > the stack which is setup right before calling the __div0 function. This
> > can't go at the top of __do_div64 because if we try to do a backtrace from
> > within __do_div64 the annotation won't be correct as the LR was never
> > saved on the stack.
>
> I suppose the debug infrastructure always assume the same stack frame
> for the whole function, hence you can't put that .pad and .save right
> before the call to __div0 without the .fnstart and have it effective
> only there?
An element in the unwinding table contains a pointer to the .fnstart
location and a set of instruction bytecodes (like .save) to the next
.fnend statement. If more 4 bytecodes (to fit in an int), it contains an
index to another table with more bytecodes. The elements in the
unwinding table are sorted by the .fnstart address.
So I think in the above case if we don't have the .fnend/.fnstart for
Ldiv0_64 we would get all the instructions in the __do_div64 unwinding
information. I don't think the unwinding bytecode is that smart to allow
other tricks like checking some conditions.
Unless anyone has a better idea to specify this:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 8/8] OMAP4: Fix the emif and dmm virtual mapping
From: Santosh Shilimkar @ 2011-09-20 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r53gnzfh.fsf@ti.com>
On Friday 16 September 2011 11:26 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> Fix the address overlap with Emulation domain (EMU).
>>
>> The previous mapping was entering into EMU mapping
>> and was not as per comments. Fix the mapping accordingly.
>>
>> [girishsg at ti.com: Helped fixing comments.]
>> Signed-off-by: Girish S G <girishsg@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> arch/arm/plat-omap/include/plat/io.h | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-omap/include/plat/io.h
>> index d72ec85..a2f7d31 100644
>> --- a/arch/arm/plat-omap/include/plat/io.h
>> +++ b/arch/arm/plat-omap/include/plat/io.h
>> @@ -228,12 +228,12 @@
>>
>> #define OMAP44XX_EMIF2_PHYS OMAP44XX_EMIF2_BASE
>> /* 0x4d000000 --> 0xfd200000 */
>> -#define OMAP44XX_EMIF2_VIRT (OMAP44XX_EMIF2_PHYS + OMAP4_L3_PER_IO_OFFSET)
>> +#define OMAP44XX_EMIF2_VIRT (OMAP44XX_EMIF1_VIRT + SZ_1M)
>
> IMO, this would be much clearer (and future proof) if you used
> '+ OMAP44XX_EMIF1_SIZE' instead of SZ_1M.
>
ok.
>> #define OMAP44XX_EMIF2_SIZE SZ_1M
>>
>> #define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE
>> /* 0x4e000000 --> 0xfd300000 */
>> -#define OMAP44XX_DMM_VIRT (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET)
>> +#define OMAP44XX_DMM_VIRT (OMAP44XX_EMIF2_VIRT + SZ_1M)
>
> and '+ OMAP44XX_EMIF2_SIZE' here.
>
Will add OMAP44XX_EMIF_SIZE since 2 EMIFs instaces are and
suppose to be identical.Almost missed this email in other traffic.
Regards
Santosh
^ permalink raw reply
* [PATCH 2/5] [media] v4l: Add mt9t111 sensor driver
From: Guennadi Liakhovetski @ 2011-09-20 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316530612-23075-3-git-send-email-deepthy.ravi@ti.com>
On Tue, 20 Sep 2011, Deepthy Ravi wrote:
> From: Vaibhav Hiremath <hvaibhav@ti.com>
>
> The MT9T111 is a 3.1Mp CMOS sensor from Aptina with
> its latest image signal processing (ISP) and 1.75??m
> pixel technology.
> The sensor driver currently supports only VGA
> resolution.
>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Signed-off-by: Deepthy Ravi <deepthy.ravi@ti.com>
> ---
> drivers/media/video/Kconfig | 7 +
> drivers/media/video/Makefile | 1 +
> drivers/media/video/mt9t111.c | 793 +++++++++++++++++++++
> drivers/media/video/mt9t111_reg.h | 1367 +++++++++++++++++++++++++++++++++++++
> include/media/mt9t111.h | 45 ++
> 5 files changed, 2213 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/mt9t111.c
> create mode 100644 drivers/media/video/mt9t111_reg.h
> create mode 100644 include/media/mt9t111.h
NAK. The mt9t112 driver claims to also support mt9t111. I'm not sure,
whether the driver has indeed been tested with mt9t111, but this is
definitely something to verify. If the chips are indeed similar, please
use the tree at
http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/shortlog/refs/heads/rc1-for-3.2
which has converted the mt9t112 driver to be also used outside ot the
soc-camera subsystem, and use that driver instead of adding another one.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Cousson, Benoit @ 2011-09-20 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E77B9E3.40004@gmail.com>
On 9/19/2011 11:53 PM, Rob Herring wrote:
> On 09/19/2011 04:14 PM, Grant Likely wrote:
>> On Mon, Sep 19, 2011 at 7:48 AM, Rob Herring<robherring2@gmail.com> wrote:
>>> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>>>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>>>> I was headed down the path of implementing the 2nd option above,
>>>>> but had a dilemma. What would be the numbering base for PPIs in
>>>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>>>> stay at 16?
>>>>
>>>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>>>> to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID#
>>>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>>>> processor has its own private timers that can generate interrupts,
>>>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>>>> its own watchdog timers that can generate interrupts, using ID30.
>>>>
>>>> So in that case, it can makes sense to use the ID. But it is
>>>> interesting to note that the PPI is identified with a 0 based index
>>>> number.
>>>>
>>> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
>>> for the timer interrupt. The first would match 0 based SPI convention.
>>> The last 2 would both match the documentation. We could never use 2 as
>>> this will for sure be different and the GIC code will have no way to
>>> know how to do the translation to ID. The only sane choice is using the
>>> ID as you say.
>>>
>>> But you can't have it both ways. It does not make sense to use the ID
>>> for some interrupts and a different scheme for others.
>>
>> Hmmm, it seems to me that some orthogonal issues are getting
>> conflated. Specifically, the binding vs. what the GIC driver using
>> internally. For my own understanding, let me see if I can summarize
>> and clarify the problem.
>>
>> Each GIC IRQ is represented in 5 different ways:
>> 1) the hardware documentation (PPI[0-15] or SPI[988] input pin)
>> 2) The DT binding to represent the connection.
>> 3) The Interrupt ID as specified by the GIC architecture reference[1]
>> (SGI:[0-15], PPI:[16-31], SPI:[32-1019], special:[1020-1023])
>> 4) The internal HWIRQ representation used by the GIC driver
>> 5) The Linux VIRQ number that #4 maps to.
>>
>> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0048b/BCGBFHCH.html
>>
>> Some thoughts:
>> - Generally the DT binding (#2) should reflect the HW view of the
>> system (#1) since that is the number most likely to be represented in
>> hardware manuals. The interrupt ID is an internal detail of the GIC,
>> and isn't really exposed in the block diagram of the hardware.
>> - Presumably it is preferable for the GIC to directly use the
>> Interrupt ID (#3) as the HWIRQ number (#4) because it is the most
>> efficient from an interrupt handling perspective, and indeed this is
>> currently what the GIC driver does.
>> - Translation between the DT binding (#2) and the Interrupt ID / HWIRQ
>> (#3/#4) is trivial, and easily managed by the GIC's irq_domain.
>> - Though not necessarily as trivial, the mapping between Linux VIRQ
>> and HWIRQ is not fixed, and when migrating to DT it should be assumed
>> to be assigned at runtime. Perhaps not so important for a core IRQ
>> controller like the GIC (as opposed to an i2c irq expander), but
>> assuming an fixed offset still should be avoided. We may still force
>> a SPI0->VIRQ32 on the root GIC as an optimization, but it is not
>> necessary and the driver still needs to support remapping for a
>> secondary GIC.
>
> The irq base is dynamic in my series, but is typically still GIC ID =
> VIRQ for a primary GIC for now. A platform can adjust this with
> irq_alloc_descs if necessary (but recommended not to of course).
>
>>
>> So, for the GIC DT binding, I'm inclined to agree with Benoit that the
>> binding should reflect the hardware connections, not the values used
>> by software for decoding IRQs. Also, I see absolutely no need to use
>> separate nodes for each GIC interrupt space. The DT interrupt
>> specifier number space can more than handle the features of the GIC in
>> a clear and concise manor. So, here's my counter proposal for a GIC
>> bindings (using Rob's text as the starting point):
>>
>> ----
>>
>> * ARM Generic Interrupt Controller
>>
>> ARM SMP cores are often associated with a GIC, providing per processor
>> interrupts (PPI), shared processor interrupts (SPI) and software
>> generated interrupts (SGI).
>>
>> Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>> Secondary GICs are cascaded into the upward interrupt controller and do not
>> have PPIs or SGIs.
>>
>> Main node required properties:
>>
>> - compatible : should be one of:
>> "arm,cortex-a9-gic"
>> "arm,arm11mp-gic"
>> - interrupt-controller : Identifies the node as an interrupt controller
>> - #interrupt-cells : Specifies the number of cells needed to encode an
>> interrupt source. The type shall be a<u32> and the value shall be 3.
>>
>> The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>> interrupts.
>> The 2nd cell contains the interrupt number for the interrupt type.
>> SPI interrupts are in the range [0-987]. PPI interrupts are in the
>> range [0-15].
>> The 3rd cell is the flags, encoded as follows:
>> bits[3:0] trigger type and level flags.
>> 1 = low-to-high edge triggered
>> 2 = high-to-low edge triggered
>> 4 = active high level-sensitive
>> 8 = active low level-sensitive
>> bits[15:8] PPI interrupt cpu mask. Each bit corresponds to
>> each of the 8 possible cpus attached to the GIC. A bit set to '1'
>> indicated the interrupt is wired to that CPU. Only valid for PPI
>> interrupts.
>>
> How about a cpu mask of 0 means SPI and non-zero means PPI? Then we can
> drop the first cell.
>
>> (Alternately, if there is no need for a CPU mask because PPI
>> interrupts will never be wired to more than one CPU, then it would be
>> better to encode the CPU number into the second cell with the SPI
>> number).
> You meant PPI number, right? ^^^
>
> The common case at least on the A9 is a PPI is routed to all cores. QC
> is different though. This was discussed previously. Basically, anything
> is possible here, so the mask is needed for sure.
>
> Overall I'm fine with this and just happy to have some conclusion. I
> will send out an updated series if there are no further comments.
I'm OK with that proposal too. That solve all the concerns I had.
Thanks for the good discussion,
Benoit
^ permalink raw reply
* [PATCH 1/3] include: fb: Add definiton for window positioning structure
From: Ajay kumar @ 2011-09-20 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920112427.GB19695@sapphire.tkos.co.il>
Hi Baruch,
On Tue, Sep 20, 2011 at 4:54 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Ajay,
>
> On Tue, Sep 20, 2011 at 11:30:39AM -0400, Ajay Kumar wrote:
>> This patch adds a data structure definiton to hold framebuffer windows/planes.
>> An ioctl number is also added to provide user access
>> to change window position dynamically.
>
> [snip]
>
>> +/* Window overlaying */
>> +struct fb_overlay_win_pos {
>> + ? ? __u32 win_pos_x; ? ? ? ?/* x-offset from LCD(0,0) where window starts */
>> + ? ? __u32 win_pos_y; ? ? ? ?/* y-offset from LCD(0,0) where window starts */
>> +};
>
> Why not allow negative offsets where the left or upper part of the framebuffer
> is hidden?
Thanks for pointing it out. Are there drivers which place the overlay
windows such that some part of the window is hidden from being
displayed on the screen?
> baruch
>
> --
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ~. .~ ? Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> ? - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
Ajay
^ permalink raw reply
* [PATCH 0/3] FB: Add window positioning support
From: Ajay Kumar @ 2011-09-20 15:30 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for positioning the overlay windows on the LCD.
These patches are based on the discussion about adding features to fbdev at:
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg06292.html
To Florian:
include: fb: Add definiton for window positioning structure
video: s3c-fb: Modify s3c-fb driver to support window positioning
To Kukjin,
ARM: SAMSUNG: Embed window positioning data structure in s3c-fb plat
data
arch/arm/plat-samsung/include/plat/fb.h | 3 ++
drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++----
include/linux/fb.h | 7 ++++++
3 files changed, 42 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH 1/3] include: fb: Add definiton for window positioning structure
From: Ajay Kumar @ 2011-09-20 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316532641-2657-1-git-send-email-ajaykumar.rs@samsung.com>
This patch adds a data structure definiton to hold framebuffer windows/planes.
An ioctl number is also added to provide user access
to change window position dynamically.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
include/linux/fb.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1d6836c..2141941 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -39,6 +39,7 @@
#define FBIOPUT_MODEINFO 0x4617
#define FBIOGET_DISPINFO 0x4618
#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)
+#define FBIOPOS_OVERLAY_WIN _IOW('F', 0x21, struct fb_overlay_win_pos)
#define FB_TYPE_PACKED_PIXELS 0 /* Packed Pixels */
#define FB_TYPE_PLANES 1 /* Non interleaved planes */
@@ -366,6 +367,12 @@ struct fb_image {
struct fb_cmap cmap; /* color map info */
};
+/* Window overlaying */
+struct fb_overlay_win_pos {
+ __u32 win_pos_x; /* x-offset from LCD(0,0) where window starts */
+ __u32 win_pos_y; /* y-offset from LCD(0,0) where window starts */
+};
+
/*
* hardware cursor control
*/
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] ARM: SAMSUNG: Embed window positioning data structure in s3c-fb plat data
From: Ajay Kumar @ 2011-09-20 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316532641-2657-1-git-send-email-ajaykumar.rs@samsung.com>
This patch adds a new field in s3c_fb_pd_win structure,
thereby allowing the user to place window at the desired position.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/plat-samsung/include/plat/fb.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
index 0fedf47..920decd 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -27,6 +27,7 @@
* @win_mode: The display parameters to initialise (not for window 0)
* @virtual_x: The virtual X size.
* @virtual_y: The virtual Y size.
+ * @winpos: Position of overlayed window w.r.t the LCD screen.
*/
struct s3c_fb_pd_win {
struct fb_videomode win_mode;
@@ -35,6 +36,8 @@ struct s3c_fb_pd_win {
unsigned short max_bpp;
unsigned short virtual_x;
unsigned short virtual_y;
+
+ struct fb_overlay_win_pos winpos;
};
/**
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] video: s3c-fb: Modify s3c-fb driver to support window positioning
From: Ajay Kumar @ 2011-09-20 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316532641-2657-1-git-send-email-ajaykumar.rs@samsung.com>
Positions the framebuffer window during driver initialization,
using the platform data.It also adds an ioctl definition
to change window position dynamically.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++++++++-----
1 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0fda252..b087a12 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -441,6 +441,7 @@ static int s3c_fb_set_par(struct fb_info *info)
{
struct fb_var_screeninfo *var = &info->var;
struct s3c_fb_win *win = info->par;
+ struct fb_overlay_win_pos *winpos = &win->windata->winpos;
struct s3c_fb *sfb = win->parent;
void __iomem *regs = sfb->regs;
void __iomem *buf = regs;
@@ -539,12 +540,13 @@ static int s3c_fb_set_par(struct fb_info *info)
/* write 'OSD' registers to control position of framebuffer */
- data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
+ data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
+ VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
writel(data, regs + VIDOSD_A(win_no, sfb->variant));
- data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
- var->xres - 1)) |
- VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
+ data = VIDOSDxB_BOTRIGHT_X((s3c_fb_align_word(var->bits_per_pixel,
+ (winpos->win_pos_x + var->xres - 1)))) |
+ VIDOSDxB_BOTRIGHT_Y((winpos->win_pos_y + var->yres - 1));
writel(data, regs + VIDOSD_B(win_no, sfb->variant));
@@ -998,9 +1000,11 @@ static int s3c_fb_ioctl(struct fb_info *info, unsigned int cmd,
unsigned long arg)
{
struct s3c_fb_win *win = info->par;
+ struct fb_overlay_win_pos *winpos = &win->windata->winpos;
struct s3c_fb *sfb = win->parent;
- int ret;
+ int ret = 0;
u32 crtc;
+ u32 data;
switch (cmd) {
case FBIO_WAITFORVSYNC:
@@ -1011,6 +1015,29 @@ static int s3c_fb_ioctl(struct fb_info *info, unsigned int cmd,
ret = s3c_fb_wait_for_vsync(sfb, crtc);
break;
+ case FBIOPOS_OVERLAY_WIN:
+ if (copy_from_user(winpos, (u32 __user *)arg,
+ sizeof(struct fb_overlay_win_pos))) {
+ ret = -EFAULT;
+ break;
+ }
+
+ shadow_protect_win(win, 1);
+
+ /* write 'OSD' registers to set position of the window */
+ data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
+ VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
+ writel(data, sfb->regs + VIDOSD_A(win->index, sfb->variant));
+
+ data = VIDOSDxB_BOTRIGHT_X(
+ s3c_fb_align_word(info->var.bits_per_pixel,
+ (winpos->win_pos_x + info->var.xres - 1)));
+ data |= VIDOSDxB_BOTRIGHT_Y(winpos->win_pos_y +
+ info->var.yres - 1);
+ writel(data, sfb->regs + VIDOSD_B(win->index, sfb->variant));
+
+ shadow_protect_win(win, 0);
+ break;
default:
ret = -ENOTTY;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 6/6] arm/imx6q: add suspend/resume support
From: Lorenzo Pieralisi @ 2011-09-20 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110917083007.GA26572@S2100-06.ap.freescale.net>
On Sat, Sep 17, 2011 at 09:30:09AM +0100, Shawn Guo wrote:
> On Fri, Sep 16, 2011 at 03:45:39PM +0100, Lorenzo Pieralisi wrote:
> > Hi Shawn,
> >
> > On Fri, Sep 16, 2011 at 07:09:00AM +0100, Shawn Guo wrote:
> > > Hi Lorenzo,
> > >
> > > On Thu, Sep 15, 2011 at 05:28:29PM +0100, Lorenzo Pieralisi wrote:
> > > > On Thu, Sep 15, 2011 at 03:45:26PM +0100, Shawn Guo wrote:
> > > > > It adds suspend/resume support for imx6q.
> > > > >
> > > > > Signed-off-by: Anson Huang <b20788@freescale.com>
> > > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > > > > ---
[...]
> One reason that I implemented pl310_resume as a function call is that
> I was trying to minimize the code that we have to put in .data section.
> Now I do not think it's a point that really matters. So following your
> suggestion, here it is. Please let me know it is not what you meant to
> see.
>
> /*
> * The following code is located into the .data section. This is to
> * allow pl310_pbase and pl310_aux_ctrl to be accessed with a relative
> * load as we are running on physical address here.
> */
> .data
> .align
>
> .macro pl310_resume
> adr r2, pl310_pbase
> ldmia r2, {r0, r1}
> str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
> mov r1, #0x1
> str r1, [r0, #L2X0_CTRL] @ re-enable L2
> .endm
>
> ENTRY(v7_cpu_resume)
> bl v7_invalidate_l1
> pl310_resume
> b cpu_resume
> ENDPROC(v7_cpu_resume)
>
> .globl
> pl310_pbase:
> .long 0
> pl310_aux_ctrl:
> .long 0
Yes, it does look simpler and better to me, but I still think there are going
to be other platforms doing the same precise thing if they run secure,
so we may want to generalize it; let's discuss it and converge.
Thanks for reworking it,
Lorenzo
^ permalink raw reply
* [PATCH 1/3] include: fb: Add definiton for window positioning structure
From: Tomi Valkeinen @ 2011-09-20 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEC9eQOTNaMcUWeSFN-DCTYrCJsVaDAO7uOZNQM=efjVdqtU2g@mail.gmail.com>
On Tue, 2011-09-20 at 20:16 +0530, Ajay kumar wrote:
> Hi Tomi,
>
> On Tue, Sep 20, 2011 at 4:40 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Tue, 2011-09-20 at 11:30 -0400, Ajay Kumar wrote:
> >> This patch adds a data structure definiton to hold framebuffer windows/planes.
> >> An ioctl number is also added to provide user access
> >> to change window position dynamically.
> >>
> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> >> Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
> >> Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >> ---
> >> include/linux/fb.h | 7 +++++++
> >> 1 files changed, 7 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/include/linux/fb.h b/include/linux/fb.h
> >> index 1d6836c..2141941 100644
> >> --- a/include/linux/fb.h
> >> +++ b/include/linux/fb.h
> >> @@ -39,6 +39,7 @@
> >> #define FBIOPUT_MODEINFO 0x4617
> >> #define FBIOGET_DISPINFO 0x4618
> >> #define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)
> >> +#define FBIOPOS_OVERLAY_WIN _IOW('F', 0x21, struct fb_overlay_win_pos)
> >>
> >> #define FB_TYPE_PACKED_PIXELS 0 /* Packed Pixels */
> >> #define FB_TYPE_PLANES 1 /* Non interleaved planes */
> >> @@ -366,6 +367,12 @@ struct fb_image {
> >> struct fb_cmap cmap; /* color map info */
> >> };
> >>
> >> +/* Window overlaying */
> >> +struct fb_overlay_win_pos {
> >> + __u32 win_pos_x; /* x-offset from LCD(0,0) where window starts */
> >> + __u32 win_pos_y; /* y-offset from LCD(0,0) where window starts */
> >> +};
> >
> > Shouldn't this also include the window size (in case scaling is
> > supported)?
>
> The "xres" and "yres" fields in fb_var_screeninfo are being used to
> represent the size of the window (visible resolution). So we have,
>
> win_pos_x: x-offset from LCD(0,0) where window starts.
> win_pos_y: y-offset from LCD(0,0) where window starts.
> (win_pos_x + xres) : x-offset from LCD(0,0) where window ends.
> (win_pos_y + yres) : y-offset from LCD(0,0) where window ends.
Sure, but the xres and yres tell the _input_ resolution, i.e. how many
pixels are read from the memory. What is missing is the _output_
resolution, which is the size of the window. These are not necessarily
the same, if the system supports scaling.
> > This also won't work for setups where the same framebuffer is used by
> > multiple overlays. For example, this is the case on OMAP when the same
> > content is cloned to, say, LCD and TV, each of which is showing an
> > overlay.
>
> These x and y position are used to configure the display controller
> (for LCD only) and not to alter the data in physical buffer
> (framebuffer). Could you elaborate the above use case you have
> mentioned and how adding the x and y offsets would not meet that
> requirement.
Nothing wrong with adding x/y offsets, but the problem is in configuring
the two overlays. If the framebuffer data is used by two overlays, each
overlay should be configured separately. And your ioctl does not have
any way to define which overlay is being affected.
Of course, if we specify that a single framebuffer will ever go only to
one output, the problem disappears.
However, even if we specify so, this will make the fbdev a bit weird:
what is x/yres after this patch? In the current fbdev x/yres is the size
of the output, and x/yres are part of video timings. After this patch
this is no longer the case: x/yres will be the size of the overlay. But
the old code will still use x/yres as part of video timings, making
things confusing.
And generally I can't really make my mind about adding these more
complex features. On one hand it would be very nice to have fbdev
supporting overlays and whatnot, but on the other hand, I can't figure
out how to add them properly.
Tomi
^ permalink raw reply
* [PATCH v2 0/3] ARM: imx: Add cpuidle for imx platforms
From: Rob Lee @ 2011-09-20 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920071633.GR31404@pengutronix.de>
Hello Sascha,
On 20 September 2011 02:16, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Hi Robert,
>
> On Fri, Sep 16, 2011 at 12:27:47PM -0500, Robert Lee wrote:
>> This patch series adds a common imx cpuidle driver, some common
>> mach-mx5 level cpuidle functionality, and an i.MX51 instance of
>> using this driver.
>>
>> The patch series is based on v3.1-rc2.
>>
>> Changes since v1:
>> * To address all the problems found during review of v1, a complete
>> re-write was needed.
>
> Much better than the last version, thanks.
>
Thanks to Shawn Guo for thoroughly reviewing and providing
feedback on this version and Jason Hui contributed to the reviewing
as well despite both of them being very busy with there own
submissions.
>>
>> Robert Lee (3):
>> ? ARM: imx: Add imx cpuidle driver
>> ? ARM: imx: Add cpuidle for mach-mx5
>> ? ARM: imx: Add cpuidle for i.MX51
>>
>> ?arch/arm/mach-mx5/Makefile ? ? ? ? ? ? ? | ? ?3 +-
>> ?arch/arm/mach-mx5/cpu_op-mx51.c ? ? ? ? ?| ? 35 +++++++-
>
> Your additions to this file...
>
>> ?arch/arm/mach-mx5/cpu_op-mx51.h ? ? ? ? ?| ? ?1 +
>> ?arch/arm/mach-mx5/mm.c ? ? ? ? ? ? ? ? ? | ? ?4 +
>> ?arch/arm/mach-mx5/system.c ? ? ? ? ? ? ? | ? 35 +++++++
>
> And this one should go to arch/arm/mach-mx5/cpuidle.c, then we have
> all i.MX5 specific cpuidle stuff together without ifdeffing the code.
> I assume that cpuidle support for i.MX53 will look identically, right?
>
After considering it further after the first patch, there can be differences
between the i.MX51 and i.MX53 state data as i.MX51 supports an
additional idle state that i.MX53 does not. This state was not added
to this version of the patch because it's additional power savings is very
small and there is fairly time consuming characterization needed to
come up with accurate cpuidle state data. But to allow for the
possibility that this state could be added in the future, it seemed the
choice was to add this init data to the an i.MX51 specific file such as
cpu_op-mx51.c/h and add ifdefs for cpuidle and cpufreq. Or, make
a cpuidle.c file as you suggest and add ifdefs for the different mx5
SoCs. Just let me know which way you think is better given this
information.
For the call to imx_cpuidle_init from imx51_soc_init in mm.c, this
seems like a good location to initialize for all imx51_soc. If I don't
call the init from here, can you recommend another location that I
should call it from?
>> ?arch/arm/plat-mxc/Makefile ? ? ? ? ? ? ? | ? ?1 +
>> ?arch/arm/plat-mxc/cpuidle.c ? ? ? ? ? ? ?| ?151 ++++++++++++++++++++++++++++++
>> ?arch/arm/plat-mxc/include/mach/cpuidle.h | ? 56 +++++++++++
>> ?arch/arm/plat-mxc/include/mach/system.h ?| ? ?3 +
>> ?9 files changed, 286 insertions(+), 3 deletions(-)
>> ?create mode 100644 arch/arm/plat-mxc/cpuidle.c
>> ?create mode 100644 arch/arm/plat-mxc/include/mach/cpuidle.h
>>
>>
>
> Sascha
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 ? ?|
> Amtsgericht Hildesheim, HRA 2686 ? ? ? ? ? | Fax: ? +49-5121-206917-5555 |
>
^ permalink raw reply
* [PATCH v2 0/3] ARM: imx: Add cpuidle for imx platforms
From: Rob Lee @ 2011-09-20 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920080320.GA2528@matterhorn1>
Hello Amit,
On 20 September 2011 03:03, Amit Kucheria <amit.kucheria@linaro.org> wrote:
> On 11 Sep 20, Sascha Hauer wrote:
>> Hi Robert,
>>
>> On Fri, Sep 16, 2011 at 12:27:47PM -0500, Robert Lee wrote:
>> > This patch series adds a common imx cpuidle driver, some common
>> > mach-mx5 level cpuidle functionality, and an i.MX51 instance of
>> > using this driver.
>> >
>> > The patch series is based on v3.1-rc2.
>> >
>> > Changes since v1:
>> > * To address all the problems found during review of v1, a complete
>> > re-write was needed.
>>
>> Much better than the last version, thanks.
>>
>> >
>> > Robert Lee (3):
>> > ? ARM: imx: Add imx cpuidle driver
>> > ? ARM: imx: Add cpuidle for mach-mx5
>> > ? ARM: imx: Add cpuidle for i.MX51
>> >
>> > ?arch/arm/mach-mx5/Makefile ? ? ? ? ? ? ? | ? ?3 +-
>> > ?arch/arm/mach-mx5/cpu_op-mx51.c ? ? ? ? ?| ? 35 +++++++-
>>
>> Your additions to this file...
>>
>> > ?arch/arm/mach-mx5/cpu_op-mx51.h ? ? ? ? ?| ? ?1 +
>> > ?arch/arm/mach-mx5/mm.c ? ? ? ? ? ? ? ? ? | ? ?4 +
>> > ?arch/arm/mach-mx5/system.c ? ? ? ? ? ? ? | ? 35 +++++++
>>
>> And this one should go to arch/arm/mach-mx5/cpuidle.c, then we have
>> all i.MX5 specific cpuidle stuff together without ifdeffing the code.
>> I assume that cpuidle support for i.MX53 will look identically, right?
>
> Yes, let's not separate only for i.MX51. i.MX53 and even i.MX6 might look
> similar. They can always tune the exit latency criteria if needed.
>
i.MX6 will have significantly different exit_latency values and may need
to have target residency values as well. Also, i.MX6 may have a
different number of states, so I think it is best to have separate sets of
SoC state data as needed instead of trying to make one set of state data
to be used by all i.MX6.
>
>
^ permalink raw reply
* DT vs ARM static mappings
From: Pawel Moll @ 2011-09-20 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E78A546.9040604@gmail.com>
On Tue, 2011-09-20 at 15:37 +0100, Rob Herring wrote
> > My point is that we should be able to handle _all_ of them using one
> > DT_MACHINE_START with a single compat value "arm,vexpress". The only
> > problem with this (so far) is the mapping.
>
> Yes, you should have 1 DT_MACHINE_START, but arm,vexpress is too
> generic. You can and should have a list of compatible strings for each
> board/machine.
Our DTS has:
compatible = "arm,vexpress-v2p-ca9", "arm,vexpress";
and v2m.c:
static const char *v2m_dt_match[] __initconst = {
"arm,vexpress",
NULL,
};
DT_MACHINE_START(VEXPRESS_DT, "ARM Versatile Express")
.map_io = v2m_map_io,
.init_early = v2m_init_early,
.init_irq = v2m_init_irq,
.timer = &v2m_timer,
.init_machine = v2m_dt_init,
.dt_compat = v2m_dt_match,
MACHINE_END
Isn't it what you meant?
Essentially I see two ways of doing what we are discussing:
1. Two DT_MACHINE_START, one matching "arm,vexpress-legacy" with map_io
= v2m_map_io_legacy and second matching "arm,vexpress-rs1" with map_io =
v2m_map_io_rs1,
2. Single DT_MACHINE_START matching (the most generic) "arm,vexpress"
and doing (rougly) this in v2m_map_io:
of_scan_flat_dt(v2m_dt_iotable_init, NULL);
v2m_dt_iotable_init(...)
{
if (depth != 0)
return 0;
if (of_flat_dt_is_compatible(node, "arm,vexpress-legacy"))
iotable_init(v2m_io_desc_legacy);
else (of_flat_dt_is_compatible(node, "arm,vexpress-rs1"))
iotable_init(v2m_io_desc_rs1);
else
panic();
}
Neither of them seem particularly appealing... ;-)
> >> In "chosen" like the kernel command line would be the place, but I don't
> >> think that is the right approach. Chosen is really for things that
> >> change frequently and this doesn't really fall in that category.
> >
> > Again, no argument from me here :-)
> >
> > The question is - where should it be?
>
> Nowhere. It's an OS specific issue, not a h/w issue.
That's exactly why I didn't like this idea in the first place. This
doesn't change the fact that current infrastructure isn't really helpful
here.
> So create a mapping per peripheral rather than per chip select. Then the
> virtual address can always be the same.
As I said (see below) this is exactly what I wanted to do, but I was
defeated by the reality :-)
On Tue, 2011-09-20 at 12:51 +0100, Pawel Moll wrote:
> > > Initially I wanted to find the mentioned devices and create individual
> > > mappings for them, so the MMIO_P2V would be still valid (if slightly
> > > "abused"), but I failed due to the problems mentioned above. And I can't
> > > delay this operation till the tree is un-flattened, as the core tile
> > > must be probed (via sysreg) in map_io (tile's specific code must be able
> > > to create its own mappings):
> >> Generally, the trend is to get rid of static mappings as much as
> >> possible. Doing that first might simplify things.
> >
> > You can't do ioremap() before kmalloc() is up and running (correct me if
> > I am wrong), at least you can't do this in map_io. So the static mapping
> > is a must sometimes. And actually, with the latest Nico's changes:
> >
> Correct. You can't do ioremap until init_irq. map_io and init_early are
> too early. My point was if you can delay h/w access then you can remove
> the static mappings. But yes, we generally can't remove them all. SCU
> and LL debug uart are 2 examples.
In my case it's sysreg and sysctl. There are two more users of static
mappings: timer01 and timer23, but they could at some point do ioremap()
on their own (especially with Nico's changes).
> For the short term, I would just have 2 static iotables and select the
> right one based on the board's (or motherboard's) compatible string.
Yes, as mentioned above. This doesn't help with the sysreg offset
problem though. I may just scan the flat tree looking for their
particular names and getting raw offset from their regs... Sounds like a
hack, though.
> Long term, we should look into implementing a common early DT address
> parsing function.
Well, assuming that we want to have them at all. I'm not convinced,
frankly ;-)
Pawe?
^ permalink raw reply
* [PATCH REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
From: Stephen Warren @ 2011-09-20 16:46 UTC (permalink / raw)
To: linux-arm-kernel
The bindings were recently updated to have separate properties for each
type of GPIO. Update the Device Tree source to match that.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Olof Johansson <olof@lixom.net>
---
I'd previously sent these to Grant assuming they'd go in his dt/next branch,
but perhaps these should go in through Arnd's arm-soc next/dt branch?
arch/arm/boot/dts/tegra-harmony.dts | 12 ++++++------
arch/arm/boot/dts/tegra-seaboard.dts | 6 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/tegra-harmony.dts b/arch/arm/boot/dts/tegra-harmony.dts
index 4c05334..e581866 100644
--- a/arch/arm/boot/dts/tegra-harmony.dts
+++ b/arch/arm/boot/dts/tegra-harmony.dts
@@ -57,14 +57,14 @@
};
sdhci at c8000200 {
- gpios = <&gpio 69 0>, /* cd, gpio PI5 */
- <&gpio 57 0>, /* wp, gpio PH1 */
- <&gpio 155 0>; /* power, gpio PT3 */
+ cd-gpios = <&gpio 69 0>; /* gpio PI5 */
+ wp-gpios = <&gpio 57 0>; /* gpio PH1 */
+ power-gpios = <&gpio 155 0>; /* gpio PT3 */
};
sdhci at c8000600 {
- gpios = <&gpio 58 0>, /* cd, gpio PH2 */
- <&gpio 59 0>, /* wp, gpio PH3 */
- <&gpio 70 0>; /* power, gpio PI6 */
+ cd-gpios = <&gpio 58 0>; /* gpio PH2 */
+ wp-gpios = <&gpio 59 0>; /* gpio PH3 */
+ power-gpios = <&gpio 70 0>; /* gpio PI6 */
};
};
diff --git a/arch/arm/boot/dts/tegra-seaboard.dts b/arch/arm/boot/dts/tegra-seaboard.dts
index 1940cae..64cedca 100644
--- a/arch/arm/boot/dts/tegra-seaboard.dts
+++ b/arch/arm/boot/dts/tegra-seaboard.dts
@@ -21,8 +21,8 @@
};
sdhci at c8000400 {
- gpios = <&gpio 69 0>, /* cd, gpio PI5 */
- <&gpio 57 0>, /* wp, gpio PH1 */
- <&gpio 70 0>; /* power, gpio PI6 */
+ cd-gpios = <&gpio 69 0>; /* gpio PI5 */
+ wp-gpios = <&gpio 57 0>; /* gpio PH1 */
+ power-gpios = <&gpio 70 0>; /* gpio PI6 */
};
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH REPOST 2/2] arm/dt: Tegra: Add support-8bit to SDHCI nodes
From: Stephen Warren @ 2011-09-20 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316537186-26753-1-git-send-email-swarren@nvidia.com>
For Seaboard's internal eMMC, this makes the difference between a
5.5MB/s and 10.2MB/s transfer rate. On Harmony, there wasn't any
measurable difference on my cheap/slow ~2MB/s card.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
arch/arm/boot/dts/tegra-harmony.dts | 1 +
arch/arm/boot/dts/tegra-seaboard.dts | 4 ++++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra-harmony.dts b/arch/arm/boot/dts/tegra-harmony.dts
index e581866..0e225b8 100644
--- a/arch/arm/boot/dts/tegra-harmony.dts
+++ b/arch/arm/boot/dts/tegra-harmony.dts
@@ -66,5 +66,6 @@
cd-gpios = <&gpio 58 0>; /* gpio PH2 */
wp-gpios = <&gpio 59 0>; /* gpio PH3 */
power-gpios = <&gpio 70 0>; /* gpio PI6 */
+ support-8bit;
};
};
diff --git a/arch/arm/boot/dts/tegra-seaboard.dts b/arch/arm/boot/dts/tegra-seaboard.dts
index 64cedca..a72299b 100644
--- a/arch/arm/boot/dts/tegra-seaboard.dts
+++ b/arch/arm/boot/dts/tegra-seaboard.dts
@@ -25,4 +25,8 @@
wp-gpios = <&gpio 57 0>; /* gpio PH1 */
power-gpios = <&gpio 70 0>; /* gpio PI6 */
};
+
+ sdhci at c8000600 {
+ support-8bit;
+ };
};
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox