[RFC] mx31moboard: patches for next merge window

[RFC] mx31moboard: patches for next merge window

[Valentin Longchamp]

Here are the patches I would like to push during the next merge window for
the mx31moboard platform.

It consists of a fix for a small hardware design issue for the main serial
port, a few GPIOs used on the robots that are declared, camera support and
finally MC13783 support as it is now getting ready.

For MC13783, we would need RTC as well, but I did not add it yet since it
is not in mainline yet.

The camera part still is initial: it works well with a single camera but I
still have to figure out what is the best way to handle the two mt9t031 we
have on the marxbot.

The main peripheral that we are using and that still is missing is the USB
host, but since the driver still needs a few improvements, I keep it aside
for now.

Please review and comment.

Val

[PATCH 1/6] mx31: various pins used for mx31moboard

[Valentin Longchamp]

Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
---
 arch/arm/plat-mxc/include/mach/iomux-mx3.h |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-mxc/include/mach/iomux-mx3.h b/arch/arm/plat-mxc/include/mach/iomux-mx3.h
index 446f867..0dcfb77 100644
--- a/arch/arm/plat-mxc/include/mach/iomux-mx3.h
+++ b/arch/arm/plat-mxc/include/mach/iomux-mx3.h
@@ -623,6 +623,8 @@ enum iomux_pins {
 #define MX31_PIN_GPIO3_0__GPIO3_0	IOMUX_MODE(MX31_PIN_GPIO3_0, IOMUX_CONFIG_GPIO)
 #define MX31_PIN_GPIO3_1__GPIO3_1	IOMUX_MODE(MX31_PIN_GPIO3_1, IOMUX_CONFIG_GPIO)
 #define MX31_PIN_TXD2__GPIO1_28		IOMUX_MODE(MX31_PIN_TXD2, IOMUX_CONFIG_GPIO)
+#define MX31_PIN_CSI_D4__GPIO3_4	IOMUX_MODE(MX31_PIN_CSI_D4, IOMUX_CONFIG_GPIO)
+#define MX31_PIN_CSI_D5__GPIO3_5	IOMUX_MODE(MX31_PIN_CSI_D5, IOMUX_CONFIG_GPIO)
 #define MX31_PIN_USBOTG_DATA0__USBOTG_DATA0    IOMUX_MODE(MX31_PIN_USBOTG_DATA0, IOMUX_CONFIG_FUNC)
 #define MX31_PIN_USBOTG_DATA1__USBOTG_DATA1    IOMUX_MODE(MX31_PIN_USBOTG_DATA1, IOMUX_CONFIG_FUNC)
 #define MX31_PIN_USBOTG_DATA2__USBOTG_DATA2    IOMUX_MODE(MX31_PIN_USBOTG_DATA2, IOMUX_CONFIG_FUNC)
@@ -693,7 +695,11 @@ enum iomux_pins {
 #define MX31_PIN_DCD_DCE1__GPIO2_11	IOMUX_MODE(MX31_PIN_DCD_DCE1, IOMUX_CONFIG_GPIO)
 #define MX31_PIN_STXD5__GPIO1_21       IOMUX_MODE(MX31_PIN_STXD5, IOMUX_CONFIG_GPIO)
 #define MX31_PIN_SRXD5__GPIO1_22       IOMUX_MODE(MX31_PIN_SRXD5, IOMUX_CONFIG_GPIO)
-
+#define MX31_PIN_GPIO1_3__GPIO1_3	IOMUX_MODE(MX31_PIN_GPIO1_3, IOMUX_CONFIG_GPIO)
+#define MX31_PIN_CSPI2_SS1__CSPI3_SS1	IOMUX_MODE(MX31_PIN_CSPI2_SS1, IOMUX_CONFIG_ALT1)
+#define MX31_PIN_RTS1__GPIO2_6		IOMUX_MODE(MX31_PIN_RTS1, IOMUX_CONFIG_GPIO)
+#define MX31_PIN_CTS1__GPIO2_7		IOMUX_MODE(MX31_PIN_CTS1, IOMUX_CONFIG_GPIO)
+#define MX31_PIN_LCS0__GPIO3_23		IOMUX_MODE(MX31_PIN_LCS0, IOMUX_CONFIG_GPIO)
 
 /*XXX: The SS0, SS1, SS2, SS3 lines of spi3 are multiplexed by cspi2_ss0, cspi2_ss1, cspi1_ss0
  * cspi1_ss1*/
-- 
1.6.0.4

[PATCH 2/6] mx31moboard: serial port fix

[Valentin Longchamp]

We get rid of CTS/RTS lines on uart0 on our platform.
This is the port we use as mail kernel console. We do not
want it to be blocking because of CTS/RTS signals, not allowing
the system to boot or print messages.

Hower we often use it with a bluetooth module needing CTS/RTS
lines as backup login in case of trouble. To be able to use it,
we assert CTS low so that the module can always send chars.

Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
---
 arch/arm/mach-mx3/mx31moboard.c |   20 ++++++++++++++++----
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-mx3/mx31moboard.c b/arch/arm/mach-mx3/mx31moboard.c
index 9243de5..ff74fab 100644
--- a/arch/arm/mach-mx3/mx31moboard.c
+++ b/arch/arm/mach-mx3/mx31moboard.c
@@ -45,8 +45,8 @@
 
 static unsigned int moboard_pins[] = {
 	/* UART0 */
-	MX31_PIN_CTS1__CTS1, MX31_PIN_RTS1__RTS1,
 	MX31_PIN_TXD1__TXD1, MX31_PIN_RXD1__RXD1,
+	MX31_PIN_CTS1__GPIO2_7,
 	/* UART4 */
 	MX31_PIN_PC_RST__CTS5, MX31_PIN_PC_VS2__RTS5,
 	MX31_PIN_PC_BVD2__TXD5, MX31_PIN_PC_BVD1__RXD5,
@@ -101,7 +101,18 @@ static struct platform_device mx31moboard_flash = {
 	.num_resources = 1,
 };
 
-static struct imxuart_platform_data uart_pdata = {
+static int moboard_uart0_init(struct platform_device *pdev)
+{
+	gpio_request(IOMUX_TO_GPIO(MX31_PIN_CTS1), "uart0-cts-hack");
+	gpio_direction_output(IOMUX_TO_GPIO(MX31_PIN_CTS1), 0);
+	return 0;
+}
+
+static struct imxuart_platform_data uart0_pdata = {
+	.init = moboard_uart0_init,
+};
+
+static struct imxuart_platform_data uart4_pdata = {
 	.flags = IMXUART_HAVE_RTSCTS,
 };
 
@@ -284,8 +295,9 @@ static void __init mxc_board_init(void)
 
 	platform_add_devices(devices, ARRAY_SIZE(devices));
 
-	mxc_register_device(&mxc_uart_device0, &uart_pdata);
-	mxc_register_device(&mxc_uart_device4, &uart_pdata);
+	mxc_register_device(&mxc_uart_device0, &uart0_pdata);
+
+	mxc_register_device(&mxc_uart_device4, &uart4_pdata);
 
 	mx31moboard_init_sel_gpios();
 
-- 
1.6.0.4

[PATCH 3/6] mx31moboard: support for pin linked for battery presence check

[Valentin Longchamp]

Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
---
 arch/arm/mach-mx3/mx31moboard-marxbot.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mx3/mx31moboard-marxbot.c b/arch/arm/mach-mx3/mx31moboard-marxbot.c
index 2bfaffb..49d47ab 100644
--- a/arch/arm/mach-mx3/mx31moboard-marxbot.c
+++ b/arch/arm/mach-mx3/mx31moboard-marxbot.c
@@ -49,6 +49,8 @@ static unsigned int marxbot_pins[] = {
 	MX31_PIN_TXD2__GPIO1_28,
 	/* dsPIC resets */
 	MX31_PIN_STXD5__GPIO1_21, MX31_PIN_SRXD5__GPIO1_22,
+	/*battery detection */
+	MX31_PIN_LCS0__GPIO3_23,
 };
 
 #define SDHC2_CD IOMUX_TO_GPIO(MX31_PIN_ATA_DIOR)
@@ -133,4 +135,11 @@ void __init mx31moboard_marxbot_init(void)
 	dspics_resets_init();
 
 	mxc_register_device(&mxcsdhc_device1, &sdhc2_pdata);
+
+	marxbot_cam_init();
+
+	/* battery present pin */
+	gpio_request(IOMUX_TO_GPIO(MX31_PIN_LCS0), "bat-present");
+	gpio_direction_input(IOMUX_TO_GPIO(MX31_PIN_LCS0));
+	gpio_export(IOMUX_TO_GPIO(MX31_PIN_LCS0), false);
 }
-- 
1.6.0.4

[PATCH 4/6] mx31moboard: initialize ipu device for all the boards

[Valentin Longchamp]

Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
---
 arch/arm/mach-mx3/mx31moboard.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mx3/mx31moboard.c b/arch/arm/mach-mx3/mx31moboard.c
index ff74fab..706a993 100644
--- a/arch/arm/mach-mx3/mx31moboard.c
+++ b/arch/arm/mach-mx3/mx31moboard.c
@@ -37,6 +37,7 @@
 #include <mach/hardware.h>
 #include <mach/imx-uart.h>
 #include <mach/iomux-mx3.h>
+#include <mach/ipu.h>
 #include <mach/i2c.h>
 #include <mach/mmc.h>
 #include <mach/mx31.h>
@@ -277,6 +278,10 @@ static void mx31moboard_init_sel_gpios(void)
 	}
 }
 
+static struct ipu_platform_data mx3_ipu_data = {
+	.irq_base = MXC_IPU_IRQ_START,
+};
+
 static struct platform_device *devices[] __initdata = {
 	&mx31moboard_flash,
 	&mx31moboard_leds_device,
@@ -306,6 +311,8 @@ static void __init mxc_board_init(void)
 
 	mxc_register_device(&mxcsdhc_device0, &sdhc1_pdata);
 
+	mxc_register_device(&mx3_ipu, &mx3_ipu_data);
+
 	usb_xcvr_reset();
 
 	moboard_usbotg_init();
-- 
1.6.0.4

[PATCH 5/6] mx31moboard: camera support

[Valentin Longchamp]

We have two mt9t031 cameras that have a muxed bus on the robot.
We can control which one we are using with gpio outputs. This
currently is not optimal

Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
---
 arch/arm/mach-mx3/mx31moboard-marxbot.c |   78 ++++++++++++++++++++++++++++++-
 arch/arm/mach-mx3/mx31moboard.c         |   37 ++++++++++++++-
 2 files changed, 113 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mx3/mx31moboard-marxbot.c b/arch/arm/mach-mx3/mx31moboard-marxbot.c
index 49d47ab..303cbdb 100644
--- a/arch/arm/mach-mx3/mx31moboard-marxbot.c
+++ b/arch/arm/mach-mx3/mx31moboard-marxbot.c
@@ -16,9 +16,11 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+#include <linux/delay.h>
 #include <linux/gpio.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
+#include <linux/i2c.h>
 #include <linux/platform_device.h>
 #include <linux/types.h>
 
@@ -28,6 +30,8 @@
 #include <mach/iomux-mx3.h>
 #include <mach/mmc.h>
 
+#include <media/soc_camera.h>
+
 #include "devices.h"
 
 static unsigned int marxbot_pins[] = {
@@ -37,7 +41,6 @@ static unsigned int marxbot_pins[] = {
 	MX31_PIN_PC_CD2_B__SD2_CLK, MX31_PIN_PC_CD1_B__SD2_CMD,
 	MX31_PIN_ATA_DIOR__GPIO3_28, MX31_PIN_ATA_DIOW__GPIO3_29,
 	/* CSI */
-	MX31_PIN_CSI_D4__CSI_D4, MX31_PIN_CSI_D5__CSI_D5,
 	MX31_PIN_CSI_D6__CSI_D6, MX31_PIN_CSI_D7__CSI_D7,
 	MX31_PIN_CSI_D8__CSI_D8, MX31_PIN_CSI_D9__CSI_D9,
 	MX31_PIN_CSI_D10__CSI_D10, MX31_PIN_CSI_D11__CSI_D11,
@@ -45,6 +48,7 @@ static unsigned int marxbot_pins[] = {
 	MX31_PIN_CSI_D14__CSI_D14, MX31_PIN_CSI_D15__CSI_D15,
 	MX31_PIN_CSI_HSYNC__CSI_HSYNC, MX31_PIN_CSI_MCLK__CSI_MCLK,
 	MX31_PIN_CSI_PIXCLK__CSI_PIXCLK, MX31_PIN_CSI_VSYNC__CSI_VSYNC,
+	MX31_PIN_CSI_D4__GPIO3_4, MX31_PIN_CSI_D5__GPIO3_5,
 	MX31_PIN_GPIO3_0__GPIO3_0, MX31_PIN_GPIO3_1__GPIO3_1,
 	MX31_PIN_TXD2__GPIO1_28,
 	/* dsPIC resets */
@@ -122,6 +126,78 @@ static void dspics_resets_init(void)
 	}
 }
 
+#define TURRETCAM_POWER	IOMUX_TO_GPIO(MX31_PIN_GPIO3_1)
+#define BASECAM_POWER	IOMUX_TO_GPIO(MX31_PIN_CSI_D5)
+#define TURRETCAM_RST_B	IOMUX_TO_GPIO(MX31_PIN_GPIO3_0)
+#define BASECAM_RST_B	IOMUX_TO_GPIO(MX31_PIN_CSI_D4)
+#define CAM_CHOICE	IOMUX_TO_GPIO(MX31_PIN_TXD2)
+
+static int marxbot_cam_power(struct device *dev, int on)
+{
+	gpio_set_value(BASECAM_POWER, !on);
+	return 0;
+}
+
+static int marxbot_cam_reset(struct device *dev)
+{
+	gpio_set_value(BASECAM_RST_B, 0);
+	udelay(100);
+	gpio_set_value(BASECAM_RST_B, 1);
+	return 0;
+}
+
+static struct i2c_board_info marxbot_i2c_devices[] = {
+	{
+		I2C_BOARD_INFO("mt9t031", 0x5d),
+	},
+};
+
+static struct soc_camera_link iclink = {
+	.bus_id		= 0,		/* Must match with the camera ID */
+	.power		= marxbot_cam_power,
+	.reset		= marxbot_cam_reset,
+	.board_info	= &marxbot_i2c_devices[0],
+	.i2c_adapter_id	= 0,
+	.module_name	= "mt9t031",
+};
+
+static struct platform_device marxbot_camera = {
+	.name	= "soc-camera-pdrv",
+	.id	= 0,
+	.dev	= {
+		.platform_data = &iclink,
+	},
+};
+
+static int __init marxbot_cam_init(void)
+{
+	int ret = gpio_request(CAM_CHOICE, "cam-choice");
+	if (ret)
+		return ret;
+	gpio_direction_output(CAM_CHOICE, 1);
+	gpio_export(CAM_CHOICE, false);
+	ret = gpio_request(BASECAM_RST_B, "basecam-reset");
+	if (ret)
+		return ret;
+	gpio_direction_output(BASECAM_RST_B, 1);
+	ret = gpio_request(BASECAM_POWER, "basecam-standby");
+	if (ret)
+		return ret;
+	gpio_direction_output(BASECAM_POWER, 0);
+
+	/*temporary part: we must use the mux better*/
+	gpio_request(TURRETCAM_RST_B, "turretcam-reset");
+	gpio_direction_output(TURRETCAM_RST_B, 1);
+	gpio_export(TURRETCAM_RST_B, false);
+
+	gpio_request(TURRETCAM_POWER, "turretcam-standby");
+	gpio_direction_output(TURRETCAM_POWER, 0);
+	gpio_export(TURRETCAM_POWER, false);
+
+	return platform_device_register(&marxbot_camera);
+}
+
+
 /*
  * system init for baseboard usage. Will be called by mx31moboard init.
  */
diff --git a/arch/arm/mach-mx3/mx31moboard.c b/arch/arm/mach-mx3/mx31moboard.c
index 706a993..605c0fa 100644
--- a/arch/arm/mach-mx3/mx31moboard.c
+++ b/arch/arm/mach-mx3/mx31moboard.c
@@ -40,7 +40,7 @@
 #include <mach/ipu.h>
 #include <mach/i2c.h>
 #include <mach/mmc.h>
-#include <mach/mx31.h>
+#include <mach/mx3_camera.h>
 
 #include "devices.h"
 
@@ -287,6 +287,39 @@ static struct platform_device *devices[] __initdata = {
 	&mx31moboard_leds_device,
 };
 
+static struct mx3_camera_pdata camera_pdata = {
+	.dma_dev	= &mx3_ipu.dev,
+	.flags		= MX3_CAMERA_DATAWIDTH_8 | MX3_CAMERA_DATAWIDTH_10,
+	.mclk_10khz	= 4800,
+};
+
+#define CAMERA_BUF_SIZE	(4*1024*1024)
+
+static int __init mx31moboard_cam_alloc_dma(const size_t buf_size)
+{
+	dma_addr_t dma_handle;
+	void *buf;
+	int dma;
+
+	if (buf_size < 2 * 1024 * 1024)
+		return -EINVAL;
+
+	buf = dma_alloc_coherent(NULL, buf_size, &dma_handle, GFP_KERNEL);
+	if (!buf) {
+		pr_err("%s: cannot allocate camera buffer-memory\n", __func__);
+		return -ENOMEM;
+	}
+
+	memset(buf, 0, buf_size);
+
+	dma = dma_declare_coherent_memory(&mx3_camera.dev,
+					dma_handle, dma_handle, buf_size,
+					DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
+
+	/* The way we call dma_declare_coherent_memory only a malloc can fail */
+	return dma & DMA_MEMORY_MAP ? 0 : -ENOMEM;
+}
+
 static int mx31moboard_baseboard;
 core_param(mx31moboard_baseboard, mx31moboard_baseboard, int, 0444);
 
@@ -312,6 +345,8 @@ static void __init mxc_board_init(void)
 	mxc_register_device(&mxcsdhc_device0, &sdhc1_pdata);
 
 	mxc_register_device(&mx3_ipu, &mx3_ipu_data);
+	if (!mx31moboard_cam_alloc_dma(CAMERA_BUF_SIZE))
+		mxc_register_device(&mx3_camera, &camera_pdata);
 
 	usb_xcvr_reset();
 
-- 
1.6.0.4

[PATCH 6/6] mx31moboard: SPI and MC13783 votage regulator support

[Valentin Longchamp]

Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
---
 arch/arm/mach-mx3/mx31moboard.c |  118 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 118 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mx3/mx31moboard.c b/arch/arm/mach-mx3/mx31moboard.c
index 605c0fa..3a0be12 100644
--- a/arch/arm/mach-mx3/mx31moboard.c
+++ b/arch/arm/mach-mx3/mx31moboard.c
@@ -26,6 +26,9 @@
 #include <linux/mtd/physmap.h>
 #include <linux/mtd/partitions.h>
 #include <linux/platform_device.h>
+#include <linux/regulator/machine.h>
+#include <linux/mfd/mc13783.h>
+#include <linux/spi/spi.h>
 #include <linux/types.h>
 
 #include <asm/mach-types.h>
@@ -41,6 +44,7 @@
 #include <mach/i2c.h>
 #include <mach/mmc.h>
 #include <mach/mx3_camera.h>
+#include <mach/spi.h>
 
 #include "devices.h"
 
@@ -80,6 +84,16 @@ static unsigned int moboard_pins[] = {
 	/* SEL */
 	MX31_PIN_DTR_DCE1__GPIO2_8, MX31_PIN_DSR_DCE1__GPIO2_9,
 	MX31_PIN_RI_DCE1__GPIO2_10, MX31_PIN_DCD_DCE1__GPIO2_11,
+	/* SPI1 */
+	MX31_PIN_CSPI2_MOSI__MOSI, MX31_PIN_CSPI2_MISO__MISO,
+	MX31_PIN_CSPI2_SCLK__SCLK, MX31_PIN_CSPI2_SPI_RDY__SPI_RDY,
+	MX31_PIN_CSPI2_SS0__SS0, MX31_PIN_CSPI2_SS2__SS2,
+	/* Atlas IRQ */
+	MX31_PIN_GPIO1_3__GPIO1_3,
+	/* SPI2 */
+	MX31_PIN_CSPI3_MOSI__MOSI, MX31_PIN_CSPI3_MISO__MISO,
+	MX31_PIN_CSPI3_SCLK__SCLK, MX31_PIN_CSPI3_SPI_RDY__SPI_RDY,
+	MX31_PIN_CSPI2_SS1__CSPI3_SS1,
 };
 
 static struct physmap_flash_data mx31moboard_flash_data = {
@@ -125,6 +139,102 @@ static struct imxi2c_platform_data moboard_i2c1_pdata = {
 	.bitrate = 100000,
 };
 
+static int moboard_spi1_cs[] = {
+	MXC_SPI_CS(0),
+	MXC_SPI_CS(2),
+};
+
+static struct spi_imx_master moboard_spi1_master = {
+	.chipselect	= moboard_spi1_cs,
+	.num_chipselect	= ARRAY_SIZE(moboard_spi1_cs),
+};
+
+static struct regulator_consumer_supply sdhc_consumers[] = {
+	{
+		.dev	= &mxcsdhc_device0.dev,
+		.supply	= "sdhc0_vcc",
+	},
+	{
+		.dev	= &mxcsdhc_device1.dev,
+		.supply	= "sdhc1_vcc",
+	},
+};
+
+static struct regulator_init_data sdhc_vreg_data = {
+	.constraints = {
+		.min_uV = 2700000,
+		.max_uV = 3000000,
+		.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE |
+			REGULATOR_CHANGE_MODE | REGULATOR_CHANGE_STATUS,
+		.valid_modes_mask = REGULATOR_MODE_NORMAL |
+			REGULATOR_MODE_FAST,
+		.always_on = 0,
+		.boot_on = 1,
+	},
+	.num_consumer_supplies = ARRAY_SIZE(sdhc_consumers),
+	.consumer_supplies = sdhc_consumers,
+};
+
+static struct regulator_consumer_supply cam_consumers[] = {
+	{
+		.dev	= &mx3_camera.dev,
+		.supply	= "cam_vcc",
+	},
+};
+
+static struct regulator_init_data cam_vreg_data = {
+	.constraints = {
+		.min_uV = 2700000,
+		.max_uV = 3000000,
+		.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE |
+			REGULATOR_CHANGE_MODE | REGULATOR_CHANGE_STATUS,
+		.valid_modes_mask = REGULATOR_MODE_NORMAL |
+			REGULATOR_MODE_FAST,
+		.always_on = 0,
+		.boot_on = 1,
+	},
+	.num_consumer_supplies = ARRAY_SIZE(cam_consumers),
+	.consumer_supplies = cam_consumers,
+};
+
+static struct mc13783_regulator_init_data moboard_regulators[] = {
+	{
+		.id = MC13783_REGU_VMMC1,
+		.init_data = &sdhc_vreg_data,
+	},
+	{
+		.id = MC13783_REGU_VCAM,
+		.init_data = &cam_vreg_data,
+	},
+};
+
+static struct mc13783_platform_data moboard_pmic = {
+	.regulators = moboard_regulators,
+	.num_regulators = ARRAY_SIZE(moboard_regulators),
+	.flags = MC13783_USE_REGULATOR | MC13783_USE_RTC,
+};
+
+static struct spi_board_info moboard_spi_board_info[] __initdata = {
+	{
+		.modalias = "mc13783",
+		.irq = IOMUX_TO_IRQ(MX31_PIN_GPIO1_3),
+		.max_speed_hz = 300000,
+		.bus_num = 1,
+		.chip_select = 0,
+		.platform_data = &moboard_pmic,
+		.mode = SPI_CS_HIGH,
+	}
+};
+
+static int moboard_spi2_cs[] = {
+	MXC_SPI_CS(1),
+};
+
+static struct spi_imx_master moboard_spi2_master = {
+	.chipselect	= moboard_spi2_cs,
+	.num_chipselect	= ARRAY_SIZE(moboard_spi2_cs),
+};
+
 #define SDHC1_CD IOMUX_TO_GPIO(MX31_PIN_ATA_CS0)
 #define SDHC1_WP IOMUX_TO_GPIO(MX31_PIN_ATA_CS1)
 
@@ -342,6 +452,14 @@ static void __init mxc_board_init(void)
 	mxc_register_device(&mxc_i2c_device0, &moboard_i2c0_pdata);
 	mxc_register_device(&mxc_i2c_device1, &moboard_i2c1_pdata);
 
+	mxc_register_device(&mxc_spi_device1, &moboard_spi1_master);
+	mxc_register_device(&mxc_spi_device2, &moboard_spi2_master);
+
+	gpio_request(IOMUX_TO_GPIO(MX31_PIN_GPIO1_3), "pmic-irq");
+	gpio_direction_input(IOMUX_TO_GPIO(MX31_PIN_GPIO1_3));
+	spi_register_board_info(moboard_spi_board_info,
+		ARRAY_SIZE(moboard_spi_board_info));
+
 	mxc_register_device(&mxcsdhc_device0, &sdhc1_pdata);
 
 	mxc_register_device(&mx3_ipu, &mx3_ipu_data);
-- 
1.6.0.4

[RFC] mx31moboard: patches for next merge window

[Sascha Hauer]

Hi Valentin,

On Thu, Oct 15, 2009 at 11:42:54AM +0200, Valentin Longchamp wrote:
> Here are the patches I would like to push during the next merge window for
> the mx31moboard platform.
> 
> It consists of a fix for a small hardware design issue for the main serial
> port, a few GPIOs used on the robots that are declared, camera support and
> finally MC13783 support as it is now getting ready.
> 
> For MC13783, we would need RTC as well, but I did not add it yet since it
> is not in mainline yet.

I think you did, but it's fine.

> 
> The camera part still is initial: it works well with a single camera but I
> still have to figure out what is the best way to handle the two mt9t031 we
> have on the marxbot.
> 
> The main peripheral that we are using and that still is missing is the USB
> host, but since the driver still needs a few improvements, I keep it aside
> for now.
> 
> Please review and comment.

Looks ok to me. I'll have a closer look on monday.

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 |

[RFC] mx31moboard: patches for next merge window

[Uwe Kleine-König]

On Thu, Oct 15, 2009 at 11:42:54AM +0200, Valentin Longchamp wrote:
> Here are the patches I would like to push during the next merge window for
> the mx31moboard platform.
> 
> It consists of a fix for a small hardware design issue for the main serial
> port, a few GPIOs used on the robots that are declared, camera support and
> finally MC13783 support as it is now getting ready.
> 
> For MC13783, we would need RTC as well, but I did not add it yet since it
> is not in mainline yet.
Note I'm currently overhauling mc13783-core.c resulting in an API change.

I plan to add some compatibility stuff, but I'll let you know when I'm
done anyhow.  Are you interested in testing my changes?

I don't know yet if I will try to get the rtc-support into mainline, but
Sasche posted a patch (without feedback) some time ago.  (It's only a
minimal driver, no alarm, no reset detection.)

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

[PATCH 6/6] mx31moboard: SPI and MC13783 votage regulator support

[Uwe Kleine-König]

Hello,

Subject ~= s/votage/voltage/

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

[RFC] mx31moboard: patches for next merge window

[Valentin Longchamp]

Uwe Kleine-K?nig wrote:
> On Thu, Oct 15, 2009 at 11:42:54AM +0200, Valentin Longchamp wrote:
>> Here are the patches I would like to push during the next merge window for
>> the mx31moboard platform.
>>
>> It consists of a fix for a small hardware design issue for the main serial
>> port, a few GPIOs used on the robots that are declared, camera support and
>> finally MC13783 support as it is now getting ready.
>>
>> For MC13783, we would need RTC as well, but I did not add it yet since it
>> is not in mainline yet.
> Note I'm currently overhauling mc13783-core.c resulting in an API change.
> 
> I plan to add some compatibility stuff, but I'll let you know when I'm
> done anyhow.  Are you interested in testing my changes?

Sure. Tell me when you have something and I will give them a spin on the 
robot.

> 
> I don't know yet if I will try to get the rtc-support into mainline, but
> Sasche posted a patch (without feedback) some time ago.  (It's only a
> minimal driver, no alarm, no reset detection.)
> 

That would be nice. We only rely on this MC13783 RTC, so if we can get 
it into mainline it would be great for us.

Another thing is the RGB led support. We have two of these leds on our 
robot. Is anyone else using them ? Has someone already worked on them ? 
The support should not be very hard to add now that we have MC13783 core 
support and since there is a LED class. The only API change to led would 
be to add RGB support, which is not present now. Any comments on this ?

Best Regards

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne

[PATCH 5/6] mx31moboard: camera support

[Russell King - ARM Linux]

On Thu, Oct 15, 2009 at 11:42:59AM +0200, Valentin Longchamp wrote:
> +	buf = dma_alloc_coherent(NULL, buf_size, &dma_handle, GFP_KERNEL);
> +	if (!buf) {
> +		pr_err("%s: cannot allocate camera buffer-memory\n", __func__);
> +		return -ENOMEM;
> +	}
> +
> +	memset(buf, 0, buf_size);

No need to memset memory returned from dma_alloc_coherent.

[PATCH 5/6] mx31moboard: camera support

[Guennadi Liakhovetski]

Hi

On Thu, 15 Oct 2009, Valentin Longchamp wrote:

> We have two mt9t031 cameras that have a muxed bus on the robot.
> We can control which one we are using with gpio outputs. This
> currently is not optimal

So, what prevents you from registering two platform devices for your two 
cameras? Is there a problem with that?

Sascha, please wait with applying this patch. I'll have a better look at 
it after I get a reply from Val.

Thanks
Guennadi

> 
> Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
> ---
>  arch/arm/mach-mx3/mx31moboard-marxbot.c |   78 ++++++++++++++++++++++++++++++-
>  arch/arm/mach-mx3/mx31moboard.c         |   37 ++++++++++++++-
>  2 files changed, 113 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-mx3/mx31moboard-marxbot.c b/arch/arm/mach-mx3/mx31moboard-marxbot.c
> index 49d47ab..303cbdb 100644
> --- a/arch/arm/mach-mx3/mx31moboard-marxbot.c
> +++ b/arch/arm/mach-mx3/mx31moboard-marxbot.c
> @@ -16,9 +16,11 @@
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>   */
>  
> +#include <linux/delay.h>
>  #include <linux/gpio.h>
>  #include <linux/init.h>
>  #include <linux/interrupt.h>
> +#include <linux/i2c.h>
>  #include <linux/platform_device.h>
>  #include <linux/types.h>
>  
> @@ -28,6 +30,8 @@
>  #include <mach/iomux-mx3.h>
>  #include <mach/mmc.h>
>  
> +#include <media/soc_camera.h>
> +
>  #include "devices.h"
>  
>  static unsigned int marxbot_pins[] = {
> @@ -37,7 +41,6 @@ static unsigned int marxbot_pins[] = {
>  	MX31_PIN_PC_CD2_B__SD2_CLK, MX31_PIN_PC_CD1_B__SD2_CMD,
>  	MX31_PIN_ATA_DIOR__GPIO3_28, MX31_PIN_ATA_DIOW__GPIO3_29,
>  	/* CSI */
> -	MX31_PIN_CSI_D4__CSI_D4, MX31_PIN_CSI_D5__CSI_D5,
>  	MX31_PIN_CSI_D6__CSI_D6, MX31_PIN_CSI_D7__CSI_D7,
>  	MX31_PIN_CSI_D8__CSI_D8, MX31_PIN_CSI_D9__CSI_D9,
>  	MX31_PIN_CSI_D10__CSI_D10, MX31_PIN_CSI_D11__CSI_D11,
> @@ -45,6 +48,7 @@ static unsigned int marxbot_pins[] = {
>  	MX31_PIN_CSI_D14__CSI_D14, MX31_PIN_CSI_D15__CSI_D15,
>  	MX31_PIN_CSI_HSYNC__CSI_HSYNC, MX31_PIN_CSI_MCLK__CSI_MCLK,
>  	MX31_PIN_CSI_PIXCLK__CSI_PIXCLK, MX31_PIN_CSI_VSYNC__CSI_VSYNC,
> +	MX31_PIN_CSI_D4__GPIO3_4, MX31_PIN_CSI_D5__GPIO3_5,
>  	MX31_PIN_GPIO3_0__GPIO3_0, MX31_PIN_GPIO3_1__GPIO3_1,
>  	MX31_PIN_TXD2__GPIO1_28,
>  	/* dsPIC resets */
> @@ -122,6 +126,78 @@ static void dspics_resets_init(void)
>  	}
>  }
>  
> +#define TURRETCAM_POWER	IOMUX_TO_GPIO(MX31_PIN_GPIO3_1)
> +#define BASECAM_POWER	IOMUX_TO_GPIO(MX31_PIN_CSI_D5)
> +#define TURRETCAM_RST_B	IOMUX_TO_GPIO(MX31_PIN_GPIO3_0)
> +#define BASECAM_RST_B	IOMUX_TO_GPIO(MX31_PIN_CSI_D4)
> +#define CAM_CHOICE	IOMUX_TO_GPIO(MX31_PIN_TXD2)
> +
> +static int marxbot_cam_power(struct device *dev, int on)
> +{
> +	gpio_set_value(BASECAM_POWER, !on);
> +	return 0;
> +}
> +
> +static int marxbot_cam_reset(struct device *dev)
> +{
> +	gpio_set_value(BASECAM_RST_B, 0);
> +	udelay(100);
> +	gpio_set_value(BASECAM_RST_B, 1);
> +	return 0;
> +}
> +
> +static struct i2c_board_info marxbot_i2c_devices[] = {
> +	{
> +		I2C_BOARD_INFO("mt9t031", 0x5d),
> +	},
> +};
> +
> +static struct soc_camera_link iclink = {
> +	.bus_id		= 0,		/* Must match with the camera ID */
> +	.power		= marxbot_cam_power,
> +	.reset		= marxbot_cam_reset,
> +	.board_info	= &marxbot_i2c_devices[0],
> +	.i2c_adapter_id	= 0,
> +	.module_name	= "mt9t031",
> +};
> +
> +static struct platform_device marxbot_camera = {
> +	.name	= "soc-camera-pdrv",
> +	.id	= 0,
> +	.dev	= {
> +		.platform_data = &iclink,
> +	},
> +};
> +
> +static int __init marxbot_cam_init(void)
> +{
> +	int ret = gpio_request(CAM_CHOICE, "cam-choice");
> +	if (ret)
> +		return ret;
> +	gpio_direction_output(CAM_CHOICE, 1);
> +	gpio_export(CAM_CHOICE, false);
> +	ret = gpio_request(BASECAM_RST_B, "basecam-reset");
> +	if (ret)
> +		return ret;
> +	gpio_direction_output(BASECAM_RST_B, 1);
> +	ret = gpio_request(BASECAM_POWER, "basecam-standby");
> +	if (ret)
> +		return ret;
> +	gpio_direction_output(BASECAM_POWER, 0);
> +
> +	/*temporary part: we must use the mux better*/
> +	gpio_request(TURRETCAM_RST_B, "turretcam-reset");
> +	gpio_direction_output(TURRETCAM_RST_B, 1);
> +	gpio_export(TURRETCAM_RST_B, false);
> +
> +	gpio_request(TURRETCAM_POWER, "turretcam-standby");
> +	gpio_direction_output(TURRETCAM_POWER, 0);
> +	gpio_export(TURRETCAM_POWER, false);
> +
> +	return platform_device_register(&marxbot_camera);
> +}
> +
> +
>  /*
>   * system init for baseboard usage. Will be called by mx31moboard init.
>   */
> diff --git a/arch/arm/mach-mx3/mx31moboard.c b/arch/arm/mach-mx3/mx31moboard.c
> index 706a993..605c0fa 100644
> --- a/arch/arm/mach-mx3/mx31moboard.c
> +++ b/arch/arm/mach-mx3/mx31moboard.c
> @@ -40,7 +40,7 @@
>  #include <mach/ipu.h>
>  #include <mach/i2c.h>
>  #include <mach/mmc.h>
> -#include <mach/mx31.h>
> +#include <mach/mx3_camera.h>
>  
>  #include "devices.h"
>  
> @@ -287,6 +287,39 @@ static struct platform_device *devices[] __initdata = {
>  	&mx31moboard_leds_device,
>  };
>  
> +static struct mx3_camera_pdata camera_pdata = {
> +	.dma_dev	= &mx3_ipu.dev,
> +	.flags		= MX3_CAMERA_DATAWIDTH_8 | MX3_CAMERA_DATAWIDTH_10,
> +	.mclk_10khz	= 4800,
> +};
> +
> +#define CAMERA_BUF_SIZE	(4*1024*1024)
> +
> +static int __init mx31moboard_cam_alloc_dma(const size_t buf_size)
> +{
> +	dma_addr_t dma_handle;
> +	void *buf;
> +	int dma;
> +
> +	if (buf_size < 2 * 1024 * 1024)
> +		return -EINVAL;
> +
> +	buf = dma_alloc_coherent(NULL, buf_size, &dma_handle, GFP_KERNEL);
> +	if (!buf) {
> +		pr_err("%s: cannot allocate camera buffer-memory\n", __func__);
> +		return -ENOMEM;
> +	}
> +
> +	memset(buf, 0, buf_size);
> +
> +	dma = dma_declare_coherent_memory(&mx3_camera.dev,
> +					dma_handle, dma_handle, buf_size,
> +					DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
> +
> +	/* The way we call dma_declare_coherent_memory only a malloc can fail */
> +	return dma & DMA_MEMORY_MAP ? 0 : -ENOMEM;
> +}
> +
>  static int mx31moboard_baseboard;
>  core_param(mx31moboard_baseboard, mx31moboard_baseboard, int, 0444);
>  
> @@ -312,6 +345,8 @@ static void __init mxc_board_init(void)
>  	mxc_register_device(&mxcsdhc_device0, &sdhc1_pdata);
>  
>  	mxc_register_device(&mx3_ipu, &mx3_ipu_data);
> +	if (!mx31moboard_cam_alloc_dma(CAMERA_BUF_SIZE))
> +		mxc_register_device(&mx3_camera, &camera_pdata);
>  
>  	usb_xcvr_reset();
>  
> -- 
> 1.6.0.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[PATCH 5/6] mx31moboard: camera support

[Valentin Longchamp]

Hi Guennadi,

Guennadi Liakhovetski wrote:
> Hi
> 
> On Thu, 15 Oct 2009, Valentin Longchamp wrote:
> 
>> We have two mt9t031 cameras that have a muxed bus on the robot.
>> We can control which one we are using with gpio outputs. This
>> currently is not optimal
> 
> So, what prevents you from registering two platform devices for your two 
> cameras? Is there a problem with that?

The lack of time until now to do it properly. I sent those patches as 
initial RFC (and by the way thanks for your comment).

I would like to have one video interface only and that I can switch 
between the two physical camera using a quite simple system call. Would 
that be compatible with registering the two platform devices ?

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne

[PATCH 5/6] mx31moboard: camera support

[Sascha Hauer]

On Mon, Oct 19, 2009 at 06:41:13PM +0200, Valentin Longchamp wrote:
> Hi Guennadi,
>
> Guennadi Liakhovetski wrote:
>> Hi
>>
>> On Thu, 15 Oct 2009, Valentin Longchamp wrote:
>>
>>> We have two mt9t031 cameras that have a muxed bus on the robot.
>>> We can control which one we are using with gpio outputs. This
>>> currently is not optimal
>>
>> So, what prevents you from registering two platform devices for your 
>> two cameras? Is there a problem with that?
>
> The lack of time until now to do it properly. I sent those patches as  
> initial RFC (and by the way thanks for your comment).
>
> I would like to have one video interface only and that I can switch  
> between the two physical camera using a quite simple system call. Would  
> that be compatible with registering the two platform devices ?

Wouldn't it be better to have /dev/video[01] for two cameras? How do
keep the registers synchron between both cameras otherwise?

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 |

Re: [PATCH 5/6] mx31moboard: camera support

[Valentin Longchamp]

Sascha Hauer wrote:
> On Mon, Oct 19, 2009 at 06:41:13PM +0200, Valentin Longchamp wrote:
>> Hi Guennadi,
>>
>> Guennadi Liakhovetski wrote:
>>> Hi
>>>
>>> On Thu, 15 Oct 2009, Valentin Longchamp wrote:
>>>
>>>> We have two mt9t031 cameras that have a muxed bus on the robot.
>>>> We can control which one we are using with gpio outputs. This
>>>> currently is not optimal
>>> So, what prevents you from registering two platform devices for your 
>>> two cameras? Is there a problem with that?
>> The lack of time until now to do it properly. I sent those patches as  
>> initial RFC (and by the way thanks for your comment).
>>
>> I would like to have one video interface only and that I can switch  
>> between the two physical camera using a quite simple system call. Would  
>> that be compatible with registering the two platform devices ?
> 
> Wouldn't it be better to have /dev/video[01] for two cameras? How do
> keep the registers synchron between both cameras otherwise?
> 

Well, from my experimentations, most initializations are done when you 
open the device. So if you close the device, switch camera and open it 
again, the registers are initialized with the need values. Of course 
there is a problem is you switch camera while the device is open.

It could be ok with /dev/video[01], but I would need something that 
would prevent one device to be opened when the other already is open (a 
mutex, but where ?).

Besides, I have read a slide from Dongsoo Kim 
(http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFile&do=get&target=Framework_for_digital_camera_in_linux-in_detail.ppt 
slides 41-47) and the cleanest solution would be to have the two chips 
enumerated with VIDIOC_ENUMINPUT as proposed. What would then be the 
v4l2 call to switch from one device to each other ? How to "link" it 
with the kernel code that make the real hardware switching ?

Thanks for your inputs.

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp@epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne

[PATCH 5/6] mx31moboard: camera support

[Valentin Longchamp]

Sascha Hauer wrote:
> On Mon, Oct 19, 2009 at 06:41:13PM +0200, Valentin Longchamp wrote:
>> Hi Guennadi,
>>
>> Guennadi Liakhovetski wrote:
>>> Hi
>>>
>>> On Thu, 15 Oct 2009, Valentin Longchamp wrote:
>>>
>>>> We have two mt9t031 cameras that have a muxed bus on the robot.
>>>> We can control which one we are using with gpio outputs. This
>>>> currently is not optimal
>>> So, what prevents you from registering two platform devices for your 
>>> two cameras? Is there a problem with that?
>> The lack of time until now to do it properly. I sent those patches as  
>> initial RFC (and by the way thanks for your comment).
>>
>> I would like to have one video interface only and that I can switch  
>> between the two physical camera using a quite simple system call. Would  
>> that be compatible with registering the two platform devices ?
> 
> Wouldn't it be better to have /dev/video[01] for two cameras? How do
> keep the registers synchron between both cameras otherwise?
> 

Well, from my experimentations, most initializations are done when you 
open the device. So if you close the device, switch camera and open it 
again, the registers are initialized with the need values. Of course 
there is a problem is you switch camera while the device is open.

It could be ok with /dev/video[01], but I would need something that 
would prevent one device to be opened when the other already is open (a 
mutex, but where ?).

Besides, I have read a slide from Dongsoo Kim 
(http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFile&do=get&target=Framework_for_digital_camera_in_linux-in_detail.ppt 
slides 41-47) and the cleanest solution would be to have the two chips 
enumerated with VIDIOC_ENUMINPUT as proposed. What would then be the 
v4l2 call to switch from one device to each other ? How to "link" it 
with the kernel code that make the real hardware switching ?

Thanks for your inputs.

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne

[PATCH 5/6] mx31moboard: camera support

[Guennadi Liakhovetski]

Hi Val

below are some comments to the patch, I'll also reply to your /dev/video* 
question in a separate mail.

On Thu, 15 Oct 2009, Valentin Longchamp wrote:

> We have two mt9t031 cameras that have a muxed bus on the robot.
> We can control which one we are using with gpio outputs. This
> currently is not optimal
> 
> Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
> ---
>  arch/arm/mach-mx3/mx31moboard-marxbot.c |   78 ++++++++++++++++++++++++++++++-
>  arch/arm/mach-mx3/mx31moboard.c         |   37 ++++++++++++++-
>  2 files changed, 113 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-mx3/mx31moboard-marxbot.c b/arch/arm/mach-mx3/mx31moboard-marxbot.c
> index 49d47ab..303cbdb 100644
> --- a/arch/arm/mach-mx3/mx31moboard-marxbot.c
> +++ b/arch/arm/mach-mx3/mx31moboard-marxbot.c
> @@ -16,9 +16,11 @@
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>   */
>  
> +#include <linux/delay.h>
>  #include <linux/gpio.h>
>  #include <linux/init.h>
>  #include <linux/interrupt.h>
> +#include <linux/i2c.h>
>  #include <linux/platform_device.h>
>  #include <linux/types.h>
>  
> @@ -28,6 +30,8 @@
>  #include <mach/iomux-mx3.h>
>  #include <mach/mmc.h>
>  
> +#include <media/soc_camera.h>
> +
>  #include "devices.h"
>  
>  static unsigned int marxbot_pins[] = {
> @@ -37,7 +41,6 @@ static unsigned int marxbot_pins[] = {
>  	MX31_PIN_PC_CD2_B__SD2_CLK, MX31_PIN_PC_CD1_B__SD2_CMD,
>  	MX31_PIN_ATA_DIOR__GPIO3_28, MX31_PIN_ATA_DIOW__GPIO3_29,
>  	/* CSI */
> -	MX31_PIN_CSI_D4__CSI_D4, MX31_PIN_CSI_D5__CSI_D5,
>  	MX31_PIN_CSI_D6__CSI_D6, MX31_PIN_CSI_D7__CSI_D7,
>  	MX31_PIN_CSI_D8__CSI_D8, MX31_PIN_CSI_D9__CSI_D9,
>  	MX31_PIN_CSI_D10__CSI_D10, MX31_PIN_CSI_D11__CSI_D11,
> @@ -45,6 +48,7 @@ static unsigned int marxbot_pins[] = {
>  	MX31_PIN_CSI_D14__CSI_D14, MX31_PIN_CSI_D15__CSI_D15,
>  	MX31_PIN_CSI_HSYNC__CSI_HSYNC, MX31_PIN_CSI_MCLK__CSI_MCLK,
>  	MX31_PIN_CSI_PIXCLK__CSI_PIXCLK, MX31_PIN_CSI_VSYNC__CSI_VSYNC,
> +	MX31_PIN_CSI_D4__GPIO3_4, MX31_PIN_CSI_D5__GPIO3_5,
>  	MX31_PIN_GPIO3_0__GPIO3_0, MX31_PIN_GPIO3_1__GPIO3_1,
>  	MX31_PIN_TXD2__GPIO1_28,
>  	/* dsPIC resets */
> @@ -122,6 +126,78 @@ static void dspics_resets_init(void)
>  	}
>  }
>  
> +#define TURRETCAM_POWER	IOMUX_TO_GPIO(MX31_PIN_GPIO3_1)
> +#define BASECAM_POWER	IOMUX_TO_GPIO(MX31_PIN_CSI_D5)
> +#define TURRETCAM_RST_B	IOMUX_TO_GPIO(MX31_PIN_GPIO3_0)
> +#define BASECAM_RST_B	IOMUX_TO_GPIO(MX31_PIN_CSI_D4)
> +#define CAM_CHOICE	IOMUX_TO_GPIO(MX31_PIN_TXD2)
> +
> +static int marxbot_cam_power(struct device *dev, int on)
> +{
> +	gpio_set_value(BASECAM_POWER, !on);
> +	return 0;
> +}
> +
> +static int marxbot_cam_reset(struct device *dev)
> +{
> +	gpio_set_value(BASECAM_RST_B, 0);
> +	udelay(100);
> +	gpio_set_value(BASECAM_RST_B, 1);
> +	return 0;
> +}
> +
> +static struct i2c_board_info marxbot_i2c_devices[] = {
> +	{
> +		I2C_BOARD_INFO("mt9t031", 0x5d),
> +	},
> +};
> +
> +static struct soc_camera_link iclink = {
> +	.bus_id		= 0,		/* Must match with the camera ID */
> +	.power		= marxbot_cam_power,
> +	.reset		= marxbot_cam_reset,
> +	.board_info	= &marxbot_i2c_devices[0],
> +	.i2c_adapter_id	= 0,
> +	.module_name	= "mt9t031",
> +};
> +
> +static struct platform_device marxbot_camera = {
> +	.name	= "soc-camera-pdrv",
> +	.id	= 0,
> +	.dev	= {
> +		.platform_data = &iclink,
> +	},
> +};
> +
> +static int __init marxbot_cam_init(void)
> +{
> +	int ret = gpio_request(CAM_CHOICE, "cam-choice");
> +	if (ret)
> +		return ret;
> +	gpio_direction_output(CAM_CHOICE, 1);
> +	gpio_export(CAM_CHOICE, false);

Why are exporting this and two more gpios below? Does this allow you to 
switch cameras from the user-space? Even if so, I wouldn't push this 
upstream, as you won't need this in the future, when you add proper 
support for the second camera into the kernel.

> +	ret = gpio_request(BASECAM_RST_B, "basecam-reset");
> +	if (ret)
> +		return ret;
> +	gpio_direction_output(BASECAM_RST_B, 1);
> +	ret = gpio_request(BASECAM_POWER, "basecam-standby");
> +	if (ret)
> +		return ret;
> +	gpio_direction_output(BASECAM_POWER, 0);
> +
> +	/*temporary part: we must use the mux better*/

Please, add spaces around text in comment.

> +	gpio_request(TURRETCAM_RST_B, "turretcam-reset");
> +	gpio_direction_output(TURRETCAM_RST_B, 1);
> +	gpio_export(TURRETCAM_RST_B, false);
> +
> +	gpio_request(TURRETCAM_POWER, "turretcam-standby");
> +	gpio_direction_output(TURRETCAM_POWER, 0);
> +	gpio_export(TURRETCAM_POWER, false);
> +
> +	return platform_device_register(&marxbot_camera);
> +}
> +
> +
>  /*
>   * system init for baseboard usage. Will be called by mx31moboard init.
>   */
> diff --git a/arch/arm/mach-mx3/mx31moboard.c b/arch/arm/mach-mx3/mx31moboard.c
> index 706a993..605c0fa 100644
> --- a/arch/arm/mach-mx3/mx31moboard.c
> +++ b/arch/arm/mach-mx3/mx31moboard.c
> @@ -40,7 +40,7 @@
>  #include <mach/ipu.h>
>  #include <mach/i2c.h>
>  #include <mach/mmc.h>
> -#include <mach/mx31.h>
> +#include <mach/mx3_camera.h>

Need

#include <linux/dma-mapping.h>

for DMA_MEMORY_MAP and DMA_MEMORY_EXCLUSIVE macros, etc.

>  
>  #include "devices.h"
>  
> @@ -287,6 +287,39 @@ static struct platform_device *devices[] __initdata = {
>  	&mx31moboard_leds_device,
>  };
>  
> +static struct mx3_camera_pdata camera_pdata = {
> +	.dma_dev	= &mx3_ipu.dev,
> +	.flags		= MX3_CAMERA_DATAWIDTH_8 | MX3_CAMERA_DATAWIDTH_10,
> +	.mclk_10khz	= 4800,
> +};
> +
> +#define CAMERA_BUF_SIZE	(4*1024*1024)
> +
> +static int __init mx31moboard_cam_alloc_dma(const size_t buf_size)
> +{
> +	dma_addr_t dma_handle;
> +	void *buf;
> +	int dma;
> +
> +	if (buf_size < 2 * 1024 * 1024)
> +		return -EINVAL;
> +
> +	buf = dma_alloc_coherent(NULL, buf_size, &dma_handle, GFP_KERNEL);
> +	if (!buf) {
> +		pr_err("%s: cannot allocate camera buffer-memory\n", __func__);
> +		return -ENOMEM;
> +	}
> +
> +	memset(buf, 0, buf_size);
> +
> +	dma = dma_declare_coherent_memory(&mx3_camera.dev,
> +					dma_handle, dma_handle, buf_size,
> +					DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
> +
> +	/* The way we call dma_declare_coherent_memory only a malloc can fail */
> +	return dma & DMA_MEMORY_MAP ? 0 : -ENOMEM;
> +}
> +
>  static int mx31moboard_baseboard;
>  core_param(mx31moboard_baseboard, mx31moboard_baseboard, int, 0444);
>  
> @@ -312,6 +345,8 @@ static void __init mxc_board_init(void)
>  	mxc_register_device(&mxcsdhc_device0, &sdhc1_pdata);
>  
>  	mxc_register_device(&mx3_ipu, &mx3_ipu_data);
> +	if (!mx31moboard_cam_alloc_dma(CAMERA_BUF_SIZE))
> +		mxc_register_device(&mx3_camera, &camera_pdata);
>  
>  	usb_xcvr_reset();
>  
> -- 
> 1.6.0.4

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/6] mx31moboard: camera support

[Guennadi Liakhovetski]

On Wed, 21 Oct 2009, Valentin Longchamp wrote:

> Sascha Hauer wrote:
> > On Mon, Oct 19, 2009 at 06:41:13PM +0200, Valentin Longchamp wrote:
> > > Hi Guennadi,
> > > 
> > > Guennadi Liakhovetski wrote:
> > > > Hi
> > > > 
> > > > On Thu, 15 Oct 2009, Valentin Longchamp wrote:
> > > > 
> > > > > We have two mt9t031 cameras that have a muxed bus on the robot.
> > > > > We can control which one we are using with gpio outputs. This
> > > > > currently is not optimal
> > > > So, what prevents you from registering two platform devices for your two
> > > > cameras? Is there a problem with that?
> > > The lack of time until now to do it properly. I sent those patches as
> > > initial RFC (and by the way thanks for your comment).
> > > 
> > > I would like to have one video interface only and that I can switch
> > > between the two physical camera using a quite simple system call. Would
> > > that be compatible with registering the two platform devices ?
> > 
> > Wouldn't it be better to have /dev/video[01] for two cameras? How do
> > keep the registers synchron between both cameras otherwise?
> > 
> 
> Well, from my experimentations, most initializations are done when you open
> the device. So if you close the device, switch camera and open it again, the
> registers are initialized with the need values. Of course there is a problem
> is you switch camera while the device is open.
> 
> It could be ok with /dev/video[01], but I would need something that would
> prevent one device to be opened when the other already is open (a mutex, but
> where ?).
> 
> Besides, I have read a slide from Dongsoo Kim
> (http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFile&do=get&target=Framework_for_digital_camera_in_linux-in_detail.ppt
> slides 41-47) and the cleanest solution would be to have the two chips
> enumerated with VIDIOC_ENUMINPUT as proposed. What would then be the v4l2 call
> to switch from one device to each other ? How to "link" it with the kernel
> code that make the real hardware switching ?

Ok, I don't have a definite answer to this, so, just my thoughts:

1. soc-camera currently registers one struct v4l2_device device per _host_ 
immediately upon its registration, and one struct video_device per 
_client_ platform device.

2. we currently have 1 or 2 boards in the mainline with two video client 
devices on one interface: arch/sh/boards/mach-migor/ and (unsure about) 
arch/sh/boards/board-ap325rxa.c. At least the first of them exports two 
platform devices and thus gets /dev/video[01]. Accesses are synchronised 
with a mutex (I don't actually like that, I'd prefer to get a -EBUSY back 
instead of hanging in D in open()), and a successful acquisition of the 
mutex switches the respective camera on. See code for details. So, this 
approach is supported and it works. In this case we have one v4l2_device 
and two video_device instances, don't know whether this matches how this 
is supposed to be done, but it works so far:-)

3. to support switching inputs, significant modifications to soc_camera.c 
would be required. I read Nate's argument before, that as long as clients 
can only be accessed one at a time, this should be presented by multiple 
inputs rather than multiple device nodes. Somebody else from the V4L folk 
has also confirmed this opinion. In principle I don't feel strongly either 
way. But currently soc-camera uses a one i2c client to one device node 
model, and I'm somewhat reluctant to change this before we're done with 
the v4l2-subdev conversion.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[PATCH 5/6] mx31moboard: camera support

[Guennadi Liakhovetski]

On Wed, 21 Oct 2009, Valentin Longchamp wrote:

> Sascha Hauer wrote:
> > On Mon, Oct 19, 2009 at 06:41:13PM +0200, Valentin Longchamp wrote:
> > > Hi Guennadi,
> > > 
> > > Guennadi Liakhovetski wrote:
> > > > Hi
> > > > 
> > > > On Thu, 15 Oct 2009, Valentin Longchamp wrote:
> > > > 
> > > > > We have two mt9t031 cameras that have a muxed bus on the robot.
> > > > > We can control which one we are using with gpio outputs. This
> > > > > currently is not optimal
> > > > So, what prevents you from registering two platform devices for your two
> > > > cameras? Is there a problem with that?
> > > The lack of time until now to do it properly. I sent those patches as
> > > initial RFC (and by the way thanks for your comment).
> > > 
> > > I would like to have one video interface only and that I can switch
> > > between the two physical camera using a quite simple system call. Would
> > > that be compatible with registering the two platform devices ?
> > 
> > Wouldn't it be better to have /dev/video[01] for two cameras? How do
> > keep the registers synchron between both cameras otherwise?
> > 
> 
> Well, from my experimentations, most initializations are done when you open
> the device. So if you close the device, switch camera and open it again, the
> registers are initialized with the need values. Of course there is a problem
> is you switch camera while the device is open.
> 
> It could be ok with /dev/video[01], but I would need something that would
> prevent one device to be opened when the other already is open (a mutex, but
> where ?).
> 
> Besides, I have read a slide from Dongsoo Kim
> (http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFile&do=get&target=Framework_for_digital_camera_in_linux-in_detail.ppt
> slides 41-47) and the cleanest solution would be to have the two chips
> enumerated with VIDIOC_ENUMINPUT as proposed. What would then be the v4l2 call
> to switch from one device to each other ? How to "link" it with the kernel
> code that make the real hardware switching ?

Ok, I don't have a definite answer to this, so, just my thoughts:

1. soc-camera currently registers one struct v4l2_device device per _host_ 
immediately upon its registration, and one struct video_device per 
_client_ platform device.

2. we currently have 1 or 2 boards in the mainline with two video client 
devices on one interface: arch/sh/boards/mach-migor/ and (unsure about) 
arch/sh/boards/board-ap325rxa.c. At least the first of them exports two 
platform devices and thus gets /dev/video[01]. Accesses are synchronised 
with a mutex (I don't actually like that, I'd prefer to get a -EBUSY back 
instead of hanging in D in open()), and a successful acquisition of the 
mutex switches the respective camera on. See code for details. So, this 
approach is supported and it works. In this case we have one v4l2_device 
and two video_device instances, don't know whether this matches how this 
is supposed to be done, but it works so far:-)

3. to support switching inputs, significant modifications to soc_camera.c 
would be required. I read Nate's argument before, that as long as clients 
can only be accessed one at a time, this should be presented by multiple 
inputs rather than multiple device nodes. Somebody else from the V4L folk 
has also confirmed this opinion. In principle I don't feel strongly either 
way. But currently soc-camera uses a one i2c client to one device node 
model, and I'm somewhat reluctant to change this before we're done with 
the v4l2-subdev conversion.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[RFC] mx31moboard: patches for next merge window

[Uwe Kleine-König]

Hello Valentin,

On Fri, Oct 16, 2009 at 11:02:58AM +0200, Valentin Longchamp wrote:
> Uwe Kleine-K?nig wrote:
>> On Thu, Oct 15, 2009 at 11:42:54AM +0200, Valentin Longchamp wrote:
>>> Here are the patches I would like to push during the next merge window for
>>> the mx31moboard platform.
>>>
>>> It consists of a fix for a small hardware design issue for the main serial
>>> port, a few GPIOs used on the robots that are declared, camera support and
>>> finally MC13783 support as it is now getting ready.
>>>
>>> For MC13783, we would need RTC as well, but I did not add it yet since it
>>> is not in mainline yet.
>> Note I'm currently overhauling mc13783-core.c resulting in an API change.
>>
>> I plan to add some compatibility stuff, but I'll let you know when I'm
>> done anyhow.  Are you interested in testing my changes?
>
> Sure. Tell me when you have something and I will give them a spin on the  
> robot.
Yesterday I sent out my update to the mc13783-core driver, and just
remembered when I was in bed that I forgot to Cc: you.  You can find it
together with some other more or less related patches in my repository
at

	git://git.pengutronix.de/git/ukl/linux-2.6.git mc13783

(It contains the last pull request by Sascha, another patch for spi-imx,
and else MC13783 related patches: hwmon (already accepted upstream),
touchscreen and rtc.)

I will follow up this mail with the rtc patch for review by the rtc
people.  Compared with the patch by Sascha it got reset detection and
works on top of my rewritten mc13783-core driver.

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Re: [PATCH 5/6] mx31moboard: camera support

[Valentin Longchamp]

Guennadi Liakhovetski wrote:
> On Wed, 21 Oct 2009, Valentin Longchamp wrote:
> 
>> Sascha Hauer wrote:
>>> On Mon, Oct 19, 2009 at 06:41:13PM +0200, Valentin Longchamp wrote:
>>>> Hi Guennadi,
>>>>
>>>> Guennadi Liakhovetski wrote:
>>>>> Hi
>>>>>
>>>>> On Thu, 15 Oct 2009, Valentin Longchamp wrote:
>>>>>
>>>>>> We have two mt9t031 cameras that have a muxed bus on the robot.
>>>>>> We can control which one we are using with gpio outputs. This
>>>>>> currently is not optimal
>>>>> So, what prevents you from registering two platform devices for your two
>>>>> cameras? Is there a problem with that?
>>>> The lack of time until now to do it properly. I sent those patches as
>>>> initial RFC (and by the way thanks for your comment).
>>>>
>>>> I would like to have one video interface only and that I can switch
>>>> between the two physical camera using a quite simple system call. Would
>>>> that be compatible with registering the two platform devices ?
>>> Wouldn't it be better to have /dev/video[01] for two cameras? How do
>>> keep the registers synchron between both cameras otherwise?
>>>
>> Well, from my experimentations, most initializations are done when you open
>> the device. So if you close the device, switch camera and open it again, the
>> registers are initialized with the need values. Of course there is a problem
>> is you switch camera while the device is open.
>>
>> It could be ok with /dev/video[01], but I would need something that would
>> prevent one device to be opened when the other already is open (a mutex, but
>> where ?).
>>
>> Besides, I have read a slide from Dongsoo Kim
>> (http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFile&do=get&target=Framework_for_digital_camera_in_linux-in_detail.ppt
>> slides 41-47) and the cleanest solution would be to have the two chips
>> enumerated with VIDIOC_ENUMINPUT as proposed. What would then be the v4l2 call
>> to switch from one device to each other ? How to "link" it with the kernel
>> code that make the real hardware switching ?
> 
> Ok, I don't have a definite answer to this, so, just my thoughts:
> 
> 1. soc-camera currently registers one struct v4l2_device device per _host_ 
> immediately upon its registration, and one struct video_device per 
> _client_ platform device.

Ok understood.

> 
> 2. we currently have 1 or 2 boards in the mainline with two video client 
> devices on one interface: arch/sh/boards/mach-migor/ and (unsure about) 
> arch/sh/boards/board-ap325rxa.c. At least the first of them exports two 
> platform devices and thus gets /dev/video[01]. Accesses are synchronised 
> with a mutex (I don't actually like that, I'd prefer to get a -EBUSY back 
> instead of hanging in D in open()), and a successful acquisition of the 
> mutex switches the respective camera on. See code for details. So, this 
> approach is supported and it works. In this case we have one v4l2_device 
> and two video_device instances, don't know whether this matches how this 
> is supposed to be done, but it works so far:-)

I am going to stick to this approach since it works now. This would 
allow me to have code that could go now into mainline.

> 
> 3. to support switching inputs, significant modifications to soc_camera.c 
> would be required. I read Nate's argument before, that as long as clients 
> can only be accessed one at a time, this should be presented by multiple 
> inputs rather than multiple device nodes. Somebody else from the V4L folk 
> has also confirmed this opinion. In principle I don't feel strongly either 
> way. But currently soc-camera uses a one i2c client to one device node 
> model, and I'm somewhat reluctant to change this before we're done with 
> the v4l2-subdev conversion.
> 

Sure, one step at a time. So for now the switching is not possible with 
soc_camera.

My problem is that both cameras have the same I2C address since they are 
the same.

Would I need to declare 2 i2c_device with the same address (I'm not sure 
it would even work ...) used by two _client_ platform_devices or would I 
have to have the two platform devices pointing to the same i2c_device ?

Thanks

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp@epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne

[PATCH 5/6] mx31moboard: camera support

[Valentin Longchamp]

Guennadi Liakhovetski wrote:
> On Wed, 21 Oct 2009, Valentin Longchamp wrote:
> 
>> Sascha Hauer wrote:
>>> On Mon, Oct 19, 2009 at 06:41:13PM +0200, Valentin Longchamp wrote:
>>>> Hi Guennadi,
>>>>
>>>> Guennadi Liakhovetski wrote:
>>>>> Hi
>>>>>
>>>>> On Thu, 15 Oct 2009, Valentin Longchamp wrote:
>>>>>
>>>>>> We have two mt9t031 cameras that have a muxed bus on the robot.
>>>>>> We can control which one we are using with gpio outputs. This
>>>>>> currently is not optimal
>>>>> So, what prevents you from registering two platform devices for your two
>>>>> cameras? Is there a problem with that?
>>>> The lack of time until now to do it properly. I sent those patches as
>>>> initial RFC (and by the way thanks for your comment).
>>>>
>>>> I would like to have one video interface only and that I can switch
>>>> between the two physical camera using a quite simple system call. Would
>>>> that be compatible with registering the two platform devices ?
>>> Wouldn't it be better to have /dev/video[01] for two cameras? How do
>>> keep the registers synchron between both cameras otherwise?
>>>
>> Well, from my experimentations, most initializations are done when you open
>> the device. So if you close the device, switch camera and open it again, the
>> registers are initialized with the need values. Of course there is a problem
>> is you switch camera while the device is open.
>>
>> It could be ok with /dev/video[01], but I would need something that would
>> prevent one device to be opened when the other already is open (a mutex, but
>> where ?).
>>
>> Besides, I have read a slide from Dongsoo Kim
>> (http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFile&do=get&target=Framework_for_digital_camera_in_linux-in_detail.ppt
>> slides 41-47) and the cleanest solution would be to have the two chips
>> enumerated with VIDIOC_ENUMINPUT as proposed. What would then be the v4l2 call
>> to switch from one device to each other ? How to "link" it with the kernel
>> code that make the real hardware switching ?
> 
> Ok, I don't have a definite answer to this, so, just my thoughts:
> 
> 1. soc-camera currently registers one struct v4l2_device device per _host_ 
> immediately upon its registration, and one struct video_device per 
> _client_ platform device.

Ok understood.

> 
> 2. we currently have 1 or 2 boards in the mainline with two video client 
> devices on one interface: arch/sh/boards/mach-migor/ and (unsure about) 
> arch/sh/boards/board-ap325rxa.c. At least the first of them exports two 
> platform devices and thus gets /dev/video[01]. Accesses are synchronised 
> with a mutex (I don't actually like that, I'd prefer to get a -EBUSY back 
> instead of hanging in D in open()), and a successful acquisition of the 
> mutex switches the respective camera on. See code for details. So, this 
> approach is supported and it works. In this case we have one v4l2_device 
> and two video_device instances, don't know whether this matches how this 
> is supposed to be done, but it works so far:-)

I am going to stick to this approach since it works now. This would 
allow me to have code that could go now into mainline.

> 
> 3. to support switching inputs, significant modifications to soc_camera.c 
> would be required. I read Nate's argument before, that as long as clients 
> can only be accessed one at a time, this should be presented by multiple 
> inputs rather than multiple device nodes. Somebody else from the V4L folk 
> has also confirmed this opinion. In principle I don't feel strongly either 
> way. But currently soc-camera uses a one i2c client to one device node 
> model, and I'm somewhat reluctant to change this before we're done with 
> the v4l2-subdev conversion.
> 

Sure, one step at a time. So for now the switching is not possible with 
soc_camera.

My problem is that both cameras have the same I2C address since they are 
the same.

Would I need to declare 2 i2c_device with the same address (I'm not sure 
it would even work ...) used by two _client_ platform_devices or would I 
have to have the two platform devices pointing to the same i2c_device ?

Thanks

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne

[PATCH 5/6] mx31moboard: camera support

[Valentin Longchamp]

Hi Guennadi,

Thanks for your input about the patch. I haven't had time to answer you 
before.

Guennadi Liakhovetski wrote:
> Hi Val
> 
> below are some comments to the patch, I'll also reply to your /dev/video* 
> question in a separate mail.

I answered you in a separate email too.

> 
> On Thu, 15 Oct 2009, Valentin Longchamp wrote:
> 
>> We have two mt9t031 cameras that have a muxed bus on the robot.
>> We can control which one we are using with gpio outputs. This
>> currently is not optimal
>>
>> Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
>> ---
>>  arch/arm/mach-mx3/mx31moboard-marxbot.c |   78 ++++++++++++++++++++++++++++++-
>>  arch/arm/mach-mx3/mx31moboard.c         |   37 ++++++++++++++-
>>  2 files changed, 113 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-mx3/mx31moboard-marxbot.c b/arch/arm/mach-mx3/mx31moboard-marxbot.c
>> index 49d47ab..303cbdb 100644
>> --- a/arch/arm/mach-mx3/mx31moboard-marxbot.c
>> +++ b/arch/arm/mach-mx3/mx31moboard-marxbot.c
>> @@ -16,9 +16,11 @@
>>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>>   */
>>  
>> +#include <linux/delay.h>
>>  #include <linux/gpio.h>
>>  #include <linux/init.h>
>>  #include <linux/interrupt.h>
>> +#include <linux/i2c.h>
>>  #include <linux/platform_device.h>
>>  #include <linux/types.h>
>>  
>> @@ -28,6 +30,8 @@
>>  #include <mach/iomux-mx3.h>
>>  #include <mach/mmc.h>
>>  
>> +#include <media/soc_camera.h>
>> +
>>  #include "devices.h"
>>  
>>  static unsigned int marxbot_pins[] = {
>> @@ -37,7 +41,6 @@ static unsigned int marxbot_pins[] = {
>>  	MX31_PIN_PC_CD2_B__SD2_CLK, MX31_PIN_PC_CD1_B__SD2_CMD,
>>  	MX31_PIN_ATA_DIOR__GPIO3_28, MX31_PIN_ATA_DIOW__GPIO3_29,
>>  	/* CSI */
>> -	MX31_PIN_CSI_D4__CSI_D4, MX31_PIN_CSI_D5__CSI_D5,
>>  	MX31_PIN_CSI_D6__CSI_D6, MX31_PIN_CSI_D7__CSI_D7,
>>  	MX31_PIN_CSI_D8__CSI_D8, MX31_PIN_CSI_D9__CSI_D9,
>>  	MX31_PIN_CSI_D10__CSI_D10, MX31_PIN_CSI_D11__CSI_D11,
>> @@ -45,6 +48,7 @@ static unsigned int marxbot_pins[] = {
>>  	MX31_PIN_CSI_D14__CSI_D14, MX31_PIN_CSI_D15__CSI_D15,
>>  	MX31_PIN_CSI_HSYNC__CSI_HSYNC, MX31_PIN_CSI_MCLK__CSI_MCLK,
>>  	MX31_PIN_CSI_PIXCLK__CSI_PIXCLK, MX31_PIN_CSI_VSYNC__CSI_VSYNC,
>> +	MX31_PIN_CSI_D4__GPIO3_4, MX31_PIN_CSI_D5__GPIO3_5,
>>  	MX31_PIN_GPIO3_0__GPIO3_0, MX31_PIN_GPIO3_1__GPIO3_1,
>>  	MX31_PIN_TXD2__GPIO1_28,
>>  	/* dsPIC resets */
>> @@ -122,6 +126,78 @@ static void dspics_resets_init(void)
>>  	}
>>  }
>>  
>> +#define TURRETCAM_POWER	IOMUX_TO_GPIO(MX31_PIN_GPIO3_1)
>> +#define BASECAM_POWER	IOMUX_TO_GPIO(MX31_PIN_CSI_D5)
>> +#define TURRETCAM_RST_B	IOMUX_TO_GPIO(MX31_PIN_GPIO3_0)
>> +#define BASECAM_RST_B	IOMUX_TO_GPIO(MX31_PIN_CSI_D4)
>> +#define CAM_CHOICE	IOMUX_TO_GPIO(MX31_PIN_TXD2)
>> +
>> +static int marxbot_cam_power(struct device *dev, int on)
>> +{
>> +	gpio_set_value(BASECAM_POWER, !on);
>> +	return 0;
>> +}
>> +
>> +static int marxbot_cam_reset(struct device *dev)
>> +{
>> +	gpio_set_value(BASECAM_RST_B, 0);
>> +	udelay(100);
>> +	gpio_set_value(BASECAM_RST_B, 1);
>> +	return 0;
>> +}
>> +
>> +static struct i2c_board_info marxbot_i2c_devices[] = {
>> +	{
>> +		I2C_BOARD_INFO("mt9t031", 0x5d),
>> +	},
>> +};
>> +
>> +static struct soc_camera_link iclink = {
>> +	.bus_id		= 0,		/* Must match with the camera ID */
>> +	.power		= marxbot_cam_power,
>> +	.reset		= marxbot_cam_reset,
>> +	.board_info	= &marxbot_i2c_devices[0],
>> +	.i2c_adapter_id	= 0,
>> +	.module_name	= "mt9t031",
>> +};
>> +
>> +static struct platform_device marxbot_camera = {
>> +	.name	= "soc-camera-pdrv",
>> +	.id	= 0,
>> +	.dev	= {
>> +		.platform_data = &iclink,
>> +	},
>> +};
>> +
>> +static int __init marxbot_cam_init(void)
>> +{
>> +	int ret = gpio_request(CAM_CHOICE, "cam-choice");
>> +	if (ret)
>> +		return ret;
>> +	gpio_direction_output(CAM_CHOICE, 1);
>> +	gpio_export(CAM_CHOICE, false);
> 
> Why are exporting this and two more gpios below? Does this allow you to 
> switch cameras from the user-space? Even if so, I wouldn't push this 
> upstream, as you won't need this in the future, when you add proper 
> support for the second camera into the kernel.

Yeah, the purpose of this is to allow to switch camera from userspace. 
But you are maybe right, I should not push the export to upstream but 
keep it in a local patch while waiting for a solution to switch in the 
kernel.

The other gpios below would not be exported anyomore but used by the 
second _client_ video platform_device (and should disappear in the next 
version of the patch).

> 
>> +	ret = gpio_request(BASECAM_RST_B, "basecam-reset");
>> +	if (ret)
>> +		return ret;
>> +	gpio_direction_output(BASECAM_RST_B, 1);
>> +	ret = gpio_request(BASECAM_POWER, "basecam-standby");
>> +	if (ret)
>> +		return ret;
>> +	gpio_direction_output(BASECAM_POWER, 0);
>> +
>> +	/*temporary part: we must use the mux better*/
> 
> Please, add spaces around text in comment.
> 
>> +	gpio_request(TURRETCAM_RST_B, "turretcam-reset");
>> +	gpio_direction_output(TURRETCAM_RST_B, 1);
>> +	gpio_export(TURRETCAM_RST_B, false);
>> +
>> +	gpio_request(TURRETCAM_POWER, "turretcam-standby");
>> +	gpio_direction_output(TURRETCAM_POWER, 0);
>> +	gpio_export(TURRETCAM_POWER, false);
>> +
>> +	return platform_device_register(&marxbot_camera);
>> +}
>> +
>> +
>>  /*
>>   * system init for baseboard usage. Will be called by mx31moboard init.
>>   */
>> diff --git a/arch/arm/mach-mx3/mx31moboard.c b/arch/arm/mach-mx3/mx31moboard.c
>> index 706a993..605c0fa 100644
>> --- a/arch/arm/mach-mx3/mx31moboard.c
>> +++ b/arch/arm/mach-mx3/mx31moboard.c
>> @@ -40,7 +40,7 @@
>>  #include <mach/ipu.h>
>>  #include <mach/i2c.h>
>>  #include <mach/mmc.h>
>> -#include <mach/mx31.h>
>> +#include <mach/mx3_camera.h>
> 
> Need
> 
> #include <linux/dma-mapping.h>
> 
> for DMA_MEMORY_MAP and DMA_MEMORY_EXCLUSIVE macros, etc.

correct. It must have been melted in another patch, I have to revise the 
patch stack.

> 
>>  
>>  #include "devices.h"
>>  
>> @@ -287,6 +287,39 @@ static struct platform_device *devices[] __initdata = {
>>  	&mx31moboard_leds_device,
>>  };
>>  
>> +static struct mx3_camera_pdata camera_pdata = {
>> +	.dma_dev	= &mx3_ipu.dev,
>> +	.flags		= MX3_CAMERA_DATAWIDTH_8 | MX3_CAMERA_DATAWIDTH_10,
>> +	.mclk_10khz	= 4800,
>> +};
>> +
>> +#define CAMERA_BUF_SIZE	(4*1024*1024)
>> +
>> +static int __init mx31moboard_cam_alloc_dma(const size_t buf_size)
>> +{
>> +	dma_addr_t dma_handle;
>> +	void *buf;
>> +	int dma;
>> +
>> +	if (buf_size < 2 * 1024 * 1024)
>> +		return -EINVAL;
>> +
>> +	buf = dma_alloc_coherent(NULL, buf_size, &dma_handle, GFP_KERNEL);
>> +	if (!buf) {
>> +		pr_err("%s: cannot allocate camera buffer-memory\n", __func__);
>> +		return -ENOMEM;
>> +	}
>> +
>> +	memset(buf, 0, buf_size);
>> +
>> +	dma = dma_declare_coherent_memory(&mx3_camera.dev,
>> +					dma_handle, dma_handle, buf_size,
>> +					DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
>> +
>> +	/* The way we call dma_declare_coherent_memory only a malloc can fail */
>> +	return dma & DMA_MEMORY_MAP ? 0 : -ENOMEM;
>> +}
>> +
>>  static int mx31moboard_baseboard;
>>  core_param(mx31moboard_baseboard, mx31moboard_baseboard, int, 0444);
>>  
>> @@ -312,6 +345,8 @@ static void __init mxc_board_init(void)
>>  	mxc_register_device(&mxcsdhc_device0, &sdhc1_pdata);
>>  
>>  	mxc_register_device(&mx3_ipu, &mx3_ipu_data);
>> +	if (!mx31moboard_cam_alloc_dma(CAMERA_BUF_SIZE))
>> +		mxc_register_device(&mx3_camera, &camera_pdata);
>>  
>>  	usb_xcvr_reset();
>>  
>> -- 

Thanks

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne

Re: [PATCH 5/6] mx31moboard: camera support

[Valentin Longchamp]

Hi Guennadi,

Valentin Longchamp wrote:
> Guennadi Liakhovetski wrote:
> 
>> 3. to support switching inputs, significant modifications to soc_camera.c 
>> would be required. I read Nate's argument before, that as long as clients 
>> can only be accessed one at a time, this should be presented by multiple 
>> inputs rather than multiple device nodes. Somebody else from the V4L folk 
>> has also confirmed this opinion. In principle I don't feel strongly either 
>> way. But currently soc-camera uses a one i2c client to one device node 
>> model, and I'm somewhat reluctant to change this before we're done with 
>> the v4l2-subdev conversion.
>>
> 
> Sure, one step at a time. So for now the switching is not possible with 
> soc_camera.
> 
> My problem is that both cameras have the same I2C address since they are 
> the same.
> 
> Would I need to declare 2 i2c_device with the same address (I'm not sure 
> it would even work ...) used by two _client_ platform_devices or would I 
> have to have the two platform devices pointing to the same i2c_device ?
> 

I've finally had time to test all this. My current problem with 
registering the two cameras is that they both have the same i2c address, 
and soc_camera calls v4l2_i2c_new_subdev_board where in my case the same 
address on the same i2c tries to be registered and of course fails.

We would need a way in soc_camera not to register a new i2c client for 
device but use an existing one (but that's what you don't want to change 
for now as you state it in your above last sentence). I just want to 
point this out once more so that you know there is interest about this 
for the next soc_camera works.

So my current solution for mainline inclusion is to register only one 
camera device node without taking care of the cam mux for now.

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp@epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne

[PATCH 5/6] mx31moboard: camera support

[Valentin Longchamp]

Hi Guennadi,

Valentin Longchamp wrote:
> Guennadi Liakhovetski wrote:
> 
>> 3. to support switching inputs, significant modifications to soc_camera.c 
>> would be required. I read Nate's argument before, that as long as clients 
>> can only be accessed one at a time, this should be presented by multiple 
>> inputs rather than multiple device nodes. Somebody else from the V4L folk 
>> has also confirmed this opinion. In principle I don't feel strongly either 
>> way. But currently soc-camera uses a one i2c client to one device node 
>> model, and I'm somewhat reluctant to change this before we're done with 
>> the v4l2-subdev conversion.
>>
> 
> Sure, one step at a time. So for now the switching is not possible with 
> soc_camera.
> 
> My problem is that both cameras have the same I2C address since they are 
> the same.
> 
> Would I need to declare 2 i2c_device with the same address (I'm not sure 
> it would even work ...) used by two _client_ platform_devices or would I 
> have to have the two platform devices pointing to the same i2c_device ?
> 

I've finally had time to test all this. My current problem with 
registering the two cameras is that they both have the same i2c address, 
and soc_camera calls v4l2_i2c_new_subdev_board where in my case the same 
address on the same i2c tries to be registered and of course fails.

We would need a way in soc_camera not to register a new i2c client for 
device but use an existing one (but that's what you don't want to change 
for now as you state it in your above last sentence). I just want to 
point this out once more so that you know there is interest about this 
for the next soc_camera works.

So my current solution for mainline inclusion is to register only one 
camera device node without taking care of the cam mux for now.

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne

Re: [PATCH 5/6] mx31moboard: camera support

[Guennadi Liakhovetski]

On Tue, 3 Nov 2009, Valentin Longchamp wrote:

> Hi Guennadi,
> 
> Valentin Longchamp wrote:
> > Guennadi Liakhovetski wrote:
> > 
> > > 3. to support switching inputs, significant modifications to soc_camera.c
> > > would be required. I read Nate's argument before, that as long as clients
> > > can only be accessed one at a time, this should be presented by multiple
> > > inputs rather than multiple device nodes. Somebody else from the V4L folk
> > > has also confirmed this opinion. In principle I don't feel strongly either
> > > way. But currently soc-camera uses a one i2c client to one device node
> > > model, and I'm somewhat reluctant to change this before we're done with
> > > the v4l2-subdev conversion.
> > > 
> > 
> > Sure, one step at a time. So for now the switching is not possible with
> > soc_camera.
> > 
> > My problem is that both cameras have the same I2C address since they are the
> > same.
> > 
> > Would I need to declare 2 i2c_device with the same address (I'm not sure it
> > would even work ...) used by two _client_ platform_devices or would I have
> > to have the two platform devices pointing to the same i2c_device ?
> > 
> 
> I've finally had time to test all this. My current problem with registering
> the two cameras is that they both have the same i2c address, and soc_camera
> calls v4l2_i2c_new_subdev_board where in my case the same address on the same
> i2c tries to be registered and of course fails.
> 
> We would need a way in soc_camera not to register a new i2c client for device
> but use an existing one (but that's what you don't want to change for now as
> you state it in your above last sentence). I just want to point this out once
> more so that you know there is interest about this for the next soc_camera
> works.

These are two separate issues: inability to work with two devices with the 
same i2c address, and arguably suboptimal choice of the way to switch 
between multiple mutually-exclusive clients (sensors) on a single 
interface.

For multiple chips with the same adderess, in principle you could register 
one or more video devices yet before registering respective i2c devices. 
And then on the selected switching operation (either opening of one of the 
/dev/video* nodes, or selecting an input) you register the i2c device, 
probe it, etc. This would work, but looks seriously overengineered to me. 
And it would indeed require pretty fundamental changes to the soc-camera 
core.

Otherwise we could push this switching down into the driver / platform. We 
could just export only one camera from the platform code, implement a 
S_INPUT method in soc-camera, that would be delivered to the sensor 
driver, it would save context of the current sensor, call the platform 
hook to switch to another camera, and restore its configuration. In this 
case the soc-camera core and the host driver would not see two sensors, 
but just one, all the switching would be done internally in the sensor 
driver / platform callback.

If we also decide to use S_INPUT to switch between different sensors on an 
interface, we would have to make a distinction between two cases in the 
core - whether the input we're switching to belongs to the "same" sensor 
or to another one.

> So my current solution for mainline inclusion is to register only one camera
> device node without taking care of the cam mux for now.

Yes, please, send me an updated version of the patch. I think, you haven't 
done that yet, right?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[PATCH 5/6] mx31moboard: camera support

[Guennadi Liakhovetski]

On Tue, 3 Nov 2009, Valentin Longchamp wrote:

> Hi Guennadi,
> 
> Valentin Longchamp wrote:
> > Guennadi Liakhovetski wrote:
> > 
> > > 3. to support switching inputs, significant modifications to soc_camera.c
> > > would be required. I read Nate's argument before, that as long as clients
> > > can only be accessed one at a time, this should be presented by multiple
> > > inputs rather than multiple device nodes. Somebody else from the V4L folk
> > > has also confirmed this opinion. In principle I don't feel strongly either
> > > way. But currently soc-camera uses a one i2c client to one device node
> > > model, and I'm somewhat reluctant to change this before we're done with
> > > the v4l2-subdev conversion.
> > > 
> > 
> > Sure, one step at a time. So for now the switching is not possible with
> > soc_camera.
> > 
> > My problem is that both cameras have the same I2C address since they are the
> > same.
> > 
> > Would I need to declare 2 i2c_device with the same address (I'm not sure it
> > would even work ...) used by two _client_ platform_devices or would I have
> > to have the two platform devices pointing to the same i2c_device ?
> > 
> 
> I've finally had time to test all this. My current problem with registering
> the two cameras is that they both have the same i2c address, and soc_camera
> calls v4l2_i2c_new_subdev_board where in my case the same address on the same
> i2c tries to be registered and of course fails.
> 
> We would need a way in soc_camera not to register a new i2c client for device
> but use an existing one (but that's what you don't want to change for now as
> you state it in your above last sentence). I just want to point this out once
> more so that you know there is interest about this for the next soc_camera
> works.

These are two separate issues: inability to work with two devices with the 
same i2c address, and arguably suboptimal choice of the way to switch 
between multiple mutually-exclusive clients (sensors) on a single 
interface.

For multiple chips with the same adderess, in principle you could register 
one or more video devices yet before registering respective i2c devices. 
And then on the selected switching operation (either opening of one of the 
/dev/video* nodes, or selecting an input) you register the i2c device, 
probe it, etc. This would work, but looks seriously overengineered to me. 
And it would indeed require pretty fundamental changes to the soc-camera 
core.

Otherwise we could push this switching down into the driver / platform. We 
could just export only one camera from the platform code, implement a 
S_INPUT method in soc-camera, that would be delivered to the sensor 
driver, it would save context of the current sensor, call the platform 
hook to switch to another camera, and restore its configuration. In this 
case the soc-camera core and the host driver would not see two sensors, 
but just one, all the switching would be done internally in the sensor 
driver / platform callback.

If we also decide to use S_INPUT to switch between different sensors on an 
interface, we would have to make a distinction between two cases in the 
core - whether the input we're switching to belongs to the "same" sensor 
or to another one.

> So my current solution for mainline inclusion is to register only one camera
> device node without taking care of the cam mux for now.

Yes, please, send me an updated version of the patch. I think, you haven't 
done that yet, right?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/6] mx31moboard: camera support

[Valentin Longchamp]

Guennadi Liakhovetski wrote:
> On Tue, 3 Nov 2009, Valentin Longchamp wrote:
> 
>> Hi Guennadi,
>>
>> Valentin Longchamp wrote:
>>> Guennadi Liakhovetski wrote:
>>>
>>>> 3. to support switching inputs, significant modifications to soc_camera.c
>>>> would be required. I read Nate's argument before, that as long as clients
>>>> can only be accessed one at a time, this should be presented by multiple
>>>> inputs rather than multiple device nodes. Somebody else from the V4L folk
>>>> has also confirmed this opinion. In principle I don't feel strongly either
>>>> way. But currently soc-camera uses a one i2c client to one device node
>>>> model, and I'm somewhat reluctant to change this before we're done with
>>>> the v4l2-subdev conversion.
>>>>
>>> Sure, one step at a time. So for now the switching is not possible with
>>> soc_camera.
>>>
>>> My problem is that both cameras have the same I2C address since they are the
>>> same.
>>>
>>> Would I need to declare 2 i2c_device with the same address (I'm not sure it
>>> would even work ...) used by two _client_ platform_devices or would I have
>>> to have the two platform devices pointing to the same i2c_device ?
>>>
>> I've finally had time to test all this. My current problem with registering
>> the two cameras is that they both have the same i2c address, and soc_camera
>> calls v4l2_i2c_new_subdev_board where in my case the same address on the same
>> i2c tries to be registered and of course fails.
>>
>> We would need a way in soc_camera not to register a new i2c client for device
>> but use an existing one (but that's what you don't want to change for now as
>> you state it in your above last sentence). I just want to point this out once
>> more so that you know there is interest about this for the next soc_camera
>> works.
> 
> These are two separate issues: inability to work with two devices with the 
> same i2c address, and arguably suboptimal choice of the way to switch 
> between multiple mutually-exclusive clients (sensors) on a single 
> interface.
> 
> For multiple chips with the same adderess, in principle you could register 
> one or more video devices yet before registering respective i2c devices. 
> And then on the selected switching operation (either opening of one of the 
> /dev/video* nodes, or selecting an input) you register the i2c device, 
> probe it, etc. This would work, but looks seriously overengineered to me. 
> And it would indeed require pretty fundamental changes to the soc-camera 
> core.

Yeah I had noticed that this was possible by not calling 
i2c_register_device (or some like that) is soc_camera.c and give the i2c 
device directly to the soc_camera client device init method, but since 
this requires changes in the soc_camera core code that you are currently 
heavily modifying, I did not find it usefull.

> 
> Otherwise we could push this switching down into the driver / platform. We 
> could just export only one camera from the platform code, implement a 
> S_INPUT method in soc-camera, that would be delivered to the sensor 
> driver, it would save context of the current sensor, call the platform 
> hook to switch to another camera, and restore its configuration. In this 
> case the soc-camera core and the host driver would not see two sensors, 
> but just one, all the switching would be done internally in the sensor 
> driver / platform callback.
> 
> If we also decide to use S_INPUT to switch between different sensors on an 
> interface, we would have to make a distinction between two cases in the 
> core - whether the input we're switching to belongs to the "same" sensor 
> or to another one.

Leaving the the camera switch to platform code looks very important to me.

Having only one camera exported looks fine to me, especially since I 
have both cameras the same (but I don't think it would be possible with 
two different sensors ?). But I don't know v4l2 API well enough to see 
when it would be used to switch to an input on the same physical sensor.

> 
>> So my current solution for mainline inclusion is to register only one camera
>> device node without taking care of the cam mux for now.
> 
> Yes, please, send me an updated version of the patch. I think, you haven't 
> done that yet, right?

I have the updated version, I have however forgotten to add you in the 
recipient list, have a look on the arm-mailing-list: 
http://article.gmane.org/gmane.linux.ports.arm.kernel/68123

Thanks for all your comments

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp@epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne

[PATCH 5/6] mx31moboard: camera support

[Valentin Longchamp]

Guennadi Liakhovetski wrote:
> On Tue, 3 Nov 2009, Valentin Longchamp wrote:
> 
>> Hi Guennadi,
>>
>> Valentin Longchamp wrote:
>>> Guennadi Liakhovetski wrote:
>>>
>>>> 3. to support switching inputs, significant modifications to soc_camera.c
>>>> would be required. I read Nate's argument before, that as long as clients
>>>> can only be accessed one at a time, this should be presented by multiple
>>>> inputs rather than multiple device nodes. Somebody else from the V4L folk
>>>> has also confirmed this opinion. In principle I don't feel strongly either
>>>> way. But currently soc-camera uses a one i2c client to one device node
>>>> model, and I'm somewhat reluctant to change this before we're done with
>>>> the v4l2-subdev conversion.
>>>>
>>> Sure, one step at a time. So for now the switching is not possible with
>>> soc_camera.
>>>
>>> My problem is that both cameras have the same I2C address since they are the
>>> same.
>>>
>>> Would I need to declare 2 i2c_device with the same address (I'm not sure it
>>> would even work ...) used by two _client_ platform_devices or would I have
>>> to have the two platform devices pointing to the same i2c_device ?
>>>
>> I've finally had time to test all this. My current problem with registering
>> the two cameras is that they both have the same i2c address, and soc_camera
>> calls v4l2_i2c_new_subdev_board where in my case the same address on the same
>> i2c tries to be registered and of course fails.
>>
>> We would need a way in soc_camera not to register a new i2c client for device
>> but use an existing one (but that's what you don't want to change for now as
>> you state it in your above last sentence). I just want to point this out once
>> more so that you know there is interest about this for the next soc_camera
>> works.
> 
> These are two separate issues: inability to work with two devices with the 
> same i2c address, and arguably suboptimal choice of the way to switch 
> between multiple mutually-exclusive clients (sensors) on a single 
> interface.
> 
> For multiple chips with the same adderess, in principle you could register 
> one or more video devices yet before registering respective i2c devices. 
> And then on the selected switching operation (either opening of one of the 
> /dev/video* nodes, or selecting an input) you register the i2c device, 
> probe it, etc. This would work, but looks seriously overengineered to me. 
> And it would indeed require pretty fundamental changes to the soc-camera 
> core.

Yeah I had noticed that this was possible by not calling 
i2c_register_device (or some like that) is soc_camera.c and give the i2c 
device directly to the soc_camera client device init method, but since 
this requires changes in the soc_camera core code that you are currently 
heavily modifying, I did not find it usefull.

> 
> Otherwise we could push this switching down into the driver / platform. We 
> could just export only one camera from the platform code, implement a 
> S_INPUT method in soc-camera, that would be delivered to the sensor 
> driver, it would save context of the current sensor, call the platform 
> hook to switch to another camera, and restore its configuration. In this 
> case the soc-camera core and the host driver would not see two sensors, 
> but just one, all the switching would be done internally in the sensor 
> driver / platform callback.
> 
> If we also decide to use S_INPUT to switch between different sensors on an 
> interface, we would have to make a distinction between two cases in the 
> core - whether the input we're switching to belongs to the "same" sensor 
> or to another one.

Leaving the the camera switch to platform code looks very important to me.

Having only one camera exported looks fine to me, especially since I 
have both cameras the same (but I don't think it would be possible with 
two different sensors ?). But I don't know v4l2 API well enough to see 
when it would be used to switch to an input on the same physical sensor.

> 
>> So my current solution for mainline inclusion is to register only one camera
>> device node without taking care of the cam mux for now.
> 
> Yes, please, send me an updated version of the patch. I think, you haven't 
> done that yet, right?

I have the updated version, I have however forgotten to add you in the 
recipient list, have a look on the arm-mailing-list: 
http://article.gmane.org/gmane.linux.ports.arm.kernel/68123

Thanks for all your comments

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne