[RFC 00/14] Add DT support to OMAPDSS

[RFC 00/14] Add DT support to OMAPDSS

[Tomi Valkeinen]

Hi,

This is an RFC for OMAPDSS DT support. I've only added support for a few boards
and a few DSS outputs, but they should give quite a good range of different use
cases. If these work well, I think the rest of the outputs and panels will be
ok too.

The purpose of this series is to get comments about the dts changes. There are
still work to be done, like adding DT binding documentation.

Some notes:

* DSS Submodules

The DSS submodules are children of the dss_core node. This is done because the
submodules require the dss_core to be alive and initialized to work, even if
the submodules are not really behind dss_core. Having the submodules as
children will make runtime PM automatically handle the dependency to dss_core.
I think usually a node being a child means that it's on the parent's bus, which
is not the case here. I'm not sure if that's an issue or not.

* ti,dsi-module-id

There's a ti,dsi-module-id property in the dsi node. The reason for this
module-id property is that we have muxes in the dss_core that route clocks
to/from a particular DSI module. So we need some way to index the DSI modules.
Another option would be to have a list of DSI modules (phandles) in the
dss_core. Both options feel a bit wrong to me, but I went for the module-id
approach as that is already used when not using DT.

* Display chains

Currently omapdss driver can handle only one display device connected to one
OMAP SoC output. This is not right in many cases, as there may be multiple
display devices in a chain, like first an external encoder and then a panel.
However, I tried to model this right in the dts. 

So, for example, for Panda HDMI output we have the following display "entities"
in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI
connector. These are connected using the "video-source" property, which tells
where the component in question gets its video data.

You could ask why there's a separate node for HDMI connector. It's true it's
not really a proper device, but we need some kind of terminator for the display
chains. For HDMI we could as well have an embedded solution, having a chain
like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector
marks the end of the chain, and acts as a panel in a sense.

* DSI lanes

The DSI panels contain "lanes" property, which tells how the SoCs DSI pins are
connected to the DSI panel. I'm not sure if the panel data is the proper place
for this, or should the data be separately for the OMAP DSI node.

 Tomi

Tomi Valkeinen (14):
  ARM: OMAP: remove DSS DT hack
  ARM: OMAP2+: add omapdss_init_of()
  OMAPDSS: Add DT support to DSS, DISPC, DPI
  OMAPDSS: Add DT support to DSI
  OMAPDSS: Add DT support to HDMI
  OMAPDSS: Taal: Add DT support
  OMAPDSS: TFP410: Add DT support
  OMAPDSS: panel-generic-dpi: add DT support
  ARM: omap3.dtsi: add omapdss information
  ARM: omap4.dtsi: add omapdss information
  ARM: omap4-panda.dts: add display information
  ARM: omap4-sdp.dts: add display information
  ARM: omap3-tobi.dts: add lcd (TEST)
  ARM: omap3-beagle.dts: add TFP410

 arch/arm/boot/dts/omap3-beagle.dts               |   20 +++++
 arch/arm/boot/dts/omap3-tobi.dts                 |   13 ++++
 arch/arm/boot/dts/omap3.dtsi                     |   49 ++++++++++++
 arch/arm/boot/dts/omap4-panda.dts                |   44 +++++++++++
 arch/arm/boot/dts/omap4-sdp.dts                  |   64 ++++++++++++++++
 arch/arm/boot/dts/omap4.dtsi                     |   71 +++++++++++++++++
 arch/arm/mach-omap2/board-generic.c              |    9 +--
 arch/arm/mach-omap2/common.h                     |    2 +
 arch/arm/mach-omap2/display.c                    |   34 +++++++++
 arch/arm/mach-omap2/dss-common.c                 |   24 ------
 arch/arm/mach-omap2/dss-common.h                 |    2 -
 drivers/video/omap2/displays/panel-generic-dpi.c |   47 ++++++++++++
 drivers/video/omap2/displays/panel-taal.c        |   89 ++++++++++++++++++++++
 drivers/video/omap2/displays/panel-tfp410.c      |   71 +++++++++++++++++
 drivers/video/omap2/dss/dispc.c                  |    7 ++
 drivers/video/omap2/dss/dpi.c                    |    8 ++
 drivers/video/omap2/dss/dsi.c                    |   24 +++++-
 drivers/video/omap2/dss/dss.c                    |    7 ++
 drivers/video/omap2/dss/hdmi.c                   |    7 ++
 drivers/video/omap2/dss/hdmi_panel.c             |   86 ++++++++++++++++++++-
 20 files changed, 641 insertions(+), 37 deletions(-)

-- 
1.7.10.4

[RFC 01/14] ARM: OMAP: remove DSS DT hack

[Tomi Valkeinen]

As a temporary solution to enable DSS for selected boards when booting
with DT, a hack was added to board-generic.c in
63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable
DSS for panda & sdp boards).

We're now adding proper DT support, so the hack can be removed.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/board-generic.c |    8 --------
 arch/arm/mach-omap2/dss-common.c    |   24 ------------------------
 arch/arm/mach-omap2/dss-common.h    |    2 --
 3 files changed, 34 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index e54a480..a61544b 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -41,14 +41,6 @@ static void __init omap_generic_init(void)
 
 	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
 
-	/*
-	 * HACK: call display setup code for selected boards to enable omapdss.
-	 * This will be removed when omapdss supports DT.
-	 */
-	if (of_machine_is_compatible("ti,omap4-panda"))
-		omap4_panda_display_init_of();
-	else if (of_machine_is_compatible("ti,omap4-sdp"))
-		omap_4430sdp_display_init_of();
 }
 
 #ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index a10c56b..78e409a 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -93,13 +93,6 @@ void __init omap4_panda_display_init(void)
 	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
 }
 
-void __init omap4_panda_display_init_of(void)
-{
-	omap_display_init(&omap4_panda_dss_data);
-	platform_device_register(&omap4_panda_tfp410_device);
-	platform_device_register(&omap4_panda_hdmi_device);
-}
-
 
 /* OMAP4 Blaze display data */
 
@@ -242,20 +235,3 @@ void __init omap_4430sdp_display_init(void)
 	omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
 	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
 }
-
-void __init omap_4430sdp_display_init_of(void)
-{
-	int r;
-
-	/* Enable LCD2 by default (instead of Pico DLP) */
-	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
-			"display_sel");
-	if (r)
-		pr_err("%s: Could not get display_sel GPIO\n", __func__);
-
-	sdp4430_picodlp_init();
-	omap_display_init(&sdp4430_dss_data);
-	platform_device_register(&sdp4430_hdmi_device);
-	platform_device_register(&sdp4430_lcd1_device);
-	platform_device_register(&sdp4430_lcd2_device);
-}
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index 915f6ff..611b341 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -7,8 +7,6 @@
  */
 
 void __init omap4_panda_display_init(void);
-void __init omap4_panda_display_init_of(void);
 void __init omap_4430sdp_display_init(void);
-void __init omap_4430sdp_display_init_of(void);
 
 #endif
-- 
1.7.10.4

[RFC 02/14] ARM: OMAP2+: add omapdss_init_of()

[Tomi Valkeinen]

omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.

This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/board-generic.c |    1 +
 arch/arm/mach-omap2/common.h        |    2 ++
 arch/arm/mach-omap2/display.c       |   34 ++++++++++++++++++++++++++++++++++
 3 files changed, 37 insertions(+)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index a61544b..29eb085 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -41,6 +41,7 @@ static void __init omap_generic_init(void)
 
 	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
 
+	omapdss_init_of();
 }
 
 #ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 40f4a03..e9ac1fd 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -293,5 +293,7 @@ extern void omap_reserve(void);
 struct omap_hwmod;
 extern int omap_dss_reset(struct omap_hwmod *);
 
+int __init omapdss_init_of(void);
+
 #endif /* __ASSEMBLER__ */
 #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index ff37be1..c62aee0 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -23,6 +23,8 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
 
 #include <video/omapdss.h>
 #include "omap_hwmod.h"
@@ -564,3 +566,35 @@ int omap_dss_reset(struct omap_hwmod *oh)
 
 	return r;
 }
+
+int __init omapdss_init_of(void)
+{
+	int r;
+	enum omapdss_version ver;
+
+	static struct omap_dss_board_info board_data = {
+		.dsi_enable_pads = omap_dsi_enable_pads,
+		.dsi_disable_pads = omap_dsi_disable_pads,
+		.get_context_loss_count = omap_pm_get_dev_context_loss_count,
+		.set_min_bus_tput = omap_dss_set_min_bus_tput,
+	};
+
+	ver = omap_display_get_version();
+
+	if (ver == OMAPDSS_VER_UNKNOWN) {
+		pr_err("DSS not supported on this SoC\n");
+		return -ENODEV;
+	}
+
+	board_data.version = ver;
+
+	omap_display_device.dev.platform_data = &board_data;
+
+	r = platform_device_register(&omap_display_device);
+	if (r < 0) {
+		pr_err("Unable to register omapdss device\n");
+		return r;
+	}
+
+	return 0;
+}
-- 
1.7.10.4

[RFC 03/14] OMAPDSS: Add DT support to DSS, DISPC, DPI

[Tomi Valkeinen]

Add the code to make DSS, DISPC and DPI drivers work with device tree on
OMAP3 and OMAP4. The only change is adding the of_match_tables.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/dispc.c |    7 +++++++
 drivers/video/omap2/dss/dpi.c   |    8 ++++++++
 drivers/video/omap2/dss/dss.c   |    7 +++++++
 3 files changed, 22 insertions(+)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 8cfa27b..be53d64 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3705,12 +3705,19 @@ static const struct dev_pm_ops dispc_pm_ops = {
 	.runtime_resume = dispc_runtime_resume,
 };
 
+static const struct of_device_id dispc_of_match[] = {
+	{ .compatible = "ti,omap3-dispc", },
+	{ .compatible = "ti,omap4-dispc", },
+	{},
+};
+
 static struct platform_driver omap_dispchw_driver = {
 	.remove         = __exit_p(omap_dispchw_remove),
 	.driver         = {
 		.name   = "omapdss_dispc",
 		.owner  = THIS_MODULE,
 		.pm	= &dispc_pm_ops,
+		.of_match_table = dispc_of_match,
 	},
 };
 
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index e7beea2..dc7e324 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -30,6 +30,7 @@
 #include <linux/platform_device.h>
 #include <linux/regulator/consumer.h>
 #include <linux/string.h>
+#include <linux/of.h>
 
 #include <video/omapdss.h>
 
@@ -765,11 +766,18 @@ static int __exit omap_dpi_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id dpi_of_match[] = {
+	{ .compatible = "ti,omap3-dpi", },
+	{ .compatible = "ti,omap4-dpi", },
+	{},
+};
+
 static struct platform_driver omap_dpi_driver = {
 	.remove         = __exit_p(omap_dpi_remove),
 	.driver         = {
 		.name   = "omapdss_dpi",
 		.owner  = THIS_MODULE,
+		.of_match_table = dpi_of_match,
 	},
 };
 
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 62db201..dc721f4 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -962,12 +962,19 @@ static const struct dev_pm_ops dss_pm_ops = {
 	.runtime_resume = dss_runtime_resume,
 };
 
+static const struct of_device_id dss_of_match[] = {
+	{ .compatible = "ti,omap3-dss", },
+	{ .compatible = "ti,omap4-dss", },
+	{},
+};
+
 static struct platform_driver omap_dsshw_driver = {
 	.remove         = __exit_p(omap_dsshw_remove),
 	.driver         = {
 		.name   = "omapdss_dss",
 		.owner  = THIS_MODULE,
 		.pm	= &dss_pm_ops,
+		.of_match_table = dss_of_match,
 	},
 };
 
-- 
1.7.10.4

[RFC 04/14] OMAPDSS: Add DT support to DSI

[Tomi Valkeinen]

Add the code to make the DSI driver work with device tree on OMAP3 and
OMAP4. The of_match_table is added, and also a bit hacky
"ti,dsi-module-id" DT property, which tells the DSI ID number.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/dsi.c |   24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index fb77aa8..1058cab 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -38,6 +38,7 @@
 #include <linux/slab.h>
 #include <linux/debugfs.h>
 #include <linux/pm_runtime.h>
+#include <linux/of.h>
 
 #include <video/omapdss.h>
 #include <video/mipi_display.h>
@@ -5541,7 +5542,20 @@ static int __init omap_dsihw_probe(struct platform_device *dsidev)
 	if (!dsi)
 		return -ENOMEM;
 
-	dsi->module_id = dsidev->id;
+	if (dsidev->dev.of_node) {
+		u32 id;
+		r = of_property_read_u32(dsidev->dev.of_node,
+				"ti,dsi-module-id", &id);
+		if (r) {
+			DSSERR("failed to read DSI module ID\n");
+			return r;
+		}
+
+		dsi->module_id = id;
+	} else {
+		dsi->module_id = dsidev->id;
+	}
+
 	dsi->pdev = dsidev;
 	dev_set_drvdata(&dsidev->dev, dsi);
 
@@ -5642,6 +5656,7 @@ static int __init omap_dsihw_probe(struct platform_device *dsidev)
 	else if (dsi->module_id == 1)
 		dss_debugfs_create_file("dsi2_irqs", dsi2_dump_irqs);
 #endif
+
 	return 0;
 
 err_runtime_get:
@@ -5700,12 +5715,19 @@ static const struct dev_pm_ops dsi_pm_ops = {
 	.runtime_resume = dsi_runtime_resume,
 };
 
+static const struct of_device_id dsi_of_match[] = {
+	{ .compatible = "ti,omap3-dsi", },
+	{ .compatible = "ti,omap4-dsi", },
+	{},
+};
+
 static struct platform_driver omap_dsihw_driver = {
 	.remove         = __exit_p(omap_dsihw_remove),
 	.driver         = {
 		.name   = "omapdss_dsi",
 		.owner  = THIS_MODULE,
 		.pm	= &dsi_pm_ops,
+		.of_match_table = dsi_of_match,
 	},
 };
 
-- 
1.7.10.4

[RFC 05/14] OMAPDSS: Add DT support to HDMI

[Tomi Valkeinen]

Add the code to make the HDMI driver work with device tree.

The OMAP SoC HDMI (hdmi.c) change is simple, just add of_match_table.

The hdmi_panel.c is a bit more complex. We model both the TPD12S015 chip
and the HDMI connector, and handle both in the same driver. In the
future those should be separate drivers.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/hdmi.c       |    7 +++
 drivers/video/omap2/dss/hdmi_panel.c |   86 +++++++++++++++++++++++++++++++++-
 2 files changed, 91 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index f9e38c4..e7a18d3 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -34,6 +34,7 @@
 #include <linux/clk.h>
 #include <linux/gpio.h>
 #include <linux/regulator/consumer.h>
+#include <linux/of_gpio.h>
 #include <video/omapdss.h>
 
 #include "ti_hdmi.h"
@@ -1202,12 +1203,18 @@ static const struct dev_pm_ops hdmi_pm_ops = {
 	.runtime_resume = hdmi_runtime_resume,
 };
 
+static const struct of_device_id hdmi_of_match[] = {
+	{ .compatible = "ti,omap4-hdmi", },
+	{},
+};
+
 static struct platform_driver omapdss_hdmihw_driver = {
 	.remove         = __exit_p(omapdss_hdmihw_remove),
 	.driver         = {
 		.name   = "omapdss_hdmi",
 		.owner  = THIS_MODULE,
 		.pm	= &hdmi_pm_ops,
+		.of_match_table = hdmi_of_match,
 	},
 };
 
diff --git a/drivers/video/omap2/dss/hdmi_panel.c b/drivers/video/omap2/dss/hdmi_panel.c
index bc4dea3..8dffd5d 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -27,12 +27,16 @@
 #include <video/omapdss.h>
 #include <linux/slab.h>
 #include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
 
 #include "dss.h"
 
 static struct {
 	struct omap_dss_device dssdev;
 
+	struct omap_dss_hdmi_data pdata;
+
 	/* This protects the panel ops, mainly when accessing the HDMI IP. */
 	struct mutex lock;
 #if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
@@ -43,6 +47,62 @@ static struct {
 
 static struct omap_dss_driver hdmi_driver;
 
+static int hdmi_panel_probe_pdata(struct platform_device *pdev)
+{
+	const struct omap_dss_hdmi_data *pdata = dev_get_platdata(&pdev->dev);
+
+	hdmi.pdata = *pdata;
+
+	return 0;
+}
+
+static int hdmi_parse_tpd12s015_of(struct device_node *node,
+		struct omap_dss_hdmi_data *pdata)
+{
+	int gpio;
+
+	gpio = of_get_gpio(node, 0);	/* CT CP HPD */
+	if (!gpio_is_valid(gpio))
+		return -EINVAL;
+	pdata->ct_cp_hpd_gpio = gpio;
+
+	gpio = of_get_gpio(node, 1);	/* LS OE */
+	if (!gpio_is_valid(gpio))
+		return -EINVAL;
+	pdata->ls_oe_gpio = gpio;
+
+	gpio = of_get_gpio(node, 2);	/* HPD */
+	if (!gpio_is_valid(gpio))
+		return -EINVAL;
+	pdata->hpd_gpio = gpio;
+
+	return 0;
+}
+
+static int hdmi_panel_probe_of(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	struct device_node *src_node;
+	int r;
+
+	/*
+	 * We don't have a real driver for the TPD12S015 chip, but it is
+	 * modeled right in the DT data. So we need to parse the TPD12S015 data
+	 * here.
+	 */
+	src_node = of_parse_phandle(node, "video-source", 0);
+	if (!src_node) {
+		dev_err(&pdev->dev, "failed to parse video source\n");
+		return -ENODEV;
+	}
+
+	r = hdmi_parse_tpd12s015_of(src_node, &hdmi.pdata);
+	if (r)
+		return r;
+
+	return 0;
+}
+
 static int hdmi_panel_probe(struct platform_device *pdev)
 {
 	/* Initialize default timings to VGA in DVI mode */
@@ -63,12 +123,28 @@ static int hdmi_panel_probe(struct platform_device *pdev)
 		.interlace	= false,
 	};
 
-	struct omap_dss_hdmi_data *pdata = dev_get_platdata(&pdev->dev);
 	struct omap_dss_device *dssdev = &hdmi.dssdev;
 	int r;
 
 	DSSDBG("ENTER hdmi_panel_probe\n");
 
+	if (dev_get_platdata(&pdev->dev)) {
+		r = hdmi_panel_probe_pdata(pdev);
+		if (r) {
+			dev_err(&pdev->dev, "failed to read platform data\n");
+			return r;
+		}
+	} else if (pdev->dev.of_node) {
+		r = hdmi_panel_probe_of(pdev);
+		if (r) {
+			dev_err(&pdev->dev, "failed to parse OF data\n");
+			return r;
+		}
+	} else {
+		return -ENODEV;
+	}
+
+
 	dssdev->panel.timings = default_timings;
 	dssdev->driver = &hdmi_driver;
 	dssdev->name = "hdmi";
@@ -78,7 +154,7 @@ static int hdmi_panel_probe(struct platform_device *pdev)
 	 * XXX for now, the hdmi panel's platform data contains the gpios for
 	 * the tpd level shifter chip, so we pass this data to the hdmi driver.
 	 */
-	dssdev->data = pdata;
+	dssdev->data = &hdmi.pdata;
 
 	DSSDBG("hdmi_panel_probe x_res= %d y_res = %d\n",
 		dssdev->panel.timings.x_res,
@@ -415,12 +491,18 @@ static struct omap_dss_driver hdmi_driver = {
 	.audio_config	= hdmi_panel_audio_config,
 };
 
+static const struct of_device_id hdmi_panel_of_match[] = {
+	{ .compatible = "ti,hdmi_connector", },
+	{},
+};
+
 static struct platform_driver hdmi_panel_platform_driver = {
 	.probe	= hdmi_panel_probe,
 	.remove	= hdmi_panel_remove,
 	.driver	= {
 		.name	= "hdmi_panel",
 		.owner	= THIS_MODULE,
+		.of_match_table = hdmi_panel_of_match,
 	},
 };
 
-- 
1.7.10.4

[RFC 06/14] OMAPDSS: Taal: Add DT support

[Tomi Valkeinen]

Add DT support to Taal panel driver.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/displays/panel-taal.c |   89 +++++++++++++++++++++++++++++
 1 file changed, 89 insertions(+)

diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
index 01de2a9..f8771da 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -32,6 +32,8 @@
 #include <linux/slab.h>
 #include <linux/mutex.h>
 #include <linux/platform_device.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
 
 #include <video/omapdss.h>
 #include <video/omap-panel-nokia-dsi.h>
@@ -788,6 +790,81 @@ static int taal_probe_pdata(struct platform_device *pdev)
 	return 0;
 }
 
+static int taal_probe_of(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	struct taal_data *td = dev_get_drvdata(&pdev->dev);
+	struct property *prop;
+	struct device_node *src_node;
+	u32 lane_arr[10];
+	int gpio, len, num_pins;
+	int r, i;
+
+	src_node = of_parse_phandle(node, "video-source", 0);
+	if (!src_node) {
+		dev_err(&pdev->dev, "failed to parse video source\n");
+		return -ENODEV;
+	}
+
+	td->src = omap_dss_find_output_by_node(src_node);
+	if (!td->src) {
+		dev_err(&pdev->dev, "failed to find video source\n");
+		return -ENODEV;
+	}
+
+	gpio = of_get_gpio(node, 0);
+
+	if (gpio_is_valid(gpio)) {
+		td->reset_gpio = gpio;
+	} else {
+		dev_err(&pdev->dev, "failed to parse reset gpio\n");
+		return gpio;
+	}
+
+	if (of_gpio_count(node) > 1) {
+		gpio = of_get_gpio(node, 1);
+
+		if (gpio_is_valid(gpio)) {
+			td->ext_te_gpio = gpio;
+		} else if (gpio == -ENOENT) {
+			td->ext_te_gpio = -1;
+		} else {
+			dev_err(&pdev->dev, "failed to parse TE gpio\n");
+			return gpio;
+		}
+	} else {
+		td->ext_te_gpio = -1;
+	}
+
+	prop = of_find_property(node, "lanes", &len);
+	if (prop == NULL) {
+		dev_err(&pdev->dev, "failed to find lane data\n");
+		return -EINVAL;
+	}
+
+	num_pins = len / sizeof(u32);
+
+	if (num_pins < 4 || num_pins % 2 != 0
+			|| num_pins > ARRAY_SIZE(lane_arr)) {
+		dev_err(&pdev->dev, "bad number of lanes\n");
+		return -EINVAL;
+	}
+
+	r = of_property_read_u32_array(node, "lanes", lane_arr, num_pins);
+	if (r) {
+		dev_err(&pdev->dev, "failed to read lane data\n");
+		return r;
+	}
+
+	td->pin_config.num_pins = num_pins;
+	for (i = 0; i < num_pins; ++i)
+		td->pin_config.pins[i] = (int)lane_arr[i];
+
+	td->dssdev.name = node->name;
+
+	return 0;
+}
+
 static int taal_probe(struct platform_device *pdev)
 {
 	const struct nokia_dsi_panel_data *pdata = dev_get_platdata(&pdev->dev);
@@ -813,6 +890,12 @@ static int taal_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev, "failed to read platform data\n");
 			return r;
 		}
+	} else if (pdev->dev.of_node) {
+		r = taal_probe_of(pdev);
+		if (r) {
+			dev_err(&pdev->dev, "failed to parse OF data\n");
+			return r;
+		}
 	} else {
 		return -ENODEV;
 	}
@@ -1576,12 +1659,18 @@ static struct omap_dss_driver taal_driver = {
 	.memory_read	= taal_memory_read,
 };
 
+static const struct of_device_id taal_of_match[] = {
+	{ .compatible = "tpo,taal", },
+	{},
+};
+
 static struct platform_driver taal_platform_driver = {
 	.probe	= taal_probe,
 	.remove	= __exit_p(taal_remove),
 	.driver	= {
 		.name	= "taal",
 		.owner	= THIS_MODULE,
+		.of_match_table = taal_of_match,
 	},
 };
 
-- 
1.7.10.4

[RFC 07/14] OMAPDSS: TFP410: Add DT support

[Tomi Valkeinen]

In the DT data we model the TFP410 chip and the DVI connector. For the
moment we have only 1 driver to handle those both.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/displays/panel-tfp410.c |   71 +++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
index a225ea1..a087489c 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -24,6 +24,8 @@
 #include <linux/gpio.h>
 #include <linux/platform_device.h>
 #include <drm/drm_edid.h>
+#include <linux/of_gpio.h>
+#include <linux/of_i2c.h>
 
 #include <video/omap-panel-tfp410.h>
 
@@ -112,6 +114,63 @@ static int tfp410_probe_pdata(struct platform_device *pdev)
 	return 0;
 }
 
+static int tfp410_probe_of(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	struct panel_drv_data *ddata = dev_get_drvdata(&pdev->dev);
+	struct device_node *adapter_node;
+	struct i2c_adapter *adapter;
+	int r, gpio, datalines;
+
+	ddata->name = node->name;
+
+	node = of_parse_phandle(node, "video-source", 0);
+	if (!node) {
+		dev_err(&pdev->dev, "failed to parse video source\n");
+		return -ENODEV;
+	}
+
+	gpio = of_get_gpio(node, 0);
+
+	if (gpio_is_valid(gpio)) {
+		r = devm_gpio_request_one(&pdev->dev, gpio,
+				GPIOF_OUT_INIT_LOW, "tfp410 pd");
+		if (r) {
+			dev_err(&pdev->dev, "Failed to request PD GPIO %d\n",
+					gpio);
+			return r;
+		}
+
+		ddata->pd_gpio = gpio;
+	} else if (gpio == -ENOENT) {
+		ddata->pd_gpio = -1;
+	} else {
+		dev_err(&pdev->dev, "failed to parse PD gpio\n");
+		return gpio;
+	}
+
+	r = of_property_read_u32(node, "data-lines", &datalines);
+	if (r) {
+		dev_err(&pdev->dev, "failed to parse datalines");
+		return r;
+	}
+
+	ddata->data_lines = datalines;
+
+	adapter_node = of_parse_phandle(node, "i2c-bus", 0);
+	if (adapter_node) {
+		adapter = of_find_i2c_adapter_by_node(adapter_node);
+		if (adapter == NULL) {
+			dev_err(&pdev->dev, "failed to parse i2c-bus\n");
+			return -EINVAL;
+		}
+
+		ddata->i2c_adapter = adapter;
+	}
+
+	return 0;
+}
+
 static int tfp410_probe(struct platform_device *pdev)
 {
 	struct tfp410_platform_data *pdata = dev_get_platdata(&pdev->dev);
@@ -131,6 +190,10 @@ static int tfp410_probe(struct platform_device *pdev)
 		r = tfp410_probe_pdata(pdev);
 		if (r)
 			return r;
+	} else if (pdev->dev.of_node) {
+		r = tfp410_probe_of(pdev);
+		if (r)
+			return r;
 	} else {
 		return -ENODEV;
 	}
@@ -380,12 +443,20 @@ static struct omap_dss_driver tfp410_driver = {
 	.detect		= tfp410_detect,
 };
 
+static const struct of_device_id tfp410_of_match[] = {
+	{
+		.compatible = "ti,dvi_connector",
+	},
+	{},
+};
+
 static struct platform_driver tfp410_platform_driver = {
 	.probe	= tfp410_probe,
 	.remove	= __exit_p(tfp410_remove),
 	.driver	= {
 		.name	= "tfp410",
 		.owner	= THIS_MODULE,
+		.of_match_table = tfp410_of_match,
 	},
 };
 
-- 
1.7.10.4

[RFC 08/14] OMAPDSS: panel-generic-dpi: add DT support

[Tomi Valkeinen]

Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
 drivers/video/omap2/displays/panel-generic-dpi.c |   47 ++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
index cc49c48..a00c942 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -34,6 +34,7 @@
 #include <linux/delay.h>
 #include <linux/slab.h>
 #include <linux/platform_device.h>
+#include <linux/of.h>
 #include <video/omapdss.h>
 
 #include <video/omap-panel-generic-dpi.h>
@@ -618,6 +619,42 @@ static int generic_dpi_panel_probe_pdata(struct platform_device *pdev)
 	return 0;
 }
 
+static int generic_dpi_panel_probe_of(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	struct panel_drv_data *drv_data = dev_get_drvdata(&pdev->dev);
+	struct panel_config *panel_config = NULL;
+	int r, i;
+	int datalines;
+	const char *panel_name;
+
+	r = of_property_read_string(node, "panel-name", &panel_name);
+	if (r)
+		return r;
+
+	for (i = 0; i < ARRAY_SIZE(generic_dpi_panels); i++) {
+		if (strcmp(panel_name, generic_dpi_panels[i].name) == 0) {
+			panel_config = &generic_dpi_panels[i];
+			break;
+		}
+	}
+
+	if (!panel_config)
+		return -EINVAL;
+
+	r = of_property_read_u32(node, "data-lines", &datalines);
+	if (r) {
+		dev_err(&pdev->dev, "failed to parse datalines");
+		return r;
+	}
+
+	drv_data->panel_config = panel_config;
+	drv_data->name = node->name;
+	drv_data->data_lines = datalines;
+
+	return 0;
+}
+
 static int generic_dpi_panel_probe(struct platform_device *pdev)
 {
 	struct panel_drv_data *drv_data;
@@ -636,6 +673,10 @@ static int generic_dpi_panel_probe(struct platform_device *pdev)
 		r = generic_dpi_panel_probe_pdata(pdev);
 		if (r)
 			return r;
+	} else if (pdev->dev.of_node) {
+		r = generic_dpi_panel_probe_of(pdev);
+		if (r)
+			return r;
 	} else {
 		return -EINVAL;
 	}
@@ -754,12 +795,18 @@ static struct omap_dss_driver generic_dpi_panel_driver = {
 	.get_resolution	= omapdss_default_get_resolution,
 };
 
+static const struct of_device_id generic_dpi_panel_of_match[] = {
+	{ .compatible = "ti,dpi_panel", },
+	{},
+};
+
 static struct platform_driver generic_dpi_panel_platform_driver = {
 	.probe	= generic_dpi_panel_probe,
 	.remove	= __exit_p(generic_dpi_panel_remove),
 	.driver	= {
 		.name	= "generic_dpi_panel",
 		.owner	= THIS_MODULE,
+		.of_match_table = generic_dpi_panel_of_match,
 	},
 };
 
-- 
1.7.10.4

[RFC 09/14] ARM: omap3.dtsi: add omapdss information

[Tomi Valkeinen]

Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/omap3.dtsi |   49 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..49de390 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,54 @@
 			ti,timer-alwon;
 			ti,timer-secure;
 		};
+
+		dss@48050000 {
+			compatible = "ti,omap3-dss", "simple-bus";
+			reg = <0x48050000 0x200>;
+			ti,hwmods = "dss_core";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			dispc@48050400 {
+				compatible = "ti,omap3-dispc";
+				reg = <0x48050400 0x400>;
+				interrupts = <25>;
+				ti,hwmods = "dss_dispc";
+			};
+
+			dpi: dpi {
+				compatible = "ti,omap3-dpi";
+			};
+
+			sdi: sdi {
+				compatible = "ti,omap3-sdi";
+			};
+
+			dsi: dsi@4804fc00 {
+				compatible = "ti,omap3-dsi";
+				reg = <0x4804fc00 0x400>;
+				interrupts = <25>;
+				ti,hwmods = "dss_dsi1";
+
+				/*
+				 * XXX dss_core needs to know module-id,
+				 * so this data should be there.
+				 */
+				ti,dsi-module-id = <0>;
+			};
+
+			rfbi: rfbi@48050800 {
+				compatible = "ti,omap3-rfbi";
+				reg = <0x48050800 0x100>;
+				ti,hwmods = "dss_rfbi";
+			};
+
+			venc: venc@48050c00 {
+				compatible = "ti,omap3-venc";
+				reg = <0x48050c00 0x100>;
+				ti,hwmods = "dss_venc";
+			};
+		};
 	};
 };
-- 
1.7.10.4

[RFC 10/14] ARM: omap4.dtsi: add omapdss information

[Tomi Valkeinen]

Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/omap4.dtsi |   71 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..967f706 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,76 @@
 			ti,hwmods = "timer11";
 			ti,timer-pwm;
 		};
+
+		dss@58000000 {
+			compatible = "ti,omap4-dss", "simple-bus";
+			reg = <0x58000000 0x80>;
+			ti,hwmods = "dss_core";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			dispc@58001000 {
+				compatible = "ti,omap4-dispc";
+				reg = <0x58001000 0x1000>;
+				interrupts = <0 25 0x4>;
+				ti,hwmods = "dss_dispc";
+			};
+
+			dpi: dpi {
+				compatible = "ti,omap4-dpi";
+			};
+
+			rfbi: rfbi@58002000  {
+				compatible = "ti,omap4-rfbi";
+				reg = <0x58002000 0x1000>;
+				ti,hwmods = "dss_rfbi";
+			};
+
+			/*
+			 * Accessing venc registers cause a crash on omap4, so
+			 * this is disabled for now.
+			 */
+			/*
+			venc: venc@58003000 {
+				compatible = "ti,omap4-venc";
+				reg = <0x58003000 0x1000>;
+				ti,hwmods = "dss_venc";
+			};
+			*/
+
+			dsi1: dsi@58004000 {
+				compatible = "ti,omap4-dsi";
+				reg = <0x58004000 0x200>;
+				interrupts = <0 53 0x4>;
+				ti,hwmods = "dss_dsi1";
+
+				/*
+				 * XXX dss_core needs to know module-id,
+				 * so this data should be there.
+				 */
+				ti,dsi-module-id = <0>;
+			};
+
+			dsi2: dsi@58005000 {
+				compatible = "ti,omap4-dsi";
+				reg = <0x58005000 0x200>;
+				interrupts = <0 84 0x4>;
+				ti,hwmods = "dss_dsi2";
+
+				/*
+				 * XXX dss_core needs to know module-id,
+				 * so this data should be there.
+				 */
+				ti,dsi-module-id = <1>;
+			};
+
+			hdmi: hdmi@58006000 {
+				compatible = "ti,omap4-hdmi";
+				reg = <0x58006000 0x1000>;
+				interrupts = <0 101 0x4>;
+				ti,hwmods = "dss_hdmi";
+			};
+		};
 	};
 };
-- 
1.7.10.4

[RFC 11/14] ARM: omap4-panda.dts: add display information

[Tomi Valkeinen]

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/boot/dts/omap4-panda.dts |   44 +++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..45dd40a 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -206,3 +206,47 @@
 &twl_usb_comparator {
 	usb-supply = <&vusb>;
 };
+
+&dsi1 {
+	vdds_dsi-supply = <&vcxio>;
+};
+
+&dsi2 {
+	vdds_dsi-supply = <&vcxio>;
+};
+
+&hdmi {
+	vdda_hdmi_dac-supply = <&vdac>;
+};
+
+/ {
+	tfp410: tfp410 {
+		compatible = "ti,tfp410";
+		video-source = <&dpi>;
+		data-lines = <24>;
+		gpios = <&gpio1 0 0>;	/* 0, power-down */
+		i2c-bus = <&i2c3>;
+	};
+
+	dvi {
+		compatible = "ti,dvi_connector";
+
+		video-source = <&tfp410>;
+	};
+
+	tpd12s015: tpd12s015 {
+		compatible = "ti,tpd12s015";
+
+		video-source = <&hdmi>;
+
+		gpios = <&gpio2 28 0>,	/* 60, CT CP HPD */
+			<&gpio2 9 0>,	/* 41, LS OE */
+			<&gpio2 31 0>;	/* 63, HPD */
+	};
+
+	hdmi {
+		compatible = "ti,hdmi_connector";
+
+		video-source = <&tpd12s015>;
+	};
+};
-- 
1.7.10.4

[RFC 12/14] ARM: omap4-sdp.dts: add display information

[Tomi Valkeinen]

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/boot/dts/omap4-sdp.dts |   64 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..3bef36e 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -428,3 +428,67 @@
 &twl_usb_comparator {
 	usb-supply = <&vusb>;
 };
+
+&dsi1 {
+	vdds_dsi-supply = <&vcxio>;
+};
+
+&dsi2 {
+	vdds_dsi-supply = <&vcxio>;
+};
+
+&hdmi {
+	vdda_hdmi_dac-supply = <&vdac>;
+};
+
+/ {
+	lcd {
+		compatible = "tpo,taal";
+
+		video-source = <&dsi1>;
+
+		lanes = <
+			0       /* clk + */
+			1       /* clk - */
+			2       /* data1 + */
+			3       /* data1 - */
+			4       /* data2 + */
+			5       /* data2 - */
+		>;
+
+		gpios = <&gpio4 6 0>;	/* 102, reset */
+	};
+
+	lcd2 {
+		compatible = "tpo,taal";
+
+		video-source = <&dsi2>;
+
+		lanes = <
+			0       /* clk + */
+			1       /* clk - */
+			2       /* data1 + */
+			3       /* data1 - */
+			4       /* data2 + */
+			5       /* data2 - */
+		>;
+
+		gpios = <&gpio4 8 0>;	/* 104, reset */
+	};
+
+	tpd12s015: tpd12s015 {
+		compatible = "ti,tpd12s015";
+
+		video-source = <&hdmi>;
+
+		gpios = <&gpio2 28 0>,	/* 60, CT CP HPD */
+			<&gpio2 9 0>,	/* 41, LS OE */
+			<&gpio2 31 0>;	/* 63, HPD */
+	};
+
+	hdmi {
+		compatible = "ti,hdmi_connector";
+
+		video-source = <&tpd12s015>;
+	};
+};
-- 
1.7.10.4

[RFC 13/14] ARM: omap3-tobi.dts: add lcd (TEST)

[Tomi Valkeinen]

This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
it as a test.

Not to be merged.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/omap3-tobi.dts |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
index a13d12d..68e3c1b 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -33,3 +33,16 @@
 &mmc3 {
 	status = "disabled";
 };
+
+&dpi {
+	vdds_dsi-supply = <&vpll2>;
+};
+
+/ {
+	lcd43 {
+		compatible = "ti,dpi_panel";
+		video-source = <&dpi>;
+		data-lines = <24>;
+		panel-name = "samsung_lte430wq_f0c";
+	};
+};
-- 
1.7.10.4

[RFC 14/14] ARM: omap3-beagle.dts: add TFP410

[Tomi Valkeinen]

Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/omap3-beagle.dts |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..84785e7 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -65,3 +65,23 @@
 &mmc3 {
 	status = "disabled";
 };
+
+&dpi {
+	vdds_dsi-supply = <&vpll2>;
+};
+
+/ {
+	tfp410: tfp410 {
+		compatible = "ti,tfp410";
+		video-source = <&dpi>;
+		data-lines = <24>;
+		gpios = <&gpio5 10 0>;	/* 170, power-down */
+		i2c-bus = <&i2c3>;
+	};
+
+	dvi {
+		compatible = "ti,dvi_connector";
+
+		video-source = <&tfp410>;
+	};
+};
-- 
1.7.10.4

Re: [RFC 02/14] ARM: OMAP2+: add omapdss_init_of()

[Benoit Cousson]

Hi Tomi,

On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
> omapdss driver uses a omapdss platform device to pass platform specific
> function pointers and DSS hardware version from the arch code to the
> driver. This device is needed also when booting with DT.
> 
> This patch adds omapdss_init_of() function, called from board-generic at
> init time, which creates the omapdss device.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>  arch/arm/mach-omap2/board-generic.c |    1 +
>  arch/arm/mach-omap2/common.h        |    2 ++
>  arch/arm/mach-omap2/display.c       |   34 ++++++++++++++++++++++++++++++++++
>  3 files changed, 37 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index a61544b..29eb085 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -41,6 +41,7 @@ static void __init omap_generic_init(void)
>  
>  	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>  
> +	omapdss_init_of();

Mmm, you should not have to call that explicitly. It looks like a hack
to me. Everything in theory should be initialized during
of_platform_populate / driver probe.

>  }
>  
>  #ifdef CONFIG_SOC_OMAP2420
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 40f4a03..e9ac1fd 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -293,5 +293,7 @@ extern void omap_reserve(void);
>  struct omap_hwmod;
>  extern int omap_dss_reset(struct omap_hwmod *);
>  
> +int __init omapdss_init_of(void);
> +
>  #endif /* __ASSEMBLER__ */
>  #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index ff37be1..c62aee0 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -23,6 +23,8 @@
>  #include <linux/clk.h>
>  #include <linux/err.h>
>  #include <linux/delay.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
>  
>  #include <video/omapdss.h>
>  #include "omap_hwmod.h"
> @@ -564,3 +566,35 @@ int omap_dss_reset(struct omap_hwmod *oh)
>  
>  	return r;
>  }
> +
> +int __init omapdss_init_of(void)
> +{
> +	int r;
> +	enum omapdss_version ver;
> +
> +	static struct omap_dss_board_info board_data = {
> +		.dsi_enable_pads = omap_dsi_enable_pads,
> +		.dsi_disable_pads = omap_dsi_disable_pads,

Pads config should be handle by pinmux framework is possible. Otherwise
a dedicated driver will be required.

> +		.get_context_loss_count = omap_pm_get_dev_context_loss_count,
> +		.set_min_bus_tput = omap_dss_set_min_bus_tput,


All that code should disappear with DT. hacking a platform device with
pdata is the old way of initializing a device.

I know that you do have some omap_pm callback, but you'd better get rid
of them in case of DT boot.
Fixing that is a generic issue, and as soon as a solution will be done
to handle these specific hooks, every drivers will be able to use that.

> +	};
> +
> +	ver = omap_display_get_version();
> +
> +	if (ver == OMAPDSS_VER_UNKNOWN) {
> +		pr_err("DSS not supported on this SoC\n");
> +		return -ENODEV;
> +	}
> +
> +	board_data.version = ver;
> +
> +	omap_display_device.dev.platform_data = &board_data;

Regards,
Benoit

Re: [RFC 00/14] Add DT support to OMAPDSS

[Benoit Cousson]

Hi Tomi,

On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
> Hi,
> 
> This is an RFC for OMAPDSS DT support. I've only added support for a few boards
> and a few DSS outputs, but they should give quite a good range of different use
> cases. If these work well, I think the rest of the outputs and panels will be
> ok too.
> 
> The purpose of this series is to get comments about the dts changes. There are
> still work to be done, like adding DT binding documentation.
> 
> Some notes:
> 
> * DSS Submodules
> 
> The DSS submodules are children of the dss_core node. This is done because the
> submodules require the dss_core to be alive and initialized to work, even if
> the submodules are not really behind dss_core. Having the submodules as
> children will make runtime PM automatically handle the dependency to dss_core.
> I think usually a node being a child means that it's on the parent's bus, which
> is not the case here. I'm not sure if that's an issue or not.

FWIW, there is a L4_DSS interconnect. It is used internally to connect
all the submodules to the DSS L3 port. So this representation is
perfectly valid and does represent accurately the HW.

Regards,
Benoit

> 
> * ti,dsi-module-id
> 
> There's a ti,dsi-module-id property in the dsi node. The reason for this
> module-id property is that we have muxes in the dss_core that route clocks
> to/from a particular DSI module. So we need some way to index the DSI modules.
> Another option would be to have a list of DSI modules (phandles) in the
> dss_core. Both options feel a bit wrong to me, but I went for the module-id
> approach as that is already used when not using DT.
> 
> * Display chains
> 
> Currently omapdss driver can handle only one display device connected to one
> OMAP SoC output. This is not right in many cases, as there may be multiple
> display devices in a chain, like first an external encoder and then a panel.
> However, I tried to model this right in the dts. 
> 
> So, for example, for Panda HDMI output we have the following display "entities"
> in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI
> connector. These are connected using the "video-source" property, which tells
> where the component in question gets its video data.
> 
> You could ask why there's a separate node for HDMI connector. It's true it's
> not really a proper device, but we need some kind of terminator for the display
> chains. For HDMI we could as well have an embedded solution, having a chain
> like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector
> marks the end of the chain, and acts as a panel in a sense.
> 
> * DSI lanes
> 
> The DSI panels contain "lanes" property, which tells how the SoCs DSI pins are
> connected to the DSI panel. I'm not sure if the panel data is the proper place
> for this, or should the data be separately for the OMAP DSI node.
> 
>  Tomi
> 
> Tomi Valkeinen (14):
>   ARM: OMAP: remove DSS DT hack
>   ARM: OMAP2+: add omapdss_init_of()
>   OMAPDSS: Add DT support to DSS, DISPC, DPI
>   OMAPDSS: Add DT support to DSI
>   OMAPDSS: Add DT support to HDMI
>   OMAPDSS: Taal: Add DT support
>   OMAPDSS: TFP410: Add DT support
>   OMAPDSS: panel-generic-dpi: add DT support
>   ARM: omap3.dtsi: add omapdss information
>   ARM: omap4.dtsi: add omapdss information
>   ARM: omap4-panda.dts: add display information
>   ARM: omap4-sdp.dts: add display information
>   ARM: omap3-tobi.dts: add lcd (TEST)
>   ARM: omap3-beagle.dts: add TFP410
> 
>  arch/arm/boot/dts/omap3-beagle.dts               |   20 +++++
>  arch/arm/boot/dts/omap3-tobi.dts                 |   13 ++++
>  arch/arm/boot/dts/omap3.dtsi                     |   49 ++++++++++++
>  arch/arm/boot/dts/omap4-panda.dts                |   44 +++++++++++
>  arch/arm/boot/dts/omap4-sdp.dts                  |   64 ++++++++++++++++
>  arch/arm/boot/dts/omap4.dtsi                     |   71 +++++++++++++++++
>  arch/arm/mach-omap2/board-generic.c              |    9 +--
>  arch/arm/mach-omap2/common.h                     |    2 +
>  arch/arm/mach-omap2/display.c                    |   34 +++++++++
>  arch/arm/mach-omap2/dss-common.c                 |   24 ------
>  arch/arm/mach-omap2/dss-common.h                 |    2 -
>  drivers/video/omap2/displays/panel-generic-dpi.c |   47 ++++++++++++
>  drivers/video/omap2/displays/panel-taal.c        |   89 ++++++++++++++++++++++
>  drivers/video/omap2/displays/panel-tfp410.c      |   71 +++++++++++++++++
>  drivers/video/omap2/dss/dispc.c                  |    7 ++
>  drivers/video/omap2/dss/dpi.c                    |    8 ++
>  drivers/video/omap2/dss/dsi.c                    |   24 +++++-
>  drivers/video/omap2/dss/dss.c                    |    7 ++
>  drivers/video/omap2/dss/hdmi.c                   |    7 ++
>  drivers/video/omap2/dss/hdmi_panel.c             |   86 ++++++++++++++++++++-
>  20 files changed, 641 insertions(+), 37 deletions(-)
> 

Re: [RFC 00/14] Add DT support to OMAPDSS

[Benoit Cousson]

+ mturquette and Rajendra

On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:

...

> * ti,dsi-module-id
> 
> There's a ti,dsi-module-id property in the dsi node. The reason for this
> module-id property is that we have muxes in the dss_core that route clocks
> to/from a particular DSI module. So we need some way to index the DSI modules.
> Another option would be to have a list of DSI modules (phandles) in the
> dss_core. Both options feel a bit wrong to me, but I went for the module-id
> approach as that is already used when not using DT.

That's not a very nice representation. Ideally you should expose 1 clock
node per DSI node, and enabling one will select the proper mux for you.

Regards,
Benoit


> 
> * Display chains
> 
> Currently omapdss driver can handle only one display device connected to one
> OMAP SoC output. This is not right in many cases, as there may be multiple
> display devices in a chain, like first an external encoder and then a panel.
> However, I tried to model this right in the dts. 
> 
> So, for example, for Panda HDMI output we have the following display "entities"
> in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI
> connector. These are connected using the "video-source" property, which tells
> where the component in question gets its video data.
> 
> You could ask why there's a separate node for HDMI connector. It's true it's
> not really a proper device, but we need some kind of terminator for the display
> chains. For HDMI we could as well have an embedded solution, having a chain
> like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector
> marks the end of the chain, and acts as a panel in a sense.
> 
> * DSI lanes
> 
> The DSI panels contain "lanes" property, which tells how the SoCs DSI pins are
> connected to the DSI panel. I'm not sure if the panel data is the proper place
> for this, or should the data be separately for the OMAP DSI node.
> 
>  Tomi
> 
> Tomi Valkeinen (14):
>   ARM: OMAP: remove DSS DT hack
>   ARM: OMAP2+: add omapdss_init_of()
>   OMAPDSS: Add DT support to DSS, DISPC, DPI
>   OMAPDSS: Add DT support to DSI
>   OMAPDSS: Add DT support to HDMI
>   OMAPDSS: Taal: Add DT support
>   OMAPDSS: TFP410: Add DT support
>   OMAPDSS: panel-generic-dpi: add DT support
>   ARM: omap3.dtsi: add omapdss information
>   ARM: omap4.dtsi: add omapdss information
>   ARM: omap4-panda.dts: add display information
>   ARM: omap4-sdp.dts: add display information
>   ARM: omap3-tobi.dts: add lcd (TEST)
>   ARM: omap3-beagle.dts: add TFP410
> 
>  arch/arm/boot/dts/omap3-beagle.dts               |   20 +++++
>  arch/arm/boot/dts/omap3-tobi.dts                 |   13 ++++
>  arch/arm/boot/dts/omap3.dtsi                     |   49 ++++++++++++
>  arch/arm/boot/dts/omap4-panda.dts                |   44 +++++++++++
>  arch/arm/boot/dts/omap4-sdp.dts                  |   64 ++++++++++++++++
>  arch/arm/boot/dts/omap4.dtsi                     |   71 +++++++++++++++++
>  arch/arm/mach-omap2/board-generic.c              |    9 +--
>  arch/arm/mach-omap2/common.h                     |    2 +
>  arch/arm/mach-omap2/display.c                    |   34 +++++++++
>  arch/arm/mach-omap2/dss-common.c                 |   24 ------
>  arch/arm/mach-omap2/dss-common.h                 |    2 -
>  drivers/video/omap2/displays/panel-generic-dpi.c |   47 ++++++++++++
>  drivers/video/omap2/displays/panel-taal.c        |   89 ++++++++++++++++++++++
>  drivers/video/omap2/displays/panel-tfp410.c      |   71 +++++++++++++++++
>  drivers/video/omap2/dss/dispc.c                  |    7 ++
>  drivers/video/omap2/dss/dpi.c                    |    8 ++
>  drivers/video/omap2/dss/dsi.c                    |   24 +++++-
>  drivers/video/omap2/dss/dss.c                    |    7 ++
>  drivers/video/omap2/dss/hdmi.c                   |    7 ++
>  drivers/video/omap2/dss/hdmi_panel.c             |   86 ++++++++++++++++++++-
>  20 files changed, 641 insertions(+), 37 deletions(-)
> 

Re: [RFC 02/14] ARM: OMAP2+: add omapdss_init_of()

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 3650 bytes --]

On 2013-03-27 11:28, Benoit Cousson wrote:
> Hi Tomi,

Hi Benoit. Thanks for your comments!

> On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
>> omapdss driver uses a omapdss platform device to pass platform specific
>> function pointers and DSS hardware version from the arch code to the
>> driver. This device is needed also when booting with DT.
>>
>> This patch adds omapdss_init_of() function, called from board-generic at
>> init time, which creates the omapdss device.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>>  arch/arm/mach-omap2/board-generic.c |    1 +
>>  arch/arm/mach-omap2/common.h        |    2 ++
>>  arch/arm/mach-omap2/display.c       |   34 ++++++++++++++++++++++++++++++++++
>>  3 files changed, 37 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
>> index a61544b..29eb085 100644
>> --- a/arch/arm/mach-omap2/board-generic.c
>> +++ b/arch/arm/mach-omap2/board-generic.c
>> @@ -41,6 +41,7 @@ static void __init omap_generic_init(void)
>>  
>>  	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>>  
>> +	omapdss_init_of();
> 
> Mmm, you should not have to call that explicitly. It looks like a hack
> to me. Everything in theory should be initialized during
> of_platform_populate / driver probe.

All the "real" devices are initialized properly. However, we still have
a "virtual" omapdss device, which does not represent a particular HW
block as such, and is not represented in the DT data. It's a legacy
thing, and slowly on its way out.

However, it still helps us to pass the platform callbacks via platform
data even in DT call, so we have this (hacky) omapdss_init_of() call.

And we also pass the OMAP revision information via the platform data, as
we need to know the DSS HW version. The only way to get that is to know
the OMAP version and revision. If we would set the DSS HW version
information into DT data, we could need separate dts files for each OMAP
revision.

>> +
>> +int __init omapdss_init_of(void)
>> +{
>> +	int r;
>> +	enum omapdss_version ver;
>> +
>> +	static struct omap_dss_board_info board_data = {
>> +		.dsi_enable_pads = omap_dsi_enable_pads,
>> +		.dsi_disable_pads = omap_dsi_disable_pads,
> 
> Pads config should be handle by pinmux framework is possible. Otherwise
> a dedicated driver will be required.

Hmm. These functions touch the OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY
(CONTROL_DSIPHY in the TRM) register. It's not a normal padconfig thing
(like, selecting between GPIO and some other function).

Can they be handled by the pinmux framework? I'm not familiar with it.
What do you mean with dedicated driver? Dedicated pinmux driver, or
something else?

>> +		.get_context_loss_count = omap_pm_get_dev_context_loss_count,
>> +		.set_min_bus_tput = omap_dss_set_min_bus_tput,
> 
> 
> All that code should disappear with DT. hacking a platform device with
> pdata is the old way of initializing a device.
> 
> I know that you do have some omap_pm callback, but you'd better get rid
> of them in case of DT boot.
> Fixing that is a generic issue, and as soon as a solution will be done
> to handle these specific hooks, every drivers will be able to use that.

So, what you're saying is that this is not the correct way, but there's
no other way to handle it currently? If so, yes, I know that, but, well,
there's no other way to handle it currently.

I could leave them out, but in that case when booting with DT there must
be no DSS context loss, and OPP must be at OPP100 all the time.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [RFC 00/14] Add DT support to OMAPDSS

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

On 2013-03-27 11:30, Benoit Cousson wrote:
> Hi Tomi,
> 
> On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
>> Hi,
>>
>> This is an RFC for OMAPDSS DT support. I've only added support for a few boards
>> and a few DSS outputs, but they should give quite a good range of different use
>> cases. If these work well, I think the rest of the outputs and panels will be
>> ok too.
>>
>> The purpose of this series is to get comments about the dts changes. There are
>> still work to be done, like adding DT binding documentation.
>>
>> Some notes:
>>
>> * DSS Submodules
>>
>> The DSS submodules are children of the dss_core node. This is done because the
>> submodules require the dss_core to be alive and initialized to work, even if
>> the submodules are not really behind dss_core. Having the submodules as
>> children will make runtime PM automatically handle the dependency to dss_core.
>> I think usually a node being a child means that it's on the parent's bus, which
>> is not the case here. I'm not sure if that's an issue or not.
> 
> FWIW, there is a L4_DSS interconnect. It is used internally to connect
> all the submodules to the DSS L3 port. So this representation is
> perfectly valid and does represent accurately the HW.

Ah, yes, I can see it mentioned in the OMAP4430 Block Diagram figure in
the TRM. No other mentions, though, I guess it's not really relevant =).
But good to know that the DT representation is actually correct.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [RFC 00/14] Add DT support to OMAPDSS

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 2103 bytes --]

On 2013-03-27 11:41, Benoit Cousson wrote:
> + mturquette and Rajendra
> 
> On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
> 
> ...
> 
>> * ti,dsi-module-id
>>
>> There's a ti,dsi-module-id property in the dsi node. The reason for this
>> module-id property is that we have muxes in the dss_core that route clocks
>> to/from a particular DSI module. So we need some way to index the DSI modules.
>> Another option would be to have a list of DSI modules (phandles) in the
>> dss_core. Both options feel a bit wrong to me, but I went for the module-id
>> approach as that is already used when not using DT.
> 
> That's not a very nice representation. Ideally you should expose 1 clock
> node per DSI node, and enabling one will select the proper mux for you.

Afaik, we need the DSI module id for the following things:

1) DSI pad configuration (OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY).

2) Setting clk mux in dss_core to select input clock for DSI protocol
engine. The choice is between DSS_CLK from PRCM, or clock from a DSI
PLL. DSI1 module can only use DSI1 PLL clock, and DSI2 module can only
use DSI2 PLL clock.

3) Setting clk mux in dss_core to select input clock for LCD/DISPC. The
choice is between DSS_CLK from PRCM, or a clock from DSI PLL. DISPC can
use either DSI1 or DSI2 PLL, LCD1 can use DSI1 PLL clock, LCD2 can use
DSI2 PLL clock.

4) Selecting the video output from DISPC which is routed to the DSI
module. LCD1 output can go to DSI1, LCD2 output can go to DSI1 or DSI2.

All the above of course change between OMAP versions.

So managing all the above was easiest with a plain module-id assigned to
the DSI device.

I guess 1) could be somehow managed by having separate nodes in the dts
for the DSIPHY control, and a link from the DSI module to that DSIPHY node.

4) could possibly be managed by having each DSS output node having a
list of possible inputs from the DISPC. And, I guess, a link somehow to
a mux node in the dss_core. Or something...

All in all, I don't have any clear idea how these should be handled.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss