[RFC 00/22] OMAPDSS: DT support

[RFC 00/22] OMAPDSS: DT support

[Tomi Valkeinen]

Hi,

This is an RFC for OMAP Display DT support. The patches work fine, at least
for me, but they are not perfect. I mostly don't have any clear questions
about specific issues, but I would like to get feedback on the selected
approaches in general, and also ideas how to proceed with the series.

This series contains the following:

DT support for the following OMAP's display subsystem devices:
- DSS
- DISPC
- DPI
- HDMI
- VENC
- DSI
- (DBI/RFBI DT is not yet implemented)

DT support for the following external display devices:
- panel-dsi-cm (Generic DSI command mode panel)
- encoder-tfp410 (DPI-to-DVI encoder)
- connector-dvi
- encoder-tpd12s015 (HDMI level-shifter & ESD protection)
- hdmi-connector
- panel-dpi (Generic DPI panel)
- connector-analog-tv (S-Video & Composite)
 
DT support for the following boards:
- OMAP4 PandaBoard
- OMAP4 SDP
- OMAP3 BeagleBoard
- OMAP3 Overo with Palo43 LCD expansion-board

The patches are not final, and many contain quite brief descriptions.
Binding descriptions are also still missing. The code and bindings in the
patches should be pretty straightforward, though.

The series is based on v3.11-rc2 + a couple of non-DSS fixes. The series
can also be found from:

git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dev-model-dt

Vocabulary
=====

Display Entity - a hardware entity that takes one or more video streams as
input and outputs one or more video streams.

Upstream Entity - A display entity in the "upstream" side of the video
stream, i.e. closer to the original video source.

Downstream Entity - A display entity in the "downstream" side of the video
stream, i.e. closer to the panel or monitor.

Video pipeline - A chain of multiple display entities, starting from the
SoC, going to the display device the user sees.

Display or Panel - A display entity showing the pixels to the user

Encoder - A display entity that takes video as an input and (usually)
outputs it in some other format.

Connector - HDMI/DVI/etc Connector on the board, to which an external
monitor is connected.

About Stable DT Bindings
============

Generally speaking, the DT bindings should be stable. This brings the
following problems:

We already have DT bindings for some OMAP4 and OMAP3 boards, and OMAP4
boards do not even have board files anymore. There are no display bindings
for those OMAP4 boards, but the display support is currently enabled as a
hack, by calling board-file-like code to add the display devices for the
selected boards. So, when we add the display bindings, we should still
support the current DT files which do not have the display bindings. Which
would mean that we'd need to keep the hacky code forever. Considering the
fact that the hacky code does not work quite correct in all cases, I don't
see keeping it as a very good option.

CDF (Common Display Framework) is in the works, and will most likely have
different or more detailed bindings. Moving to CDF would mean we'd somehow
need to still support the old OMAP bindings. In theory the display DT
bindings should stay the same, as they represent the HW, not any SW
constructs, but in practice I find it hard to believe the OMAP display
bindings would be so perfect that there would be no need for changes.

We most likely should somehow represent DSS clock tree in DT. That is not a
simple task, and when we manage to do it, it again means supporting the DT
files without clock tree data.

All in all, I'm a bit scared to push the display bindings, as it's already
clear there are changes coming. Then again, supporting the current hack for
OMAP4 based boards is not nice at all, and has issues, so it would be really
nice to get OMAP4 boards use proper display bindings.

General description of the DT bindings
===================

All the display entities are represented as DT nodes of their own, and have
a matching Linux driver. The display entities are organized by their control
bus; that is, if a display entity is not controlled via any bus, it's a
platform device, and if, say, it's controlled via i2c device, it's an i2c
device.

The exception to the above are DSI and DBI. DSI and DBI are combined control
and video busses, but the use of the busses for control purposes is not
independent of the video stream. Also, the the busses are, in practice,
one-to-one links. And last, DSI and DBI display entities are often also
controllable via, say, i2c. For these reasons there is no real Linux bus for
DSI and DBI and thus the DSI and DBI devices are either platform devices or
i2c devices.

The display entities are connected via "video-source" property. The
video-source points to the upstream display entity where the video data
comes from, and a chain of display entities thus form a full video pipeline.
All video pipelines end with either a panel or a connector. 

All the data related to a display entity, and how it is connected on the
given board, is defined in the DT node of the display entity. This means
that the DT node of the upstream entity does not have to be modified when
adding support for new boards.

As an example, consider OMAP3's DPI and two boards using it for panels.
omap3.dtsi contains a node for the DPI, and the board dts files contain
nodes for their panels. The board dts files do not change anything in the
included DPI node. So:

omap3.dtsi:

dpi: encoder@0 {
	compatible = "ti,omap3-dpi";
};

omap3-board1.dts:

	lcd0: display@0 {
		compatible = "samsung,lte430wq-f0c", "panel-dpi";
		video-source = <&dpi>;
		data-lines = <24>;
	};

omap3-board2.dts:

	lcd0: display@0 {
		compatible = "samsung,lte430wq-f0c", "panel-dpi";
		video-source = <&dpi>;
		data-lines = <16>;
	};

The logic here is that the boards may have multiple panels that are
connected to the same source, even if the panels can only be used one at a
time. Each panel may thus have different properties for the bus, like the
number of data-lines.

Video bus properties
==========

One question I've been pondering for a long time is related to the bus
between two display entities. As an example, DPI (parallel RGB) requires
configuring the number of datalines used. As described above, the properties
of the video bus are represented in the downstream entity.

This approach has one drawback: how to represent features specific to the
upstream entity? Say, if OMAP's DSI has a bus-related foo-feature, which can
be used in some scenarios, the only place where this foo-feature can be
specified is the OMAP DSI's properties. Not in the DSI Panel's properties,
which in the current model contains properties related to the bus.

So Laurent has proposed to use V4L2-like ports, as described in
Documentation/devicetree/bindings/media/video-interfaces.txt. I have not
implemented such feature for OMAP DSS for the following reasons:

- The current supported displays we use work fine with the current method
- If I were to implement such system, it'd most certainly be different than
  what CDF will have.

That said, the port based approach does sound good, and it would also remove
the design issue with OMAP DPI and SDI modules as described later. So maybe
I should just go forward with it and hope that CDF will do it in similar
manner.

DSI Module ID
======
On OMAP4 we have two DSI modules. To configure the clock routing and pin
muxing, we need to know the hardware module ID for the DSI device, i.e. is
this Linux platform device DSI1 or DSI2. The same issue exists with other
SoCs with multiple outputs of the same kind.

With non-DT case, we used the platform device's ID directly. With DT, that
doesn't work. I don't currently have a good solution for this, so as a
temporary solution the DSI driver contains a table, from which it can find
the HW module ID by using the device's base address.

I believe, but I am not totally sure, that we can remove the concept of DSI
module ID if we have a good representation of the DSS clock tree and DSI pin
muxing in DT. The clock tree is probably a huge undertaking, but the pin
muxing should be much easier. However, pinmuxing also is some complications,
like the pins requiring a regulator to be enabled.

Display names and aliases
============
With the board-file based model each display was given a name in the board
file. Additionally, each display was given an alias in the style "displayX",
where X is in incrementing number.

The name could be used by the user to see which display device is what, i.e.
on Pandaboard there are displays names "dvi" and "hdmi".

The DT bindings do not have such a name. It would be simple to add a
"nickname" property to each display node, but it just looked rather ugly so
I have left it out.

Additionally, as there's no clear order in which the displays are created,
and thus the number in "displayX" alias could change semi-randomly, I added
the displays to "aliases" node. This keeps the display number the same over
boots, and also gives us some way to define a default display, i.e. which
display to use initially if the user has not specified it.

omapdss virtual device
===========

In addition to the DSS devices matching to DSS hardware modules, we have a
"virtual" omapdss device which does not match to any actual HW module. The
device is there mostly for legacy reasons, but it has also allowed us to
easily pass platform callbacks. The same device is also present in DT
solution. It is created in code, and not present in DT bindings.

Obviously, this omapdss virtual device is on the hack side, and nobody would
mind if it would disappear.

The following data is passed via omapdss device's platform data:

- OMAP DSS version. In theory, the DSS revision registers should tell us
  which features the HW supports. In practice, the HW people have not
  bothered to change the revision number each time they've made changes. So
  we pass a DSS version from the platform code, based on OMAP revision
  number.

- omap_dss_set_min_bus_tput() and omap_pm_get_dev_context_loss_count() to
  manage PM

- DSI pin muxing functions.

I have some ideas how to deduce the DSS version by poking to certain DSS
registers, but it is not yet tested so I don't know if it will work.

We could do altogether without omap_pm_get_dev_context_loss_count(), so that
should be removable with some work. I am not sure if
omap_dss_set_min_bus_tput() is supported via standard PM calls or not.

However, the use of set_min_bus_tput() is actually a hack, as we're not
really setting min bus tput. What we want to do is prevent OPP50. DSS clocks
have different maximums on OPP100 and OPP50. So if DSS uses a clock over
OPP50 limit, OPP50 cannot be entered. We prevent OPP50 by setting an
arbitrarily high min bus tput.

The DSI pin muxing should also be solvable with DT based solution, but is
not the most trivial task and needs some work.

So, I presume that at some point we can remove the omapdss device, but in
the current solution it exists for the above reasons.

DSS submodules in DT bindings
==============
The OMAP DSS modules are accessed via L4 or L3, and in that sense they
should be on the same level in the DT bindings. However, we do not have them
in the same level, but there is a main "dss" node, under which all the other
DSS modules reside. The main reason for this is that the main DSS device
needs to be enabled for the other modules to work properly, and having this
structure makes runtime PM handle enabling DSS automatically.

If I recall right, somebody (Paul?) mentioned that in the hardware there is
actually some DSS internal bus, and thus the DT structure is good in that
sense also.

We also have nodes (and matching Linux devices) for DPI and SDI. Neither of
them are actuall a separate IP block in the hardware, but are really more
parts of DSS and maybe DISPC. They are still represented in the same way as
the other DSS modules, to have similar architecture for all DSS outputs. But
as they do not have an address-space of their own, the DT nodes use 0 and 1
as "addresses", i.e. "dpi: encoder@0".

That is rather ugly, and maybe could use some cleaning up. A V4L2 port style
approach would probably allow us to add DPI and SDI ports as part of DSS.

Some of the DSS modules are actually a combination of multiple smaller
modules.  For example, the DSI module contains DSI protocol, DSI PHY and DSI
PLL modules, each in their own address space. These could perhaps be
presented as separate DT nodes and Linux devices, but I am not sure if that
is a good approach or not.

DT Node Names
======
I have used the following naming conventions with DT nodes:

- Panels are named "display"
- Connectors are named "connector"
- Encoders are named "encoder"
- DSS and DISPC are "dss" and "dispc", as they don't really match any of the
  above

When appropriate, the address part of the node is the base address, as in
"dsi1: encoder@58004000". For platform devices, I have used an increasing
number for the address, as in "tpd12s015: encoder@1".

Final words
=====
So as is evident, I have things in my mind that should be improved. Maybe
the most important question for short term future is:

Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us
some proper testing of the related code, and would also allow us to remove
the related hacks (which don't even work quite right). However, I have no
idea yet when the unstable DSS bindings would turn stable.

If we shouldn't add the bindings as unstable, when should the bindings be
added? Wait until CDF is in the mainline, and use that?

I have not explained every piece of DSS in detail, as that would result in a
book instead of this email, so feel free to ask for more details about any
part.

And last but not least (for me, at least =), I'm on vacation for the next
two weeks, so answers may be delayed.

 Tomi

Tomi Valkeinen (22):
  ARM: OMAP: remove DSS DT hack
  OMAPDSS: remove DT hacks for regulators
  ARM: OMAP2+: add omapdss_init_of()
  OMAPDSS: if dssdev->name=NULL, use alias
  OMAPDSS: get dssdev->alias from DT alias
  OMAPFB: clean up default display search
  OMAPFB: search for default display with DT alias
  OMAPDSS: Add DT support to DSS, DISPC, DPI, HDMI, VENC
  OMAPDSS: Add DT support to DSI
  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 display information
  OMAPDSS: panel-dsi-cm: Add DT support
  OMAPDSS: encoder-tfp410: Add DT support
  OMAPDSS: connector-dvi: Add DT support
  OMAPDSS: encoder-tpd12s015: Add DT support
  OMAPDSS: hdmi-connector: Add DT support
  OMAPDSS: panel-dpi: Add DT support
  OMAPDSS: connector-analog-tv: Add DT support

 arch/arm/boot/dts/omap3-beagle.dts                 | 29 ++++++++
 arch/arm/boot/dts/omap3-tobi.dts                   | 33 ++++++++
 arch/arm/boot/dts/omap3.dtsi                       | 43 +++++++++++
 arch/arm/boot/dts/omap4-panda-common.dtsi          | 48 ++++++++++++
 arch/arm/boot/dts/omap4-sdp.dts                    | 70 +++++++++++++++++
 arch/arm/boot/dts/omap4.dtsi                       | 59 +++++++++++++++
 arch/arm/mach-omap2/board-generic.c                | 13 +---
 arch/arm/mach-omap2/common.h                       |  2 +
 arch/arm/mach-omap2/display.c                      | 34 +++++++++
 arch/arm/mach-omap2/dss-common.c                   | 23 ------
 arch/arm/mach-omap2/dss-common.h                   |  2 -
 .../video/omap2/displays-new/connector-analog-tv.c | 70 +++++++++++++++++
 drivers/video/omap2/displays-new/connector-dvi.c   | 49 ++++++++++++
 drivers/video/omap2/displays-new/connector-hdmi.c  | 36 +++++++++
 drivers/video/omap2/displays-new/encoder-tfp410.c  | 54 ++++++++++++++
 .../video/omap2/displays-new/encoder-tpd12s015.c   | 62 +++++++++++++++
 drivers/video/omap2/displays-new/panel-dpi.c       | 75 +++++++++++++++++++
 drivers/video/omap2/displays-new/panel-dsi-cm.c    | 87 ++++++++++++++++++++++
 drivers/video/omap2/dss/dispc.c                    |  7 ++
 drivers/video/omap2/dss/display.c                  | 23 +++++-
 drivers/video/omap2/dss/dpi.c                      |  8 ++
 drivers/video/omap2/dss/dsi.c                      | 58 +++++++++++++--
 drivers/video/omap2/dss/dss.c                      | 10 +++
 drivers/video/omap2/dss/hdmi.c                     | 11 +--
 drivers/video/omap2/dss/venc.c                     |  7 ++
 drivers/video/omap2/omapfb/omapfb-main.c           | 67 ++++++++++++-----
 26 files changed, 915 insertions(+), 65 deletions(-)

-- 
1.8.1.2

[RFC 01/22] 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 | 11 +----------
 arch/arm/mach-omap2/dss-common.c    | 23 -----------------------
 arch/arm/mach-omap2/dss-common.h    |  2 --
 3 files changed, 1 insertion(+), 35 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index be5d005..d388d33 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -57,17 +57,8 @@ 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();
+	if (of_machine_is_compatible("ti,omap4-panda"))
 		legacy_init_ehci_clk("auxclk3_ck");
-
-	}
-	else if (of_machine_is_compatible("ti,omap4-sdp"))
-		omap_4430sdp_display_init_of();
 	else if (of_machine_is_compatible("ti,omap5-uevm"))
 		legacy_init_ehci_clk("auxclk1_ck");
 }
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 043e570..f3282ac 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -98,12 +98,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);
-}
-
-
 /* OMAP4 Blaze display data */
 
 #define DISPLAY_SEL_GPIO	59	/* LCD2/PicoDLP switch */
@@ -232,20 +226,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;
-
-	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__);
-
-	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
-		"DLP POWER ON");
-	if (r)
-		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
-
-	omap_display_init(&sdp4430_dss_data);
-}
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.8.1.2

[RFC 02/22] OMAPDSS: remove DT hacks for regulators

[Tomi Valkeinen]

For booting Panda and 4430SDP with DT, while DSS did not support DT, we
had to had small hacks in the omapdss driver to get the regulators. With
DT now supported in DSS, we can remove those hacks.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/dsi.c  | 5 -----
 drivers/video/omap2/dss/hdmi.c | 5 -----
 2 files changed, 10 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 99a043b..0c8bd1f 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1132,11 +1132,6 @@ static int dsi_regulator_init(struct platform_device *dsidev)
 		return 0;
 
 	vdds_dsi = devm_regulator_get(&dsi->pdev->dev, "vdds_dsi");
-
-	/* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
-	if (IS_ERR(vdds_dsi))
-		vdds_dsi = devm_regulator_get(&dsi->pdev->dev, "VCXIO");
-
 	if (IS_ERR(vdds_dsi)) {
 		DSSERR("can't get VDDS_DSI regulator\n");
 		return PTR_ERR(vdds_dsi);
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 44a885b..1b38f1f 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -338,11 +338,6 @@ static int hdmi_init_regulator(void)
 		return 0;
 
 	reg = devm_regulator_get(&hdmi.pdev->dev, "vdda_hdmi_dac");
-
-	/* DT HACK: try VDAC to make omapdss work for o4 sdp/panda */
-	if (IS_ERR(reg))
-		reg = devm_regulator_get(&hdmi.pdev->dev, "VDAC");
-
 	if (IS_ERR(reg)) {
 		DSSERR("can't get VDDA_HDMI_DAC regulator\n");
 		return PTR_ERR(reg);
-- 
1.8.1.2

[RFC 03/22] 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 |  2 ++
 arch/arm/mach-omap2/common.h        |  2 ++
 arch/arm/mach-omap2/display.c       | 34 ++++++++++++++++++++++++++++++++++
 3 files changed, 38 insertions(+)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index d388d33..aaf1125 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -61,6 +61,8 @@ static void __init omap_generic_init(void)
 		legacy_init_ehci_clk("auxclk3_ck");
 	else if (of_machine_is_compatible("ti,omap5-uevm"))
 		legacy_init_ehci_clk("auxclk1_ck");
+
+	omapdss_init_of();
 }
 
 #ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index dfcc182..377900c 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -300,5 +300,7 @@ extern int omap_dss_reset(struct omap_hwmod *);
 /* SoC specific clock initializer */
 extern int (*omap_clk_init)(void);
 
+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.8.1.2

[RFC 04/22] OMAPDSS: if dssdev->name==NULL, use alias

[Tomi Valkeinen]

To avoid the need for a "nickname" property for each display, change
the display registration so that the display's alias (i.e. "display0"
etc) will be used for the dssdev->name if the display driver didn't
provide a name.

This means that when booting with board files, we will have more
descriptive names for displays, like "lcd1", "hdmi". With DT we'll only
have "display0", etc. But as there are no "nicknames" for things like
serials ports either, I hope we will do fine with this approach.

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

diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c
index fafe7c9..64fb6e5 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -137,6 +137,9 @@ int omapdss_register_display(struct omap_dss_device *dssdev)
 	snprintf(dssdev->alias, sizeof(dssdev->alias),
 			"display%d", disp_num_counter++);
 
+	if (dssdev->name = NULL)
+		dssdev->name = dssdev->alias;
+
 	if (drv && drv->get_resolution = NULL)
 		drv->get_resolution = omapdss_default_get_resolution;
 	if (drv && drv->get_recommended_bpp = NULL)
-- 
1.8.1.2

[RFC 05/22] OMAPDSS: get dssdev->alias from DT alias

[Tomi Valkeinen]

We currently create a "displayX" style alias name for all displays,
using a number that is incremented for each registered display. With the
new DSS device model there is no clear order in which the displays are
registered, and thus the numbering is somewhat random.

This patch improves the behavior for DT case so that if the displays
have been assigned DT aliases, those aliases will be used as DSS
aliases.

This means that "display0" is always the one specified in the DT alias,
and thus display0 can be used as default display in case the user didn't
specify a default display.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/display.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c
index 64fb6e5..a8833ca 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -26,6 +26,7 @@
 #include <linux/module.h>
 #include <linux/jiffies.h>
 #include <linux/platform_device.h>
+#include <linux/of.h>
 
 #include <video/omapdss.h>
 #include "dss.h"
@@ -133,9 +134,24 @@ static int disp_num_counter;
 int omapdss_register_display(struct omap_dss_device *dssdev)
 {
 	struct omap_dss_driver *drv = dssdev->driver;
+	int id;
 
-	snprintf(dssdev->alias, sizeof(dssdev->alias),
-			"display%d", disp_num_counter++);
+	/*
+	 * Note: this presumes all the displays are either using DT or non-DT,
+	 * which normally should be the case. This also presumes that all
+	 * displays either have an DT alias, or none has.
+	 */
+
+	if (dssdev->dev->of_node) {
+		id = of_alias_get_id(dssdev->dev->of_node, "display");
+
+		if (id < 0)
+			id = disp_num_counter++;
+	} else {
+		id = disp_num_counter++;
+	}
+
+	snprintf(dssdev->alias, sizeof(dssdev->alias), "display%d", id);
 
 	if (dssdev->name = NULL)
 		dssdev->name = dssdev->alias;
-- 
1.8.1.2

[RFC 06/22] OMAPFB: clean up default display search

[Tomi Valkeinen]

Separate the code for finding the default display into a function for
clarity and to make it easier to extend it in the future.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/omapfb/omapfb-main.c | 46 ++++++++++++++++++++------------
 1 file changed, 29 insertions(+), 17 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 27d6905..8bfe973 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2407,6 +2407,34 @@ static int omapfb_init_connections(struct omapfb2_device *fbdev,
 	return 0;
 }
 
+static struct omap_dss_device *
+omapfb_find_default_display(struct omapfb2_device *fbdev)
+{
+	const char *def_name;
+	int i;
+
+	/* search with the display name from the user or the board file */
+
+	def_name = omapdss_get_default_display_name();
+
+	if (def_name) {
+		for (i = 0; i < fbdev->num_displays; ++i) {
+			struct omap_dss_device *dssdev;
+
+			dssdev = fbdev->displays[i].dssdev;
+
+			if (dssdev->name && strcmp(def_name, dssdev->name) = 0)
+				return dssdev;
+		}
+
+		/* def_name given but not found */
+		return NULL;
+	}
+
+	/* return the first display we have in the list */
+	return fbdev->displays[0].dssdev;
+}
+
 static int omapfb_probe(struct platform_device *pdev)
 {
 	struct omapfb2_device *fbdev = NULL;
@@ -2484,23 +2512,7 @@ static int omapfb_probe(struct platform_device *pdev)
 	for (i = 0; i < fbdev->num_managers; i++)
 		fbdev->managers[i] = omap_dss_get_overlay_manager(i);
 
-	def_display = NULL;
-
-	for (i = 0; i < fbdev->num_displays; ++i) {
-		struct omap_dss_device *dssdev;
-		const char *def_name;
-
-		def_name = omapdss_get_default_display_name();
-
-		dssdev = fbdev->displays[i].dssdev;
-
-		if (def_name = NULL ||
-			(dssdev->name && strcmp(def_name, dssdev->name) = 0)) {
-			def_display = dssdev;
-			break;
-		}
-	}
-
+	def_display = omapfb_find_default_display(fbdev);
 	if (def_display = NULL) {
 		dev_err(fbdev->dev, "failed to find default display\n");
 		r = -EPROBE_DEFER;
-- 
1.8.1.2

[RFC 07/22] OMAPFB: search for default display with DT alias

[Tomi Valkeinen]

Improve the search for the default display in two ways:
* compare the given display name to the display's alias
* if no display name is given, look for "display0" DT alias

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

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 8bfe973..961c5c2 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2413,7 +2413,10 @@ omapfb_find_default_display(struct omapfb2_device *fbdev)
 	const char *def_name;
 	int i;
 
-	/* search with the display name from the user or the board file */
+	/*
+	 * Search with the display name from the user or the board file,
+	 * comparing to display names and aliases
+	 */
 
 	def_name = omapdss_get_default_display_name();
 
@@ -2425,12 +2428,30 @@ omapfb_find_default_display(struct omapfb2_device *fbdev)
 
 			if (dssdev->name && strcmp(def_name, dssdev->name) = 0)
 				return dssdev;
+
+			if (strcmp(def_name, dssdev->alias) = 0)
+				return dssdev;
 		}
 
 		/* def_name given but not found */
 		return NULL;
 	}
 
+	/* then look for DT alias display0 */
+	for (i = 0; i < fbdev->num_displays; ++i) {
+		struct omap_dss_device *dssdev;
+		int id;
+
+		dssdev = fbdev->displays[i].dssdev;
+
+		if (dssdev->dev->of_node = NULL)
+			continue;
+
+		id = of_alias_get_id(dssdev->dev->of_node, "display");
+		if (id = 0)
+			return dssdev;
+	}
+
 	/* return the first display we have in the list */
 	return fbdev->displays[0].dssdev;
 }
-- 
1.8.1.2

[RFC 08/22] OMAPDSS: Add DT support to DSS, DISPC, DPI, HDMI, VENC

[Tomi Valkeinen]

Add the code to make DSS, DISPC, DPI, HDMI and VENC 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   | 10 ++++++++++
 drivers/video/omap2/dss/hdmi.c  |  6 ++++++
 drivers/video/omap2/dss/venc.c  |  7 +++++++
 5 files changed, 38 insertions(+)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 02a7340..b4dccb8 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3743,12 +3743,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 a6b331e..6b832c8 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>
 
@@ -801,12 +802,19 @@ 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 = {
 	.probe		= omap_dpi_probe,
 	.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 bd01608..d0d61b1 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -23,6 +23,7 @@
 #define DSS_SUBSYS_NAME "DSS"
 
 #include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/io.h>
 #include <linux/export.h>
 #include <linux/err.h>
@@ -955,12 +956,21 @@ 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", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, dss_of_match);
+
 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,
 	},
 };
 
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 1b38f1f..1cea0ab 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -1374,6 +1374,11 @@ 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 = {
 	.probe		= omapdss_hdmihw_probe,
 	.remove         = __exit_p(omapdss_hdmihw_remove),
@@ -1381,6 +1386,7 @@ static struct platform_driver omapdss_hdmihw_driver = {
 		.name   = "omapdss_hdmi",
 		.owner  = THIS_MODULE,
 		.pm	= &hdmi_pm_ops,
+		.of_match_table = hdmi_of_match,
 	},
 };
 
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 496a106..93e13dd 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -980,6 +980,12 @@ static const struct dev_pm_ops venc_pm_ops = {
 	.runtime_resume = venc_runtime_resume,
 };
 
+
+static const struct of_device_id venc_of_match[] = {
+	{ .compatible = "ti,omap3-venc", },
+	{},
+};
+
 static struct platform_driver omap_venchw_driver = {
 	.probe		= omap_venchw_probe,
 	.remove         = __exit_p(omap_venchw_remove),
@@ -987,6 +993,7 @@ static struct platform_driver omap_venchw_driver = {
 		.name   = "omapdss_venc",
 		.owner  = THIS_MODULE,
 		.pm	= &venc_pm_ops,
+		.of_match_table = venc_of_match,
 	},
 };
 
-- 
1.8.1.2

[RFC 09/22] OMAPDSS: Add DT support to DSI

[Tomi Valkeinen]

Add the code to make the DSI driver work with device tree on OMAP3 and
OMAP4.

A minor hack is needed at the moment in the DSI driver: the DSS driver
needs to know the ID number of a DSI device, as clocks are routed in
different ways to the DSI devices. At the moment we don't have any
proper way to manage this, so this patchs adds a simple lookup table
that is used to deduce the ID from the DSI device's base address.

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

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 0c8bd1f..bccf5fc 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>
@@ -371,6 +372,13 @@ struct dsi_packet_sent_handler_data {
 	struct completion *completion;
 };
 
+struct dsi_module_id_data {
+	u32 address;
+	int id;
+};
+
+static const struct of_device_id dsi_of_match[];
+
 #ifdef DEBUG
 static bool dsi_perf;
 module_param(dsi_perf, bool, 0644);
@@ -5537,7 +5545,6 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
 	if (!dsi)
 		return -ENOMEM;
 
-	dsi->module_id = dsidev->id;
 	dsi->pdev = dsidev;
 	dev_set_drvdata(&dsidev->dev, dsi);
 
@@ -5587,6 +5594,31 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
 		return r;
 	}
 
+	if (dsidev->dev.of_node) {
+		const struct of_device_id *match;
+		const struct dsi_module_id_data *d;
+
+		match = of_match_node(dsi_of_match, dsidev->dev.of_node);
+		if (!match) {
+			DSSERR("unsupported DSI module\n");
+			return -ENODEV;
+		}
+
+		d = match->data;
+
+		while (d->address != 0 && d->address != dsi_mem->start)
+			d++;
+
+		if (d->address = 0) {
+			DSSERR("unsupported DSI module\n");
+			return -ENODEV;
+		}
+
+		dsi->module_id = d->id;
+	} else {
+		dsi->module_id = dsidev->id;
+	}
+
 	/* DSI VCs initialization */
 	for (i = 0; i < ARRAY_SIZE(dsi->vc); i++) {
 		dsi->vc[i].source = DSI_VC_SOURCE_L4;
@@ -5641,6 +5673,7 @@ static int 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_probe:
@@ -5694,6 +5727,23 @@ static const struct dev_pm_ops dsi_pm_ops = {
 	.runtime_resume = dsi_runtime_resume,
 };
 
+static const struct dsi_module_id_data dsi_of_data_omap3[] = {
+	{ .address = 0x4804fc00, .id = 0, },
+	{ },
+};
+
+static const struct dsi_module_id_data dsi_of_data_omap4[] = {
+	{ .address = 0x58004000, .id = 0, },
+	{ .address = 0x58005000, .id = 1, },
+	{ },
+};
+
+static const struct of_device_id dsi_of_match[] = {
+	{ .compatible = "ti,omap3-dsi", .data = dsi_of_data_omap3, },
+	{ .compatible = "ti,omap4-dsi", .data = dsi_of_data_omap4, },
+	{},
+};
+
 static struct platform_driver omap_dsihw_driver = {
 	.probe		= omap_dsihw_probe,
 	.remove         = __exit_p(omap_dsihw_remove),
@@ -5701,6 +5751,7 @@ static struct platform_driver omap_dsihw_driver = {
 		.name   = "omapdss_dsi",
 		.owner  = THIS_MODULE,
 		.pm	= &dsi_pm_ops,
+		.of_match_table = dsi_of_match,
 	},
 };
 
-- 
1.8.1.2

[RFC 10/22] ARM: omap3.dtsi: add omapdss information

[Tomi Valkeinen]

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

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..3308b3f 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -532,5 +532,48 @@
 			num-eps = <16>;
 			ram-bits = <12>;
 		};
+
+		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: encoder@0 {
+				compatible = "ti,omap3-dpi";
+			};
+
+			sdi: encoder@1 {
+				compatible = "ti,omap3-sdi";
+			};
+
+			dsi: encoder@4804fc00 {
+				compatible = "ti,omap3-dsi";
+				reg = <0x4804fc00 0x400>;
+				interrupts = <25>;
+				ti,hwmods = "dss_dsi1";
+			};
+
+			rfbi: encoder@48050800 {
+				compatible = "ti,omap3-rfbi";
+				reg = <0x48050800 0x100>;
+				ti,hwmods = "dss_rfbi";
+			};
+
+			venc: encoder@48050c00 {
+				compatible = "ti,omap3-venc";
+				reg = <0x48050c00 0x100>;
+				ti,hwmods = "dss_venc";
+			};
+		};
 	};
 };
-- 
1.8.1.2

[RFC 11/22] ARM: omap4.dtsi: add omapdss information

[Tomi Valkeinen]

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

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..ab19f16 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -663,5 +663,64 @@
 			ram-bits = <12>;
 			ti,has-mailbox;
 		};
+
+		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: encoder@0 {
+				compatible = "ti,omap4-dpi";
+			};
+
+			rfbi: encoder@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: encoder@58003000 {
+				compatible = "ti,omap4-venc";
+				reg = <0x58003000 0x1000>;
+				ti,hwmods = "dss_venc";
+			};
+			*/
+
+			dsi1: encoder@58004000 {
+				compatible = "ti,omap4-dsi";
+				reg = <0x58004000 0x200>;
+				interrupts = <0 53 0x4>;
+				ti,hwmods = "dss_dsi1";
+			};
+
+			dsi2: encoder@58005000 {
+				compatible = "ti,omap4-dsi";
+				reg = <0x58005000 0x200>;
+				interrupts = <0 84 0x4>;
+				ti,hwmods = "dss_dsi2";
+			};
+
+			hdmi: encoder@58006000 {
+				compatible = "ti,omap4-hdmi";
+				reg = <0x58006000 0x1000>;
+				interrupts = <0 101 0x4>;
+				ti,hwmods = "dss_hdmi";
+			};
+		};
 	};
 };
-- 
1.8.1.2

[RFC 12/22] ARM: omap4-panda.dts: add display information

[Tomi Valkeinen]

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

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..fa65b19 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -357,3 +357,51 @@
 &usbhsehci {
 	phys = <&hsusb1_phy>;
 };
+
+&dsi1 {
+	vdds_dsi-supply = <&vcxio>;
+};
+
+&dsi2 {
+	vdds_dsi-supply = <&vcxio>;
+};
+
+&hdmi {
+	vdda_hdmi_dac-supply = <&vdac>;
+};
+
+/ {
+	aliases {
+		display0 = &dvi0;
+		display1 = &hdmi0;
+	};
+
+	tfp410: encoder@0 {
+		compatible = "ti,tfp410";
+		video-source = <&dpi>;
+		data-lines = <24>;
+		gpios = <&gpio1 0 0>;	/* 0, power-down */
+	};
+
+	dvi0: connector@0 {
+		compatible = "ti,dvi_connector";
+		video-source = <&tfp410>;
+		i2c-bus = <&i2c3>;
+	};
+
+	tpd12s015: encoder@1 {
+		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 */
+	};
+
+	hdmi0: connector@1 {
+		compatible = "ti,hdmi_connector";
+
+		video-source = <&tpd12s015>;
+	};
+};
-- 
1.8.1.2

[RFC 13/22] 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 | 70 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..49f98b1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -532,3 +532,73 @@
 	mode = <3>;
 	power = <50>;
 };
+
+&dsi1 {
+	vdds_dsi-supply = <&vcxio>;
+};
+
+&dsi2 {
+	vdds_dsi-supply = <&vcxio>;
+};
+
+&hdmi {
+	vdda_hdmi_dac-supply = <&vdac>;
+};
+
+/ {
+	aliases {
+		display0 = &lcd0;
+		display1 = &lcd1;
+		display2 = &hdmi0;
+	};
+
+	lcd0: display@0 {
+		compatible = "tpo,taal", "panel-dsi-cm";
+
+		video-source = <&dsi1>;
+
+		lanes = <
+			0       /* clk + */
+			1       /* clk - */
+			2       /* data1 + */
+			3       /* data1 - */
+			4       /* data2 + */
+			5       /* data2 - */
+		>;
+
+		gpios = <&gpio4 6 0>;	/* 102, reset */
+	};
+
+	lcd1: display@1 {
+		compatible = "tpo,taal", "panel-dsi-cm";
+
+		video-source = <&dsi2>;
+
+		lanes = <
+			0       /* clk + */
+			1       /* clk - */
+			2       /* data1 + */
+			3       /* data1 - */
+			4       /* data2 + */
+			5       /* data2 - */
+		>;
+
+		gpios = <&gpio4 8 0>;	/* 104, reset */
+	};
+
+	tpd12s015: encoder@0 {
+		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 */
+	};
+
+	hdmi0: connector@0 {
+		compatible = "ti,hdmi_connector";
+
+		video-source = <&tpd12s015>;
+	};
+};
-- 
1.8.1.2

[RFC 14/22] 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@ti.com>
---
 arch/arm/boot/dts/omap3-tobi.dts | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
index 7e4ad2a..0d136d8 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -81,3 +81,36 @@
 &mmc3 {
 	status = "disabled";
 };
+
+&dpi {
+	vdds_dsi-supply = <&vpll2>;
+};
+
+/ {
+	aliases {
+		display0 = &lcd0;
+	};
+
+	lcd0: display@0 {
+		compatible = "samsung,lte430wq-f0c", "panel-dpi";
+		video-source = <&dpi>;
+		data-lines = <24>;
+
+		panel-timing {
+			clock-frequency = <9200000>;
+			hactive = <480>;
+			vactive = <272>;
+			hfront-porch = <8>;
+			hback-porch = <4>;
+			hsync-len = <41>;
+			vback-porch = <2>;
+			vfront-porch = <4>;
+			vsync-len = <10>;
+
+			hsync-active = <0>;
+			vsync-active = <0>;
+			de-active = <1>;
+			pixelclk-active = <1>;
+		};
+	};
+};
-- 
1.8.1.2

[RFC 15/22] ARM: omap3-beagle.dts: add display information

[Tomi Valkeinen]

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

diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..17cb9b0 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -180,3 +180,32 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&gpio1_pins>;
 };
+
+&dpi {
+	vdds_dsi-supply = <&vpll2>;
+};
+
+/ {
+	aliases {
+		display0 = &dvi0;
+		display1 = &tv0;
+	};
+
+	tfp410: encoder@0 {
+		compatible = "ti,tfp410";
+		video-source = <&dpi>;
+		data-lines = <24>;
+		gpios = <&gpio5 10 0>;	/* 170, power-down */
+	};
+
+	dvi0: connector@0 {
+		compatible = "ti,dvi_connector";
+		video-source = <&tfp410>;
+		i2c-bus = <&i2c3>;
+	};
+
+	tv0: connector@1 {
+		compatible = "ti,svideo_connector";
+		video-source = <&venc>;
+	};
+};
-- 
1.8.1.2

[RFC 16/22] OMAPDSS: panel-dsi-cm: Add DT support

[Tomi Valkeinen]

XXX ULPS and backlight missing.

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

diff --git a/drivers/video/omap2/displays-new/panel-dsi-cm.c b/drivers/video/omap2/displays-new/panel-dsi-cm.c
index aaaea64..f65ea4d 100644
--- a/drivers/video/omap2/displays-new/panel-dsi-cm.c
+++ b/drivers/video/omap2/displays-new/panel-dsi-cm.c
@@ -22,6 +22,8 @@
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/workqueue.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
 
 #include <video/omapdss.h>
 #include <video/omap-panel-data.h>
@@ -1156,6 +1158,79 @@ static int dsicm_probe_pdata(struct platform_device *pdev)
 	return 0;
 }
 
+static int dsicm_probe_of(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+	struct omap_dss_device *in;
+	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;
+	}
+
+	in = omap_dss_find_output_by_node(src_node);
+	if (in = NULL) {
+		dev_err(&pdev->dev, "failed to find video source\n");
+		return -EPROBE_DEFER;
+	}
+	ddata->in = in;
+
+	gpio = of_get_gpio(node, 0);
+	if (!gpio_is_valid(gpio)) {
+		dev_err(&pdev->dev, "failed to parse reset gpio\n");
+		return gpio;
+	}
+	ddata->reset_gpio = gpio;
+
+	if (of_gpio_count(node) > 1) {
+		gpio = of_get_gpio(node, 1);
+
+		if (gpio_is_valid(gpio) || gpio = -ENOENT) {
+			ddata->ext_te_gpio = gpio;
+		} else {
+			dev_err(&pdev->dev, "failed to parse TE gpio\n");
+			return gpio;
+		}
+	} else {
+		ddata->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;
+	}
+
+	ddata->pin_config.num_pins = num_pins;
+	for (i = 0; i < num_pins; ++i)
+		ddata->pin_config.pins[i] = (int)lane_arr[i];
+
+	/* TODO: ulps, backlight */
+
+	return 0;
+}
+
 static int dsicm_probe(struct platform_device *pdev)
 {
 	struct backlight_properties props;
@@ -1178,6 +1253,10 @@ static int dsicm_probe(struct platform_device *pdev)
 		r = dsicm_probe_pdata(pdev);
 		if (r)
 			return r;
+	} else if (pdev->dev.of_node) {
+		r = dsicm_probe_of(pdev);
+		if (r)
+			return r;
 	} else {
 		return -ENODEV;
 	}
@@ -1320,12 +1399,20 @@ static int __exit dsicm_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id dsicm_of_match[] = {
+	{ .compatible = "panel-dsi-cm", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, dsicm_of_match);
+
 static struct platform_driver dsicm_driver = {
 	.probe = dsicm_probe,
 	.remove = __exit_p(dsicm_remove),
 	.driver = {
 		.name = "panel-dsi-cm",
 		.owner = THIS_MODULE,
+		.of_match_table = dsicm_of_match,
 	},
 };
 
-- 
1.8.1.2

[RFC 17/22] OMAPDSS: encoder-tfp410: Add DT support

[Tomi Valkeinen]

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

diff --git a/drivers/video/omap2/displays-new/encoder-tfp410.c b/drivers/video/omap2/displays-new/encoder-tfp410.c
index a04f658..120da51 100644
--- a/drivers/video/omap2/displays-new/encoder-tfp410.c
+++ b/drivers/video/omap2/displays-new/encoder-tfp410.c
@@ -13,6 +13,7 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
+#include <linux/of_gpio.h>
 
 #include <video/omapdss.h>
 #include <video/omap-panel-data.h>
@@ -179,6 +180,47 @@ static int tfp410_probe_pdata(struct platform_device *pdev)
 	return 0;
 }
 
+static int tfp410_probe_of(struct platform_device *pdev)
+{
+	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+	struct device_node *node = pdev->dev.of_node;
+	struct omap_dss_device *in;
+	struct device_node *src_node;
+	int r, gpio, datalines;
+
+	src_node = of_parse_phandle(node, "video-source", 0);
+	if (!src_node) {
+		dev_err(&pdev->dev, "failed to parse video source\n");
+		return -ENODEV;
+	}
+
+	in = omap_dss_find_output_by_node(src_node);
+	if (in = NULL) {
+		dev_err(&pdev->dev, "failed to find video source\n");
+		return -EPROBE_DEFER;
+	}
+	ddata->in = in;
+
+	gpio = of_get_gpio(node, 0);
+
+	if (gpio_is_valid(gpio) || gpio = -ENOENT) {
+		ddata->pd_gpio = gpio;
+	} 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\n");
+		return r;
+	}
+
+	ddata->data_lines = datalines;
+
+	return 0;
+}
+
 static int tfp410_probe(struct platform_device *pdev)
 {
 	struct panel_drv_data *ddata;
@@ -195,6 +237,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;
 	}
@@ -251,12 +297,20 @@ static int __exit tfp410_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id tfp410_of_match[] = {
+	{ .compatible = "ti,tfp410", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, tfp410_of_match);
+
 static struct platform_driver tfp410_driver = {
 	.probe	= tfp410_probe,
 	.remove	= __exit_p(tfp410_remove),
 	.driver	= {
 		.name	= "tfp410",
 		.owner	= THIS_MODULE,
+		.of_match_table = tfp410_of_match,
 	},
 };
 
-- 
1.8.1.2

[RFC 18/22] OMAPDSS: connector-dvi: Add DT support

[Tomi Valkeinen]

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

diff --git a/drivers/video/omap2/displays-new/connector-dvi.c b/drivers/video/omap2/displays-new/connector-dvi.c
index bc5f8ce..99ee1b2 100644
--- a/drivers/video/omap2/displays-new/connector-dvi.c
+++ b/drivers/video/omap2/displays-new/connector-dvi.c
@@ -13,6 +13,7 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
+#include <linux/of_i2c.h>
 
 #include <drm/drm_edid.h>
 
@@ -274,6 +275,42 @@ static int dvic_probe_pdata(struct platform_device *pdev)
 	return 0;
 }
 
+static int dvic_probe_of(struct platform_device *pdev)
+{
+	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+	struct device_node *node = pdev->dev.of_node;
+	struct omap_dss_device *in;
+	struct device_node *src_node;
+	struct device_node *adapter_node;
+	struct i2c_adapter *adapter;
+
+	src_node = of_parse_phandle(node, "video-source", 0);
+	if (!src_node) {
+		dev_err(&pdev->dev, "failed to parse video source\n");
+		return -ENODEV;
+	}
+
+	in = omap_dss_find_output_by_node(src_node);
+	if (in = NULL) {
+		dev_err(&pdev->dev, "failed to find video source\n");
+		return -EPROBE_DEFER;
+	}
+	ddata->in = in;
+
+	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 dvic_probe(struct platform_device *pdev)
 {
 	struct panel_drv_data *ddata;
@@ -290,6 +327,10 @@ static int dvic_probe(struct platform_device *pdev)
 		r = dvic_probe_pdata(pdev);
 		if (r)
 			return r;
+	} else if (pdev->dev.of_node) {
+		r = dvic_probe_of(pdev);
+		if (r)
+			return r;
 	} else {
 		return -ENODEV;
 	}
@@ -335,12 +376,20 @@ static int __exit dvic_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id dvic_of_match[] = {
+	{ .compatible = "ti,dvi_connector", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, dvic_of_match);
+
 static struct platform_driver dvi_connector_driver = {
 	.probe	= dvic_probe,
 	.remove	= __exit_p(dvic_remove),
 	.driver	= {
 		.name	= "connector-dvi",
 		.owner	= THIS_MODULE,
+		.of_match_table = dvic_of_match,
 	},
 };
 
-- 
1.8.1.2

[RFC 19/22] OMAPDSS: encoder-tpd12s015: Add DT support

[Tomi Valkeinen]

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 .../video/omap2/displays-new/encoder-tpd12s015.c   | 62 ++++++++++++++++++++++
 1 file changed, 62 insertions(+)

diff --git a/drivers/video/omap2/displays-new/encoder-tpd12s015.c b/drivers/video/omap2/displays-new/encoder-tpd12s015.c
index ce0e010..4650cc7 100644
--- a/drivers/video/omap2/displays-new/encoder-tpd12s015.c
+++ b/drivers/video/omap2/displays-new/encoder-tpd12s015.c
@@ -15,6 +15,7 @@
 #include <linux/slab.h>
 #include <linux/gpio.h>
 #include <linux/platform_device.h>
+#include <linux/of_gpio.h>
 
 #include <video/omapdss.h>
 #include <video/omap-panel-data.h>
@@ -289,6 +290,55 @@ static int tpd_probe_pdata(struct platform_device *pdev)
 	return 0;
 }
 
+static int tpd_probe_of(struct platform_device *pdev)
+{
+	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+	struct device_node *node = pdev->dev.of_node;
+	struct omap_dss_device *in;
+	struct device_node *src_node;
+	int gpio;
+
+	src_node = of_parse_phandle(node, "video-source", 0);
+	if (!src_node) {
+		dev_err(&pdev->dev, "failed to parse video source\n");
+		return -ENODEV;
+	}
+
+	in = omap_dss_find_output_by_node(src_node);
+	if (in = NULL) {
+		dev_err(&pdev->dev, "failed to find video source\n");
+		return -EPROBE_DEFER;
+	}
+	ddata->in = in;
+
+	/* CT CP HPD GPIO */
+	gpio = of_get_gpio(node, 0);
+	if (!gpio_is_valid(gpio)) {
+		dev_err(&pdev->dev, "failed to parse CT CP HPD gpio\n");
+		return gpio;
+	}
+	ddata->ct_cp_hpd_gpio = gpio;
+
+	/* LS OE GPIO */
+	gpio = of_get_gpio(node, 1);
+	if (gpio_is_valid(gpio) || gpio = -ENOENT) {
+		ddata->ls_oe_gpio = gpio;
+	} else {
+		dev_err(&pdev->dev, "failed to parse LS OE gpio\n");
+		return gpio;
+	}
+
+	/* HPD GPIO */
+	gpio = of_get_gpio(node, 2);
+	if (!gpio_is_valid(gpio)) {
+		dev_err(&pdev->dev, "failed to parse HPD gpio\n");
+		return gpio;
+	}
+	ddata->hpd_gpio = gpio;
+
+	return 0;
+}
+
 static int tpd_probe(struct platform_device *pdev)
 {
 	struct omap_dss_device *in, *dssdev;
@@ -307,6 +357,10 @@ static int tpd_probe(struct platform_device *pdev)
 		r = tpd_probe_pdata(pdev);
 		if (r)
 			return r;
+	} else if (pdev->dev.of_node) {
+		r = tpd_probe_of(pdev);
+		if (r)
+			return r;
 	} else {
 		return -ENODEV;
 	}
@@ -379,12 +433,20 @@ static int __exit tpd_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id tpd_of_match[] = {
+	{ .compatible = "ti,tpd12s015", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, tpd_of_match);
+
 static struct platform_driver tpd_driver = {
 	.probe	= tpd_probe,
 	.remove	= __exit_p(tpd_remove),
 	.driver	= {
 		.name	= "tpd12s015",
 		.owner	= THIS_MODULE,
+		.of_match_table = tpd_of_match,
 	},
 };
 
-- 
1.8.1.2

[RFC 20/22] OMAPDSS: hdmi-connector: Add DT support

[Tomi Valkeinen]

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

diff --git a/drivers/video/omap2/displays-new/connector-hdmi.c b/drivers/video/omap2/displays-new/connector-hdmi.c
index c582671..13f7a5e 100644
--- a/drivers/video/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/omap2/displays-new/connector-hdmi.c
@@ -12,6 +12,7 @@
 #include <linux/slab.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
+#include <linux/of.h>
 
 #include <drm/drm_edid.h>
 
@@ -301,6 +302,29 @@ static int hdmic_probe_pdata(struct platform_device *pdev)
 	return 0;
 }
 
+static int hdmic_probe_of(struct platform_device *pdev)
+{
+	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+	struct device_node *node = pdev->dev.of_node;
+	struct omap_dss_device *in;
+	struct device_node *src_node;
+
+	src_node = of_parse_phandle(node, "video-source", 0);
+	if (!src_node) {
+		dev_err(&pdev->dev, "failed to parse video source\n");
+		return -ENODEV;
+	}
+
+	in = omap_dss_find_output_by_node(src_node);
+	if (in = NULL) {
+		dev_err(&pdev->dev, "failed to find video source\n");
+		return -EPROBE_DEFER;
+	}
+	ddata->in = in;
+
+	return 0;
+}
+
 static int hdmic_probe(struct platform_device *pdev)
 {
 	struct panel_drv_data *ddata;
@@ -318,6 +342,10 @@ static int hdmic_probe(struct platform_device *pdev)
 		r = hdmic_probe_pdata(pdev);
 		if (r)
 			return r;
+	} else if (pdev->dev.of_node) {
+		r = hdmic_probe_of(pdev);
+		if (r)
+			return r;
 	} else {
 		return -ENODEV;
 	}
@@ -359,12 +387,20 @@ static int __exit hdmic_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id hdmic_of_match[] = {
+	{ .compatible = "ti,hdmi_connector", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, hdmic_of_match);
+
 static struct platform_driver hdmi_connector_driver = {
 	.probe	= hdmic_probe,
 	.remove	= __exit_p(hdmic_remove),
 	.driver	= {
 		.name	= "connector-hdmi",
 		.owner	= THIS_MODULE,
+		.of_match_table = hdmic_of_match,
 	},
 };
 
-- 
1.8.1.2

[RFC 21/22] OMAPDSS: panel-dpi: Add DT support

[Tomi Valkeinen]

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

diff --git a/drivers/video/omap2/displays-new/panel-dpi.c b/drivers/video/omap2/displays-new/panel-dpi.c
index 5f8f7e7..31bd184 100644
--- a/drivers/video/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/omap2/displays-new/panel-dpi.c
@@ -13,9 +13,12 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
 
 #include <video/omapdss.h>
 #include <video/omap-panel-data.h>
+#include <video/of_display_timing.h>
 
 struct panel_drv_data {
 	struct omap_dss_device dssdev;
@@ -182,6 +185,66 @@ static int panel_dpi_probe_pdata(struct platform_device *pdev)
 	return 0;
 }
 
+static int panel_dpi_probe_of(struct platform_device *pdev)
+{
+	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+	struct device_node *node = pdev->dev.of_node;
+	struct omap_dss_device *in;
+	struct device_node *src_node;
+	int r, datalines;
+	struct display_timing timing;
+	struct videomode vm;
+	int gpio;
+
+	src_node = of_parse_phandle(node, "video-source", 0);
+	if (!src_node) {
+		dev_err(&pdev->dev, "failed to parse video source\n");
+		return -ENODEV;
+	}
+
+	in = omap_dss_find_output_by_node(src_node);
+	if (in = NULL) {
+		dev_err(&pdev->dev, "failed to find video source\n");
+		return -EPROBE_DEFER;
+	}
+	ddata->in = in;
+
+	r = of_property_read_u32(node, "data-lines", &datalines);
+	if (r) {
+		dev_err(&pdev->dev, "failed to parse datalines\n");
+		return r;
+	}
+
+	ddata->data_lines = datalines;
+
+	gpio = of_get_gpio(node, 0);
+	if (gpio_is_valid(gpio) || gpio = -ENOENT) {
+		ddata->enable_gpio = gpio;
+	} else {
+		dev_err(&pdev->dev, "failed to parse enable gpio\n");
+		return gpio;
+	}
+
+	gpio = of_get_gpio(node, 1);
+	if (gpio_is_valid(gpio) || gpio = -ENOENT) {
+		ddata->backlight_gpio = gpio;
+	} else {
+		dev_err(&pdev->dev, "failed to parse backlight gpio\n");
+		return gpio;
+	}
+
+	r = of_get_display_timing(node, "panel-timing", &timing);
+	if (r) {
+		dev_err(&pdev->dev, "failed to get video timing\n");
+		return r;
+	}
+
+	videomode_from_timing(&timing, &vm);
+	videomode_to_omap_video_timings(&vm, &ddata->videomode);
+
+	return 0;
+}
+
 static int panel_dpi_probe(struct platform_device *pdev)
 {
 	struct panel_drv_data *ddata;
@@ -198,6 +261,10 @@ static int panel_dpi_probe(struct platform_device *pdev)
 		r = panel_dpi_probe_pdata(pdev);
 		if (r)
 			return r;
+	} else if (pdev->dev.of_node) {
+		r = panel_dpi_probe_of(pdev);
+		if (r)
+			return r;
 	} else {
 		return -ENODEV;
 	}
@@ -254,12 +321,20 @@ static int __exit panel_dpi_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id panel_dpi_of_match[] = {
+	{ .compatible = "panel-dpi", },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, panel_dpi_of_match);
+
 static struct platform_driver panel_dpi_driver = {
 	.probe = panel_dpi_probe,
 	.remove = __exit_p(panel_dpi_remove),
 	.driver = {
 		.name = "panel-dpi",
 		.owner = THIS_MODULE,
+		.of_match_table = panel_dpi_of_match,
 	},
 };
 
-- 
1.8.1.2

[RFC 22/22] OMAPDSS: connector-analog-tv: Add DT support

[Tomi Valkeinen]

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 .../video/omap2/displays-new/connector-analog-tv.c | 70 ++++++++++++++++++++++
 1 file changed, 70 insertions(+)

diff --git a/drivers/video/omap2/displays-new/connector-analog-tv.c b/drivers/video/omap2/displays-new/connector-analog-tv.c
index 5338f36..b4fb74b 100644
--- a/drivers/video/omap2/displays-new/connector-analog-tv.c
+++ b/drivers/video/omap2/displays-new/connector-analog-tv.c
@@ -12,6 +12,7 @@
 #include <linux/slab.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
+#include <linux/of.h>
 
 #include <video/omapdss.h>
 #include <video/omap-panel-data.h>
@@ -28,6 +29,12 @@ struct panel_drv_data {
 	bool invert_polarity;
 };
 
+static const struct of_device_id tvc_of_match[];
+
+struct tvc_of_data {
+	enum omap_dss_venc_type connector_type;
+};
+
 #define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
 
 static int tvc_connect(struct omap_dss_device *dssdev)
@@ -191,6 +198,36 @@ static int tvc_probe_pdata(struct platform_device *pdev)
 	return 0;
 }
 
+static int tvc_probe_of(struct platform_device *pdev,
+		const struct tvc_of_data *data)
+{
+	struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+	struct device_node *node = pdev->dev.of_node;
+	struct omap_dss_device *in;
+	struct device_node *src_node;
+
+	src_node = of_parse_phandle(node, "video-source", 0);
+	if (!src_node) {
+		dev_err(&pdev->dev, "failed to parse video source\n");
+		return -ENODEV;
+	}
+
+	in = omap_dss_find_output_by_node(src_node);
+	if (in = NULL) {
+		dev_err(&pdev->dev, "failed to find video source\n");
+		return -EPROBE_DEFER;
+	}
+	ddata->in = in;
+
+	ddata->connector_type = data->connector_type;
+
+	ddata->invert_polarity +		of_property_read_bool(node, "invert-polarity");
+
+	return 0;
+}
+
+
 static int tvc_probe(struct platform_device *pdev)
 {
 	struct panel_drv_data *ddata;
@@ -208,6 +245,18 @@ static int tvc_probe(struct platform_device *pdev)
 		r = tvc_probe_pdata(pdev);
 		if (r)
 			return r;
+	} else if (pdev->dev.of_node) {
+		const struct of_device_id *match;
+
+		match = of_match_node(tvc_of_match, pdev->dev.of_node);
+		if (!match) {
+			dev_err(&pdev->dev, "unsupported device\n");
+			return -ENODEV;
+		}
+
+		r = tvc_probe_of(pdev, match->data);
+		if (r)
+			return r;
 	} else {
 		return -ENODEV;
 	}
@@ -249,12 +298,33 @@ static int __exit tvc_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct tvc_of_data tv_svideo_data = {
+	.connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static const struct tvc_of_data tv_composite_video_data = {
+	.connector_type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+};
+
+static const struct of_device_id tvc_of_match[] = {
+	{
+		.compatible = "ti,svideo-connector",
+		.data = &tv_svideo_data,
+	},
+	{
+		.compatible = "ti,composite-video-connector",
+		.data = &tv_composite_video_data,
+	},
+	{},
+};
+
 static struct platform_driver tvc_connector_driver = {
 	.probe	= tvc_probe,
 	.remove	= __exit_p(tvc_remove),
 	.driver	= {
 		.name	= "connector-analog-tv",
 		.owner	= THIS_MODULE,
+		.of_match_table = tvc_of_match,
 	},
 };
 
-- 
1.8.1.2

Re: [RFC 00/22] OMAPDSS: DT support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [130809 01:46]:
> 
> So as is evident, I have things in my mind that should be improved. Maybe
> the most important question for short term future is:
> 
> Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us
> some proper testing of the related code, and would also allow us to remove
> the related hacks (which don't even work quite right). However, I have no
> idea yet when the unstable DSS bindings would turn stable.
> 
> If we shouldn't add the bindings as unstable, when should the bindings be
> added? Wait until CDF is in the mainline, and use that?

I don't think we should add any temporary bindings as it's going to be
a pain to support those in the long run. I suggest you initially just
stick to established bindings for the basic hardware IO address and
interrupts etc, then those should still be valid with the generic panel
bindings later on.

Regards,

Tony

Re: [RFC 00/22] OMAPDSS: DT support

[Laurent Pinchart]

Hi Tomi,

I'm back from holidays and have finally found time to review your patch set.

On Friday 09 August 2013 11:38:45 Tomi Valkeinen wrote:
> Hi,
> 
> This is an RFC for OMAP Display DT support. The patches work fine, at least
> for me, but they are not perfect. I mostly don't have any clear questions
> about specific issues, but I would like to get feedback on the selected
> approaches in general, and also ideas how to proceed with the series.
> 
> This series contains the following:
> 
> DT support for the following OMAP's display subsystem devices:
> - DSS
> - DISPC
> - DPI
> - HDMI
> - VENC
> - DSI
> - (DBI/RFBI DT is not yet implemented)
> 
> DT support for the following external display devices:
> - panel-dsi-cm (Generic DSI command mode panel)
> - encoder-tfp410 (DPI-to-DVI encoder)
> - connector-dvi
> - encoder-tpd12s015 (HDMI level-shifter & ESD protection)
> - hdmi-connector
> - panel-dpi (Generic DPI panel)
> - connector-analog-tv (S-Video & Composite)
> 
> DT support for the following boards:
> - OMAP4 PandaBoard
> - OMAP4 SDP
> - OMAP3 BeagleBoard
> - OMAP3 Overo with Palo43 LCD expansion-board
> 
> The patches are not final, and many contain quite brief descriptions.
> Binding descriptions are also still missing. The code and bindings in the
> patches should be pretty straightforward, though.
> 
> The series is based on v3.11-rc2 + a couple of non-DSS fixes. The series
> can also be found from:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
> work/dss-dev-model-dt
> 
> Vocabulary
> =====
> 
> Display Entity - a hardware entity that takes one or more video streams as
> input and outputs one or more video streams.
> 
> Upstream Entity - A display entity in the "upstream" side of the video
> stream, i.e. closer to the original video source.
> 
> Downstream Entity - A display entity in the "downstream" side of the video
> stream, i.e. closer to the panel or monitor.
> 
> Video pipeline - A chain of multiple display entities, starting from the
> SoC, going to the display device the user sees.
> 
> Display or Panel - A display entity showing the pixels to the user
> 
> Encoder - A display entity that takes video as an input and (usually)
> outputs it in some other format.
> 
> Connector - HDMI/DVI/etc Connector on the board, to which an external
> monitor is connected.
> 
> About Stable DT Bindings
> ============
> 
> Generally speaking, the DT bindings should be stable. This brings the
> following problems:
> 
> We already have DT bindings for some OMAP4 and OMAP3 boards, and OMAP4
> boards do not even have board files anymore. There are no display bindings
> for those OMAP4 boards, but the display support is currently enabled as a
> hack, by calling board-file-like code to add the display devices for the
> selected boards. So, when we add the display bindings, we should still
> support the current DT files which do not have the display bindings. Which
> would mean that we'd need to keep the hacky code forever. Considering the
> fact that the hacky code does not work quite correct in all cases, I don't
> see keeping it as a very good option.
> 
> CDF (Common Display Framework) is in the works, and will most likely have
> different or more detailed bindings. Moving to CDF would mean we'd somehow
> need to still support the old OMAP bindings. In theory the display DT
> bindings should stay the same, as they represent the HW, not any SW
> constructs, but in practice I find it hard to believe the OMAP display
> bindings would be so perfect that there would be no need for changes.
> 
> We most likely should somehow represent DSS clock tree in DT. That is not a
> simple task, and when we manage to do it, it again means supporting the DT
> files without clock tree data.
> 
> All in all, I'm a bit scared to push the display bindings, as it's already
> clear there are changes coming. Then again, supporting the current hack for
> OMAP4 based boards is not nice at all, and has issues, so it would be really
> nice to get OMAP4 boards use proper display bindings.

Getting bindings right on the very first try is a very difficult, if not 
impossible, task. We now have dedicated DT bindings reviewers and maintainers 
to help here, and all DT bindings in mainline will likely go through extensive 
review in the not too distant future. I don't know if there has been any 
formal agreement on that, but one idea that seemed generally well approved was 
to first mark new DT bindings as experimental before promoting them to stable.

On the other hand, having experimental bindings in mainline should help 
stabilizing them, but that's obviously not a reason not to think them properly 
from the start.

> General description of the DT bindings
> ===================
> 
> All the display entities are represented as DT nodes of their own, and have
> a matching Linux driver. The display entities are organized by their control
> bus; that is, if a display entity is not controlled via any bus, it's a
> platform device, and if, say, it's controlled via i2c device, it's an i2c
> device.

I very much like that approach, and I think it's generally agreed upon.

> The exception to the above are DSI and DBI. DSI and DBI are combined control
> and video busses, but the use of the busses for control purposes is not
> independent of the video stream. Also, the the busses are, in practice,
> one-to-one links. And last, DSI and DBI display entities are often also
> controllable via, say, i2c. For these reasons there is no real Linux bus
> for DSI and DBI and thus the DSI and DBI devices are either platform
> devices or i2c devices.

That's something I'm less convinced about, but I don't have a too strong 
feeling. The best implementation should get to mainline, I won't nack this 
architecture just for theoretical reasons.

> The display entities are connected via "video-source" property. The video-
> source points to the upstream display entity where the video data comes
> from, and a chain of display entities thus form a full video pipeline. All
> video pipelines end with either a panel or a connector.

This is the part that bothers me the most, as I find it too limiting. In a 
purely linear pipeline entities will have at most one video source, but linear 
pipelines won't be enough for the future (and are actually not enough today 
already). We need to support entities with more than one sink pad in the DT 
bindings.

I've posted the third version of the Common Display Framework RFC 
(https://lwn.net/Articles/563157/). While not formally documented, the DT 
bindings are described in the cover letter. They're based on the V4L2 DT 
bindings and can express arbitrary display pipelines in DT. The patch set also 
provides helper functions to parse the DT bindings.

Could you please have a look at the bindings and tell me whether you can use 
them for the OMAPDSS (even if you don't use the CDF helpers to start with) ?

> All the data related to a display entity, and how it is connected on the
> given board, is defined in the DT node of the display entity. This means
> that the DT node of the upstream entity does not have to be modified when
> adding support for new boards.
>
> As an example, consider OMAP3's DPI and two boards using it for panels.
> omap3.dtsi contains a node for the DPI, and the board dts files contain
> nodes for their panels. The board dts files do not change anything in the
> included DPI node. So:
> 
> omap3.dtsi:
> 
> dpi: encoder@0 {
> 	compatible = "ti,omap3-dpi";
> };
> 
> omap3-board1.dts:
> 
> 	lcd0: display@0 {
> 		compatible = "samsung,lte430wq-f0c", "panel-dpi";
> 		video-source = <&dpi>;
> 		data-lines = <24>;
> 	};
> 
> omap3-board2.dts:
> 
> 	lcd0: display@0 {
> 		compatible = "samsung,lte430wq-f0c", "panel-dpi";
> 		video-source = <&dpi>;
> 		data-lines = <16>;
> 	};
> 
> The logic here is that the boards may have multiple panels that are
> connected to the same source, even if the panels can only be used one at a
> time. Each panel may thus have different properties for the bus, like the
> number of data-lines.
> 
> Video bus properties
> ==========
> 
> One question I've been pondering for a long time is related to the bus
> between two display entities. As an example, DPI (parallel RGB) requires
> configuring the number of datalines used. As described above, the properties
> of the video bus are represented in the downstream entity.
> 
> This approach has one drawback: how to represent features specific to the
> upstream entity? Say, if OMAP's DSI has a bus-related foo-feature, which can
> be used in some scenarios, the only place where this foo-feature can be
> specified is the OMAP DSI's properties. Not in the DSI Panel's properties,
> which in the current model contains properties related to the bus.
> 
> So Laurent has proposed to use V4L2-like ports, as described in
> Documentation/devicetree/bindings/media/video-interfaces.txt. I have not
> implemented such feature for OMAP DSS for the following reasons:
> 
> - The current supported displays we use work fine with the current method
> - If I were to implement such system, it'd most certainly be different than
>   what CDF will have.
> 
> That said, the port based approach does sound good, and it would also remove
> the design issue with OMAP DPI and SDI modules as described later. So maybe
> I should just go forward with it and hope that CDF will do it in similar
> manner.

I believe we should go for the port-based approach, even if you don't use the 
CDF helpers (possibly at first only).

> DSI Module ID
> ======> 
> On OMAP4 we have two DSI modules. To configure the clock routing and pin
> muxing, we need to know the hardware module ID for the DSI device, i.e. is
> this Linux platform device DSI1 or DSI2. The same issue exists with other
> SoCs with multiple outputs of the same kind.
> 
> With non-DT case, we used the platform device's ID directly. With DT, that
> doesn't work. I don't currently have a good solution for this, so as a
> temporary solution the DSI driver contains a table, from which it can find
> the HW module ID by using the device's base address.

You could add two output ports to the DSS, one for each DSI, and link the DSI 
modules to the DSS output ports in DT. That would represent the hardware 
topology, and would allow the DSI driver to know its ID based on the DSS 
output port it's connected to. It's still a bit hackish in the sense that the 
DSI driver will use information provided by the DSS (the output port number), 
but not more than the current method.

> I believe, but I am not totally sure, that we can remove the concept of DSI
> module ID if we have a good representation of the DSS clock tree and DSI pin
> muxing in DT. The clock tree is probably a huge undertaking, but the pin
> muxing should be much easier. However, pinmuxing also is some
> complications, like the pins requiring a regulator to be enabled.
>
> Display names and aliases
> ============> 
> With the board-file based model each display was given a name in the board
> file. Additionally, each display was given an alias in the style "displayX",
> where X is in incrementing number.
> 
> The name could be used by the user to see which display device is what, i.e.
> on Pandaboard there are displays names "dvi" and "hdmi".
> 
> The DT bindings do not have such a name. It would be simple to add a
> "nickname" property to each display node, but it just looked rather ugly so
> I have left it out.
> 
> Additionally, as there's no clear order in which the displays are created,
> and thus the number in "displayX" alias could change semi-randomly, I added
> the displays to "aliases" node. This keeps the display number the same over
> boots, and also gives us some way to define a default display, i.e. which
> display to use initially if the user has not specified it.
> 
> omapdss virtual device
> ===========
> 
> In addition to the DSS devices matching to DSS hardware modules, we have a
> "virtual" omapdss device which does not match to any actual HW module. The
> device is there mostly for legacy reasons, but it has also allowed us to
> easily pass platform callbacks. The same device is also present in DT
> solution. It is created in code, and not present in DT bindings.
> 
> Obviously, this omapdss virtual device is on the hack side, and nobody would
> mind if it would disappear.
> 
> The following data is passed via omapdss device's platform data:
> 
> - OMAP DSS version. In theory, the DSS revision registers should tell us
>   which features the HW supports. In practice, the HW people have not
>   bothered to change the revision number each time they've made changes. So
>   we pass a DSS version from the platform code, based on OMAP revision
>   number.
> 
> - omap_dss_set_min_bus_tput() and omap_pm_get_dev_context_loss_count() to
>   manage PM
> 
> - DSI pin muxing functions.
> 
> I have some ideas how to deduce the DSS version by poking to certain DSS
> registers, but it is not yet tested so I don't know if it will work.

That might be a stupid question, but can't you just encode the version in the 
compatible string of the DSS DT node (the one currently compatible with 
"ti,omap[34]-dss") ?

Version information might also need to be split/duplicated in several of the 
DSS DT nodes. A quick grep through the driver source code shows that the 
version is used by the submodules to infer SoC glue information. For instance 
dsi_get_channel() uses the version to find the DSI module channel ID. That 
information could possibly be retrieved from the links between the DSS DT 
nodes.

> We could do altogether without omap_pm_get_dev_context_loss_count(), so that
> should be removable with some work. I am not sure if
> omap_dss_set_min_bus_tput() is supported via standard PM calls or not.
> 
> However, the use of set_min_bus_tput() is actually a hack, as we're not
> really setting min bus tput. What we want to do is prevent OPP50. DSS clocks
> have different maximums on OPP100 and OPP50. So if DSS uses a clock over
> OPP50 limit, OPP50 cannot be entered. We prevent OPP50 by setting an
> arbitrarily high min bus tput.
> 
> The DSI pin muxing should also be solvable with DT based solution, but is
> not the most trivial task and needs some work.
> 
> So, I presume that at some point we can remove the omapdss device, but in
> the current solution it exists for the above reasons.
> 
> DSS submodules in DT bindings
> ==============> 
> The OMAP DSS modules are accessed via L4 or L3, and in that sense they
> should be on the same level in the DT bindings. However, we do not have them
> in the same level, but there is a main "dss" node, under which all the
> other DSS modules reside. The main reason for this is that the main DSS
> device needs to be enabled for the other modules to work properly, and
> having this structure makes runtime PM handle enabling DSS automatically.
> 
> If I recall right, somebody (Paul?) mentioned that in the hardware there is
> actually some DSS internal bus, and thus the DT structure is good in that
> sense also.
> 
> We also have nodes (and matching Linux devices) for DPI and SDI. Neither of
> them are actuall a separate IP block in the hardware, but are really more
> parts of DSS and maybe DISPC. They are still represented in the same way as
> the other DSS modules, to have similar architecture for all DSS outputs. But
> as they do not have an address-space of their own, the DT nodes use 0 and 1
> as "addresses", i.e. "dpi: encoder@0".
> 
> That is rather ugly, and maybe could use some cleaning up. A V4L2 port style
> approach would probably allow us to add DPI and SDI ports as part of DSS.

I think that would really be a good idea. The DPI and SDI code could be moved 
to the DSS module (it can of course still be kept in separate files as today), 
and the DISPC (if I'm not mistaken) entity would just have several output 
ports.

> Some of the DSS modules are actually a combination of multiple smaller
> modules. For example, the DSI module contains DSI protocol, DSI PHY and DSI
> PLL modules, each in their own address space. These could perhaps be
> presented as separate DT nodes and Linux devices, but I am not sure if that
> is a good approach or not.

What are the chances that one of those block will be upgraded and/or replaced 
independently of the others in the future (I know it's a tricky question) ? It 
might not be worth it going to a too fine-grained approach at the moment, but 
we need to make sure that the DT bindings will allow an easy path forward if 
needed.

> DT Node Names
> ======> 
> I have used the following naming conventions with DT nodes:
> 
> - Panels are named "display"
> - Connectors are named "connector"
> - Encoders are named "encoder"
> - DSS and DISPC are "dss" and "dispc", as they don't really match any of the
> above
> 
> When appropriate, the address part of the node is the base address, as in
> "dsi1: encoder@58004000". For platform devices, I have used an increasing
> number for the address, as in "tpd12s015: encoder@1".
> 
> Final words
> =====> 
> So as is evident, I have things in my mind that should be improved. Maybe
> the most important question for short term future is:
> 
> Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us
> some proper testing of the related code, and would also allow us to remove
> the related hacks (which don't even work quite right). However, I have no
> idea yet when the unstable DSS bindings would turn stable.
> 
> If we shouldn't add the bindings as unstable, when should the bindings be
> added? Wait until CDF is in the mainline, and use that?

What about using the CDF bindings, without waiting for CDF to be in mainline ? 
I believe the bindings should be upstreamed as unstable to start with anyway.

> I have not explained every piece of DSS in detail, as that would result in a
> book instead of this email, so feel free to ask for more details about any
> part.
> 
> And last but not least (for me, at least =), I'm on vacation for the next
> two weeks, so answers may be delayed.

Enjoy your holidays and recharge your batteries, you will need energy when 
you'll come back :-)

> Tomi Valkeinen (22):
>   ARM: OMAP: remove DSS DT hack
>   OMAPDSS: remove DT hacks for regulators
>   ARM: OMAP2+: add omapdss_init_of()
>   OMAPDSS: if dssdev->name=NULL, use alias
>   OMAPDSS: get dssdev->alias from DT alias
>   OMAPFB: clean up default display search
>   OMAPFB: search for default display with DT alias
>   OMAPDSS: Add DT support to DSS, DISPC, DPI, HDMI, VENC
>   OMAPDSS: Add DT support to DSI
>   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 display information
>   OMAPDSS: panel-dsi-cm: Add DT support
>   OMAPDSS: encoder-tfp410: Add DT support
>   OMAPDSS: connector-dvi: Add DT support
>   OMAPDSS: encoder-tpd12s015: Add DT support
>   OMAPDSS: hdmi-connector: Add DT support
>   OMAPDSS: panel-dpi: Add DT support
>   OMAPDSS: connector-analog-tv: Add DT support
> 
>  arch/arm/boot/dts/omap3-beagle.dts                 | 29 ++++++++
>  arch/arm/boot/dts/omap3-tobi.dts                   | 33 ++++++++
>  arch/arm/boot/dts/omap3.dtsi                       | 43 +++++++++++
>  arch/arm/boot/dts/omap4-panda-common.dtsi          | 48 ++++++++++++
>  arch/arm/boot/dts/omap4-sdp.dts                    | 70 +++++++++++++++++
>  arch/arm/boot/dts/omap4.dtsi                       | 59 +++++++++++++++
>  arch/arm/mach-omap2/board-generic.c                | 13 +---
>  arch/arm/mach-omap2/common.h                       |  2 +
>  arch/arm/mach-omap2/display.c                      | 34 +++++++++
>  arch/arm/mach-omap2/dss-common.c                   | 23 ------
>  arch/arm/mach-omap2/dss-common.h                   |  2 -
>  .../video/omap2/displays-new/connector-analog-tv.c | 70 +++++++++++++++++
>  drivers/video/omap2/displays-new/connector-dvi.c   | 49 ++++++++++++
>  drivers/video/omap2/displays-new/connector-hdmi.c  | 36 +++++++++
>  drivers/video/omap2/displays-new/encoder-tfp410.c  | 54 ++++++++++++++
>  .../video/omap2/displays-new/encoder-tpd12s015.c   | 62 +++++++++++++++
>  drivers/video/omap2/displays-new/panel-dpi.c       | 75 +++++++++++++++++++
>  drivers/video/omap2/displays-new/panel-dsi-cm.c    | 87 +++++++++++++++++++
>  drivers/video/omap2/dss/dispc.c                    |  7 ++
>  drivers/video/omap2/dss/display.c                  | 23 +++++-
>  drivers/video/omap2/dss/dpi.c                      |  8 ++
>  drivers/video/omap2/dss/dsi.c                      | 58 +++++++++++++--
>  drivers/video/omap2/dss/dss.c                      | 10 +++
>  drivers/video/omap2/dss/hdmi.c                     | 11 +--
>  drivers/video/omap2/dss/venc.c                     |  7 ++
>  drivers/video/omap2/omapfb/omapfb-main.c           | 67 ++++++++++++-----
>  26 files changed, 915 insertions(+), 65 deletions(-)

-- 
Regards,

Laurent Pinchart

Re: [RFC 00/22] OMAPDSS: DT support

[Tomi Valkeinen]

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

On 13/08/13 10:54, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130809 01:46]:
>>
>> So as is evident, I have things in my mind that should be improved. Maybe
>> the most important question for short term future is:
>>
>> Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us
>> some proper testing of the related code, and would also allow us to remove
>> the related hacks (which don't even work quite right). However, I have no
>> idea yet when the unstable DSS bindings would turn stable.
>>
>> If we shouldn't add the bindings as unstable, when should the bindings be
>> added? Wait until CDF is in the mainline, and use that?
> 
> I don't think we should add any temporary bindings as it's going to be
> a pain to support those in the long run. I suggest you initially just
> stick to established bindings for the basic hardware IO address and
> interrupts etc, then those should still be valid with the generic panel
> bindings later on.

I don't understand what does it matter if the bindings are temporary, or
basic established bindings. In both cases the DT data needs to be
changed when the CDF is taken into use.

Well, one difference is that the temporary bindings would give us
working display, but having only basic bindings would not. So I don't
see any reason to add only the basic bindings. Or how would it work?

 Tomi



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

Re: [RFC 00/22] OMAPDSS: DT support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [130830 02:55]:
> On 13/08/13 10:54, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [130809 01:46]:
> >>
> >> So as is evident, I have things in my mind that should be improved. Maybe
> >> the most important question for short term future is:
> >>
> >> Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us
> >> some proper testing of the related code, and would also allow us to remove
> >> the related hacks (which don't even work quite right). However, I have no
> >> idea yet when the unstable DSS bindings would turn stable.
> >>
> >> If we shouldn't add the bindings as unstable, when should the bindings be
> >> added? Wait until CDF is in the mainline, and use that?
> > 
> > I don't think we should add any temporary bindings as it's going to be
> > a pain to support those in the long run. I suggest you initially just
> > stick to established bindings for the basic hardware IO address and
> > interrupts etc, then those should still be valid with the generic panel
> > bindings later on.
> 
> I don't understand what does it matter if the bindings are temporary, or
> basic established bindings. In both cases the DT data needs to be
> changed when the CDF is taken into use.

Yes but the old bindings still need to be supported because people
are doing devices using those. So any kind of temporary binding will be
a pain to support.
 
> Well, one difference is that the temporary bindings would give us
> working display, but having only basic bindings would not. So I don't
> see any reason to add only the basic bindings. Or how would it work?

You might be able to use just a minimal binding for now using the
basic reg, interrupt and entries for the various components. Those will
be still valid when the CDF bindings are available.

Regards,

Tony

Re: [RFC 00/22] OMAPDSS: DT support

[Tomi Valkeinen]

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

On 02/09/13 09:15, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130830 02:55]:
>> On 13/08/13 10:54, Tony Lindgren wrote:
>>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130809 01:46]:
>>>>
>>>> So as is evident, I have things in my mind that should be improved. Maybe
>>>> the most important question for short term future is:
>>>>
>>>> Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us
>>>> some proper testing of the related code, and would also allow us to remove
>>>> the related hacks (which don't even work quite right). However, I have no
>>>> idea yet when the unstable DSS bindings would turn stable.
>>>>
>>>> If we shouldn't add the bindings as unstable, when should the bindings be
>>>> added? Wait until CDF is in the mainline, and use that?
>>>
>>> I don't think we should add any temporary bindings as it's going to be
>>> a pain to support those in the long run. I suggest you initially just
>>> stick to established bindings for the basic hardware IO address and
>>> interrupts etc, then those should still be valid with the generic panel
>>> bindings later on.
>>
>> I don't understand what does it matter if the bindings are temporary, or
>> basic established bindings. In both cases the DT data needs to be
>> changed when the CDF is taken into use.
> 
> Yes but the old bindings still need to be supported because people
> are doing devices using those. So any kind of temporary binding will be
> a pain to support.

If old bindings need to be supported, then we also need to support the
current state for Panda and SDP, i.e. there are no DSS related DT
bindings, but displays still work. Which means we'll have to keep the
current hacky DSS device construction mechanism for Panda and SDP.

Although maybe it's cleaner to somehow inject the DSS DT nodes for Panda
and SDP in case they are missing from the real DT data.

Doesn't supporting old bindings also mean that we can never get rid of
the hwmods? Or will there be code that injects the missing interrupt
etc. entries?

>> Well, one difference is that the temporary bindings would give us
>> working display, but having only basic bindings would not. So I don't
>> see any reason to add only the basic bindings. Or how would it work?
> 
> You might be able to use just a minimal binding for now using the
> basic reg, interrupt and entries for the various components. Those will
> be still valid when the CDF bindings are available.

Well, the entries will be valid, but the displays won't work with just
the basic bindings. I could perhaps add a new hack that creates the
required panel devices and video pipeline connections dynamically in
code for Panda and SDP, a bit like what the code does now, except the
basic DSS entries would be in the DT. But that would just add another
set of DT data that I would need to support in the future, and there
would be three different cases to support for Panda and SDP:

- DT data with no DSS related nodes
- DT data with basic DSS related nodes
- DT data with full DSS

So... If old bindings have to be supported, I'd rather try to minimize
the pain, and not add anything but the final bindings. In retrospect, it
was a bit of a mistake to add the hacky DT display support for Panda and
SDP, as it won't be very nice to keep supporting those.

  Tomi



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

Re: [RFC 00/22] OMAPDSS: DT support

[Tomi Valkeinen]

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

On 22/08/13 00:07, Laurent Pinchart wrote:

Thanks for the comments!

>> The exception to the above are DSI and DBI. DSI and DBI are combined control
>> and video busses, but the use of the busses for control purposes is not
>> independent of the video stream. Also, the the busses are, in practice,
>> one-to-one links. And last, DSI and DBI display entities are often also
>> controllable via, say, i2c. For these reasons there is no real Linux bus
>> for DSI and DBI and thus the DSI and DBI devices are either platform
>> devices or i2c devices.
> 
> That's something I'm less convinced about, but I don't have a too strong 
> feeling. The best implementation should get to mainline, I won't nack this 
> architecture just for theoretical reasons.

Ok. I posted a response to your DBI bus patch about the issues I see.

>> DSI Module ID
>> =============
>>
>> On OMAP4 we have two DSI modules. To configure the clock routing and pin
>> muxing, we need to know the hardware module ID for the DSI device, i.e. is
>> this Linux platform device DSI1 or DSI2. The same issue exists with other
>> SoCs with multiple outputs of the same kind.
>>
>> With non-DT case, we used the platform device's ID directly. With DT, that
>> doesn't work. I don't currently have a good solution for this, so as a
>> temporary solution the DSI driver contains a table, from which it can find
>> the HW module ID by using the device's base address.
> 
> You could add two output ports to the DSS, one for each DSI, and link the DSI 
> modules to the DSS output ports in DT. That would represent the hardware 
> topology, and would allow the DSI driver to know its ID based on the DSS 
> output port it's connected to. It's still a bit hackish in the sense that the 
> DSI driver will use information provided by the DSS (the output port number), 
> but not more than the current method.

Hmm, yep. That's kind of the same as having an explicit 'module-id'
property in the DSI node. I had implemented that solution at some point,
but considered it too ugly. But I agree that deducing the module-id from
the DSS output port is a bit cleaner, as it doesn't need any special
properties. And it's maybe also better than the address table I have
now, as the address table requires special code for each SoC.

I have to try the V4L2 ports to understand fully how to use them.

In the end, I hope to get rid of the module-id totally. It's really not
a DSI-thing at all. The DSI hardware does not use the module-id for
anything, it's more about how the DSI module is glued in the DSS/SoC.

>> I have some ideas how to deduce the DSS version by poking to certain DSS
>> registers, but it is not yet tested so I don't know if it will work.
> 
> That might be a stupid question, but can't you just encode the version in the 
> compatible string of the DSS DT node (the one currently compatible with 
> "ti,omap[34]-dss") ?

That would require having separate DT files for each revision. For
example, we have Beagle boards with different OMAP reversions.

It's fine to have the version encoded in the compatible string for major
versions, but having all minor revisions encoded there could result in a
mess.

> Version information might also need to be split/duplicated in several of the 
> DSS DT nodes. A quick grep through the driver source code shows that the 
> version is used by the submodules to infer SoC glue information. For instance 
> dsi_get_channel() uses the version to find the DSI module channel ID. That 
> information could possibly be retrieved from the links between the DSS DT 
> nodes.

Hmm, yes. Well. The DISPC has multiple output channels: LCD, LCD2, LCD3,
TV (depending on the SoC). These outputs go to encoders, and the routing
can be configured. If we consider only DSI encoders on OMAP4, the LCD2
output can be configured to go to DSI1 or DSI2 modules. LCD1 output can
be configured to go to DSI1 (but not to DSI2).

Because the routing has restrictions like mentioned above, it's somewhat
difficult to allocate the DISPC output channels during runtime in a
totally dynamic manner. Say, if we happened to allocate LCD2 for DSI1,
and later we'd want to use DSI2, there would be no DISPC output to use.

That's why we currently have them hardcoded in the driver, and it works
ok in all the use cases we have now. However, some board could need to
setup the channels in some other way for some particular use case.

So, I'm not totally comfortable with hardcoding the DISPC output - DSS
encoder connections in the DT data. While it'd work for most cases, it
doesn't work for all.

Then again, if the connections in the DT data would be considered more
like a default set of connections, and they could be changed later from
the kernel/userspace, then it'd be fine.

>> Some of the DSS modules are actually a combination of multiple smaller
>> modules. For example, the DSI module contains DSI protocol, DSI PHY and DSI
>> PLL modules, each in their own address space. These could perhaps be
>> presented as separate DT nodes and Linux devices, but I am not sure if that
>> is a good approach or not.
> 
> What are the chances that one of those block will be upgraded and/or replaced 
> independently of the others in the future (I know it's a tricky question) ? It 
> might not be worth it going to a too fine-grained approach at the moment, but 
> we need to make sure that the DT bindings will allow an easy path forward if 
> needed.

For DSI, I believe the chances are quite small. But for HDMI, we already
have this case for OMAP4 and OMAP5, and we're currently working on
splitting the HDMI core, PHY and PLL properly. I think it makes sense to
do the same for DSI also at the same time, especially as the PLL for DSI
and HDMI is the same (afaik).

>> If we shouldn't add the bindings as unstable, when should the bindings be
>> added? Wait until CDF is in the mainline, and use that?
> 
> What about using the CDF bindings, without waiting for CDF to be in mainline ? 
> I believe the bindings should be upstreamed as unstable to start with anyway.

Yes, I think that makes sense. And that's what I've been aiming at. I'm
just missing the ports-stuff.

Then again, I see opinions that the old bindings should be supported
(e.g. the mails with Tony in this same thread). If so, using CDF
bindings without CDF being in the mainline is a bit risky, as the
bindings could well change.

 Tomi



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

Re: [RFC 00/22] OMAPDSS: DT support

[Laurent Pinchart]

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

Hi Tomi,

On Monday 02 September 2013 11:00:15 Tomi Valkeinen wrote:
> On 22/08/13 00:07, Laurent Pinchart wrote:
> 
> Thanks for the comments!

You're welcome.

> >> The exception to the above are DSI and DBI. DSI and DBI are combined
> >> control and video busses, but the use of the busses for control purposes
> >> is not independent of the video stream. Also, the the busses are, in
> >> practice, one-to-one links. And last, DSI and DBI display entities are
> >> often also controllable via, say, i2c. For these reasons there is no
> >> real Linux bus for DSI and DBI and thus the DSI and DBI devices are
> >> either platform devices or i2c devices.
> > 
> > That's something I'm less convinced about, but I don't have a too strong
> > feeling. The best implementation should get to mainline, I won't nack this
> > architecture just for theoretical reasons.
> 
> Ok. I posted a response to your DBI bus patch about the issues I see.

I'll reply in that mail thread then.

> >> DSI Module ID
> >> =============
> >> 
> >> On OMAP4 we have two DSI modules. To configure the clock routing and pin
> >> muxing, we need to know the hardware module ID for the DSI device, i.e.
> >> is this Linux platform device DSI1 or DSI2. The same issue exists with
> >> other SoCs with multiple outputs of the same kind.
> >> 
> >> With non-DT case, we used the platform device's ID directly. With DT,
> >> that doesn't work. I don't currently have a good solution for this, so as
> >> a temporary solution the DSI driver contains a table, from which it can
> >> find the HW module ID by using the device's base address.
> > 
> > You could add two output ports to the DSS, one for each DSI, and link the
> > DSI modules to the DSS output ports in DT. That would represent the
> > hardware topology, and would allow the DSI driver to know its ID based on
> > the DSS output port it's connected to. It's still a bit hackish in the
> > sense that the DSI driver will use information provided by the DSS (the
> > output port number), but not more than the current method.
> 
> Hmm, yep. That's kind of the same as having an explicit 'module-id'
> property in the DSI node. I had implemented that solution at some point,
> but considered it too ugly. But I agree that deducing the module-id from
> the DSS output port is a bit cleaner, as it doesn't need any special
> properties. And it's maybe also better than the address table I have
> now, as the address table requires special code for each SoC.
> 
> I have to try the V4L2 ports to understand fully how to use them.

Feel free to ask questions :-)

> In the end, I hope to get rid of the module-id totally. It's really not
> a DSI-thing at all. The DSI hardware does not use the module-id for
> anything, it's more about how the DSI module is glued in the DSS/SoC.
> 
> >> I have some ideas how to deduce the DSS version by poking to certain DSS
> >> registers, but it is not yet tested so I don't know if it will work.
> > 
> > That might be a stupid question, but can't you just encode the version in
> > the compatible string of the DSS DT node (the one currently compatible
> > with "ti,omap[34]-dss") ?
> 
> That would require having separate DT files for each revision. For
> example, we have Beagle boards with different OMAP reversions.
> 
> It's fine to have the version encoded in the compatible string for major
> versions, but having all minor revisions encoded there could result in a
> mess.

Obviously if you can detect the version at runtime that would be best. Let's 
see if that can be done and then decide on what solution to implement.

> > Version information might also need to be split/duplicated in several of
> > the DSS DT nodes. A quick grep through the driver source code shows that
> > the version is used by the submodules to infer SoC glue information. For
> > instance dsi_get_channel() uses the version to find the DSI module
> > channel ID. That information could possibly be retrieved from the links
> > between the DSS DT nodes.
> 
> Hmm, yes. Well. The DISPC has multiple output channels: LCD, LCD2, LCD3,
> TV (depending on the SoC). These outputs go to encoders, and the routing
> can be configured. If we consider only DSI encoders on OMAP4, the LCD2
> output can be configured to go to DSI1 or DSI2 modules. LCD1 output can
> be configured to go to DSI1 (but not to DSI2).
> 
> Because the routing has restrictions like mentioned above, it's somewhat
> difficult to allocate the DISPC output channels during runtime in a
> totally dynamic manner. Say, if we happened to allocate LCD2 for DSI1,
> and later we'd want to use DSI2, there would be no DISPC output to use.
> 
> That's why we currently have them hardcoded in the driver, and it works
> ok in all the use cases we have now. However, some board could need to
> setup the channels in some other way for some particular use case.
> 
> So, I'm not totally comfortable with hardcoding the DISPC output - DSS
> encoder connections in the DT data. While it'd work for most cases, it
> doesn't work for all.

Encoding them in the device tree, in the driver(s), or computing them at 
runtime in the kernel are all suboptimal solutions. If the connections are 
configurable we want to expose that to userspace and let userspace configure 
the device. That's not possible yet due to API limitations, so we need to 
handle the situation on the kernel side. I'm thus fine with hardcoding this in 
the driver for now, DT should not encode more than possible connections, it 
shouldn't cary the default configuration.

> Then again, if the connections in the DT data would be considered more
> like a default set of connections, and they could be changed later from
> the kernel/userspace, then it'd be fine.
> 
> >> Some of the DSS modules are actually a combination of multiple smaller
> >> modules. For example, the DSI module contains DSI protocol, DSI PHY and
> >> DSI PLL modules, each in their own address space. These could perhaps be
> >> presented as separate DT nodes and Linux devices, but I am not sure if
> >> that is a good approach or not.
> > 
> > What are the chances that one of those block will be upgraded and/or
> > replaced independently of the others in the future (I know it's a tricky
> > question) ? It might not be worth it going to a too fine-grained approach
> > at the moment, but we need to make sure that the DT bindings will allow
> > an easy path forward if needed.
> 
> For DSI, I believe the chances are quite small. But for HDMI, we already
> have this case for OMAP4 and OMAP5, and we're currently working on
> splitting the HDMI core, PHY and PLL properly. I think it makes sense to
> do the same for DSI also at the same time, especially as the PLL for DSI
> and HDMI is the same (afaik).

Yes, then it's a good idea.

> >> If we shouldn't add the bindings as unstable, when should the bindings be
> >> added? Wait until CDF is in the mainline, and use that?
> > 
> > What about using the CDF bindings, without waiting for CDF to be in
> > mainline ? I believe the bindings should be upstreamed as unstable to
> > start with anyway.
>
> Yes, I think that makes sense. And that's what I've been aiming at. I'm
> just missing the ports-stuff.
> 
> Then again, I see opinions that the old bindings should be supported (e.g.
> the mails with Tony in this same thread). If so, using CDF bindings without
> CDF being in the mainline is a bit risky, as the bindings could well change.

But it's less risky than using custom bindings, isn't it ? :-)

-- 
Regards,

Laurent Pinchart

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [RFC 00/22] OMAPDSS: DT support

[Stefan Roese]

On 28.08.2013 13:40, Tero Kristo wrote:
> On 08/28/2013 01:14 PM, Tomi Valkeinen wrote:
>> On 28/08/13 12:48, Tero Kristo wrote:
>>> On 08/28/2013 12:22 PM, Tomi Valkeinen wrote:
>>>> Hi,
>>>>
>>>> I'm seeing odd clock behavior with Beagle, booting with DT. I'm using
>>>> v3.11-rc7 + DSS DT patches.
>>>
>>> I guess you are not using the clock DT patches? Just making sure I
>>> didn't break anything.
>>
>> No, plain rc7 with my DSS DT patches.
>>
>>>> So, for some reason, the first clk_set_rate goes wrong. Any ideas?
>>>
>>> Hmm, strange. I am not seeing similar behavior, but I am calling
>>> clk_set_rate in different location.... also I am using clock DT patches
>>> (don't try the current version though, as I am reworking them.)
>>>
>>> [    0.000000] dpll4_ck: 432000000
>>> [    0.000000] dpll4_m4_ck: 72000000
>>> [    0.000000] dpll4_m4x2_ck: 144000000
>>> [    0.000000] dss1_alwon_fck_3430es2: 144000000
>>> [    0.000000] dpll4_ck: 432000000
>>> [    0.000000] dpll4_m4_ck: 86400000
>>> [    0.000000] dpll4_m4x2_ck: 172800000
>>> [    0.000000] dss1_alwon_fck_3430es2: 172800000
>>>
>>> Do you see the error only when setting to some specific rate (86400000)
>>> or it doesn't matter?
>>
>> I also tried setting to 72000000, with the same result.
>>
>> Do you know if I can somehow easily get debug prints from the clock
>> framework, that could lighten up the issue?
>
> There isn't any good config option for that, I would suggest add prints
> to the clk_set_rate and then for the clocks you are interested in, print
> results for the recalc_rate / set_rate ops also.

Tomi, did you make any progress on this issue? If not I'll try to dig
into it later this week.

BTW: Whats the current plan for your OMAPDSS DT patchset? Is it queued
for v3.12 (this merge windows)? And do you have a git tree to pull the
latest version from?

Thanks,
Stefan

Re: [RFC 00/22] OMAPDSS: DT support

[Tomi Valkeinen]

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

On 04/09/13 10:29, Stefan Roese wrote:
> On 28.08.2013 13:40, Tero Kristo wrote:
>> On 08/28/2013 01:14 PM, Tomi Valkeinen wrote:
>>> On 28/08/13 12:48, Tero Kristo wrote:
>>>> On 08/28/2013 12:22 PM, Tomi Valkeinen wrote:
>>>>> Hi,
>>>>>
>>>>> I'm seeing odd clock behavior with Beagle, booting with DT. I'm using
>>>>> v3.11-rc7 + DSS DT patches.
>>>>
>>>> I guess you are not using the clock DT patches? Just making sure I
>>>> didn't break anything.
>>>
>>> No, plain rc7 with my DSS DT patches.
>>>
>>>>> So, for some reason, the first clk_set_rate goes wrong. Any ideas?
>>>>
>>>> Hmm, strange. I am not seeing similar behavior, but I am calling
>>>> clk_set_rate in different location.... also I am using clock DT patches
>>>> (don't try the current version though, as I am reworking them.)
>>>>
>>>> [    0.000000] dpll4_ck: 432000000
>>>> [    0.000000] dpll4_m4_ck: 72000000
>>>> [    0.000000] dpll4_m4x2_ck: 144000000
>>>> [    0.000000] dss1_alwon_fck_3430es2: 144000000
>>>> [    0.000000] dpll4_ck: 432000000
>>>> [    0.000000] dpll4_m4_ck: 86400000
>>>> [    0.000000] dpll4_m4x2_ck: 172800000
>>>> [    0.000000] dss1_alwon_fck_3430es2: 172800000
>>>>
>>>> Do you see the error only when setting to some specific rate (86400000)
>>>> or it doesn't matter?
>>>
>>> I also tried setting to 72000000, with the same result.
>>>
>>> Do you know if I can somehow easily get debug prints from the clock
>>> framework, that could lighten up the issue?
>>
>> There isn't any good config option for that, I would suggest add prints
>> to the clk_set_rate and then for the clocks you are interested in, print
>> results for the recalc_rate / set_rate ops also.
> 
> Tomi, did you make any progress on this issue? If not I'll try to dig
> into it later this week.

No, I haven't had time to debug this. And as this seems to show only
with DT, it's not a very high priority for me. DSS DT for OMAP4 is the
main priority, as the board files have already been removed for OMAP4
boards.

> BTW: Whats the current plan for your OMAPDSS DT patchset? Is it queued
> for v3.12 (this merge windows)? And do you have a git tree to pull the
> latest version from?

The git tree was mentioned in the intro mail.

No, DSS DT won't be in for 3.12. My current feeling is that it will
still take multiple kernel versions until it can be merged.

 Tomi



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

Re: [RFC 00/22] OMAPDSS: DT support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [130901 23:50]:
> On 02/09/13 09:15, Tony Lindgren wrote:
> > 
> > Yes but the old bindings still need to be supported because people
> > are doing devices using those. So any kind of temporary binding will be
> > a pain to support.
> 
> If old bindings need to be supported, then we also need to support the
> current state for Panda and SDP, i.e. there are no DSS related DT
> bindings, but displays still work. Which means we'll have to keep the
> current hacky DSS device construction mechanism for Panda and SDP.

Yes we want to keep things working for the users where possible and
not cause regressions. At least some kind of output about what the
user needs to do to update to latest kernel and some documentation
is would be needed..

> Although maybe it's cleaner to somehow inject the DSS DT nodes for Panda
> and SDP in case they are missing from the real DT data.

.. but naturally that would certainly make users life easier :)
 
> Doesn't supporting old bindings also mean that we can never get rid of
> the hwmods? Or will there be code that injects the missing interrupt
> etc. entries?

I certainly hope we won't be stuck with that and can define most of
the hwmod related data in the .dts files. We should be able to
provide at least some debug output so users know what needs to
be done to upgrade.

But yeah, if there were popular devices with the .dtb in ROM using
the legacy hwmod binding, then we'd be stuck with building or generating
the data in the kernel. Or load the data later on via /lib/firmware and
let deferred probe deal with it.
 
> >> Well, one difference is that the temporary bindings would give us
> >> working display, but having only basic bindings would not. So I don't
> >> see any reason to add only the basic bindings. Or how would it work?
> > 
> > You might be able to use just a minimal binding for now using the
> > basic reg, interrupt and entries for the various components. Those will
> > be still valid when the CDF bindings are available.
> 
> Well, the entries will be valid, but the displays won't work with just
> the basic bindings. I could perhaps add a new hack that creates the
> required panel devices and video pipeline connections dynamically in
> code for Panda and SDP, a bit like what the code does now, except the
> basic DSS entries would be in the DT. But that would just add another
> set of DT data that I would need to support in the future, and there
> would be three different cases to support for Panda and SDP:
> 
> - DT data with no DSS related nodes
> - DT data with basic DSS related nodes
> - DT data with full DSS
> 
> So... If old bindings have to be supported, I'd rather try to minimize
> the pain, and not add anything but the final bindings. In retrospect, it
> was a bit of a mistake to add the hacky DT display support for Panda and
> SDP, as it won't be very nice to keep supporting those.

Yes if that just makes things more complex, it's probably best to work
on getting the generic binding done instead.

Or just rely on getting the configuration from kernel cmdline and always
use just the basic bindings? That might help keep things working for
the "DT data with no DSS related nodes" case?

Regards,

Tony

Regards,

Tony