* [PATCH 0/4] Support for the HTKW mcx board
@ 2011-11-09 0:12 Ilya Yanok
2011-11-09 0:12 ` [PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx Ilya Yanok
` (3 more replies)
0 siblings, 4 replies; 27+ messages in thread
From: Ilya Yanok @ 2011-11-09 0:12 UTC (permalink / raw)
To: linux-omap; +Cc: wd, dzu, sasha_d, Ilya Yanok
Hello All,
these patches add support for HTKW mcx board (TI AM3517 based). This
includes fix for the DSS driver to work on 35xx, new panel type support
and some minor cleanup in common dtsi files (not all OMAP3 SoCs have
IVA).
Last patch needs updated mach-types file and relies on EDT touchscreen
driver posted to the linux-input ML:
http://thread.gmane.org/gmane.linux.kernel.input/22356
To boot successfully, these patches have to be applied:
https://lkml.org/lkml/2011/9/30/414
https://lkml.org/lkml/2011/9/30/34
Regards, Ilya.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx
2011-11-09 0:12 [PATCH 0/4] Support for the HTKW mcx board Ilya Yanok
@ 2011-11-09 0:12 ` Ilya Yanok
2011-11-09 10:10 ` Archit Taneja
2011-11-09 0:12 ` [PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support Ilya Yanok
` (2 subsequent siblings)
3 siblings, 1 reply; 27+ messages in thread
From: Ilya Yanok @ 2011-11-09 0:12 UTC (permalink / raw)
To: linux-omap; +Cc: wd, dzu, sasha_d, Ilya Yanok
AM35xx don't have VDDS_DSI regulator.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
drivers/video/omap2/dss/dpi.c | 9 +++++----
drivers/video/omap2/dss/dsi.c | 18 ++++++++++++------
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 976ac23..929e451 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -191,7 +191,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
goto err_start_dev;
}
- if (cpu_is_omap34xx()) {
+ if (cpu_is_omap34xx() && !cpu_is_omap3505() && !cpu_is_omap3517()) {
r = regulator_enable(dpi.vdds_dsi_reg);
if (r)
goto err_reg_enable;
@@ -238,7 +238,7 @@ err_get_dsi:
err_get_dispc:
dss_runtime_put();
err_get_dss:
- if (cpu_is_omap34xx())
+ if (cpu_is_omap34xx() && !cpu_is_omap3505() && !cpu_is_omap3517())
regulator_disable(dpi.vdds_dsi_reg);
err_reg_enable:
omap_dss_stop_device(dssdev);
@@ -260,7 +260,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device *dssdev)
dispc_runtime_put();
dss_runtime_put();
- if (cpu_is_omap34xx())
+ if (cpu_is_omap34xx() && !cpu_is_omap3505() && !cpu_is_omap3517())
regulator_disable(dpi.vdds_dsi_reg);
omap_dss_stop_device(dssdev);
@@ -348,7 +348,8 @@ int dpi_init_display(struct omap_dss_device *dssdev)
{
DSSDBG("init_display\n");
- if (cpu_is_omap34xx() && dpi.vdds_dsi_reg == NULL) {
+ if (cpu_is_omap34xx() && (dpi.vdds_dsi_reg == NULL) &&
+ !cpu_is_omap3505() && !cpu_is_omap3517()) {
struct regulator *vdds_dsi;
vdds_dsi = dss_get_vdds_dsi();
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 5abf8e7..7f38ab6 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1610,7 +1610,8 @@ int dsi_pll_init(struct platform_device *dsidev, bool enable_hsclk,
DSSDBG("PLL init\n");
- if (dsi->vdds_dsi_reg == NULL) {
+ if ((dsi->vdds_dsi_reg == NULL) &&
+ !cpu_is_omap3517() && !cpu_is_omap3505()) {
struct regulator *vdds_dsi;
vdds_dsi = regulator_get(&dsi->pdev->dev, "vdds_dsi");
@@ -1629,7 +1630,8 @@ int dsi_pll_init(struct platform_device *dsidev, bool enable_hsclk,
*/
dsi_enable_scp_clk(dsidev);
- if (!dsi->vdds_dsi_enabled) {
+ if (!dsi->vdds_dsi_enabled &&
+ !cpu_is_omap3517() && !cpu_is_omap3505()) {
r = regulator_enable(dsi->vdds_dsi_reg);
if (r)
goto err0;
@@ -1668,7 +1670,8 @@ int dsi_pll_init(struct platform_device *dsidev, bool enable_hsclk,
return 0;
err1:
- if (dsi->vdds_dsi_enabled) {
+ if (dsi->vdds_dsi_enabled &&
+ !cpu_is_omap3517() && !cpu_is_omap3505()) {
regulator_disable(dsi->vdds_dsi_reg);
dsi->vdds_dsi_enabled = false;
}
@@ -1684,7 +1687,8 @@ void dsi_pll_uninit(struct platform_device *dsidev, bool disconnect_lanes)
dsi->pll_locked = 0;
dsi_pll_power(dsidev, DSI_PLL_POWER_OFF);
- if (disconnect_lanes) {
+ if (disconnect_lanes &&
+ !cpu_is_omap3517() && !cpu_is_omap3505()) {
WARN_ON(!dsi->vdds_dsi_enabled);
regulator_disable(dsi->vdds_dsi_reg);
dsi->vdds_dsi_enabled = false;
@@ -4530,7 +4534,8 @@ int dsi_init_display(struct omap_dss_device *dssdev)
OMAP_DSS_DISPLAY_CAP_TEAR_ELIM;
}
- if (dsi->vdds_dsi_reg == NULL) {
+ if ((dsi->vdds_dsi_reg == NULL) &&
+ !cpu_is_omap3517() && !cpu_is_omap3505()) {
struct regulator *vdds_dsi;
vdds_dsi = regulator_get(&dsi->pdev->dev, "vdds_dsi");
@@ -4799,7 +4804,8 @@ static int omap_dsihw_remove(struct platform_device *dsidev)
dsi_put_clocks(dsidev);
- if (dsi->vdds_dsi_reg != NULL) {
+ if ((dsi->vdds_dsi_reg != NULL) &&
+ !cpu_is_omap3517() && !cpu_is_omap3505()) {
if (dsi->vdds_dsi_enabled) {
regulator_disable(dsi->vdds_dsi_reg);
dsi->vdds_dsi_enabled = false;
--
1.7.6.4
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support
2011-11-09 0:12 [PATCH 0/4] Support for the HTKW mcx board Ilya Yanok
2011-11-09 0:12 ` [PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx Ilya Yanok
@ 2011-11-09 0:12 ` Ilya Yanok
2011-11-17 0:28 ` Ilya Yanok
2011-11-17 10:26 ` Tomi Valkeinen
2011-11-09 0:12 ` [PATCH 3/4] dts/omap3: split omap3.dtsi Ilya Yanok
2011-11-09 0:12 ` [PATCH 4/4] mcx: initial support for HTKW mcx board Ilya Yanok
3 siblings, 2 replies; 27+ messages in thread
From: Ilya Yanok @ 2011-11-09 0:12 UTC (permalink / raw)
To: linux-omap; +Cc: wd, dzu, sasha_d, Ilya Yanok
Add data for the FocalTech ETM070003DH6 display to the generic_dpi_panel
display driver.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
drivers/video/omap2/displays/panel-generic-dpi.c | 24 ++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
index 519c47d..42bfe47 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -297,6 +297,30 @@ static struct panel_config generic_dpi_panels[] = {
.name = "apollon",
},
+ /* FocalTech ETM070003DH6 */
+ {
+ {
+ .x_res = 800,
+ .y_res = 480,
+
+ .pixel_clock = 28000,
+
+ .hsw = 48,
+ .hfp = 40,
+ .hbp = 40,
+
+ .vsw = 3,
+ .vfp = 13,
+ .vbp = 29,
+ },
+ .acbi = 0x0,
+ .acb = 0x28,
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS,
+ .power_on_delay = 50,
+ .power_off_delay = 100,
+ .name = "focaltech_etm070003dh6",
+ },
};
struct panel_drv_data {
--
1.7.6.4
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH 3/4] dts/omap3: split omap3.dtsi
2011-11-09 0:12 [PATCH 0/4] Support for the HTKW mcx board Ilya Yanok
2011-11-09 0:12 ` [PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx Ilya Yanok
2011-11-09 0:12 ` [PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support Ilya Yanok
@ 2011-11-09 0:12 ` Ilya Yanok
2011-11-10 12:18 ` Igor Grinberg
2011-11-09 0:12 ` [PATCH 4/4] mcx: initial support for HTKW mcx board Ilya Yanok
3 siblings, 1 reply; 27+ messages in thread
From: Ilya Yanok @ 2011-11-09 0:12 UTC (permalink / raw)
To: linux-omap; +Cc: wd, dzu, sasha_d, Ilya Yanok
Split omap3.dtsi file into common part, OM3xxx specific part and
AM35xx specific part. For now the only difference is missing IVA node on
AM35xx.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
arch/arm/boot/dts/am35xx.dtsi | 15 +++++++++++++++
arch/arm/boot/dts/om3xxx.dtsi | 28 ++++++++++++++++++++++++++++
arch/arm/boot/dts/omap3-beagle.dts | 2 +-
arch/arm/boot/dts/omap3.dtsi | 9 ---------
4 files changed, 44 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/boot/dts/am35xx.dtsi
create mode 100644 arch/arm/boot/dts/om3xxx.dtsi
diff --git a/arch/arm/boot/dts/am35xx.dtsi b/arch/arm/boot/dts/am35xx.dtsi
new file mode 100644
index 0000000..0dbc69d
--- /dev/null
+++ b/arch/arm/boot/dts/am35xx.dtsi
@@ -0,0 +1,15 @@
+/*
+ * Device Tree Source for TI AM35xx SoCs
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "omap3.dtsi"
+
+/ {
+ compatible = "ti,am35xx", "ti,omap3";
+};
diff --git a/arch/arm/boot/dts/om3xxx.dtsi b/arch/arm/boot/dts/om3xxx.dtsi
new file mode 100644
index 0000000..e8a17dd
--- /dev/null
+++ b/arch/arm/boot/dts/om3xxx.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for TI OM3xxx SoCs
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "omap3.dtsi"
+
+/ {
+ /*
+ * The soc node represents the soc top level view. It is uses for IPs
+ * that are not memory mapped in the MPU view or for the MPU itself.
+ */
+ soc {
+ iva {
+ compatible = "ti,iva2.2";
+ ti,hwmods = "iva";
+
+ dsp {
+ compatible = "ti,omap3-c64";
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index 9486be6..63e4be1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ "omap3.dtsi"
+/include/ "om3xxx.dtsi"
/ {
model = "TI OMAP3 BeagleBoard";
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..2b12b0e 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -29,15 +29,6 @@
compatible = "ti,omap3-mpu";
ti,hwmods = "mpu";
};
-
- iva {
- compatible = "ti,iva2.2";
- ti,hwmods = "iva";
-
- dsp {
- compatible = "ti,omap3-c64";
- };
- };
};
/*
--
1.7.6.4
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH 4/4] mcx: initial support for HTKW mcx board
2011-11-09 0:12 [PATCH 0/4] Support for the HTKW mcx board Ilya Yanok
` (2 preceding siblings ...)
2011-11-09 0:12 ` [PATCH 3/4] dts/omap3: split omap3.dtsi Ilya Yanok
@ 2011-11-09 0:12 ` Ilya Yanok
2011-11-10 13:08 ` Igor Grinberg
` (2 more replies)
3 siblings, 3 replies; 27+ messages in thread
From: Ilya Yanok @ 2011-11-09 0:12 UTC (permalink / raw)
To: linux-omap; +Cc: wd, dzu, sasha_d, Ilya Yanok
Support for the HTKW mcx board (TI AM3517 based) including serial,
Ethernet, I2C, USB host, HSMMC, DSS and RTC.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
arch/arm/boot/dts/mcx.dts | 29 ++
arch/arm/mach-omap2/Kconfig | 5 +
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/board-mcx.c | 618 ++++++++++++++++++++++++++
arch/arm/plat-omap/include/plat/uncompress.h | 1 +
5 files changed, 656 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/mcx.dts
create mode 100644 arch/arm/mach-omap2/board-mcx.c
diff --git a/arch/arm/boot/dts/mcx.dts b/arch/arm/boot/dts/mcx.dts
new file mode 100644
index 0000000..c87df59
--- /dev/null
+++ b/arch/arm/boot/dts/mcx.dts
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, EmCraft Systems
+ *
+ * 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.
+ */
+/dts-v1/;
+
+/include/ "am35xx.dtsi"
+
+/ {
+ model = "HTKW mcx";
+ compatible = "htkw,mcx";
+
+ /*
+ * Since the initial device tree board file does not create any
+ * devices (MMC, network...), the only way to boot is to provide a
+ * ramdisk.
+ */
+ chosen {
+ bootargs = "root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x81600000,20M ramdisk_size=20480 no_console_suspend debug earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x10000000>; /* 256 MB */
+ };
+};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index c3d530b..3be9cc0 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -230,6 +230,11 @@ config MACH_OMAP_3430SDP
default y
select OMAP_PACKAGE_CBB
+config MACH_MCX
+ bool "htkw mcx board"
+ depends on ARCH_OMAP3
+ select OMAP_PACKAGE_CBB
+
config MACH_NOKIA_N800
bool
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 69ab1c0..913aa43 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -232,6 +232,9 @@ obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
+obj-$(CONFIG_MACH_MCX) += board-mcx.o \
+ omap_phy_internal.o \
+ hsmmc.o
# Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-mcx.c b/arch/arm/mach-omap2/board-mcx.c
new file mode 100644
index 0000000..311e1fb
--- /dev/null
+++ b/arch/arm/mach-omap2/board-mcx.c
@@ -0,0 +1,618 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/leds.h>
+#include <linux/gpio.h>
+#include <linux/input.h>
+#include <linux/gpio_keys.h>
+#include <linux/opp.h>
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/nand.h>
+#include <linux/mmc/host.h>
+
+#include <linux/regulator/machine.h>
+#include <linux/davinci_emac.h>
+#include <linux/i2c/edt_ts.h>
+
+#include <mach/hardware.h>
+#include <mach/am35xx.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/mach/flash.h>
+
+#include <plat/board.h>
+#include <plat/common.h>
+#include <plat/omap_hwmod.h>
+#include <video/omapdss.h>
+#include <video/omap-panel-generic-dpi.h>
+#include <plat/gpmc.h>
+#include <plat/nand.h>
+#include <plat/usb.h>
+#include <plat/omap_device.h>
+
+#include "mux.h"
+#include "control.h"
+#include "hsmmc.h"
+#include "common-board-devices.h"
+
+#define MCX_MDIO_FREQUENCY (1000000)
+
+static struct mdio_platform_data mcx_mdio_pdata = {
+ .bus_freq = MCX_MDIO_FREQUENCY,
+};
+
+static struct resource am3517_mdio_resources[] = {
+ {
+ .start = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
+ .end = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
+ SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device am3517_mdio_device = {
+ .name = "davinci_mdio",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(am3517_mdio_resources),
+ .resource = am3517_mdio_resources,
+ .dev.platform_data = &mcx_mdio_pdata,
+};
+
+static struct emac_platform_data mcx_emac_pdata = {
+ .rmii_en = 1,
+};
+
+static struct resource am3517_emac_resources[] = {
+ {
+ .start = AM35XX_IPSS_EMAC_BASE,
+ .end = AM35XX_IPSS_EMAC_BASE + 0x2FFFF,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+ .end = INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+ .end = INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = INT_35XX_EMAC_C0_TX_PULSE_IRQ,
+ .end = INT_35XX_EMAC_C0_TX_PULSE_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = INT_35XX_EMAC_C0_MISC_PULSE_IRQ,
+ .end = INT_35XX_EMAC_C0_MISC_PULSE_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device am3517_emac_device = {
+ .name = "davinci_emac",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(am3517_emac_resources),
+ .resource = am3517_emac_resources,
+};
+
+static void am3517_enable_ethernet_int(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_TX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_MISC_PULSE_CLR |
+ AM35XX_CPGMAC_C0_RX_THRESH_CLR);
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static void am3517_disable_ethernet_int(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_TX_PULSE_CLR);
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static void mcx_ethernet_init(struct emac_platform_data *pdata)
+{
+ unsigned int regval;
+
+ pdata->ctrl_reg_offset = AM35XX_EMAC_CNTRL_OFFSET;
+ pdata->ctrl_mod_reg_offset = AM35XX_EMAC_CNTRL_MOD_OFFSET;
+ pdata->ctrl_ram_offset = AM35XX_EMAC_CNTRL_RAM_OFFSET;
+ pdata->ctrl_ram_size = AM35XX_EMAC_CNTRL_RAM_SIZE;
+ pdata->version = EMAC_VERSION_2;
+ pdata->hw_ram_addr = AM35XX_EMAC_HW_RAM_ADDR;
+ pdata->interrupt_enable = am3517_enable_ethernet_int;
+ pdata->interrupt_disable = am3517_disable_ethernet_int;
+ am3517_emac_device.dev.platform_data = pdata;
+ platform_device_register(&am3517_emac_device);
+ platform_device_register(&am3517_mdio_device);
+ clk_add_alias(NULL, dev_name(&am3517_emac_device.dev),
+ "emac_clk", &am3517_emac_device.dev);
+ clk_add_alias(NULL, dev_name(&am3517_mdio_device.dev),
+ "phy_clk", &am3517_emac_device.dev);
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+ regval = regval & (~(AM35XX_CPGMACSS_SW_RST));
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+
+ return ;
+}
+
+static struct mtd_partition mcx_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = "X-Loader",
+ .offset = 0,
+ .size = 4 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE, /* force read-only */
+ },
+ {
+ .name = "U-Boot",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x80000 */
+ .size = 15 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE, /* force read-only */
+ },
+ {
+ .name = "U-Boot Env",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x260000 */
+ .size = 1 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "Kernel",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x280000 */
+ .size = 32 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "File System",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x680000 */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+#define LCD_PWR_ENn 131
+#define HDMI_TRCVR_PDn 133
+#define LCD_BKLIGHT_EN 55
+#define LCD_LVL_SFHT_BUF_ENn 43
+
+static int lcd_enabled;
+static int dvi_enabled;
+
+static int mcx_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ if (dvi_enabled) {
+ printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
+ return -EINVAL;
+ }
+
+ gpio_set_value(LCD_BKLIGHT_EN, 1);
+ lcd_enabled = 1;
+
+ return 0;
+}
+
+static void mcx_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(LCD_BKLIGHT_EN, 0);
+ lcd_enabled = 0;
+}
+
+static struct panel_generic_dpi_data lcd_panel = {
+ .name = "focaltech_etm070003dh6",
+ .platform_enable = mcx_panel_enable_lcd,
+ .platform_disable = mcx_panel_disable_lcd,
+};
+
+static struct omap_dss_device mcx_lcd_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "lcd",
+ .driver_name = "generic_dpi_panel",
+ .data = &lcd_panel,
+ .phy.dpi.data_lines = 24,
+};
+
+/*
+ * TV Output
+ */
+
+static int mcx_panel_enable_tv(struct omap_dss_device *dssdev)
+{
+ return 0;
+}
+
+static void mcx_panel_disable_tv(struct omap_dss_device *dssdev)
+{
+}
+
+static struct omap_dss_device mcx_tv_device = {
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .name = "tv",
+ .driver_name = "venc",
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+ .platform_enable = mcx_panel_enable_tv,
+ .platform_disable = mcx_panel_disable_tv,
+};
+
+/*
+ * DVI/HDMI Output
+ */
+
+static int mcx_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+ if (lcd_enabled) {
+ printk(KERN_ERR "cannot enable DVI, LCD is enabled\n");
+ return -EINVAL;
+ }
+ dvi_enabled = 1;
+ gpio_set_value(HDMI_TRCVR_PDn, 1);
+ return 0;
+}
+
+static void mcx_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+ dvi_enabled = 0;
+ gpio_set_value(HDMI_TRCVR_PDn, 0);
+}
+
+static struct panel_generic_dpi_data dvi_panel = {
+ .platform_enable = mcx_panel_enable_dvi,
+ .platform_disable = mcx_panel_disable_dvi,
+};
+static struct omap_dss_device mcx_dvi_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "dvi",
+ .driver_name = "dvi",
+ .data = &dvi_panel,
+ .phy.dpi.data_lines = 24,
+};
+
+static struct omap_dss_device *mcx_dss_devices[] = {
+ &mcx_lcd_device,
+ &mcx_tv_device,
+ &mcx_dvi_device,
+};
+
+static struct omap_dss_board_info mcx_dss_data = {
+ .num_devices = ARRAY_SIZE(mcx_dss_devices),
+ .devices = mcx_dss_devices,
+ .default_device = &mcx_lcd_device,
+};
+
+static void __init mcx_display_init(void)
+{
+ int r;
+
+ /* disable LCD backlight */
+ r = gpio_request(LCD_BKLIGHT_EN, "LCD_BKLIGHT_EN");
+ if (r) {
+ printk(KERN_ERR "failed to get LCD_BKLIGHT_EN gpio\n");
+ goto err_1;
+ }
+ omap_mux_init_gpio(LCD_BKLIGHT_EN, OMAP_PIN_OUTPUT);
+ gpio_direction_output(LCD_BKLIGHT_EN, 0);
+
+ /* Enable VIO-> 3.3v level shifter */
+ r = gpio_request(LCD_LVL_SFHT_BUF_ENn, "LCD_LVL_SFHT_BUF_ENn");
+ if (r) {
+ printk(KERN_ERR "failed to get LCD_LVL_SFHT_BUF_ENn gpio\n");
+ goto err_2;
+ }
+ omap_mux_init_gpio(LCD_LVL_SFHT_BUF_ENn, OMAP_PIN_OUTPUT);
+ gpio_direction_output(LCD_LVL_SFHT_BUF_ENn, 0);
+
+ /* Enable LCD panel VCC */
+
+ r = gpio_request(LCD_PWR_ENn, "LCD_PWR_ENn");
+ if (r) {
+ printk(KERN_ERR "failed to get LCD_PWR_ENn\n");
+ goto err_3;
+ }
+ omap_mux_init_gpio(LCD_PWR_ENn, OMAP_PIN_OUTPUT);
+
+ gpio_direction_output(LCD_PWR_ENn, 0);
+
+ /* Disable HDMI transceiver */
+ r = gpio_request(HDMI_TRCVR_PDn, "HDMI_TRCVR_PDn");
+ if (r) {
+ printk(KERN_ERR "failed to get HDMI_TRCVR_PDn\n");
+ goto err_4;
+ }
+ omap_mux_init_gpio(HDMI_TRCVR_PDn, OMAP_PIN_OUTPUT);
+ gpio_direction_output(HDMI_TRCVR_PDn, 0);
+
+ omap_display_init(&mcx_dss_data);
+
+ return;
+
+err_4:
+ gpio_free(HDMI_TRCVR_PDn);
+err_3:
+ gpio_free(LCD_LVL_SFHT_BUF_ENn);
+err_2:
+ gpio_free(LCD_LVL_SFHT_BUF_ENn);
+err_1:
+ gpio_free(LCD_BKLIGHT_EN);
+}
+
+/* TPS65023 specific initialization */
+/* VDCDC1 -> VDD_CORE */
+static struct regulator_consumer_supply am3517_vdcdc1_supplies[] = {
+ {
+ .supply = "vdd_core",
+ },
+};
+
+/* VDCDC2 -> VDDSHV */
+static struct regulator_consumer_supply am3517_vdcdc2_supplies[] = {
+ {
+ .supply = "vddshv",
+ },
+};
+
+/*
+ * VDCDC2 |-> VDDS
+ * |-> VDDS_SRAM_CORE_BG
+ * |-> VDDS_SRAM_MPU
+ */
+static struct regulator_consumer_supply am3517_vdcdc3_supplies[] = {
+ {
+ .supply = "vdds",
+ },
+ {
+ .supply = "vdds_sram_core_bg",
+ },
+ {
+ .supply = "vdds_sram_mpu",
+ },
+};
+
+/*
+ * LDO1 |-> VDDA1P8V_USBPHY
+ * |-> VDDA_DAC
+ */
+static struct regulator_consumer_supply am3517_ldo1_supplies[] = {
+ {
+ .supply = "vdda1p8v_usbphy",
+ },
+ {
+ .supply = "vdda_dac",
+ },
+};
+
+/* LDO2 -> VDDA3P3V_USBPHY */
+static struct regulator_consumer_supply am3517_ldo2_supplies[] = {
+ {
+ .supply = "vdda3p3v_usbphy",
+ },
+};
+
+static struct regulator_init_data mcx_regulator_data[] = {
+ /* DCDC1 */
+ {
+ .constraints = {
+ .min_uV = 1200000,
+ .max_uV = 1200000,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .always_on = true,
+ .apply_uV = false,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(am3517_vdcdc1_supplies),
+ .consumer_supplies = am3517_vdcdc1_supplies,
+ },
+ /* DCDC2 */
+ {
+ .constraints = {
+ .min_uV = 3300000,
+ .max_uV = 3300000,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .always_on = true,
+ .apply_uV = false,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(am3517_vdcdc2_supplies),
+ .consumer_supplies = am3517_vdcdc2_supplies,
+ },
+ /* DCDC3 */
+ {
+ .constraints = {
+ .min_uV = 1800000,
+ .max_uV = 1800000,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .always_on = true,
+ .apply_uV = false,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(am3517_vdcdc3_supplies),
+ .consumer_supplies = am3517_vdcdc3_supplies,
+ },
+ /* LDO1 */
+ {
+ .constraints = {
+ .min_uV = 1800000,
+ .max_uV = 1800000,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .always_on = false,
+ .apply_uV = false,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(am3517_ldo1_supplies),
+ .consumer_supplies = am3517_ldo1_supplies,
+ },
+ /* LDO2 */
+ {
+ .constraints = {
+ .min_uV = 3300000,
+ .max_uV = 3300000,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .always_on = false,
+ .apply_uV = false,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(am3517_ldo2_supplies),
+ .consumer_supplies = am3517_ldo2_supplies,
+ },
+};
+
+static struct i2c_board_info __initdata mcx_i2c1_devices[] = {
+ {
+ I2C_BOARD_INFO("ds1337", 0x68),
+ },
+ {
+ I2C_BOARD_INFO("tps65023", 0x48),
+ .flags = I2C_CLIENT_WAKE,
+ .platform_data = &mcx_regulator_data[0],
+ },
+};
+
+#define TOUCH_INT_GPIO 170
+
+static struct edt_platform_data edt_ts_data = {
+ .irq_gpio = TOUCH_INT_GPIO,
+};
+
+static int __init mcx_ts_init(void)
+{
+ struct i2c_board_info mcx_edt_ts[] = {
+ {
+ I2C_BOARD_INFO("edt_ts", 0x38),
+ .platform_data = &edt_ts_data,
+ },
+ };
+
+ if (gpio_request(TOUCH_INT_GPIO, "TOUCH_INT")) {
+ printk(KERN_ERR "failed to get TOUCH_INT gpio\n");
+ return 1;
+ }
+
+ gpio_direction_input(TOUCH_INT_GPIO);
+
+ i2c_register_board_info(3, mcx_edt_ts, 1);
+
+ return 0;
+}
+
+static int __init mcx_i2c_init(void)
+{
+ omap_register_i2c_bus(1, 400, mcx_i2c1_devices,
+ ARRAY_SIZE(mcx_i2c1_devices));
+ omap_register_i2c_bus(2, 400, NULL, 0);
+ omap_register_i2c_bus(3, 400, NULL, 0);
+ mcx_ts_init();
+ return 0;
+}
+
+#define USB_HOST_PWR_EN 132
+#define USB_PHY1_RESET 154
+#define USB_PHY2_RESET 152
+
+static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
+
+ .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
+ .port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
+ .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = USB_PHY1_RESET,
+ .reset_gpio_port[1] = USB_PHY2_RESET,
+ .reset_gpio_port[2] = -EINVAL
+};
+
+#define SD_CARD_WP 65
+
+static struct omap2_hsmmc_info mmc[] = {
+ {
+ .mmc = 1,
+ .caps = MMC_CAP_4_BIT_DATA,
+ .gpio_cd = -EINVAL,
+ .gpio_wp = SD_CARD_WP,
+ .ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34 |
+ MMC_VDD_165_195,
+ },
+ {} /* Terminator */
+};
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ OMAP3_MUX(CHASSIS_DMAREQ3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ OMAP3_MUX(UART1_TX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
+ OMAP_PULL_ENA | OMAP_PULL_UP),
+ OMAP3_MUX(UART1_RX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(UART1_CTS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
+ OMAP_PULL_ENA | OMAP_PULL_UP),
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#endif
+
+static void __init mcx_init(void)
+{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ mcx_i2c_init();
+ omap_serial_init();
+
+ mcx_display_init();
+
+ /* Configure EHCI ports */
+ gpio_request(USB_HOST_PWR_EN, "USB_HOST_PWR_EN");
+ omap_mux_init_gpio(USB_HOST_PWR_EN, OMAP_PIN_OUTPUT);
+ gpio_direction_output(USB_HOST_PWR_EN, 1);
+
+ omap_mux_init_gpio(USB_PHY1_RESET, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(USB_PHY2_RESET, OMAP_PIN_OUTPUT);
+ usbhs_init(&usbhs_bdata);
+ omap_nand_flash_init(NAND_BUSWIDTH_16, mcx_nand_partitions,
+ ARRAY_SIZE(mcx_nand_partitions));
+ /*Ethernet*/
+ mcx_ethernet_init(&mcx_emac_pdata);
+
+ /* MMC init */
+ omap_mux_init_gpio(SD_CARD_WP, OMAP_PIN_INPUT);
+ omap2_hsmmc_init(mmc);
+}
+
+static const char *mcx_dt_match[] __initdata = {
+ "htkw,mcx",
+ NULL
+};
+
+MACHINE_START(MCX, "htkw mcx")
+ /* Maintainer: Ilya Yanok */
+ .atag_offset = 0x100,
+ .reserve = omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = am35xx_init_early,
+ .init_irq = omap3_init_irq,
+ .init_machine = mcx_init,
+ .timer = &omap3_timer,
+ .dt_compat = mcx_dt_match,
+MACHINE_END
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h
index 2d45ea3..5a1bb62 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -168,6 +168,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
DEBUG_LL_OMAP3(3, omap_ldp);
DEBUG_LL_OMAP3(3, overo);
DEBUG_LL_OMAP3(3, touchbook);
+ DEBUG_LL_OMAP3(3, mcx);
/* omap4 based boards using UART3 */
DEBUG_LL_OMAP4(3, omap_4430sdp);
--
1.7.6.4
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx
2011-11-09 0:12 ` [PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx Ilya Yanok
@ 2011-11-09 10:10 ` Archit Taneja
2011-11-09 18:26 ` Ilya Yanok
2011-11-16 21:03 ` Ilya Yanok
0 siblings, 2 replies; 27+ messages in thread
From: Archit Taneja @ 2011-11-09 10:10 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linux-omap, wd, dzu, sasha_d
Hi,
On Wednesday 09 November 2011 05:42 AM, Ilya Yanok wrote:
> AM35xx don't have VDDS_DSI regulator.
AM35xx do have vdds_dsi regulator. Are you saying that your particular
board doesn't have vdds_dsi connected to a regulator?
I assumed that vdds_dsi regulator was required for DPI to function
properly on omap3 devices.
Archit
>
> Signed-off-by: Ilya Yanok<yanok@emcraft.com>
> ---
> drivers/video/omap2/dss/dpi.c | 9 +++++----
> drivers/video/omap2/dss/dsi.c | 18 ++++++++++++------
> 2 files changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
> index 976ac23..929e451 100644
> --- a/drivers/video/omap2/dss/dpi.c
> +++ b/drivers/video/omap2/dss/dpi.c
> @@ -191,7 +191,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
> goto err_start_dev;
> }
>
> - if (cpu_is_omap34xx()) {
> + if (cpu_is_omap34xx()&& !cpu_is_omap3505()&& !cpu_is_omap3517()) {
> r = regulator_enable(dpi.vdds_dsi_reg);
> if (r)
> goto err_reg_enable;
> @@ -238,7 +238,7 @@ err_get_dsi:
> err_get_dispc:
> dss_runtime_put();
> err_get_dss:
> - if (cpu_is_omap34xx())
> + if (cpu_is_omap34xx()&& !cpu_is_omap3505()&& !cpu_is_omap3517())
> regulator_disable(dpi.vdds_dsi_reg);
> err_reg_enable:
> omap_dss_stop_device(dssdev);
> @@ -260,7 +260,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device *dssdev)
> dispc_runtime_put();
> dss_runtime_put();
>
> - if (cpu_is_omap34xx())
> + if (cpu_is_omap34xx()&& !cpu_is_omap3505()&& !cpu_is_omap3517())
> regulator_disable(dpi.vdds_dsi_reg);
>
> omap_dss_stop_device(dssdev);
> @@ -348,7 +348,8 @@ int dpi_init_display(struct omap_dss_device *dssdev)
> {
> DSSDBG("init_display\n");
>
> - if (cpu_is_omap34xx()&& dpi.vdds_dsi_reg == NULL) {
> + if (cpu_is_omap34xx()&& (dpi.vdds_dsi_reg == NULL)&&
> + !cpu_is_omap3505()&& !cpu_is_omap3517()) {
> struct regulator *vdds_dsi;
>
> vdds_dsi = dss_get_vdds_dsi();
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index 5abf8e7..7f38ab6 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -1610,7 +1610,8 @@ int dsi_pll_init(struct platform_device *dsidev, bool enable_hsclk,
>
> DSSDBG("PLL init\n");
>
> - if (dsi->vdds_dsi_reg == NULL) {
> + if ((dsi->vdds_dsi_reg == NULL)&&
> + !cpu_is_omap3517()&& !cpu_is_omap3505()) {
> struct regulator *vdds_dsi;
>
> vdds_dsi = regulator_get(&dsi->pdev->dev, "vdds_dsi");
> @@ -1629,7 +1630,8 @@ int dsi_pll_init(struct platform_device *dsidev, bool enable_hsclk,
> */
> dsi_enable_scp_clk(dsidev);
>
> - if (!dsi->vdds_dsi_enabled) {
> + if (!dsi->vdds_dsi_enabled&&
> + !cpu_is_omap3517()&& !cpu_is_omap3505()) {
> r = regulator_enable(dsi->vdds_dsi_reg);
> if (r)
> goto err0;
> @@ -1668,7 +1670,8 @@ int dsi_pll_init(struct platform_device *dsidev, bool enable_hsclk,
>
> return 0;
> err1:
> - if (dsi->vdds_dsi_enabled) {
> + if (dsi->vdds_dsi_enabled&&
> + !cpu_is_omap3517()&& !cpu_is_omap3505()) {
> regulator_disable(dsi->vdds_dsi_reg);
> dsi->vdds_dsi_enabled = false;
> }
> @@ -1684,7 +1687,8 @@ void dsi_pll_uninit(struct platform_device *dsidev, bool disconnect_lanes)
>
> dsi->pll_locked = 0;
> dsi_pll_power(dsidev, DSI_PLL_POWER_OFF);
> - if (disconnect_lanes) {
> + if (disconnect_lanes&&
> + !cpu_is_omap3517()&& !cpu_is_omap3505()) {
> WARN_ON(!dsi->vdds_dsi_enabled);
> regulator_disable(dsi->vdds_dsi_reg);
> dsi->vdds_dsi_enabled = false;
> @@ -4530,7 +4534,8 @@ int dsi_init_display(struct omap_dss_device *dssdev)
> OMAP_DSS_DISPLAY_CAP_TEAR_ELIM;
> }
>
> - if (dsi->vdds_dsi_reg == NULL) {
> + if ((dsi->vdds_dsi_reg == NULL)&&
> + !cpu_is_omap3517()&& !cpu_is_omap3505()) {
> struct regulator *vdds_dsi;
>
> vdds_dsi = regulator_get(&dsi->pdev->dev, "vdds_dsi");
> @@ -4799,7 +4804,8 @@ static int omap_dsihw_remove(struct platform_device *dsidev)
>
> dsi_put_clocks(dsidev);
>
> - if (dsi->vdds_dsi_reg != NULL) {
> + if ((dsi->vdds_dsi_reg != NULL)&&
> + !cpu_is_omap3517()&& !cpu_is_omap3505()) {
> if (dsi->vdds_dsi_enabled) {
> regulator_disable(dsi->vdds_dsi_reg);
> dsi->vdds_dsi_enabled = false;
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx
2011-11-09 10:10 ` Archit Taneja
@ 2011-11-09 18:26 ` Ilya Yanok
2011-11-10 6:42 ` Archit Taneja
2011-11-16 21:03 ` Ilya Yanok
1 sibling, 1 reply; 27+ messages in thread
From: Ilya Yanok @ 2011-11-09 18:26 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, wd, dzu, sasha_d
Hi Archit,
09.11.2011 14:10, Archit Taneja wrote:
>> AM35xx don't have VDDS_DSI regulator.
>
> AM35xx do have vdds_dsi regulator. Are you saying that your particular
> board doesn't have vdds_dsi connected to a regulator?
Yes, you are right. But looking at the manual (and name) I think it's
needed only for DSI operation. On our board we have LCD connected
through DPI.
> I assumed that vdds_dsi regulator was required for DPI to function
> properly on omap3 devices.
Ok, please ignore this patch then. I think I'll create fake regulator
from the board code to fix this.
Regards, Ilya.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx
2011-11-09 18:26 ` Ilya Yanok
@ 2011-11-10 6:42 ` Archit Taneja
0 siblings, 0 replies; 27+ messages in thread
From: Archit Taneja @ 2011-11-10 6:42 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linux-omap, wd, dzu, sasha_d
Hi,
On Wednesday 09 November 2011 11:56 PM, Ilya Yanok wrote:
> Hi Archit,
>
> 09.11.2011 14:10, Archit Taneja wrote:
>>> AM35xx don't have VDDS_DSI regulator.
>>
>> AM35xx do have vdds_dsi regulator. Are you saying that your particular
>> board doesn't have vdds_dsi connected to a regulator?
>
> Yes, you are right. But looking at the manual (and name) I think it's
> needed only for DSI operation. On our board we have LCD connected
> through DPI.
>
>> I assumed that vdds_dsi regulator was required for DPI to function
>> properly on omap3 devices.
>
> Ok, please ignore this patch then. I think I'll create fake regulator
> from the board code to fix this.
Also, could you push the DSS related patches as a separate series? It
will be easier to pull them since DSS2 driver has a different maintainer.
Thanks,
Archit
>
> Regards, Ilya.
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
2011-11-09 0:12 ` [PATCH 3/4] dts/omap3: split omap3.dtsi Ilya Yanok
@ 2011-11-10 12:18 ` Igor Grinberg
2011-11-10 17:09 ` Cousson, Benoit
0 siblings, 1 reply; 27+ messages in thread
From: Igor Grinberg @ 2011-11-10 12:18 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linux-omap, wd, dzu, sasha_d
Hi Ilya,
On 11/09/11 02:12, Ilya Yanok wrote:
> Split omap3.dtsi file into common part, OM3xxx specific part and
> AM35xx specific part. For now the only difference is missing IVA node on
> AM35xx.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
> arch/arm/boot/dts/am35xx.dtsi | 15 +++++++++++++++
> arch/arm/boot/dts/om3xxx.dtsi | 28 ++++++++++++++++++++++++++++
> arch/arm/boot/dts/omap3-beagle.dts | 2 +-
> arch/arm/boot/dts/omap3.dtsi | 9 ---------
> 4 files changed, 44 insertions(+), 10 deletions(-)
> create mode 100644 arch/arm/boot/dts/am35xx.dtsi
> create mode 100644 arch/arm/boot/dts/om3xxx.dtsi
om3xxx name is confusing - I haven't seen this name
in any documentation/code before...
Am I missing something?
What do you think of omap3-iva.dtsi or omap3-dsp.dtsi?
>
> diff --git a/arch/arm/boot/dts/am35xx.dtsi b/arch/arm/boot/dts/am35xx.dtsi
> new file mode 100644
> index 0000000..0dbc69d
> --- /dev/null
> +++ b/arch/arm/boot/dts/am35xx.dtsi
> @@ -0,0 +1,15 @@
> +/*
> + * Device Tree Source for TI AM35xx SoCs
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + compatible = "ti,am35xx", "ti,omap3";
> +};
> diff --git a/arch/arm/boot/dts/om3xxx.dtsi b/arch/arm/boot/dts/om3xxx.dtsi
> new file mode 100644
> index 0000000..e8a17dd
> --- /dev/null
> +++ b/arch/arm/boot/dts/om3xxx.dtsi
> @@ -0,0 +1,28 @@
> +/*
> + * Device Tree Source for TI OM3xxx SoCs
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + /*
> + * The soc node represents the soc top level view. It is uses for IPs
> + * that are not memory mapped in the MPU view or for the MPU itself.
> + */
> + soc {
> + iva {
> + compatible = "ti,iva2.2";
> + ti,hwmods = "iva";
> +
> + dsp {
> + compatible = "ti,omap3-c64";
> + };
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
> index 9486be6..63e4be1 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -7,7 +7,7 @@
> */
> /dts-v1/;
>
> -/include/ "omap3.dtsi"
> +/include/ "om3xxx.dtsi"
>
> / {
> model = "TI OMAP3 BeagleBoard";
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index d202bb5..2b12b0e 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -29,15 +29,6 @@
> compatible = "ti,omap3-mpu";
> ti,hwmods = "mpu";
> };
> -
> - iva {
> - compatible = "ti,iva2.2";
> - ti,hwmods = "iva";
> -
> - dsp {
> - compatible = "ti,omap3-c64";
> - };
> - };
> };
>
> /*
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 4/4] mcx: initial support for HTKW mcx board
2011-11-09 0:12 ` [PATCH 4/4] mcx: initial support for HTKW mcx board Ilya Yanok
@ 2011-11-10 13:08 ` Igor Grinberg
2011-11-11 0:12 ` Tony Lindgren
2011-11-13 17:56 ` Pankaj Kumar
2 siblings, 0 replies; 27+ messages in thread
From: Igor Grinberg @ 2011-11-10 13:08 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linux-omap, wd, dzu, sasha_d
Hi Ilya,
On 11/09/11 02:12, Ilya Yanok wrote:
> Support for the HTKW mcx board (TI AM3517 based) including serial,
> Ethernet, I2C, USB host, HSMMC, DSS and RTC.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
> arch/arm/boot/dts/mcx.dts | 29 ++
> arch/arm/mach-omap2/Kconfig | 5 +
> arch/arm/mach-omap2/Makefile | 3 +
> arch/arm/mach-omap2/board-mcx.c | 618 ++++++++++++++++++++++++++
> arch/arm/plat-omap/include/plat/uncompress.h | 1 +
> 5 files changed, 656 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/boot/dts/mcx.dts
> create mode 100644 arch/arm/mach-omap2/board-mcx.c
>
> diff --git a/arch/arm/boot/dts/mcx.dts b/arch/arm/boot/dts/mcx.dts
> new file mode 100644
> index 0000000..c87df59
> --- /dev/null
> +++ b/arch/arm/boot/dts/mcx.dts
> @@ -0,0 +1,29 @@
> +/*
> + * Copyright (C) 2011 Ilya Yanok, EmCraft Systems
> + *
> + * 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.
> + */
> +/dts-v1/;
> +
> +/include/ "am35xx.dtsi"
> +
> +/ {
> + model = "HTKW mcx";
> + compatible = "htkw,mcx";
> +
> + /*
> + * Since the initial device tree board file does not create any
> + * devices (MMC, network...), the only way to boot is to provide a
> + * ramdisk.
> + */
> + chosen {
> + bootargs = "root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x81600000,20M ramdisk_size=20480 no_console_suspend debug earlyprintk";
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x80000000 0x10000000>; /* 256 MB */
> + };
> +};
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index c3d530b..3be9cc0 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -230,6 +230,11 @@ config MACH_OMAP_3430SDP
> default y
> select OMAP_PACKAGE_CBB
>
> +config MACH_MCX
> + bool "htkw mcx board"
I have no problem with that, but is this really how you want
the config option to be displayed?
> + depends on ARCH_OMAP3
> + select OMAP_PACKAGE_CBB
> +
> config MACH_NOKIA_N800
> bool
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 69ab1c0..913aa43 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -232,6 +232,9 @@ obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
>
> obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
> obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
> +obj-$(CONFIG_MACH_MCX) += board-mcx.o \
> + omap_phy_internal.o \
This one is always compiled in, so you don't need to specify it
(see a couple of lines below in the file)
> + hsmmc.o
This one is compiled in when CONFIG_MMC_OMAP_HS symbol
enabled, so you don't need to specify this one either.
>
> # Platform specific device init code
>
> diff --git a/arch/arm/mach-omap2/board-mcx.c b/arch/arm/mach-omap2/board-mcx.c
> new file mode 100644
> index 0000000..311e1fb
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-mcx.c
> @@ -0,0 +1,618 @@
> +/*
> + * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
> + *
> + * Modified from mach-omap2/board-omap3beagle.c
> + *
> + * Initial code: Syed Mohammed Khasim
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/platform_device.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/leds.h>
> +#include <linux/gpio.h>
> +#include <linux/input.h>
> +#include <linux/gpio_keys.h>
> +#include <linux/opp.h>
> +
> +#include <linux/mtd/mtd.h>
> +#include <linux/mtd/partitions.h>
> +#include <linux/mtd/nand.h>
> +#include <linux/mmc/host.h>
> +
> +#include <linux/regulator/machine.h>
> +#include <linux/davinci_emac.h>
> +#include <linux/i2c/edt_ts.h>
> +
> +#include <mach/hardware.h>
> +#include <mach/am35xx.h>
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +#include <asm/mach/flash.h>
> +
> +#include <plat/board.h>
> +#include <plat/common.h>
> +#include <plat/omap_hwmod.h>
> +#include <video/omapdss.h>
> +#include <video/omap-panel-generic-dpi.h>
> +#include <plat/gpmc.h>
> +#include <plat/nand.h>
> +#include <plat/usb.h>
> +#include <plat/omap_device.h>
> +
> +#include "mux.h"
> +#include "control.h"
> +#include "hsmmc.h"
> +#include "common-board-devices.h"
I bet, you don't use and don't need all the includes above...
Can it be reduced to the really needed ones?
> +
> +#define MCX_MDIO_FREQUENCY (1000000)
> +
> +static struct mdio_platform_data mcx_mdio_pdata = {
> + .bus_freq = MCX_MDIO_FREQUENCY,
> +};
> +
> +static struct resource am3517_mdio_resources[] = {
> + {
> + .start = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
> + .end = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
> + SZ_4K - 1,
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
> +static struct platform_device am3517_mdio_device = {
> + .name = "davinci_mdio",
> + .id = 0,
> + .num_resources = ARRAY_SIZE(am3517_mdio_resources),
> + .resource = am3517_mdio_resources,
> + .dev.platform_data = &mcx_mdio_pdata,
> +};
> +
> +static struct emac_platform_data mcx_emac_pdata = {
> + .rmii_en = 1,
> +};
> +
> +static struct resource am3517_emac_resources[] = {
> + {
> + .start = AM35XX_IPSS_EMAC_BASE,
> + .end = AM35XX_IPSS_EMAC_BASE + 0x2FFFF,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = INT_35XX_EMAC_C0_RXTHRESH_IRQ,
> + .end = INT_35XX_EMAC_C0_RXTHRESH_IRQ,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = INT_35XX_EMAC_C0_RX_PULSE_IRQ,
> + .end = INT_35XX_EMAC_C0_RX_PULSE_IRQ,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = INT_35XX_EMAC_C0_TX_PULSE_IRQ,
> + .end = INT_35XX_EMAC_C0_TX_PULSE_IRQ,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = INT_35XX_EMAC_C0_MISC_PULSE_IRQ,
> + .end = INT_35XX_EMAC_C0_MISC_PULSE_IRQ,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> +static struct platform_device am3517_emac_device = {
> + .name = "davinci_emac",
> + .id = -1,
> + .num_resources = ARRAY_SIZE(am3517_emac_resources),
> + .resource = am3517_emac_resources,
> +};
> +
> +static void am3517_enable_ethernet_int(void)
> +{
> + u32 regval;
> +
> + regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
> + regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
> + AM35XX_CPGMAC_C0_TX_PULSE_CLR |
> + AM35XX_CPGMAC_C0_MISC_PULSE_CLR |
> + AM35XX_CPGMAC_C0_RX_THRESH_CLR);
> + omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
> + regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
> +}
> +
> +static void am3517_disable_ethernet_int(void)
> +{
> + u32 regval;
> +
> + regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
> + regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
> + AM35XX_CPGMAC_C0_TX_PULSE_CLR);
> + omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
> + regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
> +}
> +
> +static void mcx_ethernet_init(struct emac_platform_data *pdata)
> +{
> + unsigned int regval;
> +
> + pdata->ctrl_reg_offset = AM35XX_EMAC_CNTRL_OFFSET;
> + pdata->ctrl_mod_reg_offset = AM35XX_EMAC_CNTRL_MOD_OFFSET;
> + pdata->ctrl_ram_offset = AM35XX_EMAC_CNTRL_RAM_OFFSET;
> + pdata->ctrl_ram_size = AM35XX_EMAC_CNTRL_RAM_SIZE;
> + pdata->version = EMAC_VERSION_2;
> + pdata->hw_ram_addr = AM35XX_EMAC_HW_RAM_ADDR;
> + pdata->interrupt_enable = am3517_enable_ethernet_int;
> + pdata->interrupt_disable = am3517_disable_ethernet_int;
> + am3517_emac_device.dev.platform_data = pdata;
> + platform_device_register(&am3517_emac_device);
> + platform_device_register(&am3517_mdio_device);
> + clk_add_alias(NULL, dev_name(&am3517_emac_device.dev),
> + "emac_clk", &am3517_emac_device.dev);
> + clk_add_alias(NULL, dev_name(&am3517_mdio_device.dev),
> + "phy_clk", &am3517_emac_device.dev);
> +
> + regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
> + regval = regval & (~(AM35XX_CPGMACSS_SW_RST));
> + omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
> + regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
> +
> + return ;
?? just copy/paste?
> +}
Almost all of the data above is AM35xx specific,
not board specific.
It makes sense to put it into an AM35xx specific file.
Say am35xx-emac.c?
That way we will have much less copy/paste across boards.
> +
> +static struct mtd_partition mcx_nand_partitions[] = {
> + /* All the partition sizes are listed in terms of NAND block size */
> + {
> + .name = "X-Loader",
> + .offset = 0,
> + .size = 4 * NAND_BLOCK_SIZE,
> + .mask_flags = MTD_WRITEABLE, /* force read-only */
> + },
> + {
> + .name = "U-Boot",
> + .offset = MTDPART_OFS_APPEND, /* Offset = 0x80000 */
> + .size = 15 * NAND_BLOCK_SIZE,
> + .mask_flags = MTD_WRITEABLE, /* force read-only */
> + },
> + {
> + .name = "U-Boot Env",
> + .offset = MTDPART_OFS_APPEND, /* Offset = 0x260000 */
> + .size = 1 * NAND_BLOCK_SIZE,
> + },
> + {
> + .name = "Kernel",
> + .offset = MTDPART_OFS_APPEND, /* Offset = 0x280000 */
> + .size = 32 * NAND_BLOCK_SIZE,
> + },
> + {
> + .name = "File System",
> + .offset = MTDPART_OFS_APPEND, /* Offset = 0x680000 */
> + .size = MTDPART_SIZ_FULL,
> + },
> +};
> +
> +#define LCD_PWR_ENn 131
> +#define HDMI_TRCVR_PDn 133
> +#define LCD_BKLIGHT_EN 55
> +#define LCD_LVL_SFHT_BUF_ENn 43
> +
> +static int lcd_enabled;
> +static int dvi_enabled;
> +
> +static int mcx_panel_enable_lcd(struct omap_dss_device *dssdev)
> +{
> + if (dvi_enabled) {
> + printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
> + return -EINVAL;
> + }
> +
> + gpio_set_value(LCD_BKLIGHT_EN, 1);
> + lcd_enabled = 1;
> +
> + return 0;
> +}
> +
> +static void mcx_panel_disable_lcd(struct omap_dss_device *dssdev)
> +{
> + gpio_set_value(LCD_BKLIGHT_EN, 0);
> + lcd_enabled = 0;
> +}
> +
> +static struct panel_generic_dpi_data lcd_panel = {
> + .name = "focaltech_etm070003dh6",
> + .platform_enable = mcx_panel_enable_lcd,
> + .platform_disable = mcx_panel_disable_lcd,
> +};
> +
> +static struct omap_dss_device mcx_lcd_device = {
> + .type = OMAP_DISPLAY_TYPE_DPI,
> + .name = "lcd",
> + .driver_name = "generic_dpi_panel",
> + .data = &lcd_panel,
> + .phy.dpi.data_lines = 24,
> +};
> +
> +/*
> + * TV Output
> + */
> +
> +static int mcx_panel_enable_tv(struct omap_dss_device *dssdev)
> +{
> + return 0;
> +}
> +
> +static void mcx_panel_disable_tv(struct omap_dss_device *dssdev)
> +{
> +}
> +
> +static struct omap_dss_device mcx_tv_device = {
> + .type = OMAP_DISPLAY_TYPE_VENC,
> + .name = "tv",
> + .driver_name = "venc",
> + .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
> + .platform_enable = mcx_panel_enable_tv,
> + .platform_disable = mcx_panel_disable_tv,
> +};
> +
> +/*
> + * DVI/HDMI Output
> + */
> +
> +static int mcx_panel_enable_dvi(struct omap_dss_device *dssdev)
> +{
> + if (lcd_enabled) {
> + printk(KERN_ERR "cannot enable DVI, LCD is enabled\n");
> + return -EINVAL;
> + }
> + dvi_enabled = 1;
> + gpio_set_value(HDMI_TRCVR_PDn, 1);
> + return 0;
> +}
> +
> +static void mcx_panel_disable_dvi(struct omap_dss_device *dssdev)
> +{
> + dvi_enabled = 0;
> + gpio_set_value(HDMI_TRCVR_PDn, 0);
> +}
> +
> +static struct panel_generic_dpi_data dvi_panel = {
> + .platform_enable = mcx_panel_enable_dvi,
> + .platform_disable = mcx_panel_disable_dvi,
> +};
> +static struct omap_dss_device mcx_dvi_device = {
> + .type = OMAP_DISPLAY_TYPE_DPI,
> + .name = "dvi",
> + .driver_name = "dvi",
> + .data = &dvi_panel,
> + .phy.dpi.data_lines = 24,
> +};
> +
> +static struct omap_dss_device *mcx_dss_devices[] = {
> + &mcx_lcd_device,
> + &mcx_tv_device,
> + &mcx_dvi_device,
> +};
> +
> +static struct omap_dss_board_info mcx_dss_data = {
> + .num_devices = ARRAY_SIZE(mcx_dss_devices),
> + .devices = mcx_dss_devices,
> + .default_device = &mcx_lcd_device,
> +};
> +
> +static void __init mcx_display_init(void)
> +{
> + int r;
> +
> + /* disable LCD backlight */
> + r = gpio_request(LCD_BKLIGHT_EN, "LCD_BKLIGHT_EN");
> + if (r) {
> + printk(KERN_ERR "failed to get LCD_BKLIGHT_EN gpio\n");
> + goto err_1;
> + }
> + omap_mux_init_gpio(LCD_BKLIGHT_EN, OMAP_PIN_OUTPUT);
> + gpio_direction_output(LCD_BKLIGHT_EN, 0);
I see what are you up to here...
Do you mean: try to request the GPIO and only if it is free,
then set the mux?
I think it is redundant...
You don't really have that concurrency - no any other code
should request these GPIOs and if there is, then it is a bug
and should be treated as such.
I think there is no need in this kind of complexity - just
use gpio_{request|free}_array().
> +
> + /* Enable VIO-> 3.3v level shifter */
> + r = gpio_request(LCD_LVL_SFHT_BUF_ENn, "LCD_LVL_SFHT_BUF_ENn");
> + if (r) {
> + printk(KERN_ERR "failed to get LCD_LVL_SFHT_BUF_ENn gpio\n");
> + goto err_2;
> + }
> + omap_mux_init_gpio(LCD_LVL_SFHT_BUF_ENn, OMAP_PIN_OUTPUT);
> + gpio_direction_output(LCD_LVL_SFHT_BUF_ENn, 0);
> +
> + /* Enable LCD panel VCC */
> +
> + r = gpio_request(LCD_PWR_ENn, "LCD_PWR_ENn");
> + if (r) {
> + printk(KERN_ERR "failed to get LCD_PWR_ENn\n");
> + goto err_3;
> + }
> + omap_mux_init_gpio(LCD_PWR_ENn, OMAP_PIN_OUTPUT);
> +
> + gpio_direction_output(LCD_PWR_ENn, 0);
> +
> + /* Disable HDMI transceiver */
> + r = gpio_request(HDMI_TRCVR_PDn, "HDMI_TRCVR_PDn");
> + if (r) {
> + printk(KERN_ERR "failed to get HDMI_TRCVR_PDn\n");
> + goto err_4;
> + }
> + omap_mux_init_gpio(HDMI_TRCVR_PDn, OMAP_PIN_OUTPUT);
> + gpio_direction_output(HDMI_TRCVR_PDn, 0);
> +
> + omap_display_init(&mcx_dss_data);
> +
> + return;
> +
> +err_4:
> + gpio_free(HDMI_TRCVR_PDn);
> +err_3:
> + gpio_free(LCD_LVL_SFHT_BUF_ENn);
> +err_2:
> + gpio_free(LCD_LVL_SFHT_BUF_ENn);
> +err_1:
> + gpio_free(LCD_BKLIGHT_EN);
> +}
Why not use gpio_{request|free}_array()?
It will make the above code really simple.
> +
> +/* TPS65023 specific initialization */
> +/* VDCDC1 -> VDD_CORE */
> +static struct regulator_consumer_supply am3517_vdcdc1_supplies[] = {
> + {
> + .supply = "vdd_core",
> + },
> +};
> +
> +/* VDCDC2 -> VDDSHV */
> +static struct regulator_consumer_supply am3517_vdcdc2_supplies[] = {
> + {
> + .supply = "vddshv",
> + },
> +};
> +
> +/*
> + * VDCDC2 |-> VDDS
> + * |-> VDDS_SRAM_CORE_BG
> + * |-> VDDS_SRAM_MPU
> + */
> +static struct regulator_consumer_supply am3517_vdcdc3_supplies[] = {
> + {
> + .supply = "vdds",
> + },
> + {
> + .supply = "vdds_sram_core_bg",
> + },
> + {
> + .supply = "vdds_sram_mpu",
> + },
> +};
> +
> +/*
> + * LDO1 |-> VDDA1P8V_USBPHY
> + * |-> VDDA_DAC
> + */
> +static struct regulator_consumer_supply am3517_ldo1_supplies[] = {
> + {
> + .supply = "vdda1p8v_usbphy",
> + },
> + {
> + .supply = "vdda_dac",
> + },
> +};
> +
> +/* LDO2 -> VDDA3P3V_USBPHY */
> +static struct regulator_consumer_supply am3517_ldo2_supplies[] = {
> + {
> + .supply = "vdda3p3v_usbphy",
> + },
> +};
> +
> +static struct regulator_init_data mcx_regulator_data[] = {
> + /* DCDC1 */
> + {
> + .constraints = {
> + .min_uV = 1200000,
> + .max_uV = 1200000,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + .always_on = true,
> + .apply_uV = false,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(am3517_vdcdc1_supplies),
> + .consumer_supplies = am3517_vdcdc1_supplies,
> + },
> + /* DCDC2 */
> + {
> + .constraints = {
> + .min_uV = 3300000,
> + .max_uV = 3300000,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + .always_on = true,
> + .apply_uV = false,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(am3517_vdcdc2_supplies),
> + .consumer_supplies = am3517_vdcdc2_supplies,
> + },
> + /* DCDC3 */
> + {
> + .constraints = {
> + .min_uV = 1800000,
> + .max_uV = 1800000,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + .always_on = true,
> + .apply_uV = false,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(am3517_vdcdc3_supplies),
> + .consumer_supplies = am3517_vdcdc3_supplies,
> + },
> + /* LDO1 */
> + {
> + .constraints = {
> + .min_uV = 1800000,
> + .max_uV = 1800000,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + .always_on = false,
> + .apply_uV = false,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(am3517_ldo1_supplies),
> + .consumer_supplies = am3517_ldo1_supplies,
> + },
> + /* LDO2 */
> + {
> + .constraints = {
> + .min_uV = 3300000,
> + .max_uV = 3300000,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + .always_on = false,
> + .apply_uV = false,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(am3517_ldo2_supplies),
> + .consumer_supplies = am3517_ldo2_supplies,
> + },
> +};
> +
> +static struct i2c_board_info __initdata mcx_i2c1_devices[] = {
> + {
> + I2C_BOARD_INFO("ds1337", 0x68),
> + },
> + {
> + I2C_BOARD_INFO("tps65023", 0x48),
> + .flags = I2C_CLIENT_WAKE,
> + .platform_data = &mcx_regulator_data[0],
> + },
> +};
> +
> +#define TOUCH_INT_GPIO 170
> +
> +static struct edt_platform_data edt_ts_data = {
> + .irq_gpio = TOUCH_INT_GPIO,
> +};
> +
> +static int __init mcx_ts_init(void)
What is the point in int as return type, if you don't check it?
> +{
> + struct i2c_board_info mcx_edt_ts[] = {
> + {
> + I2C_BOARD_INFO("edt_ts", 0x38),
> + .platform_data = &edt_ts_data,
> + },
> + };
> +
> + if (gpio_request(TOUCH_INT_GPIO, "TOUCH_INT")) {
> + printk(KERN_ERR "failed to get TOUCH_INT gpio\n");
> + return 1;
> + }
> +
> + gpio_direction_input(TOUCH_INT_GPIO);
gpio_request_one()?
> +
> + i2c_register_board_info(3, mcx_edt_ts, 1);
> +
> + return 0;
> +}
> +
> +static int __init mcx_i2c_init(void)
> +{
> + omap_register_i2c_bus(1, 400, mcx_i2c1_devices,
> + ARRAY_SIZE(mcx_i2c1_devices));
> + omap_register_i2c_bus(2, 400, NULL, 0);
> + omap_register_i2c_bus(3, 400, NULL, 0);
> + mcx_ts_init();
> + return 0;
> +}
> +
> +#define USB_HOST_PWR_EN 132
> +#define USB_PHY1_RESET 154
> +#define USB_PHY2_RESET 152
> +
> +static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
> +
> + .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
> + .port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
> + .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
> +
> + .phy_reset = true,
> + .reset_gpio_port[0] = USB_PHY1_RESET,
> + .reset_gpio_port[1] = USB_PHY2_RESET,
> + .reset_gpio_port[2] = -EINVAL
> +};
> +
> +#define SD_CARD_WP 65
> +
> +static struct omap2_hsmmc_info mmc[] = {
> + {
> + .mmc = 1,
> + .caps = MMC_CAP_4_BIT_DATA,
> + .gpio_cd = -EINVAL,
> + .gpio_wp = SD_CARD_WP,
> + .ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34 |
> + MMC_VDD_165_195,
> + },
> + {} /* Terminator */
> +};
> +
> +#ifdef CONFIG_OMAP_MUX
> +static struct omap_board_mux board_mux[] __initdata = {
> + OMAP3_MUX(CHASSIS_DMAREQ3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
> + OMAP3_MUX(UART1_TX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
> + OMAP_PULL_ENA | OMAP_PULL_UP),
> + OMAP3_MUX(UART1_RX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
> + OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
> + OMAP3_MUX(UART1_CTS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
> + OMAP_PULL_ENA | OMAP_PULL_UP),
> + { .reg_offset = OMAP_MUX_TERMINATOR },
> +};
> +#endif
> +
> +static void __init mcx_init(void)
> +{
> + omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> + mcx_i2c_init();
> + omap_serial_init();
> +
> + mcx_display_init();
> +
> + /* Configure EHCI ports */
> + gpio_request(USB_HOST_PWR_EN, "USB_HOST_PWR_EN");
> + omap_mux_init_gpio(USB_HOST_PWR_EN, OMAP_PIN_OUTPUT);
> + gpio_direction_output(USB_HOST_PWR_EN, 1);
gpio_request_one()?
> +
> + omap_mux_init_gpio(USB_PHY1_RESET, OMAP_PIN_OUTPUT);
> + omap_mux_init_gpio(USB_PHY2_RESET, OMAP_PIN_OUTPUT);
> + usbhs_init(&usbhs_bdata);
> + omap_nand_flash_init(NAND_BUSWIDTH_16, mcx_nand_partitions,
> + ARRAY_SIZE(mcx_nand_partitions));
> + /*Ethernet*/
> + mcx_ethernet_init(&mcx_emac_pdata);
> +
> + /* MMC init */
> + omap_mux_init_gpio(SD_CARD_WP, OMAP_PIN_INPUT);
> + omap2_hsmmc_init(mmc);
> +}
> +
> +static const char *mcx_dt_match[] __initdata = {
> + "htkw,mcx",
> + NULL
> +};
> +
> +MACHINE_START(MCX, "htkw mcx")
> + /* Maintainer: Ilya Yanok */
> + .atag_offset = 0x100,
> + .reserve = omap_reserve,
> + .map_io = omap3_map_io,
> + .init_early = am35xx_init_early,
> + .init_irq = omap3_init_irq,
> + .init_machine = mcx_init,
> + .timer = &omap3_timer,
> + .dt_compat = mcx_dt_match,
> +MACHINE_END
> diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h
> index 2d45ea3..5a1bb62 100644
> --- a/arch/arm/plat-omap/include/plat/uncompress.h
> +++ b/arch/arm/plat-omap/include/plat/uncompress.h
> @@ -168,6 +168,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
> DEBUG_LL_OMAP3(3, omap_ldp);
> DEBUG_LL_OMAP3(3, overo);
> DEBUG_LL_OMAP3(3, touchbook);
> + DEBUG_LL_OMAP3(3, mcx);
Alphabetical order please.
>
> /* omap4 based boards using UART3 */
> DEBUG_LL_OMAP4(3, omap_4430sdp);
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
2011-11-10 12:18 ` Igor Grinberg
@ 2011-11-10 17:09 ` Cousson, Benoit
2011-11-10 17:26 ` Igor Grinberg
0 siblings, 1 reply; 27+ messages in thread
From: Cousson, Benoit @ 2011-11-10 17:09 UTC (permalink / raw)
To: Igor Grinberg
Cc: Ilya Yanok, linux-omap, wd, dzu, sasha_d,
devicetree-discuss@lists.ozlabs.org
+ devicetree ml
On 11/10/2011 1:18 PM, Igor Grinberg wrote:
> Hi Ilya,
>
> On 11/09/11 02:12, Ilya Yanok wrote:
>> Split omap3.dtsi file into common part, OM3xxx specific part and
>> AM35xx specific part. For now the only difference is missing IVA node on
>> AM35xx.
>>
>> Signed-off-by: Ilya Yanok<yanok@emcraft.com>
>> ---
>> arch/arm/boot/dts/am35xx.dtsi | 15 +++++++++++++++
>> arch/arm/boot/dts/om3xxx.dtsi | 28 ++++++++++++++++++++++++++++
>> arch/arm/boot/dts/omap3-beagle.dts | 2 +-
>> arch/arm/boot/dts/omap3.dtsi | 9 ---------
>> 4 files changed, 44 insertions(+), 10 deletions(-)
>> create mode 100644 arch/arm/boot/dts/am35xx.dtsi
>> create mode 100644 arch/arm/boot/dts/om3xxx.dtsi
>
> om3xxx name is confusing - I haven't seen this name
> in any documentation/code before...
> Am I missing something?
>
> What do you think of omap3-iva.dtsi or omap3-dsp.dtsi?
Cannot we avoid at all hacking the original file and use instead the
status = "disabled" field for any variant that will not have the
functionality?
It will be a nightmare for us to maintain a consistent OMAP3 file if
every variants force us to change the original file.
Regards,
Benoit
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
2011-11-10 17:09 ` Cousson, Benoit
@ 2011-11-10 17:26 ` Igor Grinberg
2011-11-10 18:07 ` Cousson, Benoit
0 siblings, 1 reply; 27+ messages in thread
From: Igor Grinberg @ 2011-11-10 17:26 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Ilya Yanok, linux-omap, wd, dzu, sasha_d,
devicetree-discuss@lists.ozlabs.org
On 11/10/11 19:09, Cousson, Benoit wrote:
> + devicetree ml
>
> On 11/10/2011 1:18 PM, Igor Grinberg wrote:
>> Hi Ilya,
>>
>> On 11/09/11 02:12, Ilya Yanok wrote:
>>> Split omap3.dtsi file into common part, OM3xxx specific part and
>>> AM35xx specific part. For now the only difference is missing IVA node on
>>> AM35xx.
>>>
>>> Signed-off-by: Ilya Yanok<yanok@emcraft.com>
>>> ---
>>> arch/arm/boot/dts/am35xx.dtsi | 15 +++++++++++++++
>>> arch/arm/boot/dts/om3xxx.dtsi | 28 ++++++++++++++++++++++++++++
>>> arch/arm/boot/dts/omap3-beagle.dts | 2 +-
>>> arch/arm/boot/dts/omap3.dtsi | 9 ---------
>>> 4 files changed, 44 insertions(+), 10 deletions(-)
>>> create mode 100644 arch/arm/boot/dts/am35xx.dtsi
>>> create mode 100644 arch/arm/boot/dts/om3xxx.dtsi
>>
>> om3xxx name is confusing - I haven't seen this name
>> in any documentation/code before...
>> Am I missing something?
>>
>> What do you think of omap3-iva.dtsi or omap3-dsp.dtsi?
>
> Cannot we avoid at all hacking the original file and use instead the status = "disabled" field for any variant that will not have the functionality?
This might be an option.
What I thought of is splitting the original file into "atomic"
(none splittable) parts and each OMAP variant will include
the ones it has.
This way you have all the features available and can make any
mixture of them (which, probably will reflect the hardware best ;-))
>
> It will be a nightmare for us to maintain a consistent OMAP3 file if every variants force us to change the original file.
it will be a nightmare anyway ;-)
I don't really know what can make it a less scary nightmare.
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
2011-11-10 17:26 ` Igor Grinberg
@ 2011-11-10 18:07 ` Cousson, Benoit
2011-11-11 7:32 ` Igor Grinberg
0 siblings, 1 reply; 27+ messages in thread
From: Cousson, Benoit @ 2011-11-10 18:07 UTC (permalink / raw)
To: Igor Grinberg
Cc: Ilya Yanok, linux-omap, wd, dzu, sasha_d,
devicetree-discuss@lists.ozlabs.org
Hi Igor,
On 11/10/2011 6:26 PM, Igor Grinberg wrote:
> On 11/10/11 19:09, Cousson, Benoit wrote:
>> + devicetree ml
>>
>> On 11/10/2011 1:18 PM, Igor Grinberg wrote:
>>> Hi Ilya,
>>>
>>> On 11/09/11 02:12, Ilya Yanok wrote:
>>>> Split omap3.dtsi file into common part, OM3xxx specific part and
>>>> AM35xx specific part. For now the only difference is missing IVA node on
>>>> AM35xx.
>>>>
>>>> Signed-off-by: Ilya Yanok<yanok@emcraft.com>
>>>> ---
>>>> arch/arm/boot/dts/am35xx.dtsi | 15 +++++++++++++++
>>>> arch/arm/boot/dts/om3xxx.dtsi | 28 ++++++++++++++++++++++++++++
>>>> arch/arm/boot/dts/omap3-beagle.dts | 2 +-
>>>> arch/arm/boot/dts/omap3.dtsi | 9 ---------
>>>> 4 files changed, 44 insertions(+), 10 deletions(-)
>>>> create mode 100644 arch/arm/boot/dts/am35xx.dtsi
>>>> create mode 100644 arch/arm/boot/dts/om3xxx.dtsi
>>>
>>> om3xxx name is confusing - I haven't seen this name
>>> in any documentation/code before...
>>> Am I missing something?
>>>
>>> What do you think of omap3-iva.dtsi or omap3-dsp.dtsi?
>>
>> Cannot we avoid at all hacking the original file and use instead the status = "disabled" field for any variant that will not have the functionality?
>
> This might be an option.
>
> What I thought of is splitting the original file into "atomic"
> (none splittable) parts and each OMAP variant will include
> the ones it has.
> This way you have all the features available and can make any
> mixture of them (which, probably will reflect the hardware best ;-))
Yeah, but it will be less readable for my point of view. You will add
another level of include hierarchy. The point is that each time some new
variants will come with less and less feature, we will keep
de-populating the original file.
My other concern is that all these variants are handled by different
people for different products. So by having dedicated file for each
variant, each owner can handle its own stuff without messing up the
original file.
Considering that this omap3.dtsi file is under construction, we can
expect a bunch a dirty merge conflicts if different people from
different organization start adding / removing nodes at the same time.
We already faced that kind of nightmare for our existing clock / hwmod
static data files. So if we can avoid it with DT files, it will be cool.
>> It will be a nightmare for us to maintain a consistent OMAP3 file if every variants force us to change the original file.
>
> it will be a nightmare anyway ;-)
Indeed, the best is to avoid any variant :-)
> I don't really know what can make it a less scary nightmare.
For my point of view, since I will have to keep hacking on that
omap3.dtsi, having some separate variant files that does not have to
touch this file will be much better.
If all these variants were already there and well defined, we might have
then decided to re-organized that by starting from a common subset.
But since everything is moving at the same time and with an unknown
target, we should minimize hacking any common file under construction.
Regards,
Benoit
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 4/4] mcx: initial support for HTKW mcx board
2011-11-09 0:12 ` [PATCH 4/4] mcx: initial support for HTKW mcx board Ilya Yanok
2011-11-10 13:08 ` Igor Grinberg
@ 2011-11-11 0:12 ` Tony Lindgren
2011-11-14 20:39 ` Ilya Yanok
2011-11-13 17:56 ` Pankaj Kumar
2 siblings, 1 reply; 27+ messages in thread
From: Tony Lindgren @ 2011-11-11 0:12 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linux-omap, wd, dzu, sasha_d
* Ilya Yanok <yanok@emcraft.com> [111108 15:38]:
> Support for the HTKW mcx board (TI AM3517 based) including serial,
> Ethernet, I2C, USB host, HSMMC, DSS and RTC.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
> arch/arm/boot/dts/mcx.dts | 29 ++
> arch/arm/mach-omap2/Kconfig | 5 +
> arch/arm/mach-omap2/Makefile | 3 +
> arch/arm/mach-omap2/board-mcx.c | 618 ++++++++++++++++++++++++++
This looks OK but let's concentrate on getting things working with
board-generic.c and DT only in mainline kernel.
I can apply this into testing-board, but let's not cause more churn
in mainline with the board files that will be disappearing.
Can you please split it into something minimal for mainline that
allows booting with DT, and then another patch for testing-board
branch?
Thanks,
Tony
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
2011-11-10 18:07 ` Cousson, Benoit
@ 2011-11-11 7:32 ` Igor Grinberg
0 siblings, 0 replies; 27+ messages in thread
From: Igor Grinberg @ 2011-11-11 7:32 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Ilya Yanok, linux-omap, wd, dzu, sasha_d,
devicetree-discuss@lists.ozlabs.org
On 11/10/11 20:07, Cousson, Benoit wrote:
> Hi Igor,
>
> On 11/10/2011 6:26 PM, Igor Grinberg wrote:
>> On 11/10/11 19:09, Cousson, Benoit wrote:
>>> + devicetree ml
>>>
>>> On 11/10/2011 1:18 PM, Igor Grinberg wrote:
>>>> Hi Ilya,
>>>>
>>>> On 11/09/11 02:12, Ilya Yanok wrote:
>>>>> Split omap3.dtsi file into common part, OM3xxx specific part and
>>>>> AM35xx specific part. For now the only difference is missing IVA node on
>>>>> AM35xx.
>>>>>
>>>>> Signed-off-by: Ilya Yanok<yanok@emcraft.com>
>>>>> ---
>>>>> arch/arm/boot/dts/am35xx.dtsi | 15 +++++++++++++++
>>>>> arch/arm/boot/dts/om3xxx.dtsi | 28 ++++++++++++++++++++++++++++
>>>>> arch/arm/boot/dts/omap3-beagle.dts | 2 +-
>>>>> arch/arm/boot/dts/omap3.dtsi | 9 ---------
>>>>> 4 files changed, 44 insertions(+), 10 deletions(-)
>>>>> create mode 100644 arch/arm/boot/dts/am35xx.dtsi
>>>>> create mode 100644 arch/arm/boot/dts/om3xxx.dtsi
>>>>
>>>> om3xxx name is confusing - I haven't seen this name
>>>> in any documentation/code before...
>>>> Am I missing something?
>>>>
>>>> What do you think of omap3-iva.dtsi or omap3-dsp.dtsi?
>>>
>>> Cannot we avoid at all hacking the original file and use instead the status = "disabled" field for any variant that will not have the functionality?
>>
>> This might be an option.
>>
>> What I thought of is splitting the original file into "atomic"
>> (none splittable) parts and each OMAP variant will include
>> the ones it has.
>> This way you have all the features available and can make any
>> mixture of them (which, probably will reflect the hardware best ;-))
>
> Yeah, but it will be less readable for my point of view.
Agreed, it will be less readable, because it will be spread among several files.
> You will add another level of include hierarchy.
Why is adding another level of include hierarchy is a problem?
> The point is that each time some new variants will come with less and less feature,
> we will keep de-populating the original file.
Here you assume that it will be always *less* features and never *more*?
Also, that is the reason, why I think splitting it right now to smaller pieces
will do a good job for the future.
>
> My other concern is that all these variants are handled by different people for different products.
> So by having dedicated file for each variant, each owner can handle its own stuff without messing up the original file.
I'm not saying that we should not have a dedicated file for each variant.
What I'm saying is that the dedicated file for each variant can include
the "pieces" the hardware has, instead of duplicating them or disabling
what it does not have.
> Considering that this omap3.dtsi file is under construction, we can expect a bunch a dirty merge conflicts if different people from different organization start adding / removing nodes at the same time.
IMO, that problem can also be avoided by splitting it to smaller pieces.
Don't you think so?
>
> We already faced that kind of nightmare for our existing clock / hwmod static data files. So if we can avoid it with DT files, it will be cool.
I don't think it falls in the same problem category,
but may be I'm missing something...
>
>>> It will be a nightmare for us to maintain a consistent OMAP3 file if every variants force us to change the original file.
>>
>> it will be a nightmare anyway ;-)
>
> Indeed, the best is to avoid any variant :-)
>
>> I don't really know what can make it a less scary nightmare.
>
> For my point of view, since I will have to keep hacking on that omap3.dtsi, having some separate variant files that does not have to touch this file will be much better.
Or split it to pieces right now, so no one will have to hack on it...
>
> If all these variants were already there and well defined, we might have then decided to re-organized that by starting from a common subset.
Yeah, it would be perfect, but it is never been this way and will never be...
> But since everything is moving at the same time and with an unknown target, we should minimize hacking any common file under construction.
I think the design of having a common file with data does not scale.
Again, having multiple files, each with data per subsystem or
per an ip block, does scale and IMO will do a better job,
now and in the future.
This will mean that common file will only do the includes to
assemble all the *right* data together.
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 4/4] mcx: initial support for HTKW mcx board
2011-11-09 0:12 ` [PATCH 4/4] mcx: initial support for HTKW mcx board Ilya Yanok
2011-11-10 13:08 ` Igor Grinberg
2011-11-11 0:12 ` Tony Lindgren
@ 2011-11-13 17:56 ` Pankaj Kumar
2 siblings, 0 replies; 27+ messages in thread
From: Pankaj Kumar @ 2011-11-13 17:56 UTC (permalink / raw)
Cc: linux-omap, wd, dzu, sasha_d, Ilya Yanok
Hi IIya,
> Support for the HTKW mcx board (TI AM3517 based) including serial,
> Ethernet, I2C, USB host, HSMMC, DSS and RTC.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> +static struct omap_dss_board_info mcx_dss_data = {
> + .num_devices = ARRAY_SIZE(mcx_dss_devices),
> + .devices = mcx_dss_devices,
> + .default_device = &mcx_lcd_device,
> +};
> +
> +static void __init mcx_display_init(void)
> +{
> + int r;
> +
> + /* disable LCD backlight */
> + r = gpio_request(LCD_BKLIGHT_EN, "LCD_BKLIGHT_EN");
> + if (r) {
> + printk(KERN_ERR "failed to get LCD_BKLIGHT_EN gpio\n");
You should use pr_err macro for error conditions to print, instead of printk.
> + goto err_1;
> + }
> + omap_mux_init_gpio(LCD_BKLIGHT_EN, OMAP_PIN_OUTPUT);
> + gpio_direction_output(LCD_BKLIGHT_EN, 0);
> +
> + /* Enable VIO-> 3.3v level shifter */
> + r = gpio_request(LCD_LVL_SFHT_BUF_ENn, "LCD_LVL_SFHT_BUF_ENn");
> + if (r) {
> + printk(KERN_ERR "failed to get LCD_LVL_SFHT_BUF_ENn gpio\n");
Same here. Deprecate the use of printk for error printing.
> + goto err_2;
> + }
> + omap_mux_init_gpio(LCD_LVL_SFHT_BUF_ENn, OMAP_PIN_OUTPUT);
> + gpio_direction_output(LCD_LVL_SFHT_BUF_ENn, 0);
> +
> + /* Enable LCD panel VCC */
> +
> + r = gpio_request(LCD_PWR_ENn, "LCD_PWR_ENn");
> + if (r) {
> + printk(KERN_ERR "failed to get LCD_PWR_ENn\n");
Same Here.
> + goto err_3;
> + }
> + omap_mux_init_gpio(LCD_PWR_ENn, OMAP_PIN_OUTPUT);
> +
> + gpio_direction_output(LCD_PWR_ENn, 0);
> +
> + /* Disable HDMI transceiver */
> + r = gpio_request(HDMI_TRCVR_PDn, "HDMI_TRCVR_PDn");
> + if (r) {
> + printk(KERN_ERR "failed to get HDMI_TRCVR_PDn\n");
Same Here.
> + goto err_4;
> + }
> + omap_mux_init_gpio(HDMI_TRCVR_PDn, OMAP_PIN_OUTPUT);
> + gpio_direction_output(HDMI_TRCVR_PDn, 0);
> +
> + omap_display_init(&mcx_dss_data);
> +
> + return;
> +
> +err_4:
> + gpio_free(HDMI_TRCVR_PDn);
> +err_3:
> + gpio_free(LCD_LVL_SFHT_BUF_ENn);
> +err_2:
> + gpio_free(LCD_LVL_SFHT_BUF_ENn);
> +err_1:
> + gpio_free(LCD_BKLIGHT_EN);
> +}
> +
> +/* TPS65023 specific initialization */
> +/* VDCDC1 -> VDD_CORE */
> +static struct regulator_consumer_supply am3517_vdcdc1_supplies[] = {
> + {
> + .supply = "vdd_core",
> + },
> +};
> +
> +/* VDCDC2 -> VDDSHV */
> +static struct regulator_consumer_supply am3517_vdcdc2_supplies[] = {
> + {
> + .supply = "vddshv",
> + },
> +};
> +
> +/*
> + * VDCDC2 |-> VDDS
> + * |-> VDDS_SRAM_CORE_BG
> + * |-> VDDS_SRAM_MPU
> + */
> +static struct regulator_consumer_supply am3517_vdcdc3_supplies[] = {
> + {
> + .supply = "vdds",
> + },
> + {
> + .supply = "vdds_sram_core_bg",
> + },
> + {
> + .supply = "vdds_sram_mpu",
> + },
> +};
> +
> +/*
> + * LDO1 |-> VDDA1P8V_USBPHY
> + * |-> VDDA_DAC
> + */
> +static struct regulator_consumer_supply am3517_ldo1_supplies[] = {
> + {
> + .supply = "vdda1p8v_usbphy",
> + },
> + {
> + .supply = "vdda_dac",
> + },
> +};
> +
> +/* LDO2 -> VDDA3P3V_USBPHY */
> +static struct regulator_consumer_supply am3517_ldo2_supplies[] = {
> + {
> + .supply = "vdda3p3v_usbphy",
> + },
> +};
> +
> +static struct regulator_init_data mcx_regulator_data[] = {
> + /* DCDC1 */
> + {
> + .constraints = {
> + .min_uV = 1200000,
> + .max_uV = 1200000,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + .always_on = true,
> + .apply_uV = false,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(am3517_vdcdc1_supplies),
> + .consumer_supplies = am3517_vdcdc1_supplies,
> + },
> + /* DCDC2 */
> + {
> + .constraints = {
> + .min_uV = 3300000,
> + .max_uV = 3300000,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + .always_on = true,
> + .apply_uV = false,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(am3517_vdcdc2_supplies),
> + .consumer_supplies = am3517_vdcdc2_supplies,
> + },
> + /* DCDC3 */
> + {
> + .constraints = {
> + .min_uV = 1800000,
> + .max_uV = 1800000,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + .always_on = true,
> + .apply_uV = false,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(am3517_vdcdc3_supplies),
> + .consumer_supplies = am3517_vdcdc3_supplies,
> + },
> + /* LDO1 */
> + {
> + .constraints = {
> + .min_uV = 1800000,
> + .max_uV = 1800000,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + .always_on = false,
> + .apply_uV = false,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(am3517_ldo1_supplies),
> + .consumer_supplies = am3517_ldo1_supplies,
> + },
> + /* LDO2 */
> + {
> + .constraints = {
> + .min_uV = 3300000,
> + .max_uV = 3300000,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + .always_on = false,
> + .apply_uV = false,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(am3517_ldo2_supplies),
> + .consumer_supplies = am3517_ldo2_supplies,
> + },
> +};
> +
> +static struct i2c_board_info __initdata mcx_i2c1_devices[] = {
> + {
> + I2C_BOARD_INFO("ds1337", 0x68),
> + },
> + {
> + I2C_BOARD_INFO("tps65023", 0x48),
> + .flags = I2C_CLIENT_WAKE,
> + .platform_data = &mcx_regulator_data[0],
> + },
> +};
> +
> +#define TOUCH_INT_GPIO 170
> +
> +static struct edt_platform_data edt_ts_data = {
> + .irq_gpio = TOUCH_INT_GPIO,
> +};
> +
> +static int __init mcx_ts_init(void)
> +{
> + struct i2c_board_info mcx_edt_ts[] = {
> + {
> + I2C_BOARD_INFO("edt_ts", 0x38),
> + .platform_data = &edt_ts_data,
> + },
> + };
> +
> + if (gpio_request(TOUCH_INT_GPIO, "TOUCH_INT")) {
> + printk(KERN_ERR "failed to get TOUCH_INT gpio\n");
Please use pr_err instead of printk.
> + return 1;
> + }
> +
> + gpio_direction_input(TOUCH_INT_GPIO);
> +
> + i2c_register_board_info(3, mcx_edt_ts, 1);
> +
> + return 0;
> +}
> +
> +static int __init mcx_i2c_init(void)
> +{
> + omap_register_i2c_bus(1, 400, mcx_i2c1_devices,
> + ARRAY_SIZE(mcx_i2c1_devices));
> + omap_register_i2c_bus(2, 400, NULL, 0);
> + omap_register_i2c_bus(3, 400, NULL, 0);
> + mcx_ts_init();
> + return 0;
> +}
> +
> +#define USB_HOST_PWR_EN 132
> +#define USB_PHY1_RESET 154
> +#define USB_PHY2_RESET 152
> +
> +static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
> +
> + .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
> + .port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
> + .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
> +
> + .phy_reset = true,
> + .reset_gpio_port[0] = USB_PHY1_RESET,
> + .reset_gpio_port[1] = USB_PHY2_RESET,
> + .reset_gpio_port[2] = -EINVAL
> +};
> +
> +#define SD_CARD_WP 65
> +
> +static struct omap2_hsmmc_info mmc[] = {
> + {
> + .mmc = 1,
> + .caps = MMC_CAP_4_BIT_DATA,
> + .gpio_cd = -EINVAL,
> + .gpio_wp = SD_CARD_WP,
> + .ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34 |
> + MMC_VDD_165_195,
> + },
> + {} /* Terminator */
> +};
> +
> +#ifdef CONFIG_OMAP_MUX
> +static struct omap_board_mux board_mux[] __initdata = {
> + OMAP3_MUX(CHASSIS_DMAREQ3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
> + OMAP3_MUX(UART1_TX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
> + OMAP_PULL_ENA | OMAP_PULL_UP),
> + OMAP3_MUX(UART1_RX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
> + OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
> + OMAP3_MUX(UART1_CTS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
> + OMAP_PULL_ENA | OMAP_PULL_UP),
> + { .reg_offset = OMAP_MUX_TERMINATOR },
> +};
> +#endif
> +
> +static void __init mcx_init(void)
> +{
> + omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> + mcx_i2c_init();
> + omap_serial_init();
> +
> + mcx_display_init();
> +
> + /* Configure EHCI ports */
> + gpio_request(USB_HOST_PWR_EN, "USB_HOST_PWR_EN");
No error checking for gpio_request?
> + omap_mux_init_gpio(USB_HOST_PWR_EN, OMAP_PIN_OUTPUT);
> + gpio_direction_output(USB_HOST_PWR_EN, 1);
> +
> + omap_mux_init_gpio(USB_PHY1_RESET, OMAP_PIN_OUTPUT);
> + omap_mux_init_gpio(USB_PHY2_RESET, OMAP_PIN_OUTPUT);
> + usbhs_init(&usbhs_bdata);
> + omap_nand_flash_init(NAND_BUSWIDTH_16, mcx_nand_partitions,
> + ARRAY_SIZE(mcx_nand_partitions));
> + /*Ethernet*/
> + mcx_ethernet_init(&mcx_emac_pdata);
> +
> + /* MMC init */
> + omap_mux_init_gpio(SD_CARD_WP, OMAP_PIN_INPUT);
> + omap2_hsmmc_init(mmc);
> +}
> +
> +static const char *mcx_dt_match[] __initdata = {
> + "htkw,mcx",
> + NULL
> +};
> +
> +MACHINE_START(MCX, "htkw mcx")
> + /* Maintainer: Ilya Yanok */
> + .atag_offset = 0x100,
> + .reserve = omap_reserve,
> + .map_io = omap3_map_io,
> + .init_early = am35xx_init_early,
> + .init_irq = omap3_init_irq,
> + .init_machine = mcx_init,
> + .timer = &omap3_timer,
> + .dt_compat = mcx_dt_match,
> +MACHINE_END
> diff --git a/arch/arm/plat-omap/include/plat/uncompress.h
> b/arch/arm/plat-omap/include/plat/uncompress.h
> index 2d45ea3..5a1bb62 100644
> --- a/arch/arm/plat-omap/include/plat/uncompress.h
> +++ b/arch/arm/plat-omap/include/plat/uncompress.h
> @@ -168,6 +168,7 @@ static inline void __arch_decomp_setup(unsigned long
> arch_id)
> DEBUG_LL_OMAP3(3, omap_ldp);
> DEBUG_LL_OMAP3(3, overo);
> DEBUG_LL_OMAP3(3, touchbook);
> + DEBUG_LL_OMAP3(3, mcx);
>
> /* omap4 based boards using UART3 */
> DEBUG_LL_OMAP4(3, omap_4430sdp);
> --
> 1.7.6.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Thanks,
Pankaj
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 4/4] mcx: initial support for HTKW mcx board
2011-11-11 0:12 ` Tony Lindgren
@ 2011-11-14 20:39 ` Ilya Yanok
2011-11-19 0:36 ` Tony Lindgren
0 siblings, 1 reply; 27+ messages in thread
From: Ilya Yanok @ 2011-11-14 20:39 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, wd, dzu, sasha_d
Hi Tony,
On 11.11.2011 04:12, Tony Lindgren wrote:
> This looks OK but let's concentrate on getting things working with
> board-generic.c and DT only in mainline kernel.
>
> I can apply this into testing-board, but let's not cause more churn
> in mainline with the board files that will be disappearing.
>
> Can you please split it into something minimal for mainline that
> allows booting with DT, and then another patch for testing-board
> branch?
Well, it already boots with DT actually. Did you mean booting with DT
and board-generic? I have to admit I don't know how to proceed here:
board-generic initialize twl4030 which we don't have on our board...
Could you give me some pointer how I'm supposed to handle this?
Regards, Ilya.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx
2011-11-09 10:10 ` Archit Taneja
2011-11-09 18:26 ` Ilya Yanok
@ 2011-11-16 21:03 ` Ilya Yanok
1 sibling, 0 replies; 27+ messages in thread
From: Ilya Yanok @ 2011-11-16 21:03 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, wd, dzu, sasha_d
Hi Archit,
On 09.11.2011 14:10, Archit Taneja wrote:
>> AM35xx don't have VDDS_DSI regulator.
>
> AM35xx do have vdds_dsi regulator. Are you saying that your particular
> board doesn't have vdds_dsi connected to a regulator?
>
> I assumed that vdds_dsi regulator was required for DPI to function
> properly on omap3 devices.
Could you please give me some pointer how to find VDDS_DSI on AM3517?
Looking at the AM3517 datasheet neither I nor board manufactured can't
find any reference of VDDS_DSI so we can't determine how it is powered.
Of course I can register fake fixed regulator from the board code but
I'd like to find the proper solution for this.
Regards, Ilya.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support
2011-11-09 0:12 ` [PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support Ilya Yanok
@ 2011-11-17 0:28 ` Ilya Yanok
2011-11-17 6:52 ` Igor Grinberg
2011-11-17 10:26 ` Tomi Valkeinen
1 sibling, 1 reply; 27+ messages in thread
From: Ilya Yanok @ 2011-11-17 0:28 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linux-omap, wd, dzu, sasha_d
Hi guys,
what about this patch? Can it be applied? It's pretty independent from
other ones.
Regards, Ilya.
On 09.11.2011 04:12, Ilya Yanok wrote:
> Add data for the FocalTech ETM070003DH6 display to the generic_dpi_panel
> display driver.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
> drivers/video/omap2/displays/panel-generic-dpi.c | 24 ++++++++++++++++++++++
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
> index 519c47d..42bfe47 100644
> --- a/drivers/video/omap2/displays/panel-generic-dpi.c
> +++ b/drivers/video/omap2/displays/panel-generic-dpi.c
> @@ -297,6 +297,30 @@ static struct panel_config generic_dpi_panels[] = {
>
> .name = "apollon",
> },
> + /* FocalTech ETM070003DH6 */
> + {
> + {
> + .x_res = 800,
> + .y_res = 480,
> +
> + .pixel_clock = 28000,
> +
> + .hsw = 48,
> + .hfp = 40,
> + .hbp = 40,
> +
> + .vsw = 3,
> + .vfp = 13,
> + .vbp = 29,
> + },
> + .acbi = 0x0,
> + .acb = 0x28,
> + .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
> + OMAP_DSS_LCD_IHS,
> + .power_on_delay = 50,
> + .power_off_delay = 100,
> + .name = "focaltech_etm070003dh6",
> + },
> };
>
> struct panel_drv_data {
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support
2011-11-17 0:28 ` Ilya Yanok
@ 2011-11-17 6:52 ` Igor Grinberg
0 siblings, 0 replies; 27+ messages in thread
From: Igor Grinberg @ 2011-11-17 6:52 UTC (permalink / raw)
To: Ilya Yanok
Cc: linux-omap, wd, dzu, sasha_d, Tomi Valkeinen,
linux-fbdev@vger.kernel.org
Hi Ilya,
You should have CC'd Tomi and linux-fbdev - done now.
On 11/17/11 02:28, Ilya Yanok wrote:
> Hi guys,
>
> what about this patch? Can it be applied? It's pretty independent from
> other ones.
>
> Regards, Ilya.
>
> On 09.11.2011 04:12, Ilya Yanok wrote:
>> Add data for the FocalTech ETM070003DH6 display to the generic_dpi_panel
>> display driver.
>>
>> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
>> ---
>> drivers/video/omap2/displays/panel-generic-dpi.c | 24 ++++++++++++++++++++++
>> 1 files changed, 24 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
>> index 519c47d..42bfe47 100644
>> --- a/drivers/video/omap2/displays/panel-generic-dpi.c
>> +++ b/drivers/video/omap2/displays/panel-generic-dpi.c
>> @@ -297,6 +297,30 @@ static struct panel_config generic_dpi_panels[] = {
>>
>> .name = "apollon",
>> },
>> + /* FocalTech ETM070003DH6 */
>> + {
>> + {
>> + .x_res = 800,
>> + .y_res = 480,
>> +
>> + .pixel_clock = 28000,
>> +
>> + .hsw = 48,
>> + .hfp = 40,
>> + .hbp = 40,
>> +
>> + .vsw = 3,
>> + .vfp = 13,
>> + .vbp = 29,
>> + },
>> + .acbi = 0x0,
>> + .acb = 0x28,
>> + .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
>> + OMAP_DSS_LCD_IHS,
>> + .power_on_delay = 50,
>> + .power_off_delay = 100,
>> + .name = "focaltech_etm070003dh6",
>> + },
>> };
>>
>> struct panel_drv_data {
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support
2011-11-09 0:12 ` [PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support Ilya Yanok
2011-11-17 0:28 ` Ilya Yanok
@ 2011-11-17 10:26 ` Tomi Valkeinen
2011-11-20 18:12 ` Ilya Yanok
2011-11-20 18:15 ` [PATCH V2] " Ilya Yanok
1 sibling, 2 replies; 27+ messages in thread
From: Tomi Valkeinen @ 2011-11-17 10:26 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linux-omap, wd, dzu, sasha_d
[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]
On Wed, 2011-11-09 at 01:12 +0100, Ilya Yanok wrote:
> Add data for the FocalTech ETM070003DH6 display to the generic_dpi_panel
> display driver.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
> drivers/video/omap2/displays/panel-generic-dpi.c | 24 ++++++++++++++++++++++
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
> index 519c47d..42bfe47 100644
> --- a/drivers/video/omap2/displays/panel-generic-dpi.c
> +++ b/drivers/video/omap2/displays/panel-generic-dpi.c
> @@ -297,6 +297,30 @@ static struct panel_config generic_dpi_panels[] = {
>
> .name = "apollon",
> },
> + /* FocalTech ETM070003DH6 */
> + {
> + {
> + .x_res = 800,
> + .y_res = 480,
> +
> + .pixel_clock = 28000,
> +
> + .hsw = 48,
> + .hfp = 40,
> + .hbp = 40,
> +
> + .vsw = 3,
> + .vfp = 13,
> + .vbp = 29,
> + },
> + .acbi = 0x0,
> + .acb = 0x28,
You could just remove .acbi and .acb, I don't think they are needed.
> + .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
> + OMAP_DSS_LCD_IHS,
> + .power_on_delay = 50,
> + .power_off_delay = 100,
Did you check from the panel spec if any delays are needed? These look
like just copied from the Sharp panel data.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 4/4] mcx: initial support for HTKW mcx board
2011-11-14 20:39 ` Ilya Yanok
@ 2011-11-19 0:36 ` Tony Lindgren
2011-11-22 0:21 ` Ilya Yanok
0 siblings, 1 reply; 27+ messages in thread
From: Tony Lindgren @ 2011-11-19 0:36 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linux-omap, wd, dzu, sasha_d
* Ilya Yanok <yanok@emcraft.com> [111114 12:04]:
> Hi Tony,
>
> On 11.11.2011 04:12, Tony Lindgren wrote:
> > This looks OK but let's concentrate on getting things working with
> > board-generic.c and DT only in mainline kernel.
> >
> > I can apply this into testing-board, but let's not cause more churn
> > in mainline with the board files that will be disappearing.
> >
> > Can you please split it into something minimal for mainline that
> > allows booting with DT, and then another patch for testing-board
> > branch?
>
> Well, it already boots with DT actually. Did you mean booting with DT
> and board-generic? I have to admit I don't know how to proceed here:
Good to hear you're already playing with it. Yes, let's work on making
all the boards work with DT and board-generic..
> board-generic initialize twl4030 which we don't have on our board...
> Could you give me some pointer how I'm supposed to handle this?
.. we should only initialize twl4030/twl6030 if the DT compatible flag
for it is set. But we're still missing the DT bindings for those :(
For now, maybe try to fix the twl4030 probe so it won't do anything
unless the I2C device is found?
Regards,
Tony
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support
2011-11-17 10:26 ` Tomi Valkeinen
@ 2011-11-20 18:12 ` Ilya Yanok
2011-11-20 18:15 ` [PATCH V2] " Ilya Yanok
1 sibling, 0 replies; 27+ messages in thread
From: Ilya Yanok @ 2011-11-20 18:12 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, wd, dzu, sasha_d
Hi Tomi,
On 17.11.2011 14:26, Tomi Valkeinen wrote:
>> + .acbi = 0x0,
>> + .acb = 0x28,
>
> You could just remove .acbi and .acb, I don't think they are needed.
You are right.
>> + .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
>> + OMAP_DSS_LCD_IHS,
>> + .power_on_delay = 50,
>> + .power_off_delay = 100,
>
> Did you check from the panel spec if any delays are needed? These look
> like just copied from the Sharp panel data.
Actually they were copied from some vendor code, but you are right
again, I can't see anything concerning the delays in the panel spec and
panel works ok with the delays thrown out.
Regards, Ilya.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH V2] omap_dss: add FocalTech ETM070003DH6 display support
2011-11-17 10:26 ` Tomi Valkeinen
2011-11-20 18:12 ` Ilya Yanok
@ 2011-11-20 18:15 ` Ilya Yanok
2011-11-22 10:04 ` Tomi Valkeinen
1 sibling, 1 reply; 27+ messages in thread
From: Ilya Yanok @ 2011-11-20 18:15 UTC (permalink / raw)
To: tomi.valkeinen, linux-omap; +Cc: wd, dzu, sasha_d, Ilya Yanok
Add data for the FocalTech ETM070003DH6 display to the generic_dpi_panel
display driver.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
Changes from V1:
- acb, acbi, power_on_delay and power_off_delay fields removed.
drivers/video/omap2/displays/panel-generic-dpi.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
index 519c47d..593f831 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -297,6 +297,26 @@ static struct panel_config generic_dpi_panels[] = {
.name = "apollon",
},
+ /* FocalTech ETM070003DH6 */
+ {
+ {
+ .x_res = 800,
+ .y_res = 480,
+
+ .pixel_clock = 28000,
+
+ .hsw = 48,
+ .hfp = 40,
+ .hbp = 40,
+
+ .vsw = 3,
+ .vfp = 13,
+ .vbp = 29,
+ },
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS,
+ .name = "focaltech_etm070003dh6",
+ },
};
struct panel_drv_data {
--
1.7.6.4
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 4/4] mcx: initial support for HTKW mcx board
2011-11-19 0:36 ` Tony Lindgren
@ 2011-11-22 0:21 ` Ilya Yanok
2011-12-08 0:04 ` Tony Lindgren
0 siblings, 1 reply; 27+ messages in thread
From: Ilya Yanok @ 2011-11-22 0:21 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, wd, dzu, sasha_d
Hi Tony,
On 19.11.2011 04:36, Tony Lindgren wrote:
>> Well, it already boots with DT actually. Did you mean booting with DT
>> and board-generic? I have to admit I don't know how to proceed here:
>
> Good to hear you're already playing with it. Yes, let's work on making
> all the boards work with DT and board-generic..
Hm, do you think it's absolutely necessary to make everybody work with
board-generic? It will require a lot of additional bindings to get rid
of all machine-specific code. I've just thought that on PowerPC we don't
have such strict rules: if some boards are really similar they share
common machine file but if we need something specific for the new board
we can create it's own machine file.
>> board-generic initialize twl4030 which we don't have on our board...
>> Could you give me some pointer how I'm supposed to handle this?
>
> .. we should only initialize twl4030/twl6030 if the DT compatible flag
> for it is set. But we're still missing the DT bindings for those :(
>
> For now, maybe try to fix the twl4030 probe so it won't do anything
> unless the I2C device is found?
That turned to be not such a big problem. Device is not present so we
have tons of error messages but somehow it works.
The bigger problem is that we have different regulator chip attached.
How am I supposed to register supplies/consumers data with it? Does
anybody working on DT bindings for the regulator framework?
Regards, Ilya.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH V2] omap_dss: add FocalTech ETM070003DH6 display support
2011-11-20 18:15 ` [PATCH V2] " Ilya Yanok
@ 2011-11-22 10:04 ` Tomi Valkeinen
0 siblings, 0 replies; 27+ messages in thread
From: Tomi Valkeinen @ 2011-11-22 10:04 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linux-omap, wd, dzu, sasha_d
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
On Sun, 2011-11-20 at 19:15 +0100, Ilya Yanok wrote:
> Add data for the FocalTech ETM070003DH6 display to the generic_dpi_panel
> display driver.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
> Changes from V1:
> - acb, acbi, power_on_delay and power_off_delay fields removed.
>
> drivers/video/omap2/displays/panel-generic-dpi.c | 20 ++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
Thanks, applied to DSS tree.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 4/4] mcx: initial support for HTKW mcx board
2011-11-22 0:21 ` Ilya Yanok
@ 2011-12-08 0:04 ` Tony Lindgren
0 siblings, 0 replies; 27+ messages in thread
From: Tony Lindgren @ 2011-12-08 0:04 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linux-omap, wd, dzu, sasha_d
* Ilya Yanok <yanok@emcraft.com> [111121 15:46]:
> Hi Tony,
>
> On 19.11.2011 04:36, Tony Lindgren wrote:
> >> Well, it already boots with DT actually. Did you mean booting with DT
> >> and board-generic? I have to admit I don't know how to proceed here:
> >
> > Good to hear you're already playing with it. Yes, let's work on making
> > all the boards work with DT and board-generic..
>
> Hm, do you think it's absolutely necessary to make everybody work with
> board-generic? It will require a lot of additional bindings to get rid
> of all machine-specific code. I've just thought that on PowerPC we don't
> have such strict rules: if some boards are really similar they share
> common machine file but if we need something specific for the new board
> we can create it's own machine file.
Well ideally yes we would remove the board files completely eventually.
But that will take a while, so I can carry your board file in testing-board
branch.
> >> board-generic initialize twl4030 which we don't have on our board...
> >> Could you give me some pointer how I'm supposed to handle this?
> >
> > .. we should only initialize twl4030/twl6030 if the DT compatible flag
> > for it is set. But we're still missing the DT bindings for those :(
> >
> > For now, maybe try to fix the twl4030 probe so it won't do anything
> > unless the I2C device is found?
>
> That turned to be not such a big problem. Device is not present so we
> have tons of error messages but somehow it works.
>
> The bigger problem is that we have different regulator chip attached.
> How am I supposed to register supplies/consumers data with it? Does
> anybody working on DT bindings for the regulator framework?
Rajendra has posted some regulator DT patches. I believe they have
a dependency to the deferred probe patches in many cases though.
Regards,
Tony
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2011-12-08 0:04 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-09 0:12 [PATCH 0/4] Support for the HTKW mcx board Ilya Yanok
2011-11-09 0:12 ` [PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx Ilya Yanok
2011-11-09 10:10 ` Archit Taneja
2011-11-09 18:26 ` Ilya Yanok
2011-11-10 6:42 ` Archit Taneja
2011-11-16 21:03 ` Ilya Yanok
2011-11-09 0:12 ` [PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support Ilya Yanok
2011-11-17 0:28 ` Ilya Yanok
2011-11-17 6:52 ` Igor Grinberg
2011-11-17 10:26 ` Tomi Valkeinen
2011-11-20 18:12 ` Ilya Yanok
2011-11-20 18:15 ` [PATCH V2] " Ilya Yanok
2011-11-22 10:04 ` Tomi Valkeinen
2011-11-09 0:12 ` [PATCH 3/4] dts/omap3: split omap3.dtsi Ilya Yanok
2011-11-10 12:18 ` Igor Grinberg
2011-11-10 17:09 ` Cousson, Benoit
2011-11-10 17:26 ` Igor Grinberg
2011-11-10 18:07 ` Cousson, Benoit
2011-11-11 7:32 ` Igor Grinberg
2011-11-09 0:12 ` [PATCH 4/4] mcx: initial support for HTKW mcx board Ilya Yanok
2011-11-10 13:08 ` Igor Grinberg
2011-11-11 0:12 ` Tony Lindgren
2011-11-14 20:39 ` Ilya Yanok
2011-11-19 0:36 ` Tony Lindgren
2011-11-22 0:21 ` Ilya Yanok
2011-12-08 0:04 ` Tony Lindgren
2011-11-13 17:56 ` Pankaj Kumar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).