* [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Sascha Hauer, Sebastian Hesselbarth, Rob Clark, Inki Dae,
Andrzej Hajda, Tomasz Figa, Thierry Reding, Tomi Valkeinen
In-Reply-To: <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for MIPI DSI Command Mode Panel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../devicetree/bindings/video/panel-dsi-cm.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
diff --git a/Documentation/devicetree/bindings/video/panel-dsi-cm.txt b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
new file mode 100644
index 000000000000..73f422556d4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
@@ -0,0 +1,26 @@
+Generic MIPI DSI Command Mode Panel
+=================+
+Required properties:
+- compatible: "panel-dsi-cm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- gpios: panel reset gpio and TE gpio
+
+Required nodes:
+- Video port for DSI input
+
+Example
+-------
+
+lcd0: display {
+ compatible = "tpo,taal", "panel-dsi-cm";
+ label = "lcd0";
+
+ gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */
+
+ lcd0_in: endpoint {
+ remote-endpoint = <&dsi1_out_ep>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Sascha Hauer, Sebastian Hesselbarth, Rob Clark, Inki Dae,
Andrzej Hajda, Tomasz Figa, Thierry Reding, Tomi Valkeinen
In-Reply-To: <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for Sony acx565akm panel
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Sebastian Reichel <sre@debian.org>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../devicetree/bindings/video/sony,acx565akm.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
diff --git a/Documentation/devicetree/bindings/video/sony,acx565akm.txt b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
new file mode 100644
index 000000000000..cd9cfdf7e3fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
@@ -0,0 +1,28 @@
+Sony ACX565AKM SDI Panel
+============
+
+Required properties:
+- compatible: "sony,acx565akm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- gpios: panel reset gpio
+
+Required nodes:
+- Video port for SDI input
+
+Example
+-------
+
+acx565akm@2 {
+ compatible = "sony,acx565akm";
+ spi-max-frequency = <6000000>;
+ reg = <2>;
+
+ label = "lcd";
+ gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */
+
+ lcd_in: endpoint {
+ remote-endpoint = <&sdi_out>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 8/9] Doc/DT: Add DT binding documentation for TFP410 encoder
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Sascha Hauer, Sebastian Hesselbarth, Rob Clark, Inki Dae,
Andrzej Hajda, Tomasz Figa, Thierry Reding, Tomi Valkeinen
In-Reply-To: <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for TFP410 encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../devicetree/bindings/video/ti,tfp410.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
diff --git a/Documentation/devicetree/bindings/video/ti,tfp410.txt b/Documentation/devicetree/bindings/video/ti,tfp410.txt
new file mode 100644
index 000000000000..6a5a04627584
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,tfp410.txt
@@ -0,0 +1,41 @@
+TFP410 DPI to DVI encoder
+============+
+Required properties:
+- compatible: "ti,tfp410"
+
+Optional properties:
+- gpios: power-down gpio
+
+Required nodes:
+- Video port 0 for DPI input
+- Video port 1 for DVI output
+
+Example
+-------
+
+tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@0 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Sascha Hauer, Sebastian Hesselbarth, Rob Clark, Inki Dae,
Andrzej Hajda, Tomasz Figa, Thierry Reding, Tomi Valkeinen
In-Reply-To: <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for tpd12s015 encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 ++++++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
diff --git a/Documentation/devicetree/bindings/video/ti,tpd12s015.txt b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
new file mode 100644
index 000000000000..26e6d32e3f20
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
@@ -0,0 +1,44 @@
+TPD12S015 HDMI level shifter and ESD protection chip
+==========================
+
+Required properties:
+- compatible: "ti,tpd12s015"
+
+Optional properties:
+- gpios: CT CP HPD, LS OE and HPD gpios
+
+Required nodes:
+- Video port 0 for HDMI input
+- Video port 1 for HDMI output
+
+Example
+-------
+
+tpd12s015: encoder@1 {
+ compatible = "ti,tpd12s015";
+
+ gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */
+ <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */
+ <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint@0 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Tomasz Figa @ 2014-02-28 12:37 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev, dri-devel, devicetree,
linux-arm-kernel
Cc: Russell King - ARM Linux, Andrzej Hajda, Laurent Pinchart,
Sebastian Hesselbarth
In-Reply-To: <1393590016-9361-1-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On 28.02.2014 13:20, Tomi Valkeinen wrote:
> Hi,
>
> This series is a re-send of
> http://article.gmane.org/gmane.linux.drivers.devicetree/61739
>
> I'm cc'ing more people, and I want to clarify the contents of the series:
>
> While this has been developed for OMAP, only the first patch is about OMAP
> bindings. The rest are generic bindings for video components, which can be used
> on any platform.
>
> The bindings use the V4L2 style video port/endpoint system, described in
> Documentation/devicetree/bindings/media/video-interfaces.txt, to connect the
> components. The same port/endpoint bindings are used by Philipp Zabel in his
> imx-drm patch series.
>
> Shortly about the display components in the series, in the order of probable
> public interest:
>
> * Analog TV, DVI and HDMI Connectors represent a respective connector on the
> board. They don't do much, but they do mark the end of the video pipeline (from
> the board's pov), and they should also in the future offer ways to handle
> things like the +5V pin on DVI and HDMI connector and HPD pin.
>
> * MIPI DPI panel and MIPI DSI CM panels represent bindings for simple panels
> using the respective video bus.
I'm yet to take a deeper look at this series, but have you seen Andrzej
Hajda's patches adding support for DSI panels on Exynos [1] ?
[1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/27044
Best regards,
Tomasz
^ permalink raw reply
* Re: outcome of DRM/KMS DT bindings session
From: Tomi Valkeinen @ 2014-02-28 12:44 UTC (permalink / raw)
To: Dave Airlie, Sascha Hauer
Cc: ksummit-2013-discuss, Linux Fbdev development list, dri-devel
In-Reply-To: <CAPM=9ty7+A=YjSbRLxmo9mXSQSkZsZngBvTsryZ8+tHppEMPyw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]
Hi,
A bit old thread, but I noticed this only now.
On 01/11/13 02:10, Dave Airlie wrote:
> But why? why should we have separate drivers for each component of a
> tightly coupled SoC?
>
> it makes no sense, having a driver node per every block in the chip
> isn't an advantage, it complicates
> things for no advantage at all. If we don't have hotplug hw removing
> one device shouldn't be possible
> this idea that removing a sub-driver should teardown the drm is crazy as well.
It depends. The SoC's components may be independent as Mark noted, and
having separate device/driver may even be more or less required by the
arch code. I think this is so on OMAP.
In any case, I don't see any reason to require DRM developers to do it
in one way or another. One big driver may work best on one SoC, multiple
small drivers may work best on the other.
The thing is, we anyway need to support multiple devices/drivers, in
cases where we have, say, external i2c controlled encoder, or panels
that need explicit configuration.
So we can't just escape the init time problems by requiring a single big
DRM driver. And if we have the solution for the panels and external
encoders, I don't see why it would be any different for SoC internal
components.
The video pipeline is often composed of multiple video components, and
whether they reside on the SoC, or on the board, it doesn't really make
any difference.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Sebastian Hesselbarth @ 2014-02-28 12:57 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Sascha Hauer, Rob Clark, Inki Dae, Andrzej Hajda, Tomasz Figa,
Thierry Reding
In-Reply-To: <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
On 02/28/14 13:20, Tomi Valkeinen wrote:
> This series is a re-send of
> http://article.gmane.org/gmane.linux.drivers.devicetree/61739
>
...
> Shortly about the display components in the series, in the order of probable
> public interest:
>
> * Analog TV, DVI and HDMI Connectors represent a respective connector on the
> board. They don't do much, but they do mark the end of the video pipeline (from
> the board's pov), and they should also in the future offer ways to handle
> things like the +5V pin on DVI and HDMI connector and HPD pin.
>
> * MIPI DPI panel and MIPI DSI CM panels represent bindings for simple panels
> using the respective video bus.
>
> * Sony acx565akm is an SPI controlled panel using flatlink video bus.
>
> * TFP410 is a DPI to DVI encoder.
>
> * TPD12S015 is a HDMI companion chip, used on OMAP boards.
Tomi,
Out of curiosity, will there be DT nodes for pull-up resistors soon,
too? ;)
Honestly, TPD12S015 is a level shifter, there is nothing in it that
would justify a DT node nor a driver.
Above you already note, that connector nodes should offer HPD in the
future, but I guess the binding should represent that now already.
I will be a DT stub anyway, the corresponding video sink driver will
have to look it up.
Looking through the bindings for DVI and HDMI, I guess HPD gpio is
better kept in those nodes. From the relevant (DT) properties DVI and
HDMI connectors are in no way different.
Sebastian
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Tomi Valkeinen @ 2014-02-28 13:14 UTC (permalink / raw)
To: Sebastian Hesselbarth, linux-fbdev, dri-devel, devicetree,
linux-arm-kernel
Cc: Russell King - ARM Linux, Sascha Hauer, Tomasz Figa, Inki Dae,
Andrzej Hajda, Rob Clark, Thierry Reding, Laurent Pinchart,
Philipp Zabel
In-Reply-To: <531087C0.1090501@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2116 bytes --]
On 28/02/14 14:57, Sebastian Hesselbarth wrote:
> Out of curiosity, will there be DT nodes for pull-up resistors soon,
> too? ;)
If they don't work automatically, yes, we need DT nodes and drivers for
them.
> Honestly, TPD12S015 is a level shifter, there is nothing in it that
> would justify a DT node nor a driver.
TPD requires a power. Who turns that on? It also has two GPIOs, LS_OE
and CT_CP_HPD, which need to be controlled based on what the user wants
and the state of the HPD line. Who controls those?
> Above you already note, that connector nodes should offer HPD in the
> future, but I guess the binding should represent that now already.
I think it can be added when somebody uses it. I don't see why that
would cause trouble later to those that don't use it.
> I will be a DT stub anyway, the corresponding video sink driver will
> have to look it up.
I'm not sure what you mean with that. Yes, it's not the most complex DT
nodes out there.
> Looking through the bindings for DVI and HDMI, I guess HPD gpio is
> better kept in those nodes. From the relevant (DT) properties DVI and
> HDMI connectors are in no way different.
Well, I think the HPD gpio should be where it's most logical to have it.
I mean, you could have a setup where you have the SoC HDMI encoder and
and the HDMI connector, and the HPD pin goes directly to the HDMI
encoder, which has HW support for it. In that case, the HDMI encoder
node should contain the HPD, and the HDMI encoder should handle it.
Or, your HDMI encoder could not have any kind of support for HPD. In
that case you could have the HDMI connector driver handle the hotplug
event. You could of course make the HDMI encoder driver handle the HPD
gpio, but I usually try to have the driver handle the hardware device in
question.
In OMAP's case, we have the TPD chip between the HDMI encoder and the
connector, and the logical place to handle HPD GPIO in that case is the
TPD driver, as that's where the HPD is connected to and the TPD needs to
be configured according to the state of the HPD.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 8/9] Doc/DT: Add DT binding documentation for TFP410 encoder
From: Philipp Zabel @ 2014-02-28 13:37 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, dri-devel,
Andrzej Hajda, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <1393590016-9361-9-git-send-email-tomi.valkeinen@ti.com>
Am Freitag, den 28.02.2014, 14:20 +0200 schrieb Tomi Valkeinen:
> Add DT binding documentation for TFP410 encoder
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reviewed-by: Archit Taneja <archit@ti.com>
> ---
> .../devicetree/bindings/video/ti,tfp410.txt | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
>
> diff --git a/Documentation/devicetree/bindings/video/ti,tfp410.txt b/Documentation/devicetree/bindings/video/ti,tfp410.txt
> new file mode 100644
> index 000000000000..6a5a04627584
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/ti,tfp410.txt
> @@ -0,0 +1,41 @@
> +TFP410 DPI to DVI encoder
> +============> +
> +Required properties:
> +- compatible: "ti,tfp410"
> +
> +Optional properties:
> +- gpios: power-down gpio
Maybe call this powerdown-gpios?
> +Required nodes:
> +- Video port 0 for DPI input
> +- Video port 1 for DVI output
> +
> +Example
> +-------
> +
> +tfp410: encoder@0 {
> + compatible = "ti,tfp410";
> + gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + tfp410_in: endpoint@0 {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + tfp410_out: endpoint@0 {
> + remote-endpoint = <&dvi_connector_in>;
> + };
> + };
> + };
> +};
regards
Philipp
^ permalink raw reply
* Re: [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
From: Philipp Zabel @ 2014-02-28 13:38 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, dri-devel,
Andrzej Hajda, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <1393590016-9361-8-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
Am Freitag, den 28.02.2014, 14:20 +0200 schrieb Tomi Valkeinen:
> Add DT binding documentation for Sony acx565akm panel
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reviewed-by: Sebastian Reichel <sre@debian.org>
> Reviewed-by: Archit Taneja <archit@ti.com>
> ---
> .../devicetree/bindings/video/sony,acx565akm.txt | 28 ++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
>
> diff --git a/Documentation/devicetree/bindings/video/sony,acx565akm.txt b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
> new file mode 100644
> index 000000000000..cd9cfdf7e3fe
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
> @@ -0,0 +1,28 @@
> +Sony ACX565AKM SDI Panel
> +============
> +
> +Required properties:
> +- compatible: "sony,acx565akm"
> +
> +Optional properties:
> +- label: a symbolic name for the panel
> +- gpios: panel reset gpio
please let's call this reset-gpios.
> +Required nodes:
> +- Video port for SDI input
> +
> +Example
> +-------
> +
> +acx565akm@2 {
> + compatible = "sony,acx565akm";
> + spi-max-frequency = <6000000>;
> + reg = <2>;
> +
> + label = "lcd";
> + gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */
> +
> + lcd_in: endpoint {
> + remote-endpoint = <&sdi_out>;
> + };
> +};
regards
Philipp
^ permalink raw reply
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
From: Philipp Zabel @ 2014-02-28 13:40 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, dri-devel,
Andrzej Hajda, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <1393590016-9361-6-git-send-email-tomi.valkeinen@ti.com>
Am Freitag, den 28.02.2014, 14:20 +0200 schrieb Tomi Valkeinen:
> Add DT binding documentation for MIPI DPI Panel.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reviewed-by: Archit Taneja <archit@ti.com>
> ---
> .../devicetree/bindings/video/panel-dpi.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt
>
> diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt b/Documentation/devicetree/bindings/video/panel-dpi.txt
> new file mode 100644
> index 000000000000..72636c6f1c67
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
> @@ -0,0 +1,43 @@
> +Generic MIPI DPI Panel
> +===========
> +
> +Required properties:
> +- compatible: "panel-dpi"
> +
> +Optional properties:
> +- label: a symbolic name for the panel
> +- gpios: panel enable gpio and backlight enable gpio
> +
> +Required nodes:
> +- "panel-timing" containing video timings
> + (Documentation/devicetree/bindings/video/display-timing.txt)
> +- Video port for DPI input
I don't see anything MIPI specific here. Couldn't this be added to the
existing simple-panel binding?
> +Example
> +-------
> +
> +lcd0: display@0 {
> + compatible = "samsung,lte430wq-f0c", "panel-dpi";
> + label = "lcd";
> +
> + lcd_in: endpoint {
> + remote-endpoint = <&dpi_out>;
> + };
> +
> + 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>;
> + };
> +};
regards
Philipp
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Philipp Zabel @ 2014-02-28 13:43 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, dri-devel,
Andrzej Hajda, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <1393590016-9361-4-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
Am Freitag, den 28.02.2014, 14:20 +0200 schrieb Tomi Valkeinen:
> Add DT binding documentation for DVI Connector.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reviewed-by: Archit Taneja <archit@ti.com>
> ---
> .../devicetree/bindings/video/dvi-connector.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
>
> diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt b/Documentation/devicetree/bindings/video/dvi-connector.txt
> new file mode 100644
> index 000000000000..6a0aff866c78
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/dvi-connector.txt
> @@ -0,0 +1,26 @@
> +DVI Connector
> +=======
> +
> +Required properties:
> +- compatible: "dvi-connector"
> +
> +Optional properties:
> +- label: a symbolic name for the connector
> +- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
For the i.MX bindings I had called this property 'ddc', but
Documentation/devicetree/bindings/panel/simple-panel.txt already
uses 'ddc-i2c-bus'. We should definitely standardize this.
> +Required nodes:
> +- Video port for DVI input
> +
> +Example
> +-------
> +
> +dvi0: connector@0 {
> + compatible = "dvi-connector";
> + label = "dvi";
> +
> + i2c-bus = <&i2c3>;
> +
> + dvi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> +};
regards
Philipp
^ permalink raw reply
* Re: [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
From: Tomi Valkeinen @ 2014-02-28 13:47 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Laurent Pinchart, Russell King - ARM Linux, Sascha Hauer,
Sebastian Hesselbarth, Rob Clark, Inki Dae, Andrzej Hajda,
Tomasz Figa, Thierry Reding
In-Reply-To: <1393594707.3802.31.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]
On 28/02/14 15:38, Philipp Zabel wrote:
> Hi Tomi,
>
> Am Freitag, den 28.02.2014, 14:20 +0200 schrieb Tomi Valkeinen:
>> Add DT binding documentation for Sony acx565akm panel
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> Reviewed-by: Sebastian Reichel <sre@debian.org>
>> Reviewed-by: Archit Taneja <archit@ti.com>
>> ---
>> .../devicetree/bindings/video/sony,acx565akm.txt | 28 ++++++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
>>
>> diff --git a/Documentation/devicetree/bindings/video/sony,acx565akm.txt b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
>> new file mode 100644
>> index 000000000000..cd9cfdf7e3fe
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
>> @@ -0,0 +1,28 @@
>> +Sony ACX565AKM SDI Panel
>> +========================
>> +
>> +Required properties:
>> +- compatible: "sony,acx565akm"
>> +
>> +Optional properties:
>> +- label: a symbolic name for the panel
>> +- gpios: panel reset gpio
>
> please let's call this reset-gpios.
Yes, I'll change this and the tfp410 one.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Philipp Zabel @ 2014-02-28 13:47 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, dri-devel,
Andrzej Hajda, Tomi Valkeinen, Laurent Pinchart, linux-arm-kernel
In-Reply-To: <531087C0.1090501@gmail.com>
Hi,
Am Freitag, den 28.02.2014, 13:57 +0100 schrieb Sebastian Hesselbarth:
> On 02/28/14 13:20, Tomi Valkeinen wrote:
> > This series is a re-send of
> > http://article.gmane.org/gmane.linux.drivers.devicetree/61739
> >
> ...
> > Shortly about the display components in the series, in the order of probable
> > public interest:
> >
> > * Analog TV, DVI and HDMI Connectors represent a respective connector on the
> > board. They don't do much, but they do mark the end of the video pipeline (from
> > the board's pov), and they should also in the future offer ways to handle
> > things like the +5V pin on DVI and HDMI connector and HPD pin.
> >
> > * MIPI DPI panel and MIPI DSI CM panels represent bindings for simple panels
> > using the respective video bus.
> >
> > * Sony acx565akm is an SPI controlled panel using flatlink video bus.
> >
> > * TFP410 is a DPI to DVI encoder.
> >
> > * TPD12S015 is a HDMI companion chip, used on OMAP boards.
>
> Tomi,
>
> Out of curiosity, will there be DT nodes for pull-up resistors soon,
> too? ;)
>
> Honestly, TPD12S015 is a level shifter, there is nothing in it that
> would justify a DT node nor a driver.
>
> Above you already note, that connector nodes should offer HPD in the
> future, but I guess the binding should represent that now already.
> I will be a DT stub anyway, the corresponding video sink driver will
> have to look it up.
>
> Looking through the bindings for DVI and HDMI, I guess HPD gpio is
> better kept in those nodes. From the relevant (DT) properties DVI and
> HDMI connectors are in no way different.
I like the idea of adding actual connector nodes to the board device
trees. A TV encoder driver for example could this way detect from the
device tree whether it is connected to a VGA, Composite, or S-Video
connector (or maybe to both Composite and S-Video connectors at the same
time).
regards
Philipp
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Sebastian Hesselbarth @ 2014-02-28 13:51 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Sascha Hauer, Rob Clark, Inki Dae, Andrzej Hajda, Tomasz Figa,
Thierry Reding
In-Reply-To: <53108B9C.5000006-l0cyMroinI0@public.gmane.org>
On 02/28/14 14:14, Tomi Valkeinen wrote:
> On 28/02/14 14:57, Sebastian Hesselbarth wrote:
>
>> Out of curiosity, will there be DT nodes for pull-up resistors soon,
>> too? ;)
>
> If they don't work automatically, yes, we need DT nodes and drivers for
> them.
>
>> Honestly, TPD12S015 is a level shifter, there is nothing in it that
>> would justify a DT node nor a driver.
>
> TPD requires a power. Who turns that on? It also has two GPIOs, LS_OE
> and CT_CP_HPD, which need to be controlled based on what the user wants
> and the state of the HPD line. Who controls those?
Strictly speaking TPD12S015 has _no_ GPIO but only buffers. It
translates one voltage to another. The controlling instance is
your "video card" that is really interested in the actual state
of HPD signal.
Also the same for power, TPD12S015 doesn't decide to be powered up
or down but the "video card" does. We have GPIO regulators that
deal with that situation already.
Consider the same board but replace TPD12S015 with another level-
shifter, you still want OMAP video driver work with that out-of-the-box,
don't you? Fact is, OMAP IP requires GPIOs to sense HPD status hence
that GPIO is a property of the corresponding OMAP node. How level-
translation happens is irrelevant here.
>> Above you already note, that connector nodes should offer HPD in the
>> future, but I guess the binding should represent that now already.
>
> I think it can be added when somebody uses it. I don't see why that
> would cause trouble later to those that don't use it.
Thinking about it again, HPD gpio shouldn't be a property of the
connector at all but again the controlling instance. The connector
cannot deal with the information provided by HPD nor can it determine
if anyone is listening to HPD events.
>> I will be a DT stub anyway, the corresponding video sink driver will
>> have to look it up.
>
> I'm not sure what you mean with that. Yes, it's not the most complex DT
> nodes out there.
>
>> Looking through the bindings for DVI and HDMI, I guess HPD gpio is
>> better kept in those nodes. From the relevant (DT) properties DVI and
>> HDMI connectors are in no way different.
>
> Well, I think the HPD gpio should be where it's most logical to have it.
Right, but this is usually the controlling instance and not the
consuming one. E.g. to detect presence of an MMC card by GPIO, you'd
put that into the MMC _controller_ not any card node.
> I mean, you could have a setup where you have the SoC HDMI encoder and
> and the HDMI connector, and the HPD pin goes directly to the HDMI
> encoder, which has HW support for it. In that case, the HDMI encoder
> node should contain the HPD, and the HDMI encoder should handle it.
I wonder, if in case of an dedicated HPD pin, you would ever expose that
in DT.
> Or, your HDMI encoder could not have any kind of support for HPD. In
> that case you could have the HDMI connector driver handle the hotplug
> event. You could of course make the HDMI encoder driver handle the HPD
> gpio, but I usually try to have the driver handle the hardware device in
> question.
Having a driver for a dumb connector seems to be a little exaggerated.
Consider your generic HDMI connector "driver" connected to dedicated HPD
case above. It is pretty useless then. OTOH video controllers with
dedicated HPD know very well they can control HPD themselves, video
controllers without dedicated HPD also know very well that they need
GPIO for it.
> In OMAP's case, we have the TPD chip between the HDMI encoder and the
> connector, and the logical place to handle HPD GPIO in that case is the
> TPD driver, as that's where the HPD is connected to and the TPD needs to
> be configured according to the state of the HPD.
Is it really the logical place to handle HPD? I'd have put it into the
HDMI encoder because it's the unit most interested in the state of HPD.
Please, don't get me wrong, I like all this to be baked into a binding -
just wondering if a level-shifter driver plus corresponding DT node
is too much detail in here.
Sebastian
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Sebastian Hesselbarth @ 2014-02-28 13:56 UTC (permalink / raw)
To: Philipp Zabel
Cc: Tomi Valkeinen, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Laurent Pinchart, Russell King - ARM Linux, Sascha Hauer,
Rob Clark, Inki Dae, Andrzej Hajda, Tomasz Figa, Thierry Reding
In-Reply-To: <1393595264.3802.39.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
On 02/28/14 14:47, Philipp Zabel wrote:
> Am Freitag, den 28.02.2014, 13:57 +0100 schrieb Sebastian Hesselbarth:
>> On 02/28/14 13:20, Tomi Valkeinen wrote:
>>> This series is a re-send of
>>> http://article.gmane.org/gmane.linux.drivers.devicetree/61739
>>>
>> ...
>>> Shortly about the display components in the series, in the order of probable
>>> public interest:
>>>
>>> * Analog TV, DVI and HDMI Connectors represent a respective connector on the
>>> board. They don't do much, but they do mark the end of the video pipeline (from
>>> the board's pov), and they should also in the future offer ways to handle
>>> things like the +5V pin on DVI and HDMI connector and HPD pin.
>>>
>>> * MIPI DPI panel and MIPI DSI CM panels represent bindings for simple panels
>>> using the respective video bus.
>>>
>>> * Sony acx565akm is an SPI controlled panel using flatlink video bus.
>>>
>>> * TFP410 is a DPI to DVI encoder.
>>>
>>> * TPD12S015 is a HDMI companion chip, used on OMAP boards.
>>
>> Tomi,
>>
>> Out of curiosity, will there be DT nodes for pull-up resistors soon,
>> too? ;)
>>
>> Honestly, TPD12S015 is a level shifter, there is nothing in it that
>> would justify a DT node nor a driver.
>>
>> Above you already note, that connector nodes should offer HPD in the
>> future, but I guess the binding should represent that now already.
>> I will be a DT stub anyway, the corresponding video sink driver will
>> have to look it up.
>>
>> Looking through the bindings for DVI and HDMI, I guess HPD gpio is
>> better kept in those nodes. From the relevant (DT) properties DVI and
>> HDMI connectors are in no way different.
>
> I like the idea of adding actual connector nodes to the board device
> trees. A TV encoder driver for example could this way detect from the
> device tree whether it is connected to a VGA, Composite, or S-Video
> connector (or maybe to both Composite and S-Video connectors at the same
> time).
I agree that different connectors help providing a better
user-experienced view of board layout. But I doubt that besides the
differentiation (HDMI, DVI, VGA, SVideo, ...) and the endpoint there
should be anything more in that node.
Sebastian
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Tomi Valkeinen @ 2014-02-28 15:39 UTC (permalink / raw)
To: Sebastian Hesselbarth, linux-fbdev, dri-devel, devicetree,
linux-arm-kernel
Cc: Russell King - ARM Linux, Sascha Hauer, Tomasz Figa, Inki Dae,
Andrzej Hajda, Rob Clark, Thierry Reding, Laurent Pinchart,
Philipp Zabel
In-Reply-To: <5310945A.9040106@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8208 bytes --]
On 28/02/14 15:51, Sebastian Hesselbarth wrote:
>> TPD requires a power. Who turns that on? It also has two GPIOs, LS_OE
>> and CT_CP_HPD, which need to be controlled based on what the user wants
>> and the state of the HPD line. Who controls those?
>
> Strictly speaking TPD12S015 has _no_ GPIO but only buffers. It
What do you mean with that? That TPD doesn't provide GPIOs that you
could control, in the sense that SoCs do? Sure. I didn't mean that. I
meant it has gpios in the same sense that, say, a panel might have a
'enable' gpio.
Somebody needs to control the gpio state. For a panel, I would say it's
the panel driver's job. And the gpio would be present in the panel's DT
node. The same way for TDP.
> translates one voltage to another. The controlling instance is
> your "video card" that is really interested in the actual state
> of HPD signal.
Well. I think it's the driver for the respective hardware device that
handles the gpio. Of course, that driver will usually get information
from somewhere else when to use those gpios. It may be the "video card",
but really, the video card driver also gets the information if to enable
the output from somewhere else.
> Also the same for power, TPD12S015 doesn't decide to be powered up
> or down but the "video card" does. We have GPIO regulators that
> deal with that situation already.
The same here. TPD driver gets told to enable itself (or some particular
feature that it supports). It will then enable the required powers.
> Consider the same board but replace TPD12S015 with another level-
> shifter, you still want OMAP video driver work with that out-of-the-box,
Right. For this exact reason, the TPD is a separate driver. I can easily
leave it out, or replace it with any other similar chip. Or the TPD
driver can be used on some other platform.
OMAP video driver doesn't know anything about TPD, as TPD is not part of
OMAP video hardware, or even OMAP SoC.
How would this work without TPD, or with, say, TPD1234567, which instead
has 5 GPIOs that need to be set in particular order? The video card
driver would need to know the exact details of all possible level
shifters out there? Or?
> don't you? Fact is, OMAP IP requires GPIOs to sense HPD status hence
> that GPIO is a property of the corresponding OMAP node. How level-
> translation happens is irrelevant here.
No it doesn't. There are different ways to handle HPD on OMAP HDMI. It's
true that the HDMI IP supports directly handling HPD, but that's not
used as there were some issues with it (I don't remember what). The HPD
can as well be handled outside the HDMI driver.
If the HDMI IP would be handling the HPD, then, yes, HDMI node would
have HPD gpio defined.
> Thinking about it again, HPD gpio shouldn't be a property of the
> connector at all but again the controlling instance. The connector
> cannot deal with the information provided by HPD nor can it determine
> if anyone is listening to HPD events.
Well, this goes into the driver implementation details, but I disagree.
You have a video pipeline, let's say it's just SoC's HDMI encoder, and
HDMI connector. In this particular case, the HDMI encoder IP has no
support for HPD. On top of that, you have a "video card" driver,
"display subsystem" driver, or whatever you want to call it, which is in
control of the video pipeline. Let's call it controller.
The controller asks to get notified of a HPD event from the video
pipeline. It doesn't care if the HPD is handled by the HDMI encoder
driver or the connector driver. They can each handle it, in ways that
suit the particular hardware they control. Of course, handling it in
only one place usually makes sense.
When the controller is notified of a HPD, it can then decide what to do.
If the user has told it to enable video output on HPD, the controller
can command the video pipeline to be enabled.
>> Well, I think the HPD gpio should be where it's most logical to have it.
>
> Right, but this is usually the controlling instance and not the
> consuming one. E.g. to detect presence of an MMC card by GPIO, you'd
> put that into the MMC _controller_ not any card node.
I'm not familiar with MMC, so there it may be clear. With video, we can
have arbitrarily long video pipeline chains, with each component changed
to some other, differently behaving component.
Let's think of another case. SoC's DSI encoder, an external HDMI
encoder, and a HDMI connector. Who handles the HPD? Surely not the SoC's
DSI encoder, as there's no such concept as HPD in DSI? The "video card"
driver? Maybe, but from the video card's perspective, it is driving a
DSI peripheral, and again no HPD in DSI.
The logical place there is the external HDMI encoder. And again, the
HDMI encoder doesn't independently handle decisions about what to do
when HPD happens. It just catches it, and tells somebody wiser about it.
And really, what's the difference with, say, an external HDMI encoder
and TPD? Ok, lots =). But they both take video input in, output video,
and require some config/control to make the chip work.
I totally agree that TPD is on the simpler side of components. But I
think it fits right in into the model, and it works great on OMAP.
Compared to older version, where TPD support was baked into the OMAP
HDMI driver, which was a mess.
>> I mean, you could have a setup where you have the SoC HDMI encoder and
>> and the HDMI connector, and the HPD pin goes directly to the HDMI
>> encoder, which has HW support for it. In that case, the HDMI encoder
>> node should contain the HPD, and the HDMI encoder should handle it.
>
> I wonder, if in case of an dedicated HPD pin, you would ever expose that
> in DT.
Yes, if it's a dedicated pin, no configuration information needed, thus
no information needed in DT. Well, pinctrl maybe.
> Having a driver for a dumb connector seems to be a little exaggerated.
> Consider your generic HDMI connector "driver" connected to dedicated HPD
> case above. It is pretty useless then. OTOH video controllers with
> dedicated HPD know very well they can control HPD themselves, video
> controllers without dedicated HPD also know very well that they need
> GPIO for it.
Yes, I have to say I'm not 100% sure about the connectors. They could
perhaps be left out. But they make things consistent, in my opinion, as
they present a terminator for the video pipeline.
Say, you could have these two different boards:
SoC HDMI -> TPD -> HDMI connector
SoC HDMI -> TPD -> Embedded HDMI panel
In both cases, there's a component at the end, which is the end of the
pipeline (as far as we're concerned). I think it makes the driver side a
bit cleaner, and doesn't leave the TPD's output "hanging out" there.
Also I have used the connector drivers for actual work. The DVI
connector has support for reading EDID via i2c. This is again something
that you can argue that, hey, it should be the "video card" doing it.
But it fits quite well into the DVI connector, and there's no other
hardware component that has any support for the EDID.
I again see the above so that the video pipeline offers a way to read
EDID. Where exactly that's done and how it happens on the hardware
level, the controller doesn't care.
>> In OMAP's case, we have the TPD chip between the HDMI encoder and the
>> connector, and the logical place to handle HPD GPIO in that case is the
>> TPD driver, as that's where the HPD is connected to and the TPD needs to
>> be configured according to the state of the HPD.
>
> Is it really the logical place to handle HPD? I'd have put it into the
> HDMI encoder because it's the unit most interested in the state of HPD.
At least in OMAP's case, when not using the HDMI encoder's support for
HPD, the HDMI encoder is not interested at all about the HPD.
> Please, don't get me wrong, I like all this to be baked into a binding -
> just wondering if a level-shifter driver plus corresponding DT node
> is too much detail in here.
Thanks for the comments, I appreciate it. I hope I've convinced you
enough =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Russell King - ARM Linux @ 2014-02-28 15:59 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Philipp Zabel,
Laurent Pinchart, Sascha Hauer, Sebastian Hesselbarth, Rob Clark,
Inki Dae, Andrzej Hajda, Tomasz Figa, Thierry Reding
In-Reply-To: <1393590016-9361-4-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
On Fri, Feb 28, 2014 at 02:20:10PM +0200, Tomi Valkeinen wrote:
> Add DT binding documentation for DVI Connector.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reviewed-by: Archit Taneja <archit@ti.com>
> ---
> .../devicetree/bindings/video/dvi-connector.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
>
> diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt b/Documentation/devicetree/bindings/video/dvi-connector.txt
> new file mode 100644
> index 000000000000..6a0aff866c78
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/dvi-connector.txt
> @@ -0,0 +1,26 @@
> +DVI Connector
> +=======
> +
> +Required properties:
> +- compatible: "dvi-connector"
> +
> +Optional properties:
> +- label: a symbolic name for the connector
> +- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> +
> +Required nodes:
> +- Video port for DVI input
> +
> +Example
> +-------
> +
> +dvi0: connector@0 {
> + compatible = "dvi-connector";
> + label = "dvi";
> +
> + i2c-bus = <&i2c3>;
> +
> + dvi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> +};
This looks far too simplistic. There are different classes of DVI
connector - there is:
DVI A - analogue only
DVI D - digital only (single and dual link)
DVI I - both (single and dual digital link)
DRM at least makes a distinction between these three classes, and this
disctinction is part of the user API. How would a display system know
which kind of DVI connector is wired up on the board from this DT
description?
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
From: Russell King - ARM Linux @ 2014-02-28 16:06 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, dri-devel, Andrzej Hajda,
Laurent Pinchart, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <1393590016-9361-5-git-send-email-tomi.valkeinen@ti.com>
On Fri, Feb 28, 2014 at 02:20:11PM +0200, Tomi Valkeinen wrote:
> Add DT binding documentation for HDMI Connector.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reviewed-by: Archit Taneja <archit@ti.com>
> ---
> .../devicetree/bindings/video/hdmi-connector.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
>
> diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt
> new file mode 100644
> index 000000000000..5d25f6a432bb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
> @@ -0,0 +1,23 @@
> +HDMI Connector
> +=======
> +
> +Required properties:
> +- compatible: "hdmi-connector"
> +
> +Optional properties:
> +- label: a symbolic name for the connector
> +
> +Required nodes:
> +- Video port for HDMI input
> +
> +Example
> +-------
> +
> +hdmi0: connector@1 {
> + compatible = "hdmi-connector";
> + label = "hdmi";
> +
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&tpd12s015_out>;
> + };
> +};
It seems rather weird to have DVI connectors having an optional I2C
property, but HDMI (which augments DVI) not having that as at least an
optional property.
I can quite well see the iMX HDMI support needing an i2c bus here.
Also, HDMI has two connector standards - type A and type B, much like
the single vs dual link of DVI. Again, DRM exposes this to userspace.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Tomi Valkeinen @ 2014-02-28 16:12 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree, linux-fbdev, Sascha Hauer, Tomasz Figa, dri-devel,
Inki Dae, Andrzej Hajda, Rob Clark, Thierry Reding,
Laurent Pinchart, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <20140228155937.GQ21483@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]
On 28/02/14 17:59, Russell King - ARM Linux wrote:
>> +dvi0: connector@0 {
>> + compatible = "dvi-connector";
>> + label = "dvi";
>> +
>> + i2c-bus = <&i2c3>;
>> +
>> + dvi_connector_in: endpoint {
>> + remote-endpoint = <&tfp410_out>;
>> + };
>> +};
>
> This looks far too simplistic. There are different classes of DVI
> connector - there is:
>
> DVI A - analogue only
> DVI D - digital only (single and dual link)
> DVI I - both (single and dual digital link)
>
> DRM at least makes a distinction between these three classes, and this
> disctinction is part of the user API. How would a display system know
> which kind of DVI connector is wired up on the board from this DT
> description?
Yes, I think that's a valid change. But do we also need to specify
single/dual link, in addition to the three types?
I guess the compatible string is the easiest way for differentation, at
least for the three main types, i.e. "dvi-d-connector" etc.
"dvi-d-1l-connector" and "dvi-d-2l-connector" for the single/dual link?
That looks a bit funny.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
From: Russell King - ARM Linux @ 2014-02-28 16:13 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Philipp Zabel,
Laurent Pinchart, Sascha Hauer, Sebastian Hesselbarth, Rob Clark,
Inki Dae, Andrzej Hajda, Tomasz Figa, Thierry Reding
In-Reply-To: <1393590016-9361-10-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
On Fri, Feb 28, 2014 at 02:20:16PM +0200, Tomi Valkeinen wrote:
> Add DT binding documentation for tpd12s015 encoder
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reviewed-by: Archit Taneja <archit@ti.com>
> ---
> .../devicetree/bindings/video/ti,tpd12s015.txt | 44 ++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
>
> diff --git a/Documentation/devicetree/bindings/video/ti,tpd12s015.txt b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
> new file mode 100644
> index 000000000000..26e6d32e3f20
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
> @@ -0,0 +1,44 @@
> +TPD12S015 HDMI level shifter and ESD protection chip
> +==========================
> +
> +Required properties:
> +- compatible: "ti,tpd12s015"
> +
> +Optional properties:
> +- gpios: CT CP HPD, LS OE and HPD gpios
If this is supposed to give people a clue about what these GPIOs are,
it completely fails to do this. CT CP? HPD is obviously the hotplug
detect signal, but why are there two - HDMI only has a single detect
pin on the connector.
While it makes sense to stick all three into one property, is it
possible that not all of these may be routed to a GPIO? If so, how
do you specify that one (or more) of these does not exist?
Another issue here is that other HDMI encoders are available - should
every encoder define its own set of bindings, or should there be a
base set of bindings which all encoders should conform to - such as
always having a HDMI output port?
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
From: Tomi Valkeinen @ 2014-02-28 16:15 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree, linux-fbdev, Sascha Hauer, Tomasz Figa, dri-devel,
Inki Dae, Andrzej Hajda, Rob Clark, Thierry Reding,
Laurent Pinchart, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <20140228160612.GR21483@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]
On 28/02/14 18:06, Russell King - ARM Linux wrote:
>> +hdmi0: connector@1 {
>> + compatible = "hdmi-connector";
>> + label = "hdmi";
>> +
>> + hdmi_connector_in: endpoint {
>> + remote-endpoint = <&tpd12s015_out>;
>> + };
>> +};
>
> It seems rather weird to have DVI connectors having an optional I2C
> property, but HDMI (which augments DVI) not having that as at least an
> optional property.
I have added only the properties that I have used. I did think about the
i2c for HDMI also, but thought that I don't use it, and so can't test
it, and so I could well create a bad binding.
And, as I don't see any issue in adding it later, when someone uses it,
I decided to leave it out.
> I can quite well see the iMX HDMI support needing an i2c bus here.
>
> Also, HDMI has two connector standards - type A and type B, much like
> the single vs dual link of DVI. Again, DRM exposes this to userspace.
True, but isn't that just a form factor? No functional differences? But
I agree, we can add the two types here also to the compatible string.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Russell King - ARM Linux @ 2014-02-28 16:23 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Philipp Zabel,
Laurent Pinchart, Sascha Hauer, Sebastian Hesselbarth, Rob Clark,
Inki Dae, Andrzej Hajda, Tomasz Figa, Thierry Reding
In-Reply-To: <5310B567.7040605-l0cyMroinI0@public.gmane.org>
On Fri, Feb 28, 2014 at 06:12:23PM +0200, Tomi Valkeinen wrote:
> On 28/02/14 17:59, Russell King - ARM Linux wrote:
>
> >> +dvi0: connector@0 {
> >> + compatible = "dvi-connector";
> >> + label = "dvi";
> >> +
> >> + i2c-bus = <&i2c3>;
> >> +
> >> + dvi_connector_in: endpoint {
> >> + remote-endpoint = <&tfp410_out>;
> >> + };
> >> +};
> >
> > This looks far too simplistic. There are different classes of DVI
> > connector - there is:
> >
> > DVI A - analogue only
> > DVI D - digital only (single and dual link)
> > DVI I - both (single and dual digital link)
> >
> > DRM at least makes a distinction between these three classes, and this
> > disctinction is part of the user API. How would a display system know
> > which kind of DVI connector is wired up on the board from this DT
> > description?
>
> Yes, I think that's a valid change. But do we also need to specify
> single/dual link, in addition to the three types?
I would argue that as it's a difference in physical hardware, then it
should be described in DT, even if we don't use it. The reasoning is
that although we may not use it today, we may need to use it in the
future, and as we're describing what the hardware actually is - and
even in this case what pins may be present or missing on the connector,
it's unlikely to be problematical (the only problem is when someone
omits it...)
> I guess the compatible string is the easiest way for differentation, at
> least for the three main types, i.e. "dvi-d-connector" etc.
>
> "dvi-d-1l-connector" and "dvi-d-2l-connector" for the single/dual link?
> That looks a bit funny.
I think that starts getting a tad messy:
dvi-a-connector
dvi-d-1l-connector
dvi-d-2l-connector
dvi-i-1l-connector
dvi-i-2l-connector
That's rather a lot of compatible strings. Another possibility is:
compatible = "dvi-connector";
analog;
digital;
single-link;
dual-link;
I'm debating whether "-signalling" should be on the 2nd and 3rd (or...
-signaling depending on how you prefer to spell that word.) At least
one of "analog" and/or "digital" must be specified, and if "digital"
is specified, then exactly one of "single-link" or "dual-link" should
be specified.
So, this would mean we end up with:
compatible = "dvi-connector";
analog;
digital;
dual-link;
for a DVI-I dual-link connector.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Sebastian Reichel @ 2014-02-28 16:25 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Russell King - ARM Linux, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer, Tomasz Figa,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Inki Dae,
Andrzej Hajda, Rob Clark, Thierry Reding, Laurent Pinchart,
Philipp Zabel, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
In-Reply-To: <5310B567.7040605-l0cyMroinI0@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]
On Fri, Feb 28, 2014 at 06:12:23PM +0200, Tomi Valkeinen wrote:
> On 28/02/14 17:59, Russell King - ARM Linux wrote:
>
> >> +dvi0: connector@0 {
> >> + compatible = "dvi-connector";
> >> + label = "dvi";
> >> +
> >> + i2c-bus = <&i2c3>;
> >> +
> >> + dvi_connector_in: endpoint {
> >> + remote-endpoint = <&tfp410_out>;
> >> + };
> >> +};
> >
> > This looks far too simplistic. There are different classes of DVI
> > connector - there is:
> >
> > DVI A - analogue only
> > DVI D - digital only (single and dual link)
> > DVI I - both (single and dual digital link)
> >
> > DRM at least makes a distinction between these three classes, and this
> > disctinction is part of the user API. How would a display system know
> > which kind of DVI connector is wired up on the board from this DT
> > description?
>
> Yes, I think that's a valid change. But do we also need to specify
> single/dual link, in addition to the three types?
>
> I guess the compatible string is the easiest way for differentation, at
> least for the three main types, i.e. "dvi-d-connector" etc.
>
> "dvi-d-1l-connector" and "dvi-d-2l-connector" for the single/dual link?
> That looks a bit funny.
maybe like this:
Required Properties:
- compatible: should contain one of the following:
* "dvi-d-connector"
* "dvi-a-connector"
* "dvi-i-connector"
Optional Properties:
- dual-link: Should be set for dual-link capable connectors
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Philipp Zabel @ 2014-02-28 16:25 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Tomi Valkeinen, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Laurent Pinchart, Sascha Hauer, Sebastian Hesselbarth, Rob Clark,
Inki Dae, Andrzej Hajda, Tomasz Figa, Thierry Reding
In-Reply-To: <20140228155937.GQ21483-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
Am Freitag, den 28.02.2014, 15:59 +0000 schrieb Russell King - ARM
Linux:
> On Fri, Feb 28, 2014 at 02:20:10PM +0200, Tomi Valkeinen wrote:
> > Add DT binding documentation for DVI Connector.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Reviewed-by: Archit Taneja <archit@ti.com>
> > ---
> > .../devicetree/bindings/video/dvi-connector.txt | 26 ++++++++++++++++++++++
> > 1 file changed, 26 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
> >
> > diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt b/Documentation/devicetree/bindings/video/dvi-connector.txt
> > new file mode 100644
> > index 000000000000..6a0aff866c78
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/dvi-connector.txt
> > @@ -0,0 +1,26 @@
> > +DVI Connector
> > +=======
> > +
> > +Required properties:
> > +- compatible: "dvi-connector"
> > +
> > +Optional properties:
> > +- label: a symbolic name for the connector
> > +- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> > +
> > +Required nodes:
> > +- Video port for DVI input
> > +
> > +Example
> > +-------
> > +
> > +dvi0: connector@0 {
> > + compatible = "dvi-connector";
> > + label = "dvi";
> > +
> > + i2c-bus = <&i2c3>;
> > +
> > + dvi_connector_in: endpoint {
> > + remote-endpoint = <&tfp410_out>;
> > + };
> > +};
>
> This looks far too simplistic. There are different classes of DVI
> connector - there is:
>
> DVI A - analogue only
> DVI D - digital only (single and dual link)
> DVI I - both (single and dual digital link)
>
> DRM at least makes a distinction between these three classes, and this
> disctinction is part of the user API. How would a display system know
> which kind of DVI connector is wired up on the board from this DT
> description?
Maybe this could be inferred from the sources connected to it. For
example a i.MX5 board with the SoC internal TV Encoder and an external
SiI902x HDMI encoder connected to the same DVI I connector:
ipu {
port@2 {
ipu_di0_disp0: endpoint {
remote-endpoint = <&sii902x_in>;
};
};
port@3 {
ipu_di1_tve: endpoint {
remote-endpoint = <&tve_in>;
};
};
};
&sii902x {
compatible = "si,sii9022";
port@0 {
sii902x_in: endpoint {
remote-endpoint = <&ipu_di0>;
};
};
port@1 {
sii902x_out: endpoint {
remote-endpoint = <&dvi_d_in>;
};
};
};
&tve {
compatible = "fsl,imx53-tve";
port@0 {
tve_in: endpoint {
remote-endpoint = <&ipu_di1>;
};
};
port@1 {
tve_out: endpoint {
remote-endpoint = <&dvi_a_in>;
};
};
};
dvi-connector {
compatible = "dvi-connector";
ddc-i2c-bus = <&i2c3>;
port {
dvi_d_in: endpoint@0 {
remote-endpoint = <&sii902x_out>;
};
dvi_a_in: endpoint@1 {
remote-endpoint = <&tve_out>;
};
};
};
It should be possible to let the connector know that those two endpoints
are connected to a TMDS source and to a VGA source, respectively.
regards
Philipp
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox