Re: [PATCH 1/5] ARM: omap2: cm-t35: Add regulators and clock for camera sensor
Hi Laurent,
On 02/18/14 14:47, Laurent Pinchart wrote:
Mauro, Tony,
On Monday 10 February 2014 22:54:40 Laurent Pinchart wrote:
The camera sensor will soon require regulators and clocks. Register
fixed regulators for its VAA and VDD power supplies and a fixed rate
clock for its master clock.
This patch is a prerequisite for a set of 4 patches that need to go through
the linux-media tree. It would simpler if it could go through the same tree
as
well. Given that arch/arm/mach-omap2/board-cm-t35.c has seen very little
activity recently I believe the risk of conflict is pretty low.
Indeed, as we work on DT stuff of cm-t35/3730 and pretty much stopped
updating the board-cm-t35.c file.
Tony, would
that be fine with you ?
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c index 8dd0ec8..018353d 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -16,6 +16,8 @@
*
*/
+#include linux/clk-provider.h
+#include linux/clkdev.h
#include linux/kernel.h
#include linux/init.h
#include linux/platform_device.h
@@ -542,8 +544,22 @@ static struct isp_platform_data cm_t35_isp_pdata = {
.subdevs = cm_t35_isp_subdevs,
};
+static struct regulator_consumer_supply cm_t35_camera_supplies[] = {
+REGULATOR_SUPPLY(vaa, 3-005d),
+REGULATOR_SUPPLY(vdd, 3-005d),
+};
+
static void __init cm_t35_init_camera(void)
{
+struct clk *clk;
+
+clk = clk_register_fixed_rate(NULL, mt9t001-clkin, NULL, CLK_IS_ROOT,
+ 4800);
+clk_register_clkdev(clk, NULL, 3-005d);
+
+regulator_register_fixed(2, cm_t35_camera_supplies,
+ ARRAY_SIZE(cm_t35_camera_supplies));
+
if (omap3_init_camera(cm_t35_isp_pdata) 0)
pr_warn(CM-T3x: Failed registering camera device!\n);
}
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: mach-omap2: board-rx51-peripherals: Add lirc-rx51 data
Hi Timo,
On 08/09/12 15:41, Timo Kokkonen wrote:
The IR diode on the RX51 is connected to the GPT9. This data is needed
for the IR driver to function.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 30
++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index df2534d..4a5a71b 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -34,6 +34,7 @@
#include plat/gpmc.h
#include plat/onenand.h
#include plat/gpmc-smc91x.h
+#include plat/omap-pm.h
#include mach/board-rx51.h
@@ -46,6 +47,10 @@
#include ../drivers/staging/iio/light/tsl2563.h
#include linux/lis3lv02d.h
+#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
+#include ../../../drivers/media/rc/ir-rx51.h
+#endif
That is not really nice...
You should place the struct lirc_rx51_platform_data and
other stuff used outside of the driver in: include/media/
so you will not have to add that long and ugly relative path.
+
#include mux.h
#include hsmmc.h
#include common-board-devices.h
@@ -1220,6 +1225,30 @@ static void __init rx51_init_tsc2005(void)
gpio_to_irq(RX51_TSC2005_IRQ_GPIO);
}
+#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
+static struct lirc_rx51_platform_data rx51_lirc_data = {
+ .set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
+ .pwm_timer = 9, /* Use GPT 9 for CIR */
+};
+
+static struct platform_device rx51_lirc_device = {
+ .name = lirc_rx51,
+ .id = -1,
+ .dev= {
+ .platform_data = rx51_lirc_data,
+ },
+};
+
+static void __init rx51_init_lirc(void)
+{
+ platform_device_register(rx51_lirc_device);
+}
+#else
+static void __init rx51_init_lirc(void)
+{
+}
+#endif
+
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
@@ -1230,6 +1259,7 @@ void __init rx51_peripherals_init(void)
rx51_init_wl1251();
rx51_init_tsc2005();
rx51_init_si4713();
+ rx51_init_lirc();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: rc: Introduce RX51 IR transmitter driver
On 08/09/12 15:41, Timo Kokkonen wrote:
This is the driver for the IR transmitter diode found on the Nokia
N900 (also known as RX51) device. The driver is mostly the same as
found in the original 2.6.28 based kernel that comes with the device.
The following modifications have been made compared to the original
driver version:
- Adopt to the changes that has happen in the kernel during the past
five years, such as the change in the include paths
- The OMAP DM-timers require much more care nowadays. The timers need
to be enabled and disabled or otherwise many actions fail. Timers
must not be freed without first stopping them or otherwise the timer
cannot be requested again.
The code has been tested with sending IR codes with N900 device
running Debian userland. The device receiving the codes was Anysee
DVB-C USB receiver.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/Kconfig | 10 +
drivers/media/rc/Makefile |1 +
drivers/media/rc/ir-rx51.c | 496
drivers/media/rc/ir-rx51.h | 10 +
I think the file ir-rx51.h should be placed in include/media instead.
[...]
4 files changed, 517 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/rc/ir-rx51.c
create mode 100644 drivers/media/rc/ir-rx51.h
[...]
diff --git a/drivers/media/rc/ir-rx51.h b/drivers/media/rc/ir-rx51.h
new file mode 100644
index 000..104aa89
--- /dev/null
+++ b/drivers/media/rc/ir-rx51.h
@@ -0,0 +1,10 @@
+#ifndef _LIRC_RX51_H
+#define _LIRC_RX51_H
+
+struct lirc_rx51_platform_data {
+ int pwm_timer;
+
+ int(*set_max_mpu_wakeup_lat)(struct device *dev, long t);
+};
+
+#endif
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2012-discuss] Device-tree cross-subsystem binding workshop [was Media system Summit]
On 07/13/12 04:20, Olof Johansson wrote: On Thu, Jul 12, 2012 at 12:03 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Thu July 12 2012 18:48:23 Olof Johansson wrote: On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: I'd like to add a Common device tree bindings for media devices topic to the agenda for consideration. It'd be nice to get this to join up with ASoC... There's a handful of various subsystems that have similar topics, maybe slice it the other way and do a device-tree/ACPI breakout that cuts across the various areas instead? Communication really needs to be two-way: Crafting good bindings for a complex piece of hardware isn't trivial and having someone know both the subsystem and device tree principles is rare. At least getting all those people into the same room would be good. I'm not so sure: I think that most decisions that need to be made are quite subsystem specific. Trying to figure out how to implement DT for multiple subsystems in one workshop seems unlikely to succeed, simply because of lack of time. I also don't think there is much overlap between subsystems in this respect, so while the DT implementation for one subsystem is discussed, the representatives of other subsystems are twiddling their thumbs. It might be more productive to have one or two DT experts around who rotate over the various workshops that have to deal with the DT and can offer advice. One of the real problems right now is the lack of DT reviewers and general reviewer fatigue. In particular, many of the proposed bindings tend to have the same issues (focusing too much on how the platform_data is structured today and not on what the hardware actually is), and a few other similar things. Based on that I don't think it's a better solution to have the same few people walk from room to room to cover the same thing multiple times. No one has to sit there the whole day and listen on it all, but for those who are genuinely interested in how other subsystems will handle these bindings, I think it would be very useful to learn from how they made their decisions. Don't work in a vacuum, etc. So, I'd like to formally propose this as a mini-summit or workshop or whatever you might want to call it. I can help organize it together with Rob and Grant if needed (especially since Grant has a lot of other things going on at the moment). If there's insufficent interest to do this as a separate event we can try to accomodate for it as part of the ARM mini-summit, but squeezing all of that in with the rest of the ARM activities in one day will be hard. +1 -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] arm: omap3evm: Add support for an MT9M032 based camera board.
On 12/14/11 20:14, mar...@neutronstar.dyndns.org wrote:
On Wed, Dec 14, 2011 at 11:31:35AM +0200, Igor Grinberg wrote:
Hi Martin,
On 12/14/11 03:25, Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-omap3evm-camera.c | 155
+++
arch/arm/mach-omap2/board-omap3evm.c|4 +
3 files changed, 161 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Changes in V3
* Added missing copyright and attribution.
* switched to gpio_request_array for gpio init.
* removed device_initcall and added call to omap3_evm_camera_init into
omap3_evm_init
Changes in V2:
* ported to current mainline
* Style fixes
* Fix error handling
[...]
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM board
+ * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
I don't really care about that, but I don't see any mux
being set in the above function so the name and comments
are misleading.
There's are video muxes on this board that's controlled by various
gpios. It's not a mux in the omap chip if you've expected to see that.
As this is an evaluation board it has a bunch of video connectors that
the user can choose from for different input devices.
I see... Probably a comment explaining that would not hurt here.
[...]
+
+ omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
+ ret = gpio_request_array(setup_gpios, ARRAY_SIZE(setup_gpios));
+ if (ret 0) {
+ pr_err(omap3evm-camera: Failed to setup camera signal
routing.\n);
+ return ret;
+ }
It looks like both above calls (gpio_request and mux_init)
can be moved to omap3evm_set_mux() function (or a renamed version of it),
so all the GPIO stuff will be close to each other instead of requesting
in one place and playing with values in another...
I'd like to keep the one time setup and the theoretically run time switchable
parts seperate. It doesn't complicate the code and if a brave soul wants to
connect different camera modules and switch between them it's a more
reviewable
patch from here.
Ok
+ omap3evm_set_mux(MUX_CAMERA_SENSOR);
So the plan is to add support for the 3 types,
but hard code to only one?
Can't this be runtime detected somehow?
The mux code came from out of tree drivers. I did want to keep enough
information so someone extending this board code for other setups doesn't
have a
hard time. I can't think of an reliable way to runtime detect what video
source
a specific use case would want. Ideally someone who needs one of the other
video sources should add a more generic solution here.
I'm Ok with it, but usually, stuff that is never used stays out...
I think the way it should be is to have a platform driver that uses
a callback to switch between the muxes on the extension.
[...]
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] arm: omap3evm: Add support for an MT9M032 based camera board.
Hi Martin,
On 12/14/11 03:25, Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-omap3evm-camera.c | 155
+++
arch/arm/mach-omap2/board-omap3evm.c|4 +
3 files changed, 161 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Changes in V3
* Added missing copyright and attribution.
* switched to gpio_request_array for gpio init.
* removed device_initcall and added call to omap3_evm_camera_init into
omap3_evm_init
Changes in V2:
* ported to current mainline
* Style fixes
* Fix error handling
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b009f17..6045789 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -196,7 +196,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) +=
board-omap3logic.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o
obj-$(CONFIG_MACH_ENCORE)+= board-omap3encore.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o
-obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o
+obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
+board-omap3evm-camera.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o
obj-$(CONFIG_MACH_NOKIA_N8X0)+= board-n8x0.o
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 000..bffd5b8
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,155 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Authors:
+ *Vaibhav Hiremath hvaib...@ti.com
+ *Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * Board intregration for a MT9M032 camera connected to IMAGE_CONN and I2C
Bus 2
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include linux/gpio.h
+#include plat/mux.h
+#include mux.h
+
+#include ../../../drivers/media/video/omap3isp/isp.h
Laurent,
In one of the previous reviews, you stated:
I'll probably split it and move the part required by board files to
include/media/omap3isp.h.
Is there any progress on that?
+#include media/mt9m032.h
+
+#include devices.h
+
+#define EVM_TWL_GPIO_BASE OMAP_MAX_GPIO_LINES
+#define GPIO98_VID_DEC_RES 98
+#define nCAM_VD_SEL 157
+
+#define MT9M032_I2C_BUS_NUM 2
+
+
+enum omap3evmdc_mux {
+ MUX_TVP5146,
+ MUX_CAMERA_SENSOR,
+ MUX_EXP_CAMERA_SENSOR,
+};
+
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM board
+ * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
I don't really care about that, but I don't see any mux
being set in the above function so the name and comments
are misleading.
+
+static struct mt9m032_platform_data mt9m032_platform_data = {
+ .ext_clock = 1350,
+ .pll_pre_div = 6,
+ .pll_mul = 120,
+ .pll_out_div = 5,
+
Re: [PATCH v2 2/2] OMAP3BEAGLE: Add support for mt9p031 sensor driver.
On 05/23/11 10:47, Laurent Pinchart wrote:
Hi Javier,
On Monday 23 May 2011 09:25:01 javier Martin wrote:
On 22 May 2011 15:49, Igor Grinberg grinb...@compulab.co.il wrote:
[snip]
@@ -309,6 +357,15 @@ static int beagle_twl_gpio_setup(struct device
*dev, pr_err(%s: unable to configure EHCI_nOC\n, __func__); }
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+ * Power on camera interface - only on pre-production, not
+ * needed on production boards
+ */
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
Why not gpio_request_one()?
Just to follow the same approach as in the rest of the code.
Maybe a further patch could change all gpio_request() uses to
gpio_request_one().
Please do it the other way around. Replace calls to gpio_request() +
gpio_direction_output() with a call to gpio_request_one(), and then modify
this patch to use gpio_request_one().
Well, this is done already, you need to follow Tony's linux-next branch...
So, just changing this patch would do...
Also, good practice is to base patches on maintainer's appropriate branch,
so it would be easier to apply.
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] OMAP3BEAGLE: Add support for mt9p031 sensor driver.
Hi Javier,
linux-omap should be CC'ed - added.
In addition to Koen's comments, some comments below.
On 05/20/11 16:47, Javier Martin wrote:
isp.h file has to be included as a temporal measure
since clocks of the isp are not exposed yet.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 127
++-
1 files changed, 123 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..f52e6ae 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,15 +24,20 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/i2c.h
+#include linux/mm.h
+#include linux/videodev2.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/mmc/host.h
-
+#include linux/gpio.h
Why include this for second time?
#include linux/regulator/machine.h
#include linux/i2c/twl.h
+#include media/mt9p031.h
+
#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -47,12 +52,17 @@
#include plat/nand.h
#include plat/usb.h
#include plat/omap_device.h
+#include plat/i2c.h
#include mux.h
#include hsmmc.h
#include timer-gp.h
#include pm.h
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
#define NAND_BLOCK_SIZE SZ_128K
/*
@@ -273,6 +283,44 @@ static struct regulator_consumer_supply
beagle_vsim_supply = {
static struct gpio_led gpio_leds[];
+static struct regulator_consumer_supply beagle_vaux3_supply = {
+ .supply = cam_1v8,
+};
+
+static struct regulator_consumer_supply beagle_vaux4_supply = {
+ .supply = cam_2v8,
+};
+
+/* VAUX3 for CAM_1V8 */
+static struct regulator_init_data beagle_vaux3 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux3_supply,
+};
+
+/* VAUX4 for CAM_2V8 */
+static struct regulator_init_data beagle_vaux4 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux4_supply,
+};
+
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -309,6 +357,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+ * Power on camera interface - only on pre-production, not
+ * needed on production boards
+ */
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
Why not gpio_request_one()?
+ }
+
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
@@ -451,6 +508,8 @@ static struct twl4030_platform_data beagle_twldata = {
.vsim = beagle_vsim,
.vdac = beagle_vdac,
.vpll2 = beagle_vpll2,
+ .vaux3 = beagle_vaux3,
+ .vaux4 = beagle_vaux4,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
@@ -463,15 +522,16 @@ static struct i2c_board_info __initdata
beagle_i2c_boardinfo[] = {
};
static struct i2c_board_info __initdata beagle_i2c_eeprom[] = {
- {
- I2C_BOARD_INFO(eeprom, 0x50),
- },
+ {
+ I2C_BOARD_INFO(eeprom, 0x50),
+ },
};
This part of the hunk is not related to the patch
and should be in a separate (cleanup) patch.
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
+ omap_register_i2c_bus(2, 100, NULL, 0); /* Enable I2C2 for camera */
/* Bus 3 is attached to the DVI port where devices like the
