* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
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.
* 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.
These patches, on top of the OMAP DSS DT work, can be found from:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
Tomi
Tomi Valkeinen (9):
Doc/DT: Add OMAP DSS DT Bindings
Doc/DT: Add DT binding documentation for Analog TV Connector
Doc/DT: Add DT binding documentation for DVI Connector
Doc/DT: Add DT binding documentation for HDMI Connector
Doc/DT: Add DT binding documentation for MIPI DPI Panel
Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
Doc/DT: Add DT binding documentation for Sony acx565akm panel
Doc/DT: Add DT binding documentation for TFP410 encoder
Doc/DT: Add DT binding documentation for tpd12s015 encoder
.../bindings/video/analog-tv-connector.txt | 23 +++
.../devicetree/bindings/video/dvi-connector.txt | 26 +++
.../devicetree/bindings/video/hdmi-connector.txt | 23 +++
.../devicetree/bindings/video/panel-dpi.txt | 43 +++++
.../devicetree/bindings/video/panel-dsi-cm.txt | 26 +++
.../devicetree/bindings/video/sony,acx565akm.txt | 28 +++
.../devicetree/bindings/video/ti,omap-dss.txt | 203 +++++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 ++++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 83 +++++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 111 +++++++++++
.../devicetree/bindings/video/ti,tfp410.txt | 41 +++++
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 +++++
.../devicetree/bindings/video/video-ports.txt | 22 +++
13 files changed, 727 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt
create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
create mode 100644 Documentation/devicetree/bindings/video/video-ports.txt
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
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.
* 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.
These patches, on top of the OMAP DSS DT work, can be found from:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
Tomi
Tomi Valkeinen (9):
Doc/DT: Add OMAP DSS DT Bindings
Doc/DT: Add DT binding documentation for Analog TV Connector
Doc/DT: Add DT binding documentation for DVI Connector
Doc/DT: Add DT binding documentation for HDMI Connector
Doc/DT: Add DT binding documentation for MIPI DPI Panel
Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
Doc/DT: Add DT binding documentation for Sony acx565akm panel
Doc/DT: Add DT binding documentation for TFP410 encoder
Doc/DT: Add DT binding documentation for tpd12s015 encoder
.../bindings/video/analog-tv-connector.txt | 23 +++
.../devicetree/bindings/video/dvi-connector.txt | 26 +++
.../devicetree/bindings/video/hdmi-connector.txt | 23 +++
.../devicetree/bindings/video/panel-dpi.txt | 43 +++++
.../devicetree/bindings/video/panel-dsi-cm.txt | 26 +++
.../devicetree/bindings/video/sony,acx565akm.txt | 28 +++
.../devicetree/bindings/video/ti,omap-dss.txt | 203 +++++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 ++++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 83 +++++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 111 +++++++++++
.../devicetree/bindings/video/ti,tfp410.txt | 41 +++++
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 +++++
.../devicetree/bindings/video/video-ports.txt | 22 +++
13 files changed, 727 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt
create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
create mode 100644 Documentation/devicetree/bindings/video/video-ports.txt
--
1.8.3.2
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-arm-kernel
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.
* 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.
These patches, on top of the OMAP DSS DT work, can be found from:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
Tomi
Tomi Valkeinen (9):
Doc/DT: Add OMAP DSS DT Bindings
Doc/DT: Add DT binding documentation for Analog TV Connector
Doc/DT: Add DT binding documentation for DVI Connector
Doc/DT: Add DT binding documentation for HDMI Connector
Doc/DT: Add DT binding documentation for MIPI DPI Panel
Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
Doc/DT: Add DT binding documentation for Sony acx565akm panel
Doc/DT: Add DT binding documentation for TFP410 encoder
Doc/DT: Add DT binding documentation for tpd12s015 encoder
.../bindings/video/analog-tv-connector.txt | 23 +++
.../devicetree/bindings/video/dvi-connector.txt | 26 +++
.../devicetree/bindings/video/hdmi-connector.txt | 23 +++
.../devicetree/bindings/video/panel-dpi.txt | 43 +++++
.../devicetree/bindings/video/panel-dsi-cm.txt | 26 +++
.../devicetree/bindings/video/sony,acx565akm.txt | 28 +++
.../devicetree/bindings/video/ti,omap-dss.txt | 203 +++++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 ++++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 83 +++++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 111 +++++++++++
.../devicetree/bindings/video/ti,tfp410.txt | 41 +++++
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 +++++
.../devicetree/bindings/video/video-ports.txt | 22 +++
13 files changed, 727 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt
create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
create mode 100644 Documentation/devicetree/bindings/video/video-ports.txt
--
1.8.3.2
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 1/9] Doc/DT: Add OMAP DSS DT Bindings
[not found] ` <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 12:20 ` Tomi Valkeinen
@ 2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
` (9 subsequent siblings)
11 siblings, 0 replies; 207+ messages in thread
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
Add device tree bindings for OMAP Display Subsystem for the following
SoCs: OMAP2, OMAP3, OMAP4.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
---
.../devicetree/bindings/video/ti,omap-dss.txt | 203 +++++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 ++++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 83 +++++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 111 +++++++++++
.../devicetree/bindings/video/video-ports.txt | 22 +++
5 files changed, 473 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/video-ports.txt
diff --git a/Documentation/devicetree/bindings/video/ti,omap-dss.txt b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
new file mode 100644
index 000000000000..a0f2e69b0e3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
@@ -0,0 +1,203 @@
+Texas Instruments OMAP Display Subsystem
+========================================
+
+Generic Description
+-------------------
+
+This document is a generic description of the OMAP Display Subsystem bindings.
+Binding details for each OMAP SoC version are described in respective binding
+documentation.
+
+The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and
+a number of encoder modules. All DSS versions contain DSS Core and DISPC, but
+the encoder modules vary.
+
+The DSS Core is the parent of the other DSS modules, and manages clock routing,
+integration to the SoC, etc.
+
+DISPC is the display controller, which reads pixels from the memory and outputs
+a RGB pixel stream to encoders.
+
+The encoder modules encode the received RGB pixel stream to a video output like
+HDMI, MIPI DPI, etc.
+
+Video Ports
+-----------
+
+The DSS Core and the encoders have video port outputs. The structure of the
+video ports is described in Documentation/devicetree/bindings/video/video-
+ports.txt, and the properties for the ports and endpoints for each encoder are
+described in the SoC's DSS binding documentation.
+
+The video ports are used to describe the connections to external hardware, like
+panels or external encoders.
+
+Aliases
+-------
+
+The board dts file may define aliases for displays to assign "displayX" style
+name for each display. If no aliases are defined, a semi-random number is used
+for the display.
+
+Example
+-------
+
+A shortened example of the DSS description for OMAP4, with non-relevant parts
+removed, defined in omap4.dtsi:
+
+dss: dss@58000000 {
+ compatible = "ti,omap4-dss", "simple-bus";
+ reg = <0x58000000 0x80>;
+ status = "disabled";
+ ti,hwmods = "dss_core";
+ clocks = <&dss_dss_clk>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc@58001000 {
+ compatible = "ti,omap4-dispc";
+ reg = <0x58001000 0x1000>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ ti,hwmods = "dss_dispc";
+ clocks = <&dss_dss_clk>;
+ clock-names = "fck";
+ };
+
+ hdmi: encoder@58006000 {
+ compatible = "ti,omap4-hdmi";
+ reg = <0x58006000 0x200>,
+ <0x58006200 0x100>,
+ <0x58006300 0x100>,
+ <0x58006400 0x1000>;
+ reg-names = "wp", "pll", "phy", "core";
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ ti,hwmods = "dss_hdmi";
+ clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
+ clock-names = "fck", "sys_clk";
+ };
+};
+
+A shortened example of the board description for OMAP4 Panda board, defined in
+omap4-panda.dts.
+
+The Panda board has a DVI and a HDMI connector, and the board contains a TFP410
+chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level
+shifter). The video pipelines for the connectors are formed as follows:
+
+DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector
+OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI Connector
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ display1 = &hdmi0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; /* 0, power-down */
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tfp410_pins>;
+
+ 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>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = "dvi-connector";
+ label = "dvi";
+
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+
+ tpd12s015: encoder@1 {
+ compatible = "ti,tpd12s015";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tpd12s015_pins>;
+
+ 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>;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@1 {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_dpi_pins>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+};
+
+&hdmi {
+ status = "ok";
+ vdda-supply = <&vdac>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_hdmi_pins>;
+
+ hdmi_out: endpoint {
+ remote-endpoint = <&tpd12s015_in>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/video/ti,omap2-dss.txt b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
new file mode 100644
index 000000000000..fa8bb2ed1170
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
@@ -0,0 +1,54 @@
+Texas Instruments OMAP2 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap2-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+
+Optional nodes:
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap2-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap2-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap2-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+
+VENC Endpoint required properties:
+
+Required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
diff --git a/Documentation/devicetree/bindings/video/ti,omap3-dss.txt b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
new file mode 100644
index 000000000000..0023fa4b1328
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
@@ -0,0 +1,83 @@
+Texas Instruments OMAP3 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap3-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video ports:
+ - Port 0: DPI output
+ - Port 1: SDI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+SDI Endpoint required properties:
+- datapairs: number of datapairs used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap3-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap3-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap3-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap3-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
new file mode 100644
index 000000000000..f85d6fcfa705
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
@@ -0,0 +1,111 @@
+Texas Instruments OMAP4 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap4-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Required nodes:
+- DISPC
+
+Optional nodes:
+- DSS Submodules: RFBI, VENC, DSI, HDMI
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap4-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap4-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+Optional nodes:
+- Video port for RFBI output
+- RFBI controlled peripherals
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap4-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video port for VENC output
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap4-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1" or "dss_dsi2"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for DSI output
+- DSI controlled peripherals
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
+
+
+HDMI
+----
+
+Required properties:
+- compatible: "ti,omap4-hdmi"
+- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy',
+ 'core'
+- reg-names: "wp", "pll", "phy", "core"
+- interrupts: the HDMI interrupt line
+- ti,hwmods: "dss_hdmi"
+- vdda-supply: vdda power supply
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for HDMI output
diff --git a/Documentation/devicetree/bindings/video/video-ports.txt b/Documentation/devicetree/bindings/video/video-ports.txt
new file mode 100644
index 000000000000..dad4c436caae
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/video-ports.txt
@@ -0,0 +1,22 @@
+Video Ports
+===========
+
+The video port bindings used for display devices is a superset of the v4l2 video
+ports described here:
+
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+The only difference is a more compact way to describe devices with only one
+endpoint. In cases like that, the 'ports' and 'port' nodes are not needed. For
+example, a DPI panel with a single input endpoint:
+
+lcd0: display@0 {
+ compatible = "samsung,lte430wq-f0c", "panel-dpi";
+
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+};
+
+The rest of the bindings are the same as in v4l2 video port bindings and not
+described here.
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 1/9] Doc/DT: Add OMAP DSS DT Bindings
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
Add device tree bindings for OMAP Display Subsystem for the following
SoCs: OMAP2, OMAP3, OMAP4.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../devicetree/bindings/video/ti,omap-dss.txt | 203 +++++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 ++++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 83 +++++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 111 +++++++++++
.../devicetree/bindings/video/video-ports.txt | 22 +++
5 files changed, 473 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/video-ports.txt
diff --git a/Documentation/devicetree/bindings/video/ti,omap-dss.txt b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
new file mode 100644
index 000000000000..a0f2e69b0e3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
@@ -0,0 +1,203 @@
+Texas Instruments OMAP Display Subsystem
+====================
+
+Generic Description
+-------------------
+
+This document is a generic description of the OMAP Display Subsystem bindings.
+Binding details for each OMAP SoC version are described in respective binding
+documentation.
+
+The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and
+a number of encoder modules. All DSS versions contain DSS Core and DISPC, but
+the encoder modules vary.
+
+The DSS Core is the parent of the other DSS modules, and manages clock routing,
+integration to the SoC, etc.
+
+DISPC is the display controller, which reads pixels from the memory and outputs
+a RGB pixel stream to encoders.
+
+The encoder modules encode the received RGB pixel stream to a video output like
+HDMI, MIPI DPI, etc.
+
+Video Ports
+-----------
+
+The DSS Core and the encoders have video port outputs. The structure of the
+video ports is described in Documentation/devicetree/bindings/video/video-
+ports.txt, and the properties for the ports and endpoints for each encoder are
+described in the SoC's DSS binding documentation.
+
+The video ports are used to describe the connections to external hardware, like
+panels or external encoders.
+
+Aliases
+-------
+
+The board dts file may define aliases for displays to assign "displayX" style
+name for each display. If no aliases are defined, a semi-random number is used
+for the display.
+
+Example
+-------
+
+A shortened example of the DSS description for OMAP4, with non-relevant parts
+removed, defined in omap4.dtsi:
+
+dss: dss@58000000 {
+ compatible = "ti,omap4-dss", "simple-bus";
+ reg = <0x58000000 0x80>;
+ status = "disabled";
+ ti,hwmods = "dss_core";
+ clocks = <&dss_dss_clk>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc@58001000 {
+ compatible = "ti,omap4-dispc";
+ reg = <0x58001000 0x1000>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ ti,hwmods = "dss_dispc";
+ clocks = <&dss_dss_clk>;
+ clock-names = "fck";
+ };
+
+ hdmi: encoder@58006000 {
+ compatible = "ti,omap4-hdmi";
+ reg = <0x58006000 0x200>,
+ <0x58006200 0x100>,
+ <0x58006300 0x100>,
+ <0x58006400 0x1000>;
+ reg-names = "wp", "pll", "phy", "core";
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ ti,hwmods = "dss_hdmi";
+ clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
+ clock-names = "fck", "sys_clk";
+ };
+};
+
+A shortened example of the board description for OMAP4 Panda board, defined in
+omap4-panda.dts.
+
+The Panda board has a DVI and a HDMI connector, and the board contains a TFP410
+chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level
+shifter). The video pipelines for the connectors are formed as follows:
+
+DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector
+OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI Connector
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ display1 = &hdmi0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; /* 0, power-down */
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tfp410_pins>;
+
+ 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>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = "dvi-connector";
+ label = "dvi";
+
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+
+ tpd12s015: encoder@1 {
+ compatible = "ti,tpd12s015";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tpd12s015_pins>;
+
+ 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>;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@1 {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_dpi_pins>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+};
+
+&hdmi {
+ status = "ok";
+ vdda-supply = <&vdac>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_hdmi_pins>;
+
+ hdmi_out: endpoint {
+ remote-endpoint = <&tpd12s015_in>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/video/ti,omap2-dss.txt b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
new file mode 100644
index 000000000000..fa8bb2ed1170
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
@@ -0,0 +1,54 @@
+Texas Instruments OMAP2 Display Subsystem
+====================+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap2-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+
+Optional nodes:
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap2-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap2-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap2-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+
+VENC Endpoint required properties:
+
+Required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
diff --git a/Documentation/devicetree/bindings/video/ti,omap3-dss.txt b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
new file mode 100644
index 000000000000..0023fa4b1328
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
@@ -0,0 +1,83 @@
+Texas Instruments OMAP3 Display Subsystem
+====================+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap3-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video ports:
+ - Port 0: DPI output
+ - Port 1: SDI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+SDI Endpoint required properties:
+- datapairs: number of datapairs used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap3-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap3-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap3-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap3-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
new file mode 100644
index 000000000000..f85d6fcfa705
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
@@ -0,0 +1,111 @@
+Texas Instruments OMAP4 Display Subsystem
+====================+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap4-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Required nodes:
+- DISPC
+
+Optional nodes:
+- DSS Submodules: RFBI, VENC, DSI, HDMI
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap4-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap4-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+Optional nodes:
+- Video port for RFBI output
+- RFBI controlled peripherals
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap4-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video port for VENC output
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap4-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1" or "dss_dsi2"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for DSI output
+- DSI controlled peripherals
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
+
+
+HDMI
+----
+
+Required properties:
+- compatible: "ti,omap4-hdmi"
+- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy',
+ 'core'
+- reg-names: "wp", "pll", "phy", "core"
+- interrupts: the HDMI interrupt line
+- ti,hwmods: "dss_hdmi"
+- vdda-supply: vdda power supply
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for HDMI output
diff --git a/Documentation/devicetree/bindings/video/video-ports.txt b/Documentation/devicetree/bindings/video/video-ports.txt
new file mode 100644
index 000000000000..dad4c436caae
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/video-ports.txt
@@ -0,0 +1,22 @@
+Video Ports
+=====+
+The video port bindings used for display devices is a superset of the v4l2 video
+ports described here:
+
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+The only difference is a more compact way to describe devices with only one
+endpoint. In cases like that, the 'ports' and 'port' nodes are not needed. For
+example, a DPI panel with a single input endpoint:
+
+lcd0: display@0 {
+ compatible = "samsung,lte430wq-f0c", "panel-dpi";
+
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+};
+
+The rest of the bindings are the same as in v4l2 video port bindings and not
+described here.
--
1.8.3.2
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 1/9] Doc/DT: Add OMAP DSS DT Bindings
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-arm-kernel
Add device tree bindings for OMAP Display Subsystem for the following
SoCs: OMAP2, OMAP3, OMAP4.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../devicetree/bindings/video/ti,omap-dss.txt | 203 +++++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 ++++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 83 +++++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 111 +++++++++++
.../devicetree/bindings/video/video-ports.txt | 22 +++
5 files changed, 473 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/video-ports.txt
diff --git a/Documentation/devicetree/bindings/video/ti,omap-dss.txt b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
new file mode 100644
index 000000000000..a0f2e69b0e3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
@@ -0,0 +1,203 @@
+Texas Instruments OMAP Display Subsystem
+========================================
+
+Generic Description
+-------------------
+
+This document is a generic description of the OMAP Display Subsystem bindings.
+Binding details for each OMAP SoC version are described in respective binding
+documentation.
+
+The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and
+a number of encoder modules. All DSS versions contain DSS Core and DISPC, but
+the encoder modules vary.
+
+The DSS Core is the parent of the other DSS modules, and manages clock routing,
+integration to the SoC, etc.
+
+DISPC is the display controller, which reads pixels from the memory and outputs
+a RGB pixel stream to encoders.
+
+The encoder modules encode the received RGB pixel stream to a video output like
+HDMI, MIPI DPI, etc.
+
+Video Ports
+-----------
+
+The DSS Core and the encoders have video port outputs. The structure of the
+video ports is described in Documentation/devicetree/bindings/video/video-
+ports.txt, and the properties for the ports and endpoints for each encoder are
+described in the SoC's DSS binding documentation.
+
+The video ports are used to describe the connections to external hardware, like
+panels or external encoders.
+
+Aliases
+-------
+
+The board dts file may define aliases for displays to assign "displayX" style
+name for each display. If no aliases are defined, a semi-random number is used
+for the display.
+
+Example
+-------
+
+A shortened example of the DSS description for OMAP4, with non-relevant parts
+removed, defined in omap4.dtsi:
+
+dss: dss at 58000000 {
+ compatible = "ti,omap4-dss", "simple-bus";
+ reg = <0x58000000 0x80>;
+ status = "disabled";
+ ti,hwmods = "dss_core";
+ clocks = <&dss_dss_clk>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc at 58001000 {
+ compatible = "ti,omap4-dispc";
+ reg = <0x58001000 0x1000>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ ti,hwmods = "dss_dispc";
+ clocks = <&dss_dss_clk>;
+ clock-names = "fck";
+ };
+
+ hdmi: encoder at 58006000 {
+ compatible = "ti,omap4-hdmi";
+ reg = <0x58006000 0x200>,
+ <0x58006200 0x100>,
+ <0x58006300 0x100>,
+ <0x58006400 0x1000>;
+ reg-names = "wp", "pll", "phy", "core";
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ ti,hwmods = "dss_hdmi";
+ clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
+ clock-names = "fck", "sys_clk";
+ };
+};
+
+A shortened example of the board description for OMAP4 Panda board, defined in
+omap4-panda.dts.
+
+The Panda board has a DVI and a HDMI connector, and the board contains a TFP410
+chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level
+shifter). The video pipelines for the connectors are formed as follows:
+
+DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector
+OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI Connector
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ display1 = &hdmi0;
+ };
+
+ tfp410: encoder at 0 {
+ compatible = "ti,tfp410";
+ gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; /* 0, power-down */
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tfp410_pins>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ tfp410_in: endpoint at 0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ tfp410_out: endpoint at 0 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector at 0 {
+ compatible = "dvi-connector";
+ label = "dvi";
+
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+
+ tpd12s015: encoder at 1 {
+ compatible = "ti,tpd12s015";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tpd12s015_pins>;
+
+ 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 at 0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint at 0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint at 0 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector at 1 {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_dpi_pins>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+};
+
+&hdmi {
+ status = "ok";
+ vdda-supply = <&vdac>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_hdmi_pins>;
+
+ hdmi_out: endpoint {
+ remote-endpoint = <&tpd12s015_in>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/video/ti,omap2-dss.txt b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
new file mode 100644
index 000000000000..fa8bb2ed1170
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
@@ -0,0 +1,54 @@
+Texas Instruments OMAP2 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap2-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+
+Optional nodes:
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap2-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap2-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap2-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+
+VENC Endpoint required properties:
+
+Required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
diff --git a/Documentation/devicetree/bindings/video/ti,omap3-dss.txt b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
new file mode 100644
index 000000000000..0023fa4b1328
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
@@ -0,0 +1,83 @@
+Texas Instruments OMAP3 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap3-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video ports:
+ - Port 0: DPI output
+ - Port 1: SDI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+SDI Endpoint required properties:
+- datapairs: number of datapairs used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap3-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap3-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap3-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap3-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
new file mode 100644
index 000000000000..f85d6fcfa705
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
@@ -0,0 +1,111 @@
+Texas Instruments OMAP4 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap4-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Required nodes:
+- DISPC
+
+Optional nodes:
+- DSS Submodules: RFBI, VENC, DSI, HDMI
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap4-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap4-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+Optional nodes:
+- Video port for RFBI output
+- RFBI controlled peripherals
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap4-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video port for VENC output
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap4-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1" or "dss_dsi2"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for DSI output
+- DSI controlled peripherals
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
+
+
+HDMI
+----
+
+Required properties:
+- compatible: "ti,omap4-hdmi"
+- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy',
+ 'core'
+- reg-names: "wp", "pll", "phy", "core"
+- interrupts: the HDMI interrupt line
+- ti,hwmods: "dss_hdmi"
+- vdda-supply: vdda power supply
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for HDMI output
diff --git a/Documentation/devicetree/bindings/video/video-ports.txt b/Documentation/devicetree/bindings/video/video-ports.txt
new file mode 100644
index 000000000000..dad4c436caae
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/video-ports.txt
@@ -0,0 +1,22 @@
+Video Ports
+===========
+
+The video port bindings used for display devices is a superset of the v4l2 video
+ports described here:
+
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+The only difference is a more compact way to describe devices with only one
+endpoint. In cases like that, the 'ports' and 'port' nodes are not needed. For
+example, a DPI panel with a single input endpoint:
+
+lcd0: display at 0 {
+ compatible = "samsung,lte430wq-f0c", "panel-dpi";
+
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+};
+
+The rest of the bindings are the same as in v4l2 video port bindings and not
+described here.
--
1.8.3.2
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 2/9] Doc/DT: Add DT binding documentation for Analog TV Connector
[not found] ` <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 12:20 ` Tomi Valkeinen
@ 2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
` (9 subsequent siblings)
11 siblings, 0 replies; 207+ messages in thread
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
Add DT binding documentation for Analog TV Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
---
.../bindings/video/analog-tv-connector.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
new file mode 100644
index 000000000000..d6be373d8705
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
@@ -0,0 +1,23 @@
+Analog TV Connector
+===================
+
+Required properties:
+- compatible: "composite-connector" or "svideo-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+
+Required nodes:
+- Video port for TV input
+
+Example
+-------
+
+tv: connector {
+ compatible = "composite-connector";
+ label = "tv";
+
+ tv_connector_in: endpoint {
+ remote-endpoint = <&venc_out>;
+ };
+};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 2/9] Doc/DT: Add DT binding documentation for Analog TV Connector
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
Add DT binding documentation for Analog TV Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../bindings/video/analog-tv-connector.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
new file mode 100644
index 000000000000..d6be373d8705
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
@@ -0,0 +1,23 @@
+Analog TV Connector
+=========+
+Required properties:
+- compatible: "composite-connector" or "svideo-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+
+Required nodes:
+- Video port for TV input
+
+Example
+-------
+
+tv: connector {
+ compatible = "composite-connector";
+ label = "tv";
+
+ tv_connector_in: endpoint {
+ remote-endpoint = <&venc_out>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 2/9] Doc/DT: Add DT binding documentation for Analog TV Connector
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-arm-kernel
Add DT binding documentation for Analog TV Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
---
.../bindings/video/analog-tv-connector.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
new file mode 100644
index 000000000000..d6be373d8705
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
@@ -0,0 +1,23 @@
+Analog TV Connector
+===================
+
+Required properties:
+- compatible: "composite-connector" or "svideo-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+
+Required nodes:
+- Video port for TV input
+
+Example
+-------
+
+tv: connector {
+ compatible = "composite-connector";
+ label = "tv";
+
+ tv_connector_in: endpoint {
+ remote-endpoint = <&venc_out>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
[not found] ` <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 12:20 ` Tomi Valkeinen
@ 2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
` (9 subsequent siblings)
11 siblings, 0 replies; 207+ messages in thread
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
Add DT binding documentation for DVI Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
---
.../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>;
+ };
+};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
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>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-arm-kernel
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 at 0 {
+ compatible = "dvi-connector";
+ label = "dvi";
+
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
[not found] ` <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 12:20 ` Tomi Valkeinen
@ 2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
` (9 subsequent siblings)
11 siblings, 0 replies; 207+ messages in thread
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
Add DT binding documentation for HDMI Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
---
.../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>;
+ };
+};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
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>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-arm-kernel
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 at 1 {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
[not found] ` <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 12:20 ` Tomi Valkeinen
@ 2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
` (9 subsequent siblings)
11 siblings, 0 replies; 207+ messages in thread
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
Add DT binding documentation for MIPI DPI Panel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
---
.../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
+
+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>;
+ };
+};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
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
+
+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>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-arm-kernel
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
+
+Example
+-------
+
+lcd0: display at 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>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
[not found] ` <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 12:20 ` Tomi Valkeinen
@ 2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
` (9 subsequent siblings)
11 siblings, 0 replies; 207+ messages in thread
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
Add DT binding documentation for MIPI DSI Command Mode Panel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
---
.../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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 207+ messages in thread
* [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
[not found] ` <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 12:20 ` Tomi Valkeinen
@ 2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
` (9 subsequent siblings)
11 siblings, 0 replies; 207+ messages in thread
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
Add DT binding documentation for Sony acx565akm panel
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Reviewed-by: Sebastian Reichel <sre-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
---
.../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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 [flat|nested] 207+ messages in thread
* [PATCH 8/9] Doc/DT: Add DT binding documentation for TFP410 encoder
[not found] ` <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 12:20 ` Tomi Valkeinen
@ 2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
` (9 subsequent siblings)
11 siblings, 0 replies; 207+ messages in thread
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
Add DT binding documentation for TFP410 encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
---
.../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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 8/9] Doc/DT: Add DT binding documentation for TFP410 encoder
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 8/9] Doc/DT: Add DT binding documentation for TFP410 encoder
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-arm-kernel
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 at 0 {
+ compatible = "ti,tfp410";
+ gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ tfp410_in: endpoint at 0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ tfp410_out: endpoint at 0 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
[not found] ` <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 12:20 ` Tomi Valkeinen
@ 2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
` (9 subsequent siblings)
11 siblings, 0 replies; 207+ messages in thread
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
Add DT binding documentation for tpd12s015 encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
---
.../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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 207+ messages in thread
* [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
@ 2014-02-28 12:20 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 12:20 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint at 0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint at 0 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
2014-02-28 12:20 ` Tomi Valkeinen
(?)
@ 2014-02-28 12:37 ` Tomasz Figa
-1 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 12:37 ` Tomasz Figa
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 12:37 ` Tomasz Figa
0 siblings, 0 replies; 207+ messages in thread
From: Tomasz Figa @ 2014-02-28 12:37 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
[not found] ` <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 12:20 ` Tomi Valkeinen
@ 2014-02-28 12:57 ` Sebastian Hesselbarth
2014-02-28 12:20 ` Tomi Valkeinen
` (9 subsequent siblings)
11 siblings, 0 replies; 207+ messages in thread
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
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 12:57 ` Sebastian Hesselbarth
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 12:57 ` Sebastian Hesselbarth
0 siblings, 0 replies; 207+ messages in thread
From: Sebastian Hesselbarth @ 2014-02-28 12:57 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
2014-02-28 12:57 ` Sebastian Hesselbarth
(?)
@ 2014-02-28 13:14 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
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
[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 13:14 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
[-- 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 [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 13:14 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 13:14 UTC (permalink / raw)
To: linux-arm-kernel
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140228/60e99aeb/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 8/9] Doc/DT: Add DT binding documentation for TFP410 encoder
2014-02-28 12:20 ` Tomi Valkeinen
(?)
@ 2014-02-28 13:37 ` Philipp Zabel
-1 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 8/9] Doc/DT: Add DT binding documentation for TFP410 encoder
@ 2014-02-28 13:37 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 8/9] Doc/DT: Add DT binding documentation for TFP410 encoder
@ 2014-02-28 13:37 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
From: Philipp Zabel @ 2014-02-28 13:37 UTC (permalink / raw)
To: linux-arm-kernel
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 at 0 {
> + compatible = "ti,tfp410";
> + gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> +
> + tfp410_in: endpoint at 0 {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> +
> + tfp410_out: endpoint at 0 {
> + remote-endpoint = <&dvi_connector_in>;
> + };
> + };
> + };
> +};
regards
Philipp
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
2014-02-28 12:20 ` Tomi Valkeinen
(?)
@ 2014-02-28 13:38 ` Philipp Zabel
-1 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
@ 2014-02-28 13:38 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
@ 2014-02-28 13:38 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
From: Philipp Zabel @ 2014-02-28 13:38 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 [flat|nested] 207+ messages in thread
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
2014-02-28 12:20 ` Tomi Valkeinen
(?)
@ 2014-02-28 13:40 ` Philipp Zabel
-1 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
@ 2014-02-28 13:40 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
@ 2014-02-28 13:40 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
From: Philipp Zabel @ 2014-02-28 13:40 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
2014-02-28 12:20 ` Tomi Valkeinen
(?)
@ 2014-02-28 13:43 ` Philipp Zabel
-1 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 13:43 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 13:43 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
From: Philipp Zabel @ 2014-02-28 13:43 UTC (permalink / raw)
To: linux-arm-kernel
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 at 0 {
> + compatible = "dvi-connector";
> + label = "dvi";
> +
> + i2c-bus = <&i2c3>;
> +
> + dvi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> +};
regards
Philipp
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
[not found] ` <1393594707.3802.31.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
2014-02-28 13:47 ` Tomi Valkeinen
@ 2014-02-28 13:47 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
[-- Attachment #1: Type: text/plain, Size: 1276 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-l0cyMroinI0@public.gmane.org>
>> Reviewed-by: Sebastian Reichel <sre-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
>> Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
>> ---
>> .../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 [flat|nested] 207+ messages in thread
* Re: [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
@ 2014-02-28 13:47 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
[-- 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 [flat|nested] 207+ messages in thread
* [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
@ 2014-02-28 13:47 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 13:47 UTC (permalink / raw)
To: linux-arm-kernel
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140228/0c9c7a15/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
2014-02-28 12:57 ` Sebastian Hesselbarth
(?)
@ 2014-02-28 13:47 ` Philipp Zabel
-1 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 13:47 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 13:47 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
From: Philipp Zabel @ 2014-02-28 13:47 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
[not found] ` <53108B9C.5000006-l0cyMroinI0@public.gmane.org>
2014-02-28 13:51 ` Sebastian Hesselbarth
@ 2014-02-28 13:51 ` Sebastian Hesselbarth
0 siblings, 0 replies; 207+ messages in thread
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
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 13:51 ` Sebastian Hesselbarth
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 13:51 ` Sebastian Hesselbarth
0 siblings, 0 replies; 207+ messages in thread
From: Sebastian Hesselbarth @ 2014-02-28 13:51 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
[not found] ` <1393595264.3802.39.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
2014-02-28 13:56 ` Sebastian Hesselbarth
@ 2014-02-28 13:56 ` Sebastian Hesselbarth
0 siblings, 0 replies; 207+ messages in thread
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
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 13:56 ` Sebastian Hesselbarth
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 13:56 ` Sebastian Hesselbarth
0 siblings, 0 replies; 207+ messages in thread
From: Sebastian Hesselbarth @ 2014-02-28 13:56 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
2014-02-28 13:51 ` Sebastian Hesselbarth
(?)
@ 2014-02-28 15:39 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
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
[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 15:39 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
[-- 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 [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 15:39 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 15:39 UTC (permalink / raw)
To: linux-arm-kernel
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140228/e3853902/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
[not found] ` <1393590016-9361-4-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 15:59 ` Russell King - ARM Linux
@ 2014-02-28 15:59 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
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
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-l0cyMroinI0@public.gmane.org>
> Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
> ---
> .../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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 15:59 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 15:59 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
From: Russell King - ARM Linux @ 2014-02-28 15:59 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 [flat|nested] 207+ messages in thread
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
2014-02-28 12:20 ` Tomi Valkeinen
(?)
@ 2014-02-28 16:06 ` Russell King - ARM Linux
-1 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-02-28 16:06 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-02-28 16:06 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
From: Russell King - ARM Linux @ 2014-02-28 16:06 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
2014-02-28 15:59 ` Russell King - ARM Linux
(?)
@ 2014-02-28 16:12 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
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
[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 16:12 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
[-- 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 [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 16:12 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 16:12 UTC (permalink / raw)
To: linux-arm-kernel
On 28/02/14 17:59, Russell King - ARM Linux wrote:
>> +dvi0: connector at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140228/e3be1e68/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
[not found] ` <1393590016-9361-10-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 16:13 ` Russell King - ARM Linux
@ 2014-02-28 16:13 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
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
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-l0cyMroinI0@public.gmane.org>
> Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
> ---
> .../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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
@ 2014-02-28 16:13 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
@ 2014-02-28 16:13 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
From: Russell King - ARM Linux @ 2014-02-28 16:13 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
2014-02-28 16:06 ` Russell King - ARM Linux
(?)
@ 2014-02-28 16:15 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
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
[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-02-28 16:15 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
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
[-- 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 [flat|nested] 207+ messages in thread
* [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-02-28 16:15 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 16:15 UTC (permalink / raw)
To: linux-arm-kernel
On 28/02/14 18:06, Russell King - ARM Linux wrote:
>> +hdmi0: connector at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140228/28e9e5c9/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
[not found] ` <5310B567.7040605-l0cyMroinI0@public.gmane.org>
2014-02-28 16:23 ` Russell King - ARM Linux
@ 2014-02-28 16:23 ` Russell King - ARM Linux
1 sibling, 0 replies; 207+ messages in thread
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
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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 16:23 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 16:23 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
From: Russell King - ARM Linux @ 2014-02-28 16:23 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
[not found] ` <5310B567.7040605-l0cyMroinI0@public.gmane.org>
2014-02-28 16:23 ` Russell King - ARM Linux
@ 2014-02-28 16:25 ` Sebastian Reichel
1 sibling, 0 replies; 207+ messages in thread
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
[-- 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 [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 16:25 ` Sebastian Reichel
0 siblings, 0 replies; 207+ messages in thread
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
[-- 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 [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 16:25 ` Sebastian Reichel
0 siblings, 0 replies; 207+ messages in thread
From: Sebastian Reichel @ 2014-02-28 16:25 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140228/91551572/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
[not found] ` <20140228155937.GQ21483-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-02-28 16:25 ` Philipp Zabel
@ 2014-02-28 16:25 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
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
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-l0cyMroinI0@public.gmane.org>
> > Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
> > ---
> > .../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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 16:25 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
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
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 [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 16:25 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
From: Philipp Zabel @ 2014-02-28 16:25 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 2 {
ipu_di0_disp0: endpoint {
remote-endpoint = <&sii902x_in>;
};
};
port at 3 {
ipu_di1_tve: endpoint {
remote-endpoint = <&tve_in>;
};
};
};
&sii902x {
compatible = "si,sii9022";
port at 0 {
sii902x_in: endpoint {
remote-endpoint = <&ipu_di0>;
};
};
port at 1 {
sii902x_out: endpoint {
remote-endpoint = <&dvi_d_in>;
};
};
};
&tve {
compatible = "fsl,imx53-tve";
port at 0 {
tve_in: endpoint {
remote-endpoint = <&ipu_di1>;
};
};
port at 1 {
tve_out: endpoint {
remote-endpoint = <&dvi_a_in>;
};
};
};
dvi-connector {
compatible = "dvi-connector";
ddc-i2c-bus = <&i2c3>;
port {
dvi_d_in: endpoint at 0 {
remote-endpoint = <&sii902x_out>;
};
dvi_a_in: endpoint at 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 [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
[not found] ` <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 12:20 ` Tomi Valkeinen
@ 2014-02-28 16:27 ` Russell King - ARM Linux
2014-02-28 12:20 ` Tomi Valkeinen
` (9 subsequent siblings)
11 siblings, 0 replies; 207+ messages in thread
From: Russell King - ARM Linux @ 2014-02-28 16:27 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
On Fri, Feb 28, 2014 at 02:20:07PM +0200, Tomi Valkeinen wrote:
> 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.
The big thing which concerns me is that we're using very generic
compatible strings here - has anyone done any searches to see whether
there are any existing standards for this kind of stuff already?
Even if none can be found, if we're going to create something like
this, it should probably become a public standard not just for Linux.
If we're not willing to do that, I'd suggest prefixing the compatible
strings with "linux," as a "company" identifier so that there's no
chance that we may hit some major problem caused by a conflicting
implementation in the future.
We could alternatively take the view that Linux will only ever be used
with Linux specific DT files, but I think that's a rather broken
approach given what DT is supposed to be.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 16:27 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
From: Russell King - ARM Linux @ 2014-02-28 16:27 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
On Fri, Feb 28, 2014 at 02:20:07PM +0200, Tomi Valkeinen wrote:
> 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.
The big thing which concerns me is that we're using very generic
compatible strings here - has anyone done any searches to see whether
there are any existing standards for this kind of stuff already?
Even if none can be found, if we're going to create something like
this, it should probably become a public standard not just for Linux.
If we're not willing to do that, I'd suggest prefixing the compatible
strings with "linux," as a "company" identifier so that there's no
chance that we may hit some major problem caused by a conflicting
implementation in the future.
We could alternatively take the view that Linux will only ever be used
with Linux specific DT files, but I think that's a rather broken
approach given what DT is supposed to be.
--
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 [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 16:27 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
From: Russell King - ARM Linux @ 2014-02-28 16:27 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 28, 2014 at 02:20:07PM +0200, Tomi Valkeinen wrote:
> 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.
The big thing which concerns me is that we're using very generic
compatible strings here - has anyone done any searches to see whether
there are any existing standards for this kind of stuff already?
Even if none can be found, if we're going to create something like
this, it should probably become a public standard not just for Linux.
If we're not willing to do that, I'd suggest prefixing the compatible
strings with "linux," as a "company" identifier so that there's no
chance that we may hit some major problem caused by a conflicting
implementation in the future.
We could alternatively take the view that Linux will only ever be used
with Linux specific DT files, but I think that's a rather broken
approach given what DT is supposed to be.
--
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
[not found] ` <20140228162327.GT21483-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-02-28 16:28 ` Warner Losh
@ 2014-02-28 16:28 ` Warner Losh
1 sibling, 0 replies; 207+ messages in thread
From: Warner Losh @ 2014-02-28 16:28 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Tomi Valkeinen, 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
On Feb 28, 2014, at 9:23 AM, Russell King - ARM Linux <linux-lFZ/pmaqli6BGKjqNUprAg@public.gmane.orgorg.uk> wrote:
> 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...)
And the “we” that uses the DT files is larger than just the Linux, and one of
those systems may use it.
Warner
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 16:28 ` Warner Losh
0 siblings, 0 replies; 207+ messages in thread
From: Warner Losh @ 2014-02-28 16:28 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Tomi Valkeinen, 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
On Feb 28, 2014, at 9:23 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 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...)
And the “we” that uses the DT files is larger than just the Linux, and one of
those systems may use it.
Warner
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-02-28 16:28 ` Warner Losh
0 siblings, 0 replies; 207+ messages in thread
From: Warner Losh @ 2014-02-28 16:28 UTC (permalink / raw)
To: linux-arm-kernel
On Feb 28, 2014, at 9:23 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 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 at 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...)
And the ?we? that uses the DT files is larger than just the Linux, and one of
those systems may use it.
Warner
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
2014-02-28 16:13 ` Russell King - ARM Linux
(?)
@ 2014-02-28 16:30 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 16:30 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
[-- Attachment #1.1: Type: text/plain, Size: 3329 bytes --]
On 28/02/14 18:13, Russell King - ARM Linux wrote:
> 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.
No, it's not supposed to give a clue. But if you have a TPD chip on your
board, and you use it and write a dts file, you need to know what those
GPIOs are and where they are connected. They're described in the TPD
spec and should be visible on your boards schematics.
I did stop a few times when writing the binding docs, trying to decide
when I should go to details and when not. I usually decided that if the
particular information is 100% if you have the component spec sheet, I'm
not describing it here.
I don't even know what "CT CP" is short for, and I don't remember the
spec telling it... It does tell how to use it, though.
> 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?
The normal way, leave it out. From
Documentation/devicetree/bindings/gpio/gpio.txt:
chipsel-gpios = <&gpio1 12 0>,
<&gpio1 13 0>,
<0>, /* holes are permitted, means no GPIO 2 */
<&gpio2 2>;
> 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?
The TPD is not an actual HDMI encoder, it's a level shifter, ESD
protection companion chip for the actual HDMI encoder.
But as for your question... I don't know. I don't know how much common
things there are. An HDMI encoder could have, say, two output ports. And
the encoder could have various number of input ports, so you can't say
either that the second port is always an output port.
If I had to make a guess right now, I'd guess that there are not enough
common things to justify defining common parts for all HDMI encoders.
But I have only dealt with the OMAP HDMI encoders, and a few one's from
Toshiba (DPI to HDMI and DSI to HDMI).
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
@ 2014-02-28 16:30 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 16:30 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
[-- Attachment #1: Type: text/plain, Size: 3329 bytes --]
On 28/02/14 18:13, Russell King - ARM Linux wrote:
> 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.
No, it's not supposed to give a clue. But if you have a TPD chip on your
board, and you use it and write a dts file, you need to know what those
GPIOs are and where they are connected. They're described in the TPD
spec and should be visible on your boards schematics.
I did stop a few times when writing the binding docs, trying to decide
when I should go to details and when not. I usually decided that if the
particular information is 100% if you have the component spec sheet, I'm
not describing it here.
I don't even know what "CT CP" is short for, and I don't remember the
spec telling it... It does tell how to use it, though.
> 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?
The normal way, leave it out. From
Documentation/devicetree/bindings/gpio/gpio.txt:
chipsel-gpios = <&gpio1 12 0>,
<&gpio1 13 0>,
<0>, /* holes are permitted, means no GPIO 2 */
<&gpio2 2>;
> 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?
The TPD is not an actual HDMI encoder, it's a level shifter, ESD
protection companion chip for the actual HDMI encoder.
But as for your question... I don't know. I don't know how much common
things there are. An HDMI encoder could have, say, two output ports. And
the encoder could have various number of input ports, so you can't say
either that the second port is always an output port.
If I had to make a guess right now, I'd guess that there are not enough
common things to justify defining common parts for all HDMI encoders.
But I have only dealt with the OMAP HDMI encoders, and a few one's from
Toshiba (DPI to HDMI and DSI to HDMI).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
@ 2014-02-28 16:30 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 16:30 UTC (permalink / raw)
To: linux-arm-kernel
On 28/02/14 18:13, Russell King - ARM Linux wrote:
> 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.
No, it's not supposed to give a clue. But if you have a TPD chip on your
board, and you use it and write a dts file, you need to know what those
GPIOs are and where they are connected. They're described in the TPD
spec and should be visible on your boards schematics.
I did stop a few times when writing the binding docs, trying to decide
when I should go to details and when not. I usually decided that if the
particular information is 100% if you have the component spec sheet, I'm
not describing it here.
I don't even know what "CT CP" is short for, and I don't remember the
spec telling it... It does tell how to use it, though.
> 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?
The normal way, leave it out. From
Documentation/devicetree/bindings/gpio/gpio.txt:
chipsel-gpios = <&gpio1 12 0>,
<&gpio1 13 0>,
<0>, /* holes are permitted, means no GPIO 2 */
<&gpio2 2>;
> 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?
The TPD is not an actual HDMI encoder, it's a level shifter, ESD
protection companion chip for the actual HDMI encoder.
But as for your question... I don't know. I don't know how much common
things there are. An HDMI encoder could have, say, two output ports. And
the encoder could have various number of input ports, so you can't say
either that the second port is always an output port.
If I had to make a guess right now, I'd guess that there are not enough
common things to justify defining common parts for all HDMI encoders.
But I have only dealt with the OMAP HDMI encoders, and a few one's from
Toshiba (DPI to HDMI and DSI to HDMI).
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140228/b1bedf67/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
2014-02-28 16:15 ` Tomi Valkeinen
@ 2014-02-28 16:34 ` Russell King - ARM Linux
-1 siblings, 0 replies; 207+ messages in thread
From: Russell King - ARM Linux @ 2014-02-28 16:34 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, dri-devel, Andrzej Hajda,
Laurent Pinchart, linux-arm-kernel, Sebastian Hesselbarth
On Fri, Feb 28, 2014 at 06:15:05PM +0200, Tomi Valkeinen wrote:
> 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.
HDMI A is 19 pins carrying TMDS channels 0-2. HDMI B is 29 pins
carrying TMDS channels 0-5. So, the difference is the same as the
single vs dual link on DVI-D/I connectors.
There's actually three HDMI connectors:
All three connectors carry all required HDMI signals, including a TMDS
link. The Type B connector is slightly larger and carries a second TMDS
link, which is necessary to support very high resolution displays using
dual link. The Type C connector carries the same signals as the Type A
but is more compact and intended for mobile applications.
So, Type C and Type A are electrically the same.
--
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 [flat|nested] 207+ messages in thread
* [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-02-28 16:34 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
From: Russell King - ARM Linux @ 2014-02-28 16:34 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 28, 2014 at 06:15:05PM +0200, Tomi Valkeinen wrote:
> On 28/02/14 18:06, Russell King - ARM Linux wrote:
>
> >> +hdmi0: connector at 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.
HDMI A is 19 pins carrying TMDS channels 0-2. HDMI B is 29 pins
carrying TMDS channels 0-5. So, the difference is the same as the
single vs dual link on DVI-D/I connectors.
There's actually three HDMI connectors:
All three connectors carry all required HDMI signals, including a TMDS
link. The Type B connector is slightly larger and carries a second TMDS
link, which is necessary to support very high resolution displays using
dual link. The Type C connector carries the same signals as the Type A
but is more compact and intended for mobile applications.
So, Type C and Type A are electrically the same.
--
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
2014-02-28 13:51 ` Sebastian Hesselbarth
@ 2014-02-28 16:48 ` Russell King - ARM Linux
-1 siblings, 0 replies; 207+ messages in thread
From: Russell King - ARM Linux @ 2014-02-28 16:48 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: devicetree, linux-fbdev, dri-devel, Andrzej Hajda,
Tomi Valkeinen, Laurent Pinchart, linux-arm-kernel
On Fri, Feb 28, 2014 at 02:51:22PM +0100, Sebastian Hesselbarth wrote:
> 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.
I think this is where differences in hardware become a problem.
Yes, it makes sense to handle the HPD at the encoder level, because
your HDMI encoder may require a HPD signal from the connector, and it
may handle this internally.
However, it's also true that the HPD signal from the HDMI connector may
be routed directly to a GPIO on the SoC.
Both are equally valid - and actually something which DRM as a subsystem
understands:
struct drm_connector_funcs {
enum drm_connector_status (*detect)(struct drm_connector *connector,
bool force);
};
struct drm_encoder_helper_funcs {
enum drm_connector_status (*detect)(struct drm_encoder *encoder,
struct drm_connector *connector);
};
although the original intention for the encoder detection method was for
DAC-style detection, such as found on Intel adapters (which regularly
pulse the R,G,B signals and measure any attached load.) We also use
the encoder detection method for TDA998x on Dove (currently via the
slave encoder stuff.)
So, I'd say that there's scope for a HDMI connector having a hotplug
GPIO attached to it - and if it isn't there (and there's no other form
of connector-based detection), the connector should refer to it's
attached encoder for connect status.
--
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 [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 16:48 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
From: Russell King - ARM Linux @ 2014-02-28 16:48 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 28, 2014 at 02:51:22PM +0100, Sebastian Hesselbarth wrote:
> 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.
I think this is where differences in hardware become a problem.
Yes, it makes sense to handle the HPD at the encoder level, because
your HDMI encoder may require a HPD signal from the connector, and it
may handle this internally.
However, it's also true that the HPD signal from the HDMI connector may
be routed directly to a GPIO on the SoC.
Both are equally valid - and actually something which DRM as a subsystem
understands:
struct drm_connector_funcs {
enum drm_connector_status (*detect)(struct drm_connector *connector,
bool force);
};
struct drm_encoder_helper_funcs {
enum drm_connector_status (*detect)(struct drm_encoder *encoder,
struct drm_connector *connector);
};
although the original intention for the encoder detection method was for
DAC-style detection, such as found on Intel adapters (which regularly
pulse the R,G,B signals and measure any attached load.) We also use
the encoder detection method for TDA998x on Dove (currently via the
slave encoder stuff.)
So, I'd say that there's scope for a HDMI connector having a hotplug
GPIO attached to it - and if it isn't there (and there's no other form
of connector-based detection), the connector should refer to it's
attached encoder for connect status.
--
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
[not found] ` <20140228162752.GU21483-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-02-28 16:48 ` Tomi Valkeinen
@ 2014-02-28 16:48 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 16:48 UTC (permalink / raw)
To: Russell King - ARM Linux
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
[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]
On 28/02/14 18:27, Russell King - ARM Linux wrote:
> On Fri, Feb 28, 2014 at 02:20:07PM +0200, Tomi Valkeinen wrote:
>> 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.
>
> The big thing which concerns me is that we're using very generic
> compatible strings here - has anyone done any searches to see whether
> there are any existing standards for this kind of stuff already?
I did look for any display related DT bindings when I started the work
on OMAP DSS DT bindings. I didn't really find any. If I recall right,
the only thing I found was an example of basically:
fb@1234567 {
compatible="asd";
reg=<1234567>;
};
So just a node for "framebuffer", with the register addresses. And maybe
video timings in some form.
Maybe I didn't know where to look.
> Even if none can be found, if we're going to create something like
> this, it should probably become a public standard not just for Linux.
This is totally unclear to me. How does it become a public standard?
What's the forum for this?
> If we're not willing to do that, I'd suggest prefixing the compatible
> strings with "linux," as a "company" identifier so that there's no
> chance that we may hit some major problem caused by a conflicting
> implementation in the future.
I don't have an issue with "linux," either. We could always later remove
the prefix (but keep drivers compatible with it). So it sounds quite a
safe approach to me, if we're not quite clear if these bindings are
acceptable, or how to get "public approval" for them.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 16:48 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 16:48 UTC (permalink / raw)
To: Russell King - ARM Linux
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
[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]
On 28/02/14 18:27, Russell King - ARM Linux wrote:
> On Fri, Feb 28, 2014 at 02:20:07PM +0200, Tomi Valkeinen wrote:
>> 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.
>
> The big thing which concerns me is that we're using very generic
> compatible strings here - has anyone done any searches to see whether
> there are any existing standards for this kind of stuff already?
I did look for any display related DT bindings when I started the work
on OMAP DSS DT bindings. I didn't really find any. If I recall right,
the only thing I found was an example of basically:
fb@1234567 {
compatible="asd";
reg=<1234567>;
};
So just a node for "framebuffer", with the register addresses. And maybe
video timings in some form.
Maybe I didn't know where to look.
> Even if none can be found, if we're going to create something like
> this, it should probably become a public standard not just for Linux.
This is totally unclear to me. How does it become a public standard?
What's the forum for this?
> If we're not willing to do that, I'd suggest prefixing the compatible
> strings with "linux," as a "company" identifier so that there's no
> chance that we may hit some major problem caused by a conflicting
> implementation in the future.
I don't have an issue with "linux," either. We could always later remove
the prefix (but keep drivers compatible with it). So it sounds quite a
safe approach to me, if we're not quite clear if these bindings are
acceptable, or how to get "public approval" for them.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 16:48 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-02-28 16:48 UTC (permalink / raw)
To: linux-arm-kernel
On 28/02/14 18:27, Russell King - ARM Linux wrote:
> On Fri, Feb 28, 2014 at 02:20:07PM +0200, Tomi Valkeinen wrote:
>> 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.
>
> The big thing which concerns me is that we're using very generic
> compatible strings here - has anyone done any searches to see whether
> there are any existing standards for this kind of stuff already?
I did look for any display related DT bindings when I started the work
on OMAP DSS DT bindings. I didn't really find any. If I recall right,
the only thing I found was an example of basically:
fb at 1234567 {
compatible="asd";
reg=<1234567>;
};
So just a node for "framebuffer", with the register addresses. And maybe
video timings in some form.
Maybe I didn't know where to look.
> Even if none can be found, if we're going to create something like
> this, it should probably become a public standard not just for Linux.
This is totally unclear to me. How does it become a public standard?
What's the forum for this?
> If we're not willing to do that, I'd suggest prefixing the compatible
> strings with "linux," as a "company" identifier so that there's no
> chance that we may hit some major problem caused by a conflicting
> implementation in the future.
I don't have an issue with "linux," either. We could always later remove
the prefix (but keep drivers compatible with it). So it sounds quite a
safe approach to me, if we're not quite clear if these bindings are
acceptable, or how to get "public approval" for them.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140228/4738c8ed/attachment-0001.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
2014-02-28 16:48 ` Tomi Valkeinen
@ 2014-02-28 16:56 ` Russell King - ARM Linux
-1 siblings, 0 replies; 207+ messages in thread
From: Russell King - ARM Linux @ 2014-02-28 16:56 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, dri-devel, Andrzej Hajda,
Laurent Pinchart, linux-arm-kernel, Sebastian Hesselbarth
On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
> This is totally unclear to me. How does it become a public standard?
> What's the forum for this?
Me too. That's where I'd hope someone on devicetree-discuss will be
able to help us work out what's the right approach here. :)
--
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 [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-02-28 16:56 ` Russell King - ARM Linux
0 siblings, 0 replies; 207+ messages in thread
From: Russell King - ARM Linux @ 2014-02-28 16:56 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
> This is totally unclear to me. How does it become a public standard?
> What's the forum for this?
Me too. That's where I'd hope someone on devicetree-discuss will be
able to help us work out what's the right approach here. :)
--
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 [flat|nested] 207+ messages in thread
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
2014-02-28 16:34 ` Russell King - ARM Linux
(?)
@ 2014-03-01 18:58 ` Geert Uytterhoeven
-1 siblings, 0 replies; 207+ messages in thread
From: Geert Uytterhoeven @ 2014-03-01 18:58 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree, Linux Fbdev development list, DRI Development,
Andrzej Hajda, Tomi Valkeinen, Laurent Pinchart,
linux-arm-kernel, Sebastian Hesselbarth
On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> There's actually three HDMI connectors:
>
> All three connectors carry all required HDMI signals, including a TMDS
> link. The Type B connector is slightly larger and carries a second TMDS
> link, which is necessary to support very high resolution displays using
> dual link. The Type C connector carries the same signals as the Type A
> but is more compact and intended for mobile applications.
>
> So, Type C and Type A are electrically the same.
There's also D (e.g. on BeagleBone Black) and E:
http://en.wikipedia.org/wiki/HDMI#Connectors
Electrically they seem to be the same as A/C.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-03-01 18:58 ` Geert Uytterhoeven
0 siblings, 0 replies; 207+ messages in thread
From: Geert Uytterhoeven @ 2014-03-01 18:58 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree, Linux Fbdev development list, DRI Development,
Andrzej Hajda, Tomi Valkeinen, Laurent Pinchart,
linux-arm-kernel, Sebastian Hesselbarth
On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> There's actually three HDMI connectors:
>
> All three connectors carry all required HDMI signals, including a TMDS
> link. The Type B connector is slightly larger and carries a second TMDS
> link, which is necessary to support very high resolution displays using
> dual link. The Type C connector carries the same signals as the Type A
> but is more compact and intended for mobile applications.
>
> So, Type C and Type A are electrically the same.
There's also D (e.g. on BeagleBone Black) and E:
http://en.wikipedia.org/wiki/HDMI#Connectors
Electrically they seem to be the same as A/C.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-03-01 18:58 ` Geert Uytterhoeven
0 siblings, 0 replies; 207+ messages in thread
From: Geert Uytterhoeven @ 2014-03-01 18:58 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> There's actually three HDMI connectors:
>
> All three connectors carry all required HDMI signals, including a TMDS
> link. The Type B connector is slightly larger and carries a second TMDS
> link, which is necessary to support very high resolution displays using
> dual link. The Type C connector carries the same signals as the Type A
> but is more compact and intended for mobile applications.
>
> So, Type C and Type A are electrically the same.
There's also D (e.g. on BeagleBone Black) and E:
http://en.wikipedia.org/wiki/HDMI#Connectors
Electrically they seem to be the same as A/C.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
2014-02-28 13:40 ` Philipp Zabel
(?)
@ 2014-03-03 6:05 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 6:05 UTC (permalink / raw)
To: Philipp Zabel
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 1438 bytes --]
On 28/02/14 15:40, Philipp Zabel wrote:
> 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?
Hmm, well, the simple-panel bindings doesn't define video ports, and not
even a common compatible property.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
@ 2014-03-03 6:05 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 6:05 UTC (permalink / raw)
To: Philipp Zabel
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]
On 28/02/14 15:40, Philipp Zabel wrote:
> 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?
Hmm, well, the simple-panel bindings doesn't define video ports, and not
even a common compatible property.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
@ 2014-03-03 6:05 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 6:05 UTC (permalink / raw)
To: linux-arm-kernel
On 28/02/14 15:40, Philipp Zabel wrote:
> 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?
Hmm, well, the simple-panel bindings doesn't define video ports, and not
even a common compatible property.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140303/b3d21203/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
2014-02-28 13:43 ` Philipp Zabel
(?)
@ 2014-03-03 6:25 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 6:25 UTC (permalink / raw)
To: Philipp Zabel
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 1294 bytes --]
On 28/02/14 15:43, Philipp Zabel wrote:
> 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.
I like 'ddc-i2c-bus'.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-03 6:25 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 6:25 UTC (permalink / raw)
To: Philipp Zabel
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]
On 28/02/14 15:43, Philipp Zabel wrote:
> 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.
I like 'ddc-i2c-bus'.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-03 6:25 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 6:25 UTC (permalink / raw)
To: linux-arm-kernel
On 28/02/14 15:43, Philipp Zabel wrote:
> 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.
I like 'ddc-i2c-bus'.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140303/3f2b2a36/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
2014-02-28 16:23 ` Russell King - ARM Linux
(?)
@ 2014-03-03 6:42 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 6:42 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
[-- Attachment #1.1: Type: text/plain, Size: 1613 bytes --]
On 28/02/14 18:23, Russell King - ARM Linux wrote:
>> 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
Yes, it's messy. Pondering this over the weekend, I think it makes sense
to have just one compatible string, as all those connectors are still
the same DVI connector, just different variations of the same.
> 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.
Another option would be:
num-links = 2;
But I like your suggestion more. We could also optimize it, "digital" is
extra as both "single-link" and "dual-link" mean also digital. But... I
don't see much point in optimizing that way. So I agree with your
suggestion as is.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-03 6:42 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 6:42 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
[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]
On 28/02/14 18:23, Russell King - ARM Linux wrote:
>> 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
Yes, it's messy. Pondering this over the weekend, I think it makes sense
to have just one compatible string, as all those connectors are still
the same DVI connector, just different variations of the same.
> 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.
Another option would be:
num-links = 2;
But I like your suggestion more. We could also optimize it, "digital" is
extra as both "single-link" and "dual-link" mean also digital. But... I
don't see much point in optimizing that way. So I agree with your
suggestion as is.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-03 6:42 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 6:42 UTC (permalink / raw)
To: linux-arm-kernel
On 28/02/14 18:23, Russell King - ARM Linux wrote:
>> 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
Yes, it's messy. Pondering this over the weekend, I think it makes sense
to have just one compatible string, as all those connectors are still
the same DVI connector, just different variations of the same.
> 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.
Another option would be:
num-links = 2;
But I like your suggestion more. We could also optimize it, "digital" is
extra as both "single-link" and "dual-link" mean also digital. But... I
don't see much point in optimizing that way. So I agree with your
suggestion as is.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140303/8ac18169/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
2014-03-01 18:58 ` Geert Uytterhoeven
(?)
@ 2014-03-03 7:23 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 7:23 UTC (permalink / raw)
To: Geert Uytterhoeven, Russell King - ARM Linux
Cc: devicetree, Linux Fbdev development list, Sascha Hauer,
Tomasz Figa, DRI Development, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, Philipp Zabel,
linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 1181 bytes --]
On 01/03/14 20:58, Geert Uytterhoeven wrote:
> On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> There's actually three HDMI connectors:
>>
>> All three connectors carry all required HDMI signals, including a TMDS
>> link. The Type B connector is slightly larger and carries a second TMDS
>> link, which is necessary to support very high resolution displays using
>> dual link. The Type C connector carries the same signals as the Type A
>> but is more compact and intended for mobile applications.
>>
>> So, Type C and Type A are electrically the same.
>
> There's also D (e.g. on BeagleBone Black) and E:
>
> http://en.wikipedia.org/wiki/HDMI#Connectors
>
> Electrically they seem to be the same as A/C.
Right. And then there are the HDMI versions, and things like HDMI
Ethernet Channel. After looking at these a bit, I don't think the HDMI
connector needs any of those (hdmi version, eth) defined.
So...
compatible = "hdmi-connector";
type = "a";
Or
compatible = "hdmi-connector";
type-a;
I don't right away see any big pro with either one compared to the other.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-03-03 7:23 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 7:23 UTC (permalink / raw)
To: Geert Uytterhoeven, Russell King - ARM Linux
Cc: devicetree, Linux Fbdev development list, Sascha Hauer,
Tomasz Figa, DRI Development, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, Philipp Zabel,
linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]
On 01/03/14 20:58, Geert Uytterhoeven wrote:
> On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> There's actually three HDMI connectors:
>>
>> All three connectors carry all required HDMI signals, including a TMDS
>> link. The Type B connector is slightly larger and carries a second TMDS
>> link, which is necessary to support very high resolution displays using
>> dual link. The Type C connector carries the same signals as the Type A
>> but is more compact and intended for mobile applications.
>>
>> So, Type C and Type A are electrically the same.
>
> There's also D (e.g. on BeagleBone Black) and E:
>
> http://en.wikipedia.org/wiki/HDMI#Connectors
>
> Electrically they seem to be the same as A/C.
Right. And then there are the HDMI versions, and things like HDMI
Ethernet Channel. After looking at these a bit, I don't think the HDMI
connector needs any of those (hdmi version, eth) defined.
So...
compatible = "hdmi-connector";
type = "a";
Or
compatible = "hdmi-connector";
type-a;
I don't right away see any big pro with either one compared to the other.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-03-03 7:23 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 7:23 UTC (permalink / raw)
To: linux-arm-kernel
On 01/03/14 20:58, Geert Uytterhoeven wrote:
> On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> There's actually three HDMI connectors:
>>
>> All three connectors carry all required HDMI signals, including a TMDS
>> link. The Type B connector is slightly larger and carries a second TMDS
>> link, which is necessary to support very high resolution displays using
>> dual link. The Type C connector carries the same signals as the Type A
>> but is more compact and intended for mobile applications.
>>
>> So, Type C and Type A are electrically the same.
>
> There's also D (e.g. on BeagleBone Black) and E:
>
> http://en.wikipedia.org/wiki/HDMI#Connectors
>
> Electrically they seem to be the same as A/C.
Right. And then there are the HDMI versions, and things like HDMI
Ethernet Channel. After looking at these a bit, I don't think the HDMI
connector needs any of those (hdmi version, eth) defined.
So...
compatible = "hdmi-connector";
type = "a";
Or
compatible = "hdmi-connector";
type-a;
I don't right away see any big pro with either one compared to the other.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140303/9622c09d/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
2014-02-28 16:56 ` Russell King - ARM Linux
(?)
@ 2014-03-03 8:04 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 8:04 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, Philipp Zabel,
linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 1460 bytes --]
Hi Rob, Pawel, Mark, Ian, Kumar,
On 28/02/14 18:56, Russell King - ARM Linux wrote:
> On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
>> This is totally unclear to me. How does it become a public standard?
>> What's the forum for this?
>
> Me too. That's where I'd hope someone on devicetree-discuss will be
> able to help us work out what's the right approach here. :)
The story briefly so far: I've implemented DT support for OMAP display,
and created bindings for various (non-OMAP) display components,
including generic connector bindings for DVI, HDMI and analog-tv.
Russell's point was that these connector bindings are very generic, i.e.
they are not for any particular chip from a particular vendor, but for
any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
shouldn't define such generic bindings without consulting the whole
device-tree community (i.e including non-linux users).
So the question is, is there such a community and a forum to bring up
this kind of things? If yes, should we bring this up there? If yes, what
kind of things in general should be brought into the attention of
non-linux users?
What I wonder here is that while a thing like DVI connector is, of
course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
case still the same: we're defining global bindings for hardware that
should work for everyone, not only Linux users?
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-03 8:04 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 8:04 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, Philipp Zabel,
linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
Hi Rob, Pawel, Mark, Ian, Kumar,
On 28/02/14 18:56, Russell King - ARM Linux wrote:
> On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
>> This is totally unclear to me. How does it become a public standard?
>> What's the forum for this?
>
> Me too. That's where I'd hope someone on devicetree-discuss will be
> able to help us work out what's the right approach here. :)
The story briefly so far: I've implemented DT support for OMAP display,
and created bindings for various (non-OMAP) display components,
including generic connector bindings for DVI, HDMI and analog-tv.
Russell's point was that these connector bindings are very generic, i.e.
they are not for any particular chip from a particular vendor, but for
any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
shouldn't define such generic bindings without consulting the whole
device-tree community (i.e including non-linux users).
So the question is, is there such a community and a forum to bring up
this kind of things? If yes, should we bring this up there? If yes, what
kind of things in general should be brought into the attention of
non-linux users?
What I wonder here is that while a thing like DVI connector is, of
course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
case still the same: we're defining global bindings for hardware that
should work for everyone, not only Linux users?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-03 8:04 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-03 8:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rob, Pawel, Mark, Ian, Kumar,
On 28/02/14 18:56, Russell King - ARM Linux wrote:
> On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
>> This is totally unclear to me. How does it become a public standard?
>> What's the forum for this?
>
> Me too. That's where I'd hope someone on devicetree-discuss will be
> able to help us work out what's the right approach here. :)
The story briefly so far: I've implemented DT support for OMAP display,
and created bindings for various (non-OMAP) display components,
including generic connector bindings for DVI, HDMI and analog-tv.
Russell's point was that these connector bindings are very generic, i.e.
they are not for any particular chip from a particular vendor, but for
any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
shouldn't define such generic bindings without consulting the whole
device-tree community (i.e including non-linux users).
So the question is, is there such a community and a forum to bring up
this kind of things? If yes, should we bring this up there? If yes, what
kind of things in general should be brought into the attention of
non-linux users?
What I wonder here is that while a thing like DVI connector is, of
course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
case still the same: we're defining global bindings for hardware that
should work for everyone, not only Linux users?
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140303/e40abbd0/attachment-0001.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
2014-02-28 16:23 ` Russell King - ARM Linux
(?)
@ 2014-03-04 12:54 ` Daniel Vetter
-1 siblings, 0 replies; 207+ messages in thread
From: Daniel Vetter @ 2014-03-04 12:54 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree, linux-fbdev, dri-devel, Andrzej Hajda,
Tomi Valkeinen, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
On Fri, Feb 28, 2014 at 04:23:27PM +0000, Russell King - ARM Linux wrote:
> 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...)
If you plug a dual-link dvi screen into a soc which can do dual-link but
the actual connector is cheap and doesn't have this wired up
(differentiate wtf) then the kernel needs to know. Otherwise it can't
correctly filter out the modes with dotclocks high enough to require dual
link and the user will look at a black screen.
3.14 has a regression in drm/i915 where we've screwed this up ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-04 12:54 ` Daniel Vetter
0 siblings, 0 replies; 207+ messages in thread
From: Daniel Vetter @ 2014-03-04 12:54 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree, linux-fbdev, dri-devel, Andrzej Hajda,
Tomi Valkeinen, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
On Fri, Feb 28, 2014 at 04:23:27PM +0000, Russell King - ARM Linux wrote:
> 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...)
If you plug a dual-link dvi screen into a soc which can do dual-link but
the actual connector is cheap and doesn't have this wired up
(differentiate wtf) then the kernel needs to know. Otherwise it can't
correctly filter out the modes with dotclocks high enough to require dual
link and the user will look at a black screen.
3.14 has a regression in drm/i915 where we've screwed this up ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-04 12:54 ` Daniel Vetter
0 siblings, 0 replies; 207+ messages in thread
From: Daniel Vetter @ 2014-03-04 12:54 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 28, 2014 at 04:23:27PM +0000, Russell King - ARM Linux wrote:
> 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 at 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...)
If you plug a dual-link dvi screen into a soc which can do dual-link but
the actual connector is cheap and doesn't have this wired up
(differentiate wtf) then the kernel needs to know. Otherwise it can't
correctly filter out the modes with dotclocks high enough to require dual
link and the user will look at a black screen.
3.14 has a regression in drm/i915 where we've screwed this up ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
2014-02-28 16:06 ` Russell King - ARM Linux
(?)
@ 2014-03-04 12:59 ` Daniel Vetter
-1 siblings, 0 replies; 207+ messages in thread
From: Daniel Vetter @ 2014-03-04 12:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree, linux-fbdev, dri-devel, Andrzej Hajda,
Tomi Valkeinen, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
On Fri, Feb 28, 2014 at 04:06:12PM +0000, Russell King - ARM Linux wrote:
> 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.
Yeah, there's a dual-link hdmi standard somewhere. I've never seen it in
the wild anywhere though, and newer hdmi all just increase the max link
clock to push higher res modes over the wire. Imo can't hurt to just
enumerate all type of physical connectors standardized.
HDMI revisions themselves are only relevant for the sink (as advertised
capabilities in the EDID) and for your hdmi encoder chip (where pretty
much just the max dotclock is interesting really). So I don't think we
need a hdmi revision in dt for the physical connector.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-03-04 12:59 ` Daniel Vetter
0 siblings, 0 replies; 207+ messages in thread
From: Daniel Vetter @ 2014-03-04 12:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree, linux-fbdev, dri-devel, Andrzej Hajda,
Tomi Valkeinen, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
On Fri, Feb 28, 2014 at 04:06:12PM +0000, Russell King - ARM Linux wrote:
> 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.
Yeah, there's a dual-link hdmi standard somewhere. I've never seen it in
the wild anywhere though, and newer hdmi all just increase the max link
clock to push higher res modes over the wire. Imo can't hurt to just
enumerate all type of physical connectors standardized.
HDMI revisions themselves are only relevant for the sink (as advertised
capabilities in the EDID) and for your hdmi encoder chip (where pretty
much just the max dotclock is interesting really). So I don't think we
need a hdmi revision in dt for the physical connector.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-03-04 12:59 ` Daniel Vetter
0 siblings, 0 replies; 207+ messages in thread
From: Daniel Vetter @ 2014-03-04 12:59 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 28, 2014 at 04:06:12PM +0000, Russell King - ARM Linux wrote:
> 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 at 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.
Yeah, there's a dual-link hdmi standard somewhere. I've never seen it in
the wild anywhere though, and newer hdmi all just increase the max link
clock to push higher res modes over the wire. Imo can't hurt to just
enumerate all type of physical connectors standardized.
HDMI revisions themselves are only relevant for the sink (as advertised
capabilities in the EDID) and for your hdmi encoder chip (where pretty
much just the max dotclock is interesting really). So I don't think we
need a hdmi revision in dt for the physical connector.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
[not found] ` <20140228162327.GT21483-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-02-28 16:28 ` Warner Losh
@ 2014-03-05 8:41 ` Tomi Valkeinen
1 sibling, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-05 8:41 UTC (permalink / raw)
To: Russell King - ARM Linux
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,
Daniel Vetter
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
On 28/02/14 18:23, Russell King - ARM Linux wrote:
> That's rather a lot of compatible strings. Another possibility is:
>
> compatible = "dvi-connector";
> analog;
> digital;
> single-link;
> dual-link;
I made the following changes compared to the posted version. I decided
to leave the "single-link" out, as it's implied if "digital" is set.
Tomi
@@ -6,11 +6,16 @@ Required properties:
Optional properties:
- label: a symbolic name for the connector
-- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
+- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
+- analog: the connector has DVI analog pins
+- digital: the connector has DVI digital pins
+- dual-link: the connector has pins for DVI dual-link
Required nodes:
- Video port for DVI input
+Note: One (or both) of 'analog' or 'digital' must be set.
+
Example
-------
@@ -18,7 +23,9 @@ dvi0: connector@0 {
compatible = "dvi-connector";
label = "dvi";
- i2c-bus = <&i2c3>;
+ digital;
+
+ ddc-i2c-bus = <&i2c3>;
dvi_connector_in: endpoint {
remote-endpoint = <&tfp410_out>;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-05 8:41 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-05 8:41 UTC (permalink / raw)
To: Russell King - ARM Linux
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,
Daniel Vetter
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
On 28/02/14 18:23, Russell King - ARM Linux wrote:
> That's rather a lot of compatible strings. Another possibility is:
>
> compatible = "dvi-connector";
> analog;
> digital;
> single-link;
> dual-link;
I made the following changes compared to the posted version. I decided
to leave the "single-link" out, as it's implied if "digital" is set.
Tomi
@@ -6,11 +6,16 @@ Required properties:
Optional properties:
- label: a symbolic name for the connector
-- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
+- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
+- analog: the connector has DVI analog pins
+- digital: the connector has DVI digital pins
+- dual-link: the connector has pins for DVI dual-link
Required nodes:
- Video port for DVI input
+Note: One (or both) of 'analog' or 'digital' must be set.
+
Example
-------
@@ -18,7 +23,9 @@ dvi0: connector@0 {
compatible = "dvi-connector";
label = "dvi";
- i2c-bus = <&i2c3>;
+ digital;
+
+ ddc-i2c-bus = <&i2c3>;
dvi_connector_in: endpoint {
remote-endpoint = <&tfp410_out>;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-05 8:41 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-05 8:41 UTC (permalink / raw)
To: linux-arm-kernel
On 28/02/14 18:23, Russell King - ARM Linux wrote:
> That's rather a lot of compatible strings. Another possibility is:
>
> compatible = "dvi-connector";
> analog;
> digital;
> single-link;
> dual-link;
I made the following changes compared to the posted version. I decided
to leave the "single-link" out, as it's implied if "digital" is set.
Tomi
@@ -6,11 +6,16 @@ Required properties:
Optional properties:
- label: a symbolic name for the connector
-- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
+- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
+- analog: the connector has DVI analog pins
+- digital: the connector has DVI digital pins
+- dual-link: the connector has pins for DVI dual-link
Required nodes:
- Video port for DVI input
+Note: One (or both) of 'analog' or 'digital' must be set.
+
Example
-------
@@ -18,7 +23,9 @@ dvi0: connector at 0 {
compatible = "dvi-connector";
label = "dvi";
- i2c-bus = <&i2c3>;
+ digital;
+
+ ddc-i2c-bus = <&i2c3>;
dvi_connector_in: endpoint {
remote-endpoint = <&tfp410_out>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140305/4868fdb2/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
2014-03-01 18:58 ` Geert Uytterhoeven
(?)
@ 2014-03-05 8:42 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-05 8:42 UTC (permalink / raw)
To: Geert Uytterhoeven, Russell King - ARM Linux
Cc: devicetree, Linux Fbdev development list, Daniel Vetter,
Sascha Hauer, Tomasz Figa, DRI Development, Inki Dae,
Andrzej Hajda, Rob Clark, Thierry Reding, Laurent Pinchart,
Philipp Zabel, linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 1316 bytes --]
On 01/03/14 20:58, Geert Uytterhoeven wrote:
> On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> There's actually three HDMI connectors:
>>
>> All three connectors carry all required HDMI signals, including a TMDS
>> link. The Type B connector is slightly larger and carries a second TMDS
>> link, which is necessary to support very high resolution displays using
>> dual link. The Type C connector carries the same signals as the Type A
>> but is more compact and intended for mobile applications.
>>
>> So, Type C and Type A are electrically the same.
>
> There's also D (e.g. on BeagleBone Black) and E:
>
> http://en.wikipedia.org/wiki/HDMI#Connectors
>
> Electrically they seem to be the same as A/C.
I made the following change compared to the posted version.
Tomi
@@ -3,6 +3,7 @@ HDMI Connector
Required properties:
- compatible: "hdmi-connector"
+- type: the HDMI connector type: "a", "b", "c", "d" or "e"
Optional properties:
- label: a symbolic name for the connector
@@ -17,6 +18,8 @@ hdmi0: connector@1 {
compatible = "hdmi-connector";
label = "hdmi";
+ type = "a";
+
hdmi_connector_in: endpoint {
remote-endpoint = <&tpd12s015_out>;
};
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-03-05 8:42 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-05 8:42 UTC (permalink / raw)
To: Geert Uytterhoeven, Russell King - ARM Linux
Cc: devicetree, Linux Fbdev development list, Daniel Vetter,
Sascha Hauer, Tomasz Figa, DRI Development, Inki Dae,
Andrzej Hajda, Rob Clark, Thierry Reding, Laurent Pinchart,
Philipp Zabel, linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]
On 01/03/14 20:58, Geert Uytterhoeven wrote:
> On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> There's actually three HDMI connectors:
>>
>> All three connectors carry all required HDMI signals, including a TMDS
>> link. The Type B connector is slightly larger and carries a second TMDS
>> link, which is necessary to support very high resolution displays using
>> dual link. The Type C connector carries the same signals as the Type A
>> but is more compact and intended for mobile applications.
>>
>> So, Type C and Type A are electrically the same.
>
> There's also D (e.g. on BeagleBone Black) and E:
>
> http://en.wikipedia.org/wiki/HDMI#Connectors
>
> Electrically they seem to be the same as A/C.
I made the following change compared to the posted version.
Tomi
@@ -3,6 +3,7 @@ HDMI Connector
Required properties:
- compatible: "hdmi-connector"
+- type: the HDMI connector type: "a", "b", "c", "d" or "e"
Optional properties:
- label: a symbolic name for the connector
@@ -17,6 +18,8 @@ hdmi0: connector@1 {
compatible = "hdmi-connector";
label = "hdmi";
+ type = "a";
+
hdmi_connector_in: endpoint {
remote-endpoint = <&tpd12s015_out>;
};
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
@ 2014-03-05 8:42 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-05 8:42 UTC (permalink / raw)
To: linux-arm-kernel
On 01/03/14 20:58, Geert Uytterhoeven wrote:
> On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> There's actually three HDMI connectors:
>>
>> All three connectors carry all required HDMI signals, including a TMDS
>> link. The Type B connector is slightly larger and carries a second TMDS
>> link, which is necessary to support very high resolution displays using
>> dual link. The Type C connector carries the same signals as the Type A
>> but is more compact and intended for mobile applications.
>>
>> So, Type C and Type A are electrically the same.
>
> There's also D (e.g. on BeagleBone Black) and E:
>
> http://en.wikipedia.org/wiki/HDMI#Connectors
>
> Electrically they seem to be the same as A/C.
I made the following change compared to the posted version.
Tomi
@@ -3,6 +3,7 @@ HDMI Connector
Required properties:
- compatible: "hdmi-connector"
+- type: the HDMI connector type: "a", "b", "c", "d" or "e"
Optional properties:
- label: a symbolic name for the connector
@@ -17,6 +18,8 @@ hdmi0: connector at 1 {
compatible = "hdmi-connector";
label = "hdmi";
+ type = "a";
+
hdmi_connector_in: endpoint {
remote-endpoint = <&tpd12s015_out>;
};
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140305/ce46cb06/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
2014-03-05 8:41 ` Tomi Valkeinen
(?)
@ 2014-03-06 8:39 ` Geert Uytterhoeven
-1 siblings, 0 replies; 207+ messages in thread
From: Geert Uytterhoeven @ 2014-03-06 8:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, Linux Fbdev development list,
Russell King - ARM Linux, DRI Development, Andrzej Hajda,
Laurent Pinchart, linux-arm-kernel, Sebastian Hesselbarth
On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 28/02/14 18:23, Russell King - ARM Linux wrote:
>
>> That's rather a lot of compatible strings. Another possibility is:
>>
>> compatible = "dvi-connector";
>> analog;
>> digital;
>> single-link;
>> dual-link;
>
> I made the following changes compared to the posted version. I decided
> to leave the "single-link" out, as it's implied if "digital" is set.
>
> Tomi
>
> @@ -6,11 +6,16 @@ Required properties:
>
> Optional properties:
> - label: a symbolic name for the connector
> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> +- analog: the connector has DVI analog pins
> +- digital: the connector has DVI digital pins
> +- dual-link: the connector has pins for DVI dual-link
>
> Required nodes:
> - Video port for DVI input
>
> +Note: One (or both) of 'analog' or 'digital' must be set.
So dual-link needs both "digital" and "dual-link"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-06 8:39 ` Geert Uytterhoeven
0 siblings, 0 replies; 207+ messages in thread
From: Geert Uytterhoeven @ 2014-03-06 8:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, Linux Fbdev development list,
Russell King - ARM Linux, DRI Development, Andrzej Hajda,
Laurent Pinchart, linux-arm-kernel, Sebastian Hesselbarth
On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 28/02/14 18:23, Russell King - ARM Linux wrote:
>
>> That's rather a lot of compatible strings. Another possibility is:
>>
>> compatible = "dvi-connector";
>> analog;
>> digital;
>> single-link;
>> dual-link;
>
> I made the following changes compared to the posted version. I decided
> to leave the "single-link" out, as it's implied if "digital" is set.
>
> Tomi
>
> @@ -6,11 +6,16 @@ Required properties:
>
> Optional properties:
> - label: a symbolic name for the connector
> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> +- analog: the connector has DVI analog pins
> +- digital: the connector has DVI digital pins
> +- dual-link: the connector has pins for DVI dual-link
>
> Required nodes:
> - Video port for DVI input
>
> +Note: One (or both) of 'analog' or 'digital' must be set.
So dual-link needs both "digital" and "dual-link"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-06 8:39 ` Geert Uytterhoeven
0 siblings, 0 replies; 207+ messages in thread
From: Geert Uytterhoeven @ 2014-03-06 8:39 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 28/02/14 18:23, Russell King - ARM Linux wrote:
>
>> That's rather a lot of compatible strings. Another possibility is:
>>
>> compatible = "dvi-connector";
>> analog;
>> digital;
>> single-link;
>> dual-link;
>
> I made the following changes compared to the posted version. I decided
> to leave the "single-link" out, as it's implied if "digital" is set.
>
> Tomi
>
> @@ -6,11 +6,16 @@ Required properties:
>
> Optional properties:
> - label: a symbolic name for the connector
> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> +- analog: the connector has DVI analog pins
> +- digital: the connector has DVI digital pins
> +- dual-link: the connector has pins for DVI dual-link
>
> Required nodes:
> - Video port for DVI input
>
> +Note: One (or both) of 'analog' or 'digital' must be set.
So dual-link needs both "digital" and "dual-link"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
[not found] ` <CAMuHMdWVSfKrudBhE7FW-ZWBvMOLWjrQZvn1qZUfRt_H+P7A2w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-06 8:52 ` Tomi Valkeinen
@ 2014-03-06 8:52 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-06 8:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King - ARM Linux, Linux Fbdev development list,
DRI Development, 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,
Daniel Vetter
[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]
On 06/03/14 10:39, Geert Uytterhoeven wrote:
> On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org> wrote:
>> On 28/02/14 18:23, Russell King - ARM Linux wrote:
>>
>>> That's rather a lot of compatible strings. Another possibility is:
>>>
>>> compatible = "dvi-connector";
>>> analog;
>>> digital;
>>> single-link;
>>> dual-link;
>>
>> I made the following changes compared to the posted version. I decided
>> to leave the "single-link" out, as it's implied if "digital" is set.
>>
>> Tomi
>>
>> @@ -6,11 +6,16 @@ Required properties:
>>
>> Optional properties:
>> - label: a symbolic name for the connector
>> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
>> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
>> +- analog: the connector has DVI analog pins
>> +- digital: the connector has DVI digital pins
>> +- dual-link: the connector has pins for DVI dual-link
>>
>> Required nodes:
>> - Video port for DVI input
>>
>> +Note: One (or both) of 'analog' or 'digital' must be set.
>
> So dual-link needs both "digital" and "dual-link"?
Yes. It is extra, but it felt clearer to me to have 'digital' as a
matching property for 'analog'.
Alternatively we could have three options:
analog;
digital-single-link;
digital-dual-link;
My reasoning to the format I chose was basically that when a connector
supports 'digital', it contains TMDS clock and TMDS data for link 1.
Adding dual link to that adds only TMDS data for link 2, so the second
data link is kind of an additional feature, marked with a flag.
Not a very big argument, and I'm fine with other format suggestions.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-06 8:52 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-06 8:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King - ARM Linux, Linux Fbdev development list,
DRI Development, 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,
Daniel Vetter
[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]
On 06/03/14 10:39, Geert Uytterhoeven wrote:
> On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 28/02/14 18:23, Russell King - ARM Linux wrote:
>>
>>> That's rather a lot of compatible strings. Another possibility is:
>>>
>>> compatible = "dvi-connector";
>>> analog;
>>> digital;
>>> single-link;
>>> dual-link;
>>
>> I made the following changes compared to the posted version. I decided
>> to leave the "single-link" out, as it's implied if "digital" is set.
>>
>> Tomi
>>
>> @@ -6,11 +6,16 @@ Required properties:
>>
>> Optional properties:
>> - label: a symbolic name for the connector
>> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
>> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
>> +- analog: the connector has DVI analog pins
>> +- digital: the connector has DVI digital pins
>> +- dual-link: the connector has pins for DVI dual-link
>>
>> Required nodes:
>> - Video port for DVI input
>>
>> +Note: One (or both) of 'analog' or 'digital' must be set.
>
> So dual-link needs both "digital" and "dual-link"?
Yes. It is extra, but it felt clearer to me to have 'digital' as a
matching property for 'analog'.
Alternatively we could have three options:
analog;
digital-single-link;
digital-dual-link;
My reasoning to the format I chose was basically that when a connector
supports 'digital', it contains TMDS clock and TMDS data for link 1.
Adding dual link to that adds only TMDS data for link 2, so the second
data link is kind of an additional feature, marked with a flag.
Not a very big argument, and I'm fine with other format suggestions.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-06 8:52 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-06 8:52 UTC (permalink / raw)
To: linux-arm-kernel
On 06/03/14 10:39, Geert Uytterhoeven wrote:
> On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 28/02/14 18:23, Russell King - ARM Linux wrote:
>>
>>> That's rather a lot of compatible strings. Another possibility is:
>>>
>>> compatible = "dvi-connector";
>>> analog;
>>> digital;
>>> single-link;
>>> dual-link;
>>
>> I made the following changes compared to the posted version. I decided
>> to leave the "single-link" out, as it's implied if "digital" is set.
>>
>> Tomi
>>
>> @@ -6,11 +6,16 @@ Required properties:
>>
>> Optional properties:
>> - label: a symbolic name for the connector
>> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
>> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
>> +- analog: the connector has DVI analog pins
>> +- digital: the connector has DVI digital pins
>> +- dual-link: the connector has pins for DVI dual-link
>>
>> Required nodes:
>> - Video port for DVI input
>>
>> +Note: One (or both) of 'analog' or 'digital' must be set.
>
> So dual-link needs both "digital" and "dual-link"?
Yes. It is extra, but it felt clearer to me to have 'digital' as a
matching property for 'analog'.
Alternatively we could have three options:
analog;
digital-single-link;
digital-dual-link;
My reasoning to the format I chose was basically that when a connector
supports 'digital', it contains TMDS clock and TMDS data for link 1.
Adding dual link to that adds only TMDS data for link 2, so the second
data link is kind of an additional feature, marked with a flag.
Not a very big argument, and I'm fine with other format suggestions.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140306/65ecafc2/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
2014-03-03 8:04 ` Tomi Valkeinen
(?)
@ 2014-03-07 12:56 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-07 12:56 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, Philipp Zabel,
linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 1615 bytes --]
On 03/03/14 10:04, Tomi Valkeinen wrote:
> Hi Rob, Pawel, Mark, Ian, Kumar,
Ping,
Any hints on how to continue with this?
> On 28/02/14 18:56, Russell King - ARM Linux wrote:
>> On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
>>> This is totally unclear to me. How does it become a public standard?
>>> What's the forum for this?
>>
>> Me too. That's where I'd hope someone on devicetree-discuss will be
>> able to help us work out what's the right approach here. :)
>
> The story briefly so far: I've implemented DT support for OMAP display,
> and created bindings for various (non-OMAP) display components,
> including generic connector bindings for DVI, HDMI and analog-tv.
>
> Russell's point was that these connector bindings are very generic, i.e.
> they are not for any particular chip from a particular vendor, but for
> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
> shouldn't define such generic bindings without consulting the whole
> device-tree community (i.e including non-linux users).
>
> So the question is, is there such a community and a forum to bring up
> this kind of things? If yes, should we bring this up there? If yes, what
> kind of things in general should be brought into the attention of
> non-linux users?
>
> What I wonder here is that while a thing like DVI connector is, of
> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
> case still the same: we're defining global bindings for hardware that
> should work for everyone, not only Linux users?
>
> Tomi
>
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-07 12:56 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-07 12:56 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, Philipp Zabel,
linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]
On 03/03/14 10:04, Tomi Valkeinen wrote:
> Hi Rob, Pawel, Mark, Ian, Kumar,
Ping,
Any hints on how to continue with this?
> On 28/02/14 18:56, Russell King - ARM Linux wrote:
>> On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
>>> This is totally unclear to me. How does it become a public standard?
>>> What's the forum for this?
>>
>> Me too. That's where I'd hope someone on devicetree-discuss will be
>> able to help us work out what's the right approach here. :)
>
> The story briefly so far: I've implemented DT support for OMAP display,
> and created bindings for various (non-OMAP) display components,
> including generic connector bindings for DVI, HDMI and analog-tv.
>
> Russell's point was that these connector bindings are very generic, i.e.
> they are not for any particular chip from a particular vendor, but for
> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
> shouldn't define such generic bindings without consulting the whole
> device-tree community (i.e including non-linux users).
>
> So the question is, is there such a community and a forum to bring up
> this kind of things? If yes, should we bring this up there? If yes, what
> kind of things in general should be brought into the attention of
> non-linux users?
>
> What I wonder here is that while a thing like DVI connector is, of
> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
> case still the same: we're defining global bindings for hardware that
> should work for everyone, not only Linux users?
>
> Tomi
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-07 12:56 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-07 12:56 UTC (permalink / raw)
To: linux-arm-kernel
On 03/03/14 10:04, Tomi Valkeinen wrote:
> Hi Rob, Pawel, Mark, Ian, Kumar,
Ping,
Any hints on how to continue with this?
> On 28/02/14 18:56, Russell King - ARM Linux wrote:
>> On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
>>> This is totally unclear to me. How does it become a public standard?
>>> What's the forum for this?
>>
>> Me too. That's where I'd hope someone on devicetree-discuss will be
>> able to help us work out what's the right approach here. :)
>
> The story briefly so far: I've implemented DT support for OMAP display,
> and created bindings for various (non-OMAP) display components,
> including generic connector bindings for DVI, HDMI and analog-tv.
>
> Russell's point was that these connector bindings are very generic, i.e.
> they are not for any particular chip from a particular vendor, but for
> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
> shouldn't define such generic bindings without consulting the whole
> device-tree community (i.e including non-linux users).
>
> So the question is, is there such a community and a forum to bring up
> this kind of things? If yes, should we bring this up there? If yes, what
> kind of things in general should be brought into the attention of
> non-linux users?
>
> What I wonder here is that while a thing like DVI connector is, of
> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
> case still the same: we're defining global bindings for hardware that
> should work for everyone, not only Linux users?
>
> Tomi
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140307/490977c1/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
2014-03-06 8:52 ` Tomi Valkeinen
(?)
@ 2014-03-07 14:17 ` Philipp Zabel
-1 siblings, 0 replies; 207+ messages in thread
From: Philipp Zabel @ 2014-03-07 14:17 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, Linux Fbdev development list,
Russell King - ARM Linux, DRI Development, Andrzej Hajda,
Geert Uytterhoeven, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
Hi,
Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen:
> On 06/03/14 10:39, Geert Uytterhoeven wrote:
> > On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> On 28/02/14 18:23, Russell King - ARM Linux wrote:
> >>
> >>> That's rather a lot of compatible strings. Another possibility is:
> >>>
> >>> compatible = "dvi-connector";
> >>> analog;
> >>> digital;
> >>> single-link;
> >>> dual-link;
> >>
> >> I made the following changes compared to the posted version. I decided
> >> to leave the "single-link" out, as it's implied if "digital" is set.
> >>
> >> Tomi
> >>
> >> @@ -6,11 +6,16 @@ Required properties:
> >>
> >> Optional properties:
> >> - label: a symbolic name for the connector
> >> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> >> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> >> +- analog: the connector has DVI analog pins
> >> +- digital: the connector has DVI digital pins
> >> +- dual-link: the connector has pins for DVI dual-link
> >>
> >> Required nodes:
> >> - Video port for DVI input
> >>
> >> +Note: One (or both) of 'analog' or 'digital' must be set.
> >
> > So dual-link needs both "digital" and "dual-link"?
>
> Yes. It is extra, but it felt clearer to me to have 'digital' as a
> matching property for 'analog'.
>
> Alternatively we could have three options:
>
> analog;
> digital-single-link;
> digital-dual-link;
>
> My reasoning to the format I chose was basically that when a connector
> supports 'digital', it contains TMDS clock and TMDS data for link 1.
> Adding dual link to that adds only TMDS data for link 2, so the second
> data link is kind of an additional feature, marked with a flag.
>
> Not a very big argument, and I'm fine with other format suggestions.
I'd prefer the analog / digital / dual-link variant for aesthetic
reasons. But looking at other connector types, I wonder if this should
be generalized even more:
For HDMI/DVI (digital) single-link means one clock pair and 3 TMDS data
pairs, dual-link means one clock pair and 6 data pairs.
On LVDS connectors, there usually are one clock pair and three (18-bit)
or four (24-bit) LVDS data pairs, in dual channel configuration two
clock pairs and 6 or 8 data pairs are used.
For DisplayPort there is no separate clock pair, but 1 to 4 data pairs,
and MIPI DSI again has one clock pair and a one or more data pairs.
There are already optional endpoint configuration properties
'data-lanes' and 'clock-lanes' for MIPI CSI-2 defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Could/should this be aligned with the same?
regards
Philipp
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-07 14:17 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
From: Philipp Zabel @ 2014-03-07 14:17 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, Linux Fbdev development list,
Russell King - ARM Linux, DRI Development, Andrzej Hajda,
Geert Uytterhoeven, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
Hi,
Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen:
> On 06/03/14 10:39, Geert Uytterhoeven wrote:
> > On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> On 28/02/14 18:23, Russell King - ARM Linux wrote:
> >>
> >>> That's rather a lot of compatible strings. Another possibility is:
> >>>
> >>> compatible = "dvi-connector";
> >>> analog;
> >>> digital;
> >>> single-link;
> >>> dual-link;
> >>
> >> I made the following changes compared to the posted version. I decided
> >> to leave the "single-link" out, as it's implied if "digital" is set.
> >>
> >> Tomi
> >>
> >> @@ -6,11 +6,16 @@ Required properties:
> >>
> >> Optional properties:
> >> - label: a symbolic name for the connector
> >> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> >> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> >> +- analog: the connector has DVI analog pins
> >> +- digital: the connector has DVI digital pins
> >> +- dual-link: the connector has pins for DVI dual-link
> >>
> >> Required nodes:
> >> - Video port for DVI input
> >>
> >> +Note: One (or both) of 'analog' or 'digital' must be set.
> >
> > So dual-link needs both "digital" and "dual-link"?
>
> Yes. It is extra, but it felt clearer to me to have 'digital' as a
> matching property for 'analog'.
>
> Alternatively we could have three options:
>
> analog;
> digital-single-link;
> digital-dual-link;
>
> My reasoning to the format I chose was basically that when a connector
> supports 'digital', it contains TMDS clock and TMDS data for link 1.
> Adding dual link to that adds only TMDS data for link 2, so the second
> data link is kind of an additional feature, marked with a flag.
>
> Not a very big argument, and I'm fine with other format suggestions.
I'd prefer the analog / digital / dual-link variant for aesthetic
reasons. But looking at other connector types, I wonder if this should
be generalized even more:
For HDMI/DVI (digital) single-link means one clock pair and 3 TMDS data
pairs, dual-link means one clock pair and 6 data pairs.
On LVDS connectors, there usually are one clock pair and three (18-bit)
or four (24-bit) LVDS data pairs, in dual channel configuration two
clock pairs and 6 or 8 data pairs are used.
For DisplayPort there is no separate clock pair, but 1 to 4 data pairs,
and MIPI DSI again has one clock pair and a one or more data pairs.
There are already optional endpoint configuration properties
'data-lanes' and 'clock-lanes' for MIPI CSI-2 defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Could/should this be aligned with the same?
regards
Philipp
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-07 14:17 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
From: Philipp Zabel @ 2014-03-07 14:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen:
> On 06/03/14 10:39, Geert Uytterhoeven wrote:
> > On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> On 28/02/14 18:23, Russell King - ARM Linux wrote:
> >>
> >>> That's rather a lot of compatible strings. Another possibility is:
> >>>
> >>> compatible = "dvi-connector";
> >>> analog;
> >>> digital;
> >>> single-link;
> >>> dual-link;
> >>
> >> I made the following changes compared to the posted version. I decided
> >> to leave the "single-link" out, as it's implied if "digital" is set.
> >>
> >> Tomi
> >>
> >> @@ -6,11 +6,16 @@ Required properties:
> >>
> >> Optional properties:
> >> - label: a symbolic name for the connector
> >> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> >> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> >> +- analog: the connector has DVI analog pins
> >> +- digital: the connector has DVI digital pins
> >> +- dual-link: the connector has pins for DVI dual-link
> >>
> >> Required nodes:
> >> - Video port for DVI input
> >>
> >> +Note: One (or both) of 'analog' or 'digital' must be set.
> >
> > So dual-link needs both "digital" and "dual-link"?
>
> Yes. It is extra, but it felt clearer to me to have 'digital' as a
> matching property for 'analog'.
>
> Alternatively we could have three options:
>
> analog;
> digital-single-link;
> digital-dual-link;
>
> My reasoning to the format I chose was basically that when a connector
> supports 'digital', it contains TMDS clock and TMDS data for link 1.
> Adding dual link to that adds only TMDS data for link 2, so the second
> data link is kind of an additional feature, marked with a flag.
>
> Not a very big argument, and I'm fine with other format suggestions.
I'd prefer the analog / digital / dual-link variant for aesthetic
reasons. But looking at other connector types, I wonder if this should
be generalized even more:
For HDMI/DVI (digital) single-link means one clock pair and 3 TMDS data
pairs, dual-link means one clock pair and 6 data pairs.
On LVDS connectors, there usually are one clock pair and three (18-bit)
or four (24-bit) LVDS data pairs, in dual channel configuration two
clock pairs and 6 or 8 data pairs are used.
For DisplayPort there is no separate clock pair, but 1 to 4 data pairs,
and MIPI DSI again has one clock pair and a one or more data pairs.
There are already optional endpoint configuration properties
'data-lanes' and 'clock-lanes' for MIPI CSI-2 defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Could/should this be aligned with the same?
regards
Philipp
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
2014-03-07 14:17 ` Philipp Zabel
(?)
@ 2014-03-10 10:32 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-10 10:32 UTC (permalink / raw)
To: Philipp Zabel
Cc: devicetree, Linux Fbdev development list,
Russell King - ARM Linux, Sascha Hauer, Tomasz Figa,
DRI Development, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Geert Uytterhoeven, Laurent Pinchart,
Daniel Vetter, linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 1919 bytes --]
On 07/03/14 16:17, Philipp Zabel wrote:
> Hi,
>
> Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen:
>> analog;
>> digital-single-link;
>> digital-dual-link;
>>
>> My reasoning to the format I chose was basically that when a connector
>> supports 'digital', it contains TMDS clock and TMDS data for link 1.
>> Adding dual link to that adds only TMDS data for link 2, so the second
>> data link is kind of an additional feature, marked with a flag.
>>
>> Not a very big argument, and I'm fine with other format suggestions.
>
> I'd prefer the analog / digital / dual-link variant for aesthetic
> reasons. But looking at other connector types, I wonder if this should
> be generalized even more:
>
> For HDMI/DVI (digital) single-link means one clock pair and 3 TMDS data
> pairs, dual-link means one clock pair and 6 data pairs.
>
> On LVDS connectors, there usually are one clock pair and three (18-bit)
> or four (24-bit) LVDS data pairs, in dual channel configuration two
> clock pairs and 6 or 8 data pairs are used.
>
> For DisplayPort there is no separate clock pair, but 1 to 4 data pairs,
> and MIPI DSI again has one clock pair and a one or more data pairs.
>
> There are already optional endpoint configuration properties
> 'data-lanes' and 'clock-lanes' for MIPI CSI-2 defined in
> Documentation/devicetree/bindings/media/video-interfaces.txt.
> Could/should this be aligned with the same?
Hmm. Well, at least for HDMI and DP we anyway need the connector type,
which tells the form factor, and it also tells the TMDS details. So, we
could define the lanes in a common way, but we'd still need extra
information.
For MIPI DSI and (I believe) LVDS, we don't need connectors. Connectors,
as described in this binding, are meant for standard hotpluggable
connectors to which you can connect any device that has that same connector.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-10 10:32 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-10 10:32 UTC (permalink / raw)
To: Philipp Zabel
Cc: devicetree, Linux Fbdev development list,
Russell King - ARM Linux, Sascha Hauer, Tomasz Figa,
DRI Development, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Geert Uytterhoeven, Laurent Pinchart,
Daniel Vetter, linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
On 07/03/14 16:17, Philipp Zabel wrote:
> Hi,
>
> Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen:
>> analog;
>> digital-single-link;
>> digital-dual-link;
>>
>> My reasoning to the format I chose was basically that when a connector
>> supports 'digital', it contains TMDS clock and TMDS data for link 1.
>> Adding dual link to that adds only TMDS data for link 2, so the second
>> data link is kind of an additional feature, marked with a flag.
>>
>> Not a very big argument, and I'm fine with other format suggestions.
>
> I'd prefer the analog / digital / dual-link variant for aesthetic
> reasons. But looking at other connector types, I wonder if this should
> be generalized even more:
>
> For HDMI/DVI (digital) single-link means one clock pair and 3 TMDS data
> pairs, dual-link means one clock pair and 6 data pairs.
>
> On LVDS connectors, there usually are one clock pair and three (18-bit)
> or four (24-bit) LVDS data pairs, in dual channel configuration two
> clock pairs and 6 or 8 data pairs are used.
>
> For DisplayPort there is no separate clock pair, but 1 to 4 data pairs,
> and MIPI DSI again has one clock pair and a one or more data pairs.
>
> There are already optional endpoint configuration properties
> 'data-lanes' and 'clock-lanes' for MIPI CSI-2 defined in
> Documentation/devicetree/bindings/media/video-interfaces.txt.
> Could/should this be aligned with the same?
Hmm. Well, at least for HDMI and DP we anyway need the connector type,
which tells the form factor, and it also tells the TMDS details. So, we
could define the lanes in a common way, but we'd still need extra
information.
For MIPI DSI and (I believe) LVDS, we don't need connectors. Connectors,
as described in this binding, are meant for standard hotpluggable
connectors to which you can connect any device that has that same connector.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-10 10:32 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-10 10:32 UTC (permalink / raw)
To: linux-arm-kernel
On 07/03/14 16:17, Philipp Zabel wrote:
> Hi,
>
> Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen:
>> analog;
>> digital-single-link;
>> digital-dual-link;
>>
>> My reasoning to the format I chose was basically that when a connector
>> supports 'digital', it contains TMDS clock and TMDS data for link 1.
>> Adding dual link to that adds only TMDS data for link 2, so the second
>> data link is kind of an additional feature, marked with a flag.
>>
>> Not a very big argument, and I'm fine with other format suggestions.
>
> I'd prefer the analog / digital / dual-link variant for aesthetic
> reasons. But looking at other connector types, I wonder if this should
> be generalized even more:
>
> For HDMI/DVI (digital) single-link means one clock pair and 3 TMDS data
> pairs, dual-link means one clock pair and 6 data pairs.
>
> On LVDS connectors, there usually are one clock pair and three (18-bit)
> or four (24-bit) LVDS data pairs, in dual channel configuration two
> clock pairs and 6 or 8 data pairs are used.
>
> For DisplayPort there is no separate clock pair, but 1 to 4 data pairs,
> and MIPI DSI again has one clock pair and a one or more data pairs.
>
> There are already optional endpoint configuration properties
> 'data-lanes' and 'clock-lanes' for MIPI CSI-2 defined in
> Documentation/devicetree/bindings/media/video-interfaces.txt.
> Could/should this be aligned with the same?
Hmm. Well, at least for HDMI and DP we anyway need the connector type,
which tells the form factor, and it also tells the TMDS details. So, we
could define the lanes in a common way, but we'd still need extra
information.
For MIPI DSI and (I believe) LVDS, we don't need connectors. Connectors,
as described in this binding, are meant for standard hotpluggable
connectors to which you can connect any device that has that same connector.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140310/6e78afa8/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
[not found] ` <53143796.2050309-l0cyMroinI0@public.gmane.org>
2014-03-10 16:05 ` Rob Herring
@ 2014-03-10 16:05 ` Rob Herring
0 siblings, 0 replies; 207+ messages in thread
From: Rob Herring @ 2014-03-10 16:05 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Russell King - ARM Linux,
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
On Mon, Mar 3, 2014 at 2:04 AM, Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org> wrote:
> Hi Rob, Pawel, Mark, Ian, Kumar,
>
> On 28/02/14 18:56, Russell King - ARM Linux wrote:
>> On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
>>> This is totally unclear to me. How does it become a public standard?
>>> What's the forum for this?
>>
>> Me too. That's where I'd hope someone on devicetree-discuss will be
>> able to help us work out what's the right approach here. :)
>
> The story briefly so far: I've implemented DT support for OMAP display,
> and created bindings for various (non-OMAP) display components,
> including generic connector bindings for DVI, HDMI and analog-tv.
>
> Russell's point was that these connector bindings are very generic, i.e.
> they are not for any particular chip from a particular vendor, but for
> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
> shouldn't define such generic bindings without consulting the whole
> device-tree community (i.e including non-linux users).
So re-work it to be generic and send it out. DT maintainers would
rarely disagree that something shouldn't be made generic.
> So the question is, is there such a community and a forum to bring up
> this kind of things? If yes, should we bring this up there? If yes, what
> kind of things in general should be brought into the attention of
> non-linux users?
devicetree list is just that. It is not just for Linux. There is the
newly created devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org which is for more
core/common binding discussion.
>
> What I wonder here is that while a thing like DVI connector is, of
> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
> case still the same: we're defining global bindings for hardware that
> should work for everyone, not only Linux users?
Defining the connectors in DT is a useful thing although mainly when
you have multiple connectors of the same type. Labels for composite,
SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or
printed label (like front vs. rear connections) seem more useful to
me.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-10 16:05 ` Rob Herring
0 siblings, 0 replies; 207+ messages in thread
From: Rob Herring @ 2014-03-10 16:05 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Russell King - ARM Linux,
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
On Mon, Mar 3, 2014 at 2:04 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Rob, Pawel, Mark, Ian, Kumar,
>
> On 28/02/14 18:56, Russell King - ARM Linux wrote:
>> On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
>>> This is totally unclear to me. How does it become a public standard?
>>> What's the forum for this?
>>
>> Me too. That's where I'd hope someone on devicetree-discuss will be
>> able to help us work out what's the right approach here. :)
>
> The story briefly so far: I've implemented DT support for OMAP display,
> and created bindings for various (non-OMAP) display components,
> including generic connector bindings for DVI, HDMI and analog-tv.
>
> Russell's point was that these connector bindings are very generic, i.e.
> they are not for any particular chip from a particular vendor, but for
> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
> shouldn't define such generic bindings without consulting the whole
> device-tree community (i.e including non-linux users).
So re-work it to be generic and send it out. DT maintainers would
rarely disagree that something shouldn't be made generic.
> So the question is, is there such a community and a forum to bring up
> this kind of things? If yes, should we bring this up there? If yes, what
> kind of things in general should be brought into the attention of
> non-linux users?
devicetree list is just that. It is not just for Linux. There is the
newly created devicetree-spec@vger.kernel.org which is for more
core/common binding discussion.
>
> What I wonder here is that while a thing like DVI connector is, of
> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
> case still the same: we're defining global bindings for hardware that
> should work for everyone, not only Linux users?
Defining the connectors in DT is a useful thing although mainly when
you have multiple connectors of the same type. Labels for composite,
SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or
printed label (like front vs. rear connections) seem more useful to
me.
Rob
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-10 16:05 ` Rob Herring
0 siblings, 0 replies; 207+ messages in thread
From: Rob Herring @ 2014-03-10 16:05 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 3, 2014 at 2:04 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Rob, Pawel, Mark, Ian, Kumar,
>
> On 28/02/14 18:56, Russell King - ARM Linux wrote:
>> On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
>>> This is totally unclear to me. How does it become a public standard?
>>> What's the forum for this?
>>
>> Me too. That's where I'd hope someone on devicetree-discuss will be
>> able to help us work out what's the right approach here. :)
>
> The story briefly so far: I've implemented DT support for OMAP display,
> and created bindings for various (non-OMAP) display components,
> including generic connector bindings for DVI, HDMI and analog-tv.
>
> Russell's point was that these connector bindings are very generic, i.e.
> they are not for any particular chip from a particular vendor, but for
> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
> shouldn't define such generic bindings without consulting the whole
> device-tree community (i.e including non-linux users).
So re-work it to be generic and send it out. DT maintainers would
rarely disagree that something shouldn't be made generic.
> So the question is, is there such a community and a forum to bring up
> this kind of things? If yes, should we bring this up there? If yes, what
> kind of things in general should be brought into the attention of
> non-linux users?
devicetree list is just that. It is not just for Linux. There is the
newly created devicetree-spec at vger.kernel.org which is for more
core/common binding discussion.
>
> What I wonder here is that while a thing like DVI connector is, of
> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
> case still the same: we're defining global bindings for hardware that
> should work for everyone, not only Linux users?
Defining the connectors in DT is a useful thing although mainly when
you have multiple connectors of the same type. Labels for composite,
SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or
printed label (like front vs. rear connections) seem more useful to
me.
Rob
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
2014-03-10 16:05 ` Rob Herring
(?)
@ 2014-03-10 16:40 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-10 16:40 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linux-fbdev, Russell King - ARM Linux,
Pawel Moll, Ian Campbell, Sascha Hauer, Tomasz Figa, dri-devel,
Inki Dae, Andrzej Hajda, Rob Clark, Rob Herring, Thierry Reding,
Laurent Pinchart, Philipp Zabel, Kumar Gala, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 2900 bytes --]
Hi Rob,
On 10/03/14 18:05, Rob Herring wrote:
>> Russell's point was that these connector bindings are very generic, i.e.
>> they are not for any particular chip from a particular vendor, but for
>> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
>> shouldn't define such generic bindings without consulting the whole
>> device-tree community (i.e including non-linux users).
>
> So re-work it to be generic and send it out. DT maintainers would
> rarely disagree that something shouldn't be made generic.
They (in this series) are already designed to be generic.
I should perhaps re-word the question: we are concerned whether these
bindings are good for all the users, not just us, and whether there
already exists something that overlaps.
Afaik, there's nothing overlapping. And I don't see why they wouldn't be
good for all users (with the few minor modifications that have been
discussed in this thread). But, if I gathered right, Russell would like
some kind of ack from someone who might know better than us.
So is it enough to have posted these, and gotten acks from the people
involved, or should we get acks from DT maintainers also?
Is there a way to get the attention of, say, BSD people, or should we
just presume they'll follow the list?
>> So the question is, is there such a community and a forum to bring up
>> this kind of things? If yes, should we bring this up there? If yes, what
>> kind of things in general should be brought into the attention of
>> non-linux users?
>
> devicetree list is just that. It is not just for Linux. There is the
> newly created devicetree-spec@vger.kernel.org which is for more
> core/common binding discussion.
Ok.
>> What I wonder here is that while a thing like DVI connector is, of
>> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
>> case still the same: we're defining global bindings for hardware that
>> should work for everyone, not only Linux users?
>
> Defining the connectors in DT is a useful thing although mainly when
> you have multiple connectors of the same type. Labels for composite,
> SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or
> printed label (like front vs. rear connections) seem more useful to
> me.
My point above was that it feels mentally easier to define bindings for
one particular IP block or chip, than defining bindings for a more
generic thing like "HDMI connector". But, in the end, I believe they
both should go through similar review, and there's no such difference.
As for the labels, they can be anything that makes sense for that
particular board. It can be "HDMI Front", if such makes sense, or
"HDMI-2" if the connector has such physical printed label. Or, say,
"Main LCD", "Secondary LCD". It's a free form text that is given to the
user.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-10 16:40 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-10 16:40 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linux-fbdev, Russell King - ARM Linux,
Pawel Moll, Ian Campbell, Sascha Hauer, Tomasz Figa, dri-devel,
Inki Dae, Andrzej Hajda, Rob Clark, Rob Herring, Thierry Reding,
Laurent Pinchart, Philipp Zabel, Kumar Gala, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 2900 bytes --]
Hi Rob,
On 10/03/14 18:05, Rob Herring wrote:
>> Russell's point was that these connector bindings are very generic, i.e.
>> they are not for any particular chip from a particular vendor, but for
>> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
>> shouldn't define such generic bindings without consulting the whole
>> device-tree community (i.e including non-linux users).
>
> So re-work it to be generic and send it out. DT maintainers would
> rarely disagree that something shouldn't be made generic.
They (in this series) are already designed to be generic.
I should perhaps re-word the question: we are concerned whether these
bindings are good for all the users, not just us, and whether there
already exists something that overlaps.
Afaik, there's nothing overlapping. And I don't see why they wouldn't be
good for all users (with the few minor modifications that have been
discussed in this thread). But, if I gathered right, Russell would like
some kind of ack from someone who might know better than us.
So is it enough to have posted these, and gotten acks from the people
involved, or should we get acks from DT maintainers also?
Is there a way to get the attention of, say, BSD people, or should we
just presume they'll follow the list?
>> So the question is, is there such a community and a forum to bring up
>> this kind of things? If yes, should we bring this up there? If yes, what
>> kind of things in general should be brought into the attention of
>> non-linux users?
>
> devicetree list is just that. It is not just for Linux. There is the
> newly created devicetree-spec@vger.kernel.org which is for more
> core/common binding discussion.
Ok.
>> What I wonder here is that while a thing like DVI connector is, of
>> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
>> case still the same: we're defining global bindings for hardware that
>> should work for everyone, not only Linux users?
>
> Defining the connectors in DT is a useful thing although mainly when
> you have multiple connectors of the same type. Labels for composite,
> SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or
> printed label (like front vs. rear connections) seem more useful to
> me.
My point above was that it feels mentally easier to define bindings for
one particular IP block or chip, than defining bindings for a more
generic thing like "HDMI connector". But, in the end, I believe they
both should go through similar review, and there's no such difference.
As for the labels, they can be anything that makes sense for that
particular board. It can be "HDMI Front", if such makes sense, or
"HDMI-2" if the connector has such physical printed label. Or, say,
"Main LCD", "Secondary LCD". It's a free form text that is given to the
user.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-10 16:40 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-10 16:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rob,
On 10/03/14 18:05, Rob Herring wrote:
>> Russell's point was that these connector bindings are very generic, i.e.
>> they are not for any particular chip from a particular vendor, but for
>> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
>> shouldn't define such generic bindings without consulting the whole
>> device-tree community (i.e including non-linux users).
>
> So re-work it to be generic and send it out. DT maintainers would
> rarely disagree that something shouldn't be made generic.
They (in this series) are already designed to be generic.
I should perhaps re-word the question: we are concerned whether these
bindings are good for all the users, not just us, and whether there
already exists something that overlaps.
Afaik, there's nothing overlapping. And I don't see why they wouldn't be
good for all users (with the few minor modifications that have been
discussed in this thread). But, if I gathered right, Russell would like
some kind of ack from someone who might know better than us.
So is it enough to have posted these, and gotten acks from the people
involved, or should we get acks from DT maintainers also?
Is there a way to get the attention of, say, BSD people, or should we
just presume they'll follow the list?
>> So the question is, is there such a community and a forum to bring up
>> this kind of things? If yes, should we bring this up there? If yes, what
>> kind of things in general should be brought into the attention of
>> non-linux users?
>
> devicetree list is just that. It is not just for Linux. There is the
> newly created devicetree-spec at vger.kernel.org which is for more
> core/common binding discussion.
Ok.
>> What I wonder here is that while a thing like DVI connector is, of
>> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
>> case still the same: we're defining global bindings for hardware that
>> should work for everyone, not only Linux users?
>
> Defining the connectors in DT is a useful thing although mainly when
> you have multiple connectors of the same type. Labels for composite,
> SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or
> printed label (like front vs. rear connections) seem more useful to
> me.
My point above was that it feels mentally easier to define bindings for
one particular IP block or chip, than defining bindings for a more
generic thing like "HDMI connector". But, in the end, I believe they
both should go through similar review, and there's no such difference.
As for the labels, they can be anything that makes sense for that
particular board. It can be "HDMI Front", if such makes sense, or
"HDMI-2" if the connector has such physical printed label. Or, say,
"Main LCD", "Secondary LCD". It's a free form text that is given to the
user.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140310/d894abf5/attachment-0001.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
[not found] ` <531DEB1A.5090509-l0cyMroinI0@public.gmane.org>
2014-03-10 20:32 ` Rob Herring
@ 2014-03-10 20:32 ` Rob Herring
0 siblings, 0 replies; 207+ messages in thread
From: Rob Herring @ 2014-03-10 20:32 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Russell King - ARM Linux,
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
On Mon, Mar 10, 2014 at 11:40 AM, Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org> wrote:
> Hi Rob,
>
> On 10/03/14 18:05, Rob Herring wrote:
>
>>> Russell's point was that these connector bindings are very generic, i.e.
>>> they are not for any particular chip from a particular vendor, but for
>>> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
>>> shouldn't define such generic bindings without consulting the whole
>>> device-tree community (i.e including non-linux users).
>>
>> So re-work it to be generic and send it out. DT maintainers would
>> rarely disagree that something shouldn't be made generic.
>
> They (in this series) are already designed to be generic.
>
> I should perhaps re-word the question: we are concerned whether these
> bindings are good for all the users, not just us, and whether there
> already exists something that overlaps.
Given this is tied into the rest of video description with endpoints
and such, you really have to look at the whole picture to answer that
question. I'd guess Linux well ahead of other OSs in terms of dealing
with the plethora of video and graphics h/w. I'd be more concerned
that the bindings are good for all h/w rather than all OS's.
> Afaik, there's nothing overlapping. And I don't see why they wouldn't be
> good for all users (with the few minor modifications that have been
> discussed in this thread). But, if I gathered right, Russell would like
> some kind of ack from someone who might know better than us.
>
> So is it enough to have posted these, and gotten acks from the people
> involved, or should we get acks from DT maintainers also?
We really leave it up to the subsystem maintainers to decide, but for
new common/generic bindings it is a good idea to get DT maintainers
ack. I'll go thru the individual patches.
> Is there a way to get the attention of, say, BSD people, or should we
> just presume they'll follow the list?
devicetree-spec was created specifically to have a lower volume list
without a bunch of Linux driver patches which aren't relevant to
people from other OSs.
>>> So the question is, is there such a community and a forum to bring up
>>> this kind of things? If yes, should we bring this up there? If yes, what
>>> kind of things in general should be brought into the attention of
>>> non-linux users?
>>
>> devicetree list is just that. It is not just for Linux. There is the
>> newly created devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org which is for more
>> core/common binding discussion.
>
> Ok.
>
>>> What I wonder here is that while a thing like DVI connector is, of
>>> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
>>> case still the same: we're defining global bindings for hardware that
>>> should work for everyone, not only Linux users?
>>
>> Defining the connectors in DT is a useful thing although mainly when
>> you have multiple connectors of the same type. Labels for composite,
>> SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or
>> printed label (like front vs. rear connections) seem more useful to
>> me.
>
> My point above was that it feels mentally easier to define bindings for
> one particular IP block or chip, than defining bindings for a more
> generic thing like "HDMI connector". But, in the end, I believe they
> both should go through similar review, and there's no such difference.
Unless you need to describe different types of HDMI connectors, I
don't see any issue with it being generic. I certainly don't see the
need for prepending with "linux," in this case.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-10 20:32 ` Rob Herring
0 siblings, 0 replies; 207+ messages in thread
From: Rob Herring @ 2014-03-10 20:32 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Russell King - ARM Linux,
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
On Mon, Mar 10, 2014 at 11:40 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Rob,
>
> On 10/03/14 18:05, Rob Herring wrote:
>
>>> Russell's point was that these connector bindings are very generic, i.e.
>>> they are not for any particular chip from a particular vendor, but for
>>> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
>>> shouldn't define such generic bindings without consulting the whole
>>> device-tree community (i.e including non-linux users).
>>
>> So re-work it to be generic and send it out. DT maintainers would
>> rarely disagree that something shouldn't be made generic.
>
> They (in this series) are already designed to be generic.
>
> I should perhaps re-word the question: we are concerned whether these
> bindings are good for all the users, not just us, and whether there
> already exists something that overlaps.
Given this is tied into the rest of video description with endpoints
and such, you really have to look at the whole picture to answer that
question. I'd guess Linux well ahead of other OSs in terms of dealing
with the plethora of video and graphics h/w. I'd be more concerned
that the bindings are good for all h/w rather than all OS's.
> Afaik, there's nothing overlapping. And I don't see why they wouldn't be
> good for all users (with the few minor modifications that have been
> discussed in this thread). But, if I gathered right, Russell would like
> some kind of ack from someone who might know better than us.
>
> So is it enough to have posted these, and gotten acks from the people
> involved, or should we get acks from DT maintainers also?
We really leave it up to the subsystem maintainers to decide, but for
new common/generic bindings it is a good idea to get DT maintainers
ack. I'll go thru the individual patches.
> Is there a way to get the attention of, say, BSD people, or should we
> just presume they'll follow the list?
devicetree-spec was created specifically to have a lower volume list
without a bunch of Linux driver patches which aren't relevant to
people from other OSs.
>>> So the question is, is there such a community and a forum to bring up
>>> this kind of things? If yes, should we bring this up there? If yes, what
>>> kind of things in general should be brought into the attention of
>>> non-linux users?
>>
>> devicetree list is just that. It is not just for Linux. There is the
>> newly created devicetree-spec@vger.kernel.org which is for more
>> core/common binding discussion.
>
> Ok.
>
>>> What I wonder here is that while a thing like DVI connector is, of
>>> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
>>> case still the same: we're defining global bindings for hardware that
>>> should work for everyone, not only Linux users?
>>
>> Defining the connectors in DT is a useful thing although mainly when
>> you have multiple connectors of the same type. Labels for composite,
>> SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or
>> printed label (like front vs. rear connections) seem more useful to
>> me.
>
> My point above was that it feels mentally easier to define bindings for
> one particular IP block or chip, than defining bindings for a more
> generic thing like "HDMI connector". But, in the end, I believe they
> both should go through similar review, and there's no such difference.
Unless you need to describe different types of HDMI connectors, I
don't see any issue with it being generic. I certainly don't see the
need for prepending with "linux," in this case.
Rob
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-10 20:32 ` Rob Herring
0 siblings, 0 replies; 207+ messages in thread
From: Rob Herring @ 2014-03-10 20:32 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 10, 2014 at 11:40 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Rob,
>
> On 10/03/14 18:05, Rob Herring wrote:
>
>>> Russell's point was that these connector bindings are very generic, i.e.
>>> they are not for any particular chip from a particular vendor, but for
>>> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
>>> shouldn't define such generic bindings without consulting the whole
>>> device-tree community (i.e including non-linux users).
>>
>> So re-work it to be generic and send it out. DT maintainers would
>> rarely disagree that something shouldn't be made generic.
>
> They (in this series) are already designed to be generic.
>
> I should perhaps re-word the question: we are concerned whether these
> bindings are good for all the users, not just us, and whether there
> already exists something that overlaps.
Given this is tied into the rest of video description with endpoints
and such, you really have to look at the whole picture to answer that
question. I'd guess Linux well ahead of other OSs in terms of dealing
with the plethora of video and graphics h/w. I'd be more concerned
that the bindings are good for all h/w rather than all OS's.
> Afaik, there's nothing overlapping. And I don't see why they wouldn't be
> good for all users (with the few minor modifications that have been
> discussed in this thread). But, if I gathered right, Russell would like
> some kind of ack from someone who might know better than us.
>
> So is it enough to have posted these, and gotten acks from the people
> involved, or should we get acks from DT maintainers also?
We really leave it up to the subsystem maintainers to decide, but for
new common/generic bindings it is a good idea to get DT maintainers
ack. I'll go thru the individual patches.
> Is there a way to get the attention of, say, BSD people, or should we
> just presume they'll follow the list?
devicetree-spec was created specifically to have a lower volume list
without a bunch of Linux driver patches which aren't relevant to
people from other OSs.
>>> So the question is, is there such a community and a forum to bring up
>>> this kind of things? If yes, should we bring this up there? If yes, what
>>> kind of things in general should be brought into the attention of
>>> non-linux users?
>>
>> devicetree list is just that. It is not just for Linux. There is the
>> newly created devicetree-spec at vger.kernel.org which is for more
>> core/common binding discussion.
>
> Ok.
>
>>> What I wonder here is that while a thing like DVI connector is, of
>>> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
>>> case still the same: we're defining global bindings for hardware that
>>> should work for everyone, not only Linux users?
>>
>> Defining the connectors in DT is a useful thing although mainly when
>> you have multiple connectors of the same type. Labels for composite,
>> SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or
>> printed label (like front vs. rear connections) seem more useful to
>> me.
>
> My point above was that it feels mentally easier to define bindings for
> one particular IP block or chip, than defining bindings for a more
> generic thing like "HDMI connector". But, in the end, I believe they
> both should go through similar review, and there's no such difference.
Unless you need to describe different types of HDMI connectors, I
don't see any issue with it being generic. I certainly don't see the
need for prepending with "linux," in this case.
Rob
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
[not found] ` <1393604717.3802.61.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
2014-03-10 21:45 ` Rob Herring
@ 2014-03-10 21:45 ` Rob Herring
0 siblings, 0 replies; 207+ messages in thread
From: Rob Herring @ 2014-03-10 21:45 UTC (permalink / raw)
To: Philipp Zabel
Cc: Russell King - ARM Linux, 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
On Fri, Feb 28, 2014 at 10:25 AM, Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> 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-l0cyMroinI0@public.gmane.org>
>> > Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
>> > ---
>> > .../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.
I like this proposal over the others. Although, would dual link be a
single endpoint or 2 endpoints? How would you differentiate that?
The port node seems a bit pointless.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-10 21:45 ` Rob Herring
0 siblings, 0 replies; 207+ messages in thread
From: Rob Herring @ 2014-03-10 21:45 UTC (permalink / raw)
To: Philipp Zabel
Cc: Russell King - ARM Linux, 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
On Fri, Feb 28, 2014 at 10:25 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> 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.
I like this proposal over the others. Although, would dual link be a
single endpoint or 2 endpoints? How would you differentiate that?
The port node seems a bit pointless.
Rob
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-10 21:45 ` Rob Herring
0 siblings, 0 replies; 207+ messages in thread
From: Rob Herring @ 2014-03-10 21:45 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 28, 2014 at 10:25 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> 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 at 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 at 2 {
> ipu_di0_disp0: endpoint {
> remote-endpoint = <&sii902x_in>;
> };
> };
> port at 3 {
> ipu_di1_tve: endpoint {
> remote-endpoint = <&tve_in>;
> };
> };
> };
>
> &sii902x {
> compatible = "si,sii9022";
>
> port at 0 {
> sii902x_in: endpoint {
> remote-endpoint = <&ipu_di0>;
> };
> };
> port at 1 {
> sii902x_out: endpoint {
> remote-endpoint = <&dvi_d_in>;
> };
> };
> };
>
> &tve {
> compatible = "fsl,imx53-tve";
> port at 0 {
> tve_in: endpoint {
> remote-endpoint = <&ipu_di1>;
> };
> };
> port at 1 {
> tve_out: endpoint {
> remote-endpoint = <&dvi_a_in>;
> };
> };
> };
>
> dvi-connector {
> compatible = "dvi-connector";
> ddc-i2c-bus = <&i2c3>;
>
> port {
> dvi_d_in: endpoint at 0 {
> remote-endpoint = <&sii902x_out>;
> };
> dvi_a_in: endpoint at 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.
I like this proposal over the others. Although, would dual link be a
single endpoint or 2 endpoints? How would you differentiate that?
The port node seems a bit pointless.
Rob
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
2014-03-10 21:45 ` Rob Herring
(?)
@ 2014-03-11 6:39 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-11 6:39 UTC (permalink / raw)
To: Rob Herring, Philipp Zabel
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 1038 bytes --]
On 10/03/14 23:45, Rob Herring wrote:
> I like this proposal over the others. Although, would dual link be a
I don't like inferring the information. With the above, you can't find
out that the DVI connector has digital and analog support before all the
drivers are loaded.
> single endpoint or 2 endpoints? How would you differentiate that?
Hmm, well endpoints for a single port are exclusive. So it's either a
single port and a single endpoint, or two ports and two endpoints. I
think dual link has to be single port & endpoint, as the TMDS links need
to be driven together as a single bus.
And dual-link is not really "two links". DVI dual-link means 1 clock
lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
single-link.
> The port node seems a bit pointless.
There's another thread discussing the ports and endpoints.
The port node represents, for example, the pins for the connection for
that device. And an endpoint-endpoint link represents wires between two
ports.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-11 6:39 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-11 6:39 UTC (permalink / raw)
To: Rob Herring, Philipp Zabel
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]
On 10/03/14 23:45, Rob Herring wrote:
> I like this proposal over the others. Although, would dual link be a
I don't like inferring the information. With the above, you can't find
out that the DVI connector has digital and analog support before all the
drivers are loaded.
> single endpoint or 2 endpoints? How would you differentiate that?
Hmm, well endpoints for a single port are exclusive. So it's either a
single port and a single endpoint, or two ports and two endpoints. I
think dual link has to be single port & endpoint, as the TMDS links need
to be driven together as a single bus.
And dual-link is not really "two links". DVI dual-link means 1 clock
lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
single-link.
> The port node seems a bit pointless.
There's another thread discussing the ports and endpoints.
The port node represents, for example, the pins for the connection for
that device. And an endpoint-endpoint link represents wires between two
ports.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-11 6:39 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-11 6:39 UTC (permalink / raw)
To: linux-arm-kernel
On 10/03/14 23:45, Rob Herring wrote:
> I like this proposal over the others. Although, would dual link be a
I don't like inferring the information. With the above, you can't find
out that the DVI connector has digital and analog support before all the
drivers are loaded.
> single endpoint or 2 endpoints? How would you differentiate that?
Hmm, well endpoints for a single port are exclusive. So it's either a
single port and a single endpoint, or two ports and two endpoints. I
think dual link has to be single port & endpoint, as the TMDS links need
to be driven together as a single bus.
And dual-link is not really "two links". DVI dual-link means 1 clock
lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
single-link.
> The port node seems a bit pointless.
There's another thread discussing the ports and endpoints.
The port node represents, for example, the pins for the connection for
that device. And an endpoint-endpoint link represents wires between two
ports.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140311/a7245985/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
2014-02-28 16:25 ` Philipp Zabel
(?)
@ 2014-03-11 6:43 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-11 6:43 UTC (permalink / raw)
To: Philipp Zabel
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 887 bytes --]
On 28/02/14 18:25, Philipp Zabel wrote:
> 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.
I have not worked with boards that would have the analog part, so just
wondering about the above.
The above would mean that either digital or analog is in use, but not
both. Was that the intention? From the connector's perspective, the
analog and digital pins are separate, and I think they can be used at
the same time. That kind of sounds like the analog and digital pins
should be represented as separate ports.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-11 6:43 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-11 6:43 UTC (permalink / raw)
To: Philipp Zabel
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
On 28/02/14 18:25, Philipp Zabel wrote:
> 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.
I have not worked with boards that would have the analog part, so just
wondering about the above.
The above would mean that either digital or analog is in use, but not
both. Was that the intention? From the connector's perspective, the
analog and digital pins are separate, and I think they can be used at
the same time. That kind of sounds like the analog and digital pins
should be represented as separate ports.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-11 6:43 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-11 6:43 UTC (permalink / raw)
To: linux-arm-kernel
On 28/02/14 18:25, Philipp Zabel wrote:
> dvi-connector {
> compatible = "dvi-connector";
> ddc-i2c-bus = <&i2c3>;
>
> port {
> dvi_d_in: endpoint at 0 {
> remote-endpoint = <&sii902x_out>;
> };
> dvi_a_in: endpoint at 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.
I have not worked with boards that would have the analog part, so just
wondering about the above.
The above would mean that either digital or analog is in use, but not
both. Was that the intention? From the connector's perspective, the
analog and digital pins are separate, and I think they can be used at
the same time. That kind of sounds like the analog and digital pins
should be represented as separate ports.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140311/22de5d0b/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
2014-03-11 6:39 ` Tomi Valkeinen
(?)
@ 2014-03-11 8:00 ` Geert Uytterhoeven
-1 siblings, 0 replies; 207+ messages in thread
From: Geert Uytterhoeven @ 2014-03-11 8:00 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, Linux Fbdev development list,
Russell King - ARM Linux, DRI Development, Andrzej Hajda,
Rob Herring, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
On Tue, Mar 11, 2014 at 7:39 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 10/03/14 23:45, Rob Herring wrote:
>> I like this proposal over the others. Although, would dual link be a
>
> I don't like inferring the information. With the above, you can't find
> out that the DVI connector has digital and analog support before all the
> drivers are loaded.
>
>> single endpoint or 2 endpoints? How would you differentiate that?
>
> Hmm, well endpoints for a single port are exclusive. So it's either a
> single port and a single endpoint, or two ports and two endpoints. I
> think dual link has to be single port & endpoint, as the TMDS links need
> to be driven together as a single bus.
>
> And dual-link is not really "two links". DVI dual-link means 1 clock
> lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
> single-link.
What about having a property for the number of data lanes?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-11 8:00 ` Geert Uytterhoeven
0 siblings, 0 replies; 207+ messages in thread
From: Geert Uytterhoeven @ 2014-03-11 8:00 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, Linux Fbdev development list,
Russell King - ARM Linux, DRI Development, Andrzej Hajda,
Rob Herring, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
On Tue, Mar 11, 2014 at 7:39 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 10/03/14 23:45, Rob Herring wrote:
>> I like this proposal over the others. Although, would dual link be a
>
> I don't like inferring the information. With the above, you can't find
> out that the DVI connector has digital and analog support before all the
> drivers are loaded.
>
>> single endpoint or 2 endpoints? How would you differentiate that?
>
> Hmm, well endpoints for a single port are exclusive. So it's either a
> single port and a single endpoint, or two ports and two endpoints. I
> think dual link has to be single port & endpoint, as the TMDS links need
> to be driven together as a single bus.
>
> And dual-link is not really "two links". DVI dual-link means 1 clock
> lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
> single-link.
What about having a property for the number of data lanes?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-11 8:00 ` Geert Uytterhoeven
0 siblings, 0 replies; 207+ messages in thread
From: Geert Uytterhoeven @ 2014-03-11 8:00 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 11, 2014 at 7:39 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 10/03/14 23:45, Rob Herring wrote:
>> I like this proposal over the others. Although, would dual link be a
>
> I don't like inferring the information. With the above, you can't find
> out that the DVI connector has digital and analog support before all the
> drivers are loaded.
>
>> single endpoint or 2 endpoints? How would you differentiate that?
>
> Hmm, well endpoints for a single port are exclusive. So it's either a
> single port and a single endpoint, or two ports and two endpoints. I
> think dual link has to be single port & endpoint, as the TMDS links need
> to be driven together as a single bus.
>
> And dual-link is not really "two links". DVI dual-link means 1 clock
> lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
> single-link.
What about having a property for the number of data lanes?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
2014-03-11 8:00 ` Geert Uytterhoeven
(?)
@ 2014-03-11 8:04 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-11 8:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: devicetree, Linux Fbdev development list,
Russell King - ARM Linux, Sascha Hauer, Tomasz Figa,
DRI Development, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, Philipp Zabel,
linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 1277 bytes --]
On 11/03/14 10:00, Geert Uytterhoeven wrote:
> On Tue, Mar 11, 2014 at 7:39 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 10/03/14 23:45, Rob Herring wrote:
>>> I like this proposal over the others. Although, would dual link be a
>>
>> I don't like inferring the information. With the above, you can't find
>> out that the DVI connector has digital and analog support before all the
>> drivers are loaded.
>>
>>> single endpoint or 2 endpoints? How would you differentiate that?
>>
>> Hmm, well endpoints for a single port are exclusive. So it's either a
>> single port and a single endpoint, or two ports and two endpoints. I
>> think dual link has to be single port & endpoint, as the TMDS links need
>> to be driven together as a single bus.
>>
>> And dual-link is not really "two links". DVI dual-link means 1 clock
>> lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
>> single-link.
>
> What about having a property for the number of data lanes?
That was already suggested by Philipp in this thread. I don't see
anything wrong with that, but I don't really see benefit either.
"dual-link" is a standard term for 6 data lanes for the DVI connector.
And the choices are 3 or 6 data lanes, nothing else.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-11 8:04 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-11 8:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: devicetree, Linux Fbdev development list,
Russell King - ARM Linux, Sascha Hauer, Tomasz Figa,
DRI Development, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, Philipp Zabel,
linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]
On 11/03/14 10:00, Geert Uytterhoeven wrote:
> On Tue, Mar 11, 2014 at 7:39 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 10/03/14 23:45, Rob Herring wrote:
>>> I like this proposal over the others. Although, would dual link be a
>>
>> I don't like inferring the information. With the above, you can't find
>> out that the DVI connector has digital and analog support before all the
>> drivers are loaded.
>>
>>> single endpoint or 2 endpoints? How would you differentiate that?
>>
>> Hmm, well endpoints for a single port are exclusive. So it's either a
>> single port and a single endpoint, or two ports and two endpoints. I
>> think dual link has to be single port & endpoint, as the TMDS links need
>> to be driven together as a single bus.
>>
>> And dual-link is not really "two links". DVI dual-link means 1 clock
>> lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
>> single-link.
>
> What about having a property for the number of data lanes?
That was already suggested by Philipp in this thread. I don't see
anything wrong with that, but I don't really see benefit either.
"dual-link" is a standard term for 6 data lanes for the DVI connector.
And the choices are 3 or 6 data lanes, nothing else.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-11 8:04 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-11 8:04 UTC (permalink / raw)
To: linux-arm-kernel
On 11/03/14 10:00, Geert Uytterhoeven wrote:
> On Tue, Mar 11, 2014 at 7:39 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 10/03/14 23:45, Rob Herring wrote:
>>> I like this proposal over the others. Although, would dual link be a
>>
>> I don't like inferring the information. With the above, you can't find
>> out that the DVI connector has digital and analog support before all the
>> drivers are loaded.
>>
>>> single endpoint or 2 endpoints? How would you differentiate that?
>>
>> Hmm, well endpoints for a single port are exclusive. So it's either a
>> single port and a single endpoint, or two ports and two endpoints. I
>> think dual link has to be single port & endpoint, as the TMDS links need
>> to be driven together as a single bus.
>>
>> And dual-link is not really "two links". DVI dual-link means 1 clock
>> lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
>> single-link.
>
> What about having a property for the number of data lanes?
That was already suggested by Philipp in this thread. I don't see
anything wrong with that, but I don't really see benefit either.
"dual-link" is a standard term for 6 data lanes for the DVI connector.
And the choices are 3 or 6 data lanes, nothing else.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140311/c86122b5/attachment-0001.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
2014-03-11 8:04 ` Tomi Valkeinen
(?)
@ 2014-03-11 11:19 ` Philipp Zabel
-1 siblings, 0 replies; 207+ messages in thread
From: Philipp Zabel @ 2014-03-11 11:19 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, Linux Fbdev development list,
Russell King - ARM Linux, DRI Development, Andrzej Hajda,
Rob Herring, Laurent Pinchart, Geert Uytterhoeven,
linux-arm-kernel, Sebastian Hesselbarth
Am Dienstag, den 11.03.2014, 10:04 +0200 schrieb Tomi Valkeinen:
> On 11/03/14 10:00, Geert Uytterhoeven wrote:
> > On Tue, Mar 11, 2014 at 7:39 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> On 10/03/14 23:45, Rob Herring wrote:
> >>> I like this proposal over the others. Although, would dual link be a
> >>
> >> I don't like inferring the information. With the above, you can't find
> >> out that the DVI connector has digital and analog support before all the
> >> drivers are loaded.
> >>
> >>> single endpoint or 2 endpoints? How would you differentiate that?
> >>
> >> Hmm, well endpoints for a single port are exclusive. So it's either a
> >> single port and a single endpoint, or two ports and two endpoints. I
> >> think dual link has to be single port & endpoint, as the TMDS links need
> >> to be driven together as a single bus.
> >>
> >> And dual-link is not really "two links". DVI dual-link means 1 clock
> >> lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
> >> single-link.
> >
> > What about having a property for the number of data lanes?
>
> That was already suggested by Philipp in this thread. I don't see
> anything wrong with that, but I don't really see benefit either.
> "dual-link" is a standard term for 6 data lanes for the DVI connector.
> And the choices are 3 or 6 data lanes, nothing else.
The number of lanes of a DisplayPort connector could be 1 to 4. Also,
there's dual-mode DP which can use four lanes to drive
somewhat-like-HDMI single link TMDS signals.
regards
Philipp
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-11 11:19 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
From: Philipp Zabel @ 2014-03-11 11:19 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, Linux Fbdev development list,
Russell King - ARM Linux, DRI Development, Andrzej Hajda,
Rob Herring, Laurent Pinchart, Geert Uytterhoeven,
linux-arm-kernel, Sebastian Hesselbarth
Am Dienstag, den 11.03.2014, 10:04 +0200 schrieb Tomi Valkeinen:
> On 11/03/14 10:00, Geert Uytterhoeven wrote:
> > On Tue, Mar 11, 2014 at 7:39 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> On 10/03/14 23:45, Rob Herring wrote:
> >>> I like this proposal over the others. Although, would dual link be a
> >>
> >> I don't like inferring the information. With the above, you can't find
> >> out that the DVI connector has digital and analog support before all the
> >> drivers are loaded.
> >>
> >>> single endpoint or 2 endpoints? How would you differentiate that?
> >>
> >> Hmm, well endpoints for a single port are exclusive. So it's either a
> >> single port and a single endpoint, or two ports and two endpoints. I
> >> think dual link has to be single port & endpoint, as the TMDS links need
> >> to be driven together as a single bus.
> >>
> >> And dual-link is not really "two links". DVI dual-link means 1 clock
> >> lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
> >> single-link.
> >
> > What about having a property for the number of data lanes?
>
> That was already suggested by Philipp in this thread. I don't see
> anything wrong with that, but I don't really see benefit either.
> "dual-link" is a standard term for 6 data lanes for the DVI connector.
> And the choices are 3 or 6 data lanes, nothing else.
The number of lanes of a DisplayPort connector could be 1 to 4. Also,
there's dual-mode DP which can use four lanes to drive
somewhat-like-HDMI single link TMDS signals.
regards
Philipp
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
@ 2014-03-11 11:19 ` Philipp Zabel
0 siblings, 0 replies; 207+ messages in thread
From: Philipp Zabel @ 2014-03-11 11:19 UTC (permalink / raw)
To: linux-arm-kernel
Am Dienstag, den 11.03.2014, 10:04 +0200 schrieb Tomi Valkeinen:
> On 11/03/14 10:00, Geert Uytterhoeven wrote:
> > On Tue, Mar 11, 2014 at 7:39 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> On 10/03/14 23:45, Rob Herring wrote:
> >>> I like this proposal over the others. Although, would dual link be a
> >>
> >> I don't like inferring the information. With the above, you can't find
> >> out that the DVI connector has digital and analog support before all the
> >> drivers are loaded.
> >>
> >>> single endpoint or 2 endpoints? How would you differentiate that?
> >>
> >> Hmm, well endpoints for a single port are exclusive. So it's either a
> >> single port and a single endpoint, or two ports and two endpoints. I
> >> think dual link has to be single port & endpoint, as the TMDS links need
> >> to be driven together as a single bus.
> >>
> >> And dual-link is not really "two links". DVI dual-link means 1 clock
> >> lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
> >> single-link.
> >
> > What about having a property for the number of data lanes?
>
> That was already suggested by Philipp in this thread. I don't see
> anything wrong with that, but I don't really see benefit either.
> "dual-link" is a standard term for 6 data lanes for the DVI connector.
> And the choices are 3 or 6 data lanes, nothing else.
The number of lanes of a DisplayPort connector could be 1 to 4. Also,
there's dual-mode DP which can use four lanes to drive
somewhat-like-HDMI single link TMDS signals.
regards
Philipp
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
[not found] ` <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 12:20 ` Tomi Valkeinen
@ 2014-03-12 8:15 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
` (9 subsequent siblings)
11 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-12 8:15 UTC (permalink / raw)
To: Grant Likely
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Philipp Zabel,
Laurent Pinchart, Russell King - ARM Linux, Sascha Hauer,
Sebastian Hesselbarth, Rob Clark, Inki Dae, Andrzej Hajda,
Tomasz Figa, Thierry Reding
[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]
Hi Grant,
On 28/02/14 14: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.
This series is a piece of bigger series, which brings DT support for
OMAP display subsystem. This uses the same V4L2 style ports/endpoints as
has been discussed recently regarding the series from Philipp. It
doesn't use the helper code from Philipp, but a custom one as Philipp's
code didn't exist when I made this, and also because I needed extra
functionality not present in Philipp's series (which aimed to just move
the current V4L2 code to a common place).
The main concerns with the ports/endpoints has been the optional 'port'
node for the case where we have a single endpoint, and the
double-linking of the endpoints.
If I remove the optional 'port' usage from my series, are you ok with me
proceeding with this series for 3.15, with the double-linked endpoints?
As far as I see, when we come to a conclusion how the linking should be
made, it's trivial to change the bindings in this series to match it,
even without needing any compatibility code. I just need to remove the
other link, and old dts files having double-linking will still work fine.
The reason I want to push this forward asap is that omap4 and omap5 are
already DT only, and for omap5 we don't have working display without DT
support for display. For omap4, we have a really hacky way to add
display support for a few boards, but that is causing major headaches
and I want to get rid of it.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-12 8:15 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-12 8:15 UTC (permalink / raw)
To: Grant Likely
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Philipp Zabel,
Laurent Pinchart, Russell King - ARM Linux, Sascha Hauer,
Sebastian Hesselbarth, Rob Clark, Inki Dae, Andrzej Hajda,
Tomasz Figa, Thierry Reding
[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]
Hi Grant,
On 28/02/14 14: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.
This series is a piece of bigger series, which brings DT support for
OMAP display subsystem. This uses the same V4L2 style ports/endpoints as
has been discussed recently regarding the series from Philipp. It
doesn't use the helper code from Philipp, but a custom one as Philipp's
code didn't exist when I made this, and also because I needed extra
functionality not present in Philipp's series (which aimed to just move
the current V4L2 code to a common place).
The main concerns with the ports/endpoints has been the optional 'port'
node for the case where we have a single endpoint, and the
double-linking of the endpoints.
If I remove the optional 'port' usage from my series, are you ok with me
proceeding with this series for 3.15, with the double-linked endpoints?
As far as I see, when we come to a conclusion how the linking should be
made, it's trivial to change the bindings in this series to match it,
even without needing any compatibility code. I just need to remove the
other link, and old dts files having double-linking will still work fine.
The reason I want to push this forward asap is that omap4 and omap5 are
already DT only, and for omap5 we don't have working display without DT
support for display. For omap4, we have a really hacky way to add
display support for a few boards, but that is causing major headaches
and I want to get rid of it.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-12 8:15 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-12 8:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Grant,
On 28/02/14 14: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.
This series is a piece of bigger series, which brings DT support for
OMAP display subsystem. This uses the same V4L2 style ports/endpoints as
has been discussed recently regarding the series from Philipp. It
doesn't use the helper code from Philipp, but a custom one as Philipp's
code didn't exist when I made this, and also because I needed extra
functionality not present in Philipp's series (which aimed to just move
the current V4L2 code to a common place).
The main concerns with the ports/endpoints has been the optional 'port'
node for the case where we have a single endpoint, and the
double-linking of the endpoints.
If I remove the optional 'port' usage from my series, are you ok with me
proceeding with this series for 3.15, with the double-linked endpoints?
As far as I see, when we come to a conclusion how the linking should be
made, it's trivial to change the bindings in this series to match it,
even without needing any compatibility code. I just need to remove the
other link, and old dts files having double-linking will still work fine.
The reason I want to push this forward asap is that omap4 and omap5 are
already DT only, and for omap5 we don't have working display without DT
support for display. For omap4, we have a really hacky way to add
display support for a few boards, but that is causing major headaches
and I want to get rid of it.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140312/f3b90cfd/attachment-0001.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
2014-03-12 8:15 ` Tomi Valkeinen
(?)
@ 2014-03-17 13:55 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-17 13:55 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, Philipp Zabel,
linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 2340 bytes --]
Hi Grant,
Ping.
Are you fine with me proceeding with the current V4L2 port/endpoint
bindings?
Tomi
On 12/03/14 10:15, Tomi Valkeinen wrote:
> Hi Grant,
>
> On 28/02/14 14: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.
>
> This series is a piece of bigger series, which brings DT support for
> OMAP display subsystem. This uses the same V4L2 style ports/endpoints as
> has been discussed recently regarding the series from Philipp. It
> doesn't use the helper code from Philipp, but a custom one as Philipp's
> code didn't exist when I made this, and also because I needed extra
> functionality not present in Philipp's series (which aimed to just move
> the current V4L2 code to a common place).
>
> The main concerns with the ports/endpoints has been the optional 'port'
> node for the case where we have a single endpoint, and the
> double-linking of the endpoints.
>
> If I remove the optional 'port' usage from my series, are you ok with me
> proceeding with this series for 3.15, with the double-linked endpoints?
>
> As far as I see, when we come to a conclusion how the linking should be
> made, it's trivial to change the bindings in this series to match it,
> even without needing any compatibility code. I just need to remove the
> other link, and old dts files having double-linking will still work fine.
>
> The reason I want to push this forward asap is that omap4 and omap5 are
> already DT only, and for omap5 we don't have working display without DT
> support for display. For omap4, we have a really hacky way to add
> display support for a few boards, but that is causing major headaches
> and I want to get rid of it.
>
> Tomi
>
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-17 13:55 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-17 13:55 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, Philipp Zabel,
linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]
Hi Grant,
Ping.
Are you fine with me proceeding with the current V4L2 port/endpoint
bindings?
Tomi
On 12/03/14 10:15, Tomi Valkeinen wrote:
> Hi Grant,
>
> On 28/02/14 14: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.
>
> This series is a piece of bigger series, which brings DT support for
> OMAP display subsystem. This uses the same V4L2 style ports/endpoints as
> has been discussed recently regarding the series from Philipp. It
> doesn't use the helper code from Philipp, but a custom one as Philipp's
> code didn't exist when I made this, and also because I needed extra
> functionality not present in Philipp's series (which aimed to just move
> the current V4L2 code to a common place).
>
> The main concerns with the ports/endpoints has been the optional 'port'
> node for the case where we have a single endpoint, and the
> double-linking of the endpoints.
>
> If I remove the optional 'port' usage from my series, are you ok with me
> proceeding with this series for 3.15, with the double-linked endpoints?
>
> As far as I see, when we come to a conclusion how the linking should be
> made, it's trivial to change the bindings in this series to match it,
> even without needing any compatibility code. I just need to remove the
> other link, and old dts files having double-linking will still work fine.
>
> The reason I want to push this forward asap is that omap4 and omap5 are
> already DT only, and for omap5 we don't have working display without DT
> support for display. For omap4, we have a really hacky way to add
> display support for a few boards, but that is causing major headaches
> and I want to get rid of it.
>
> Tomi
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-17 13:55 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-17 13:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi Grant,
Ping.
Are you fine with me proceeding with the current V4L2 port/endpoint
bindings?
Tomi
On 12/03/14 10:15, Tomi Valkeinen wrote:
> Hi Grant,
>
> On 28/02/14 14: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.
>
> This series is a piece of bigger series, which brings DT support for
> OMAP display subsystem. This uses the same V4L2 style ports/endpoints as
> has been discussed recently regarding the series from Philipp. It
> doesn't use the helper code from Philipp, but a custom one as Philipp's
> code didn't exist when I made this, and also because I needed extra
> functionality not present in Philipp's series (which aimed to just move
> the current V4L2 code to a common place).
>
> The main concerns with the ports/endpoints has been the optional 'port'
> node for the case where we have a single endpoint, and the
> double-linking of the endpoints.
>
> If I remove the optional 'port' usage from my series, are you ok with me
> proceeding with this series for 3.15, with the double-linked endpoints?
>
> As far as I see, when we come to a conclusion how the linking should be
> made, it's trivial to change the bindings in this series to match it,
> even without needing any compatibility code. I just need to remove the
> other link, and old dts files having double-linking will still work fine.
>
> The reason I want to push this forward asap is that omap4 and omap5 are
> already DT only, and for omap5 we don't have working display without DT
> support for display. For omap4, we have a really hacky way to add
> display support for a few boards, but that is causing major headaches
> and I want to get rid of it.
>
> Tomi
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140317/4a5eb300/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
2014-02-28 12:20 ` Tomi Valkeinen
(?)
@ 2014-03-17 14:19 ` Laurent Pinchart
-1 siblings, 0 replies; 207+ messages in thread
From: Laurent Pinchart @ 2014-03-17 14:19 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, dri-devel,
Andrzej Hajda, linux-arm-kernel, Sebastian Hesselbarth
Hi Tomi,
Thank you for the patch.
On Friday 28 February 2014 14:20:12 Tomi Valkeinen wrote:
> 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
While integrated in the panel module, the backlight is a separate piece of
hardware, which could be controlled through other means (I2C for instance).
Wouldn't it be better to add an explicit DT node for the backlight device and
reference that node from the panel node ?
> +
> +Required nodes:
> +- "panel-timing" containing video timings
> + (Documentation/devicetree/bindings/video/display-timing.txt)
> +- Video port for DPI input
> +
> +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,
Laurent Pinchart
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
@ 2014-03-17 14:19 ` Laurent Pinchart
0 siblings, 0 replies; 207+ messages in thread
From: Laurent Pinchart @ 2014-03-17 14:19 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, dri-devel,
Andrzej Hajda, linux-arm-kernel, Sebastian Hesselbarth
Hi Tomi,
Thank you for the patch.
On Friday 28 February 2014 14:20:12 Tomi Valkeinen wrote:
> 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
While integrated in the panel module, the backlight is a separate piece of
hardware, which could be controlled through other means (I2C for instance).
Wouldn't it be better to add an explicit DT node for the backlight device and
reference that node from the panel node ?
> +
> +Required nodes:
> +- "panel-timing" containing video timings
> + (Documentation/devicetree/bindings/video/display-timing.txt)
> +- Video port for DPI input
> +
> +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,
Laurent Pinchart
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
@ 2014-03-17 14:19 ` Laurent Pinchart
0 siblings, 0 replies; 207+ messages in thread
From: Laurent Pinchart @ 2014-03-17 14:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomi,
Thank you for the patch.
On Friday 28 February 2014 14:20:12 Tomi Valkeinen wrote:
> 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
While integrated in the panel module, the backlight is a separate piece of
hardware, which could be controlled through other means (I2C for instance).
Wouldn't it be better to add an explicit DT node for the backlight device and
reference that node from the panel node ?
> +
> +Required nodes:
> +- "panel-timing" containing video timings
> + (Documentation/devicetree/bindings/video/display-timing.txt)
> +- Video port for DPI input
> +
> +Example
> +-------
> +
> +lcd0: display at 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,
Laurent Pinchart
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
2014-02-28 12:20 ` Tomi Valkeinen
(?)
@ 2014-03-17 14:22 ` Laurent Pinchart
-1 siblings, 0 replies; 207+ messages in thread
From: Laurent Pinchart @ 2014-03-17 14:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, dri-devel,
Andrzej Hajda, linux-arm-kernel, Sebastian Hesselbarth
Hi Tomi,
Thank you for the patch.
On Friday 28 February 2014 14:20:13 Tomi Valkeinen wrote:
> 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 */
If the panel uses a TE GPIO but no reset GPIO, do you plan to express this
with a "hole" for the reset GPIO ? e.g. something like
gpios = <0>, <&gpio4 6 GPIO_ACTIVE_HIGH>;
Wouldn't it be better to split the gpios property into "reset-gpios" and "te-
gpios" ?
> +
> + lcd0_in: endpoint {
> + remote-endpoint = <&dsi1_out_ep>;
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
@ 2014-03-17 14:22 ` Laurent Pinchart
0 siblings, 0 replies; 207+ messages in thread
From: Laurent Pinchart @ 2014-03-17 14:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, dri-devel,
Andrzej Hajda, linux-arm-kernel, Sebastian Hesselbarth
Hi Tomi,
Thank you for the patch.
On Friday 28 February 2014 14:20:13 Tomi Valkeinen wrote:
> 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 */
If the panel uses a TE GPIO but no reset GPIO, do you plan to express this
with a "hole" for the reset GPIO ? e.g. something like
gpios = <0>, <&gpio4 6 GPIO_ACTIVE_HIGH>;
Wouldn't it be better to split the gpios property into "reset-gpios" and "te-
gpios" ?
> +
> + lcd0_in: endpoint {
> + remote-endpoint = <&dsi1_out_ep>;
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
@ 2014-03-17 14:22 ` Laurent Pinchart
0 siblings, 0 replies; 207+ messages in thread
From: Laurent Pinchart @ 2014-03-17 14:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomi,
Thank you for the patch.
On Friday 28 February 2014 14:20:13 Tomi Valkeinen wrote:
> 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 */
If the panel uses a TE GPIO but no reset GPIO, do you plan to express this
with a "hole" for the reset GPIO ? e.g. something like
gpios = <0>, <&gpio4 6 GPIO_ACTIVE_HIGH>;
Wouldn't it be better to split the gpios property into "reset-gpios" and "te-
gpios" ?
> +
> + lcd0_in: endpoint {
> + remote-endpoint = <&dsi1_out_ep>;
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
2014-03-17 14:22 ` Laurent Pinchart
(?)
@ 2014-03-18 6:33 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-18 6:33 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 885 bytes --]
On 17/03/14 16:22, Laurent Pinchart wrote:
>> +Example
>> +-------
>> +
>> +lcd0: display {
>> + compatible = "tpo,taal", "panel-dsi-cm";
>> + label = "lcd0";
>> +
>> + gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */
>
> If the panel uses a TE GPIO but no reset GPIO, do you plan to express this
> with a "hole" for the reset GPIO ? e.g. something like
>
> gpios = <0>, <&gpio4 6 GPIO_ACTIVE_HIGH>;
Yes.
> Wouldn't it be better to split the gpios property into "reset-gpios" and "te-
> gpios" ?
Yes, I can change it. I don't have a strong preference.
I've gotten similar comments for other bindings also, so I guess the
preferred way is to use named "-gpios" properties for everything except
the case where you really have multiple gpios with the same purpose?
The gpio binding documentation doesn't give much guidance on this.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
@ 2014-03-18 6:33 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-18 6:33 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 885 bytes --]
On 17/03/14 16:22, Laurent Pinchart wrote:
>> +Example
>> +-------
>> +
>> +lcd0: display {
>> + compatible = "tpo,taal", "panel-dsi-cm";
>> + label = "lcd0";
>> +
>> + gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */
>
> If the panel uses a TE GPIO but no reset GPIO, do you plan to express this
> with a "hole" for the reset GPIO ? e.g. something like
>
> gpios = <0>, <&gpio4 6 GPIO_ACTIVE_HIGH>;
Yes.
> Wouldn't it be better to split the gpios property into "reset-gpios" and "te-
> gpios" ?
Yes, I can change it. I don't have a strong preference.
I've gotten similar comments for other bindings also, so I guess the
preferred way is to use named "-gpios" properties for everything except
the case where you really have multiple gpios with the same purpose?
The gpio binding documentation doesn't give much guidance on this.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
@ 2014-03-18 6:33 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-18 6:33 UTC (permalink / raw)
To: linux-arm-kernel
On 17/03/14 16:22, Laurent Pinchart wrote:
>> +Example
>> +-------
>> +
>> +lcd0: display {
>> + compatible = "tpo,taal", "panel-dsi-cm";
>> + label = "lcd0";
>> +
>> + gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */
>
> If the panel uses a TE GPIO but no reset GPIO, do you plan to express this
> with a "hole" for the reset GPIO ? e.g. something like
>
> gpios = <0>, <&gpio4 6 GPIO_ACTIVE_HIGH>;
Yes.
> Wouldn't it be better to split the gpios property into "reset-gpios" and "te-
> gpios" ?
Yes, I can change it. I don't have a strong preference.
I've gotten similar comments for other bindings also, so I guess the
preferred way is to use named "-gpios" properties for everything except
the case where you really have multiple gpios with the same purpose?
The gpio binding documentation doesn't give much guidance on this.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140318/d3f51e70/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
2014-03-17 14:19 ` Laurent Pinchart
(?)
@ 2014-03-18 6:41 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-18 6:41 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 762 bytes --]
On 17/03/14 16:19, Laurent Pinchart wrote:
>> +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
>
> While integrated in the panel module, the backlight is a separate piece of
> hardware, which could be controlled through other means (I2C for instance).
> Wouldn't it be better to add an explicit DT node for the backlight device and
> reference that node from the panel node ?
Yes, I agree, but do we have the infrastructure or bindings for that?
Ah, I see we now do have a gpio-backlight driver, but it doesn't have DT
bindings.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
@ 2014-03-18 6:41 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-18 6:41 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
On 17/03/14 16:19, Laurent Pinchart wrote:
>> +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
>
> While integrated in the panel module, the backlight is a separate piece of
> hardware, which could be controlled through other means (I2C for instance).
> Wouldn't it be better to add an explicit DT node for the backlight device and
> reference that node from the panel node ?
Yes, I agree, but do we have the infrastructure or bindings for that?
Ah, I see we now do have a gpio-backlight driver, but it doesn't have DT
bindings.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
@ 2014-03-18 6:41 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-18 6:41 UTC (permalink / raw)
To: linux-arm-kernel
On 17/03/14 16:19, Laurent Pinchart wrote:
>> +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
>
> While integrated in the panel module, the backlight is a separate piece of
> hardware, which could be controlled through other means (I2C for instance).
> Wouldn't it be better to add an explicit DT node for the backlight device and
> reference that node from the panel node ?
Yes, I agree, but do we have the infrastructure or bindings for that?
Ah, I see we now do have a gpio-backlight driver, but it doesn't have DT
bindings.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140318/85ddaef8/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
2014-03-18 6:41 ` Tomi Valkeinen
(?)
@ 2014-03-18 7:06 ` Tomi Valkeinen
-1 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-18 7:06 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 1174 bytes --]
On 18/03/14 08:41, Tomi Valkeinen wrote:
> On 17/03/14 16:19, Laurent Pinchart wrote:
>
>>> +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
>>
>> While integrated in the panel module, the backlight is a separate piece of
>> hardware, which could be controlled through other means (I2C for instance).
>> Wouldn't it be better to add an explicit DT node for the backlight device and
>> reference that node from the panel node ?
>
> Yes, I agree, but do we have the infrastructure or bindings for that?
>
> Ah, I see we now do have a gpio-backlight driver, but it doesn't have DT
> bindings.
Seems there's a patch from Denis Carikli for this, which will probably
be merged for 3.15.
I realized I don't actually use panel-dpi at the moment in my OMAP DSS
DT series, as I dropped the board changes that used panel-dpi. So I'll
drop panel-dpi bindings from my series, and the backlight for panel-dpi
can then be fixed for 3.16.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
@ 2014-03-18 7:06 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-18 7:06 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]
On 18/03/14 08:41, Tomi Valkeinen wrote:
> On 17/03/14 16:19, Laurent Pinchart wrote:
>
>>> +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
>>
>> While integrated in the panel module, the backlight is a separate piece of
>> hardware, which could be controlled through other means (I2C for instance).
>> Wouldn't it be better to add an explicit DT node for the backlight device and
>> reference that node from the panel node ?
>
> Yes, I agree, but do we have the infrastructure or bindings for that?
>
> Ah, I see we now do have a gpio-backlight driver, but it doesn't have DT
> bindings.
Seems there's a patch from Denis Carikli for this, which will probably
be merged for 3.15.
I realized I don't actually use panel-dpi at the moment in my OMAP DSS
DT series, as I dropped the board changes that used panel-dpi. So I'll
drop panel-dpi bindings from my series, and the backlight for panel-dpi
can then be fixed for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
@ 2014-03-18 7:06 ` Tomi Valkeinen
0 siblings, 0 replies; 207+ messages in thread
From: Tomi Valkeinen @ 2014-03-18 7:06 UTC (permalink / raw)
To: linux-arm-kernel
On 18/03/14 08:41, Tomi Valkeinen wrote:
> On 17/03/14 16:19, Laurent Pinchart wrote:
>
>>> +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
>>
>> While integrated in the panel module, the backlight is a separate piece of
>> hardware, which could be controlled through other means (I2C for instance).
>> Wouldn't it be better to add an explicit DT node for the backlight device and
>> reference that node from the panel node ?
>
> Yes, I agree, but do we have the infrastructure or bindings for that?
>
> Ah, I see we now do have a gpio-backlight driver, but it doesn't have DT
> bindings.
Seems there's a patch from Denis Carikli for this, which will probably
be merged for 3.15.
I realized I don't actually use panel-dpi at the moment in my OMAP DSS
DT series, as I dropped the board changes that used panel-dpi. So I'll
drop panel-dpi bindings from my series, and the backlight for panel-dpi
can then be fixed for 3.16.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140318/ed0d92a9/attachment-0001.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
2014-03-18 6:33 ` Tomi Valkeinen
(?)
@ 2014-03-18 12:43 ` Laurent Pinchart
-1 siblings, 0 replies; 207+ messages in thread
From: Laurent Pinchart @ 2014-03-18 12:43 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, dri-devel,
Andrzej Hajda, linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1.1: Type: text/plain, Size: 1060 bytes --]
Hi Tomi,
On Tuesday 18 March 2014 08:33:55 Tomi Valkeinen wrote:
> On 17/03/14 16:22, Laurent Pinchart wrote:
> >> +Example
> >> +-------
> >> +
> >> +lcd0: display {
> >> + compatible = "tpo,taal", "panel-dsi-cm";
> >> + label = "lcd0";
> >> +
> >> + gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */
> >
> > If the panel uses a TE GPIO but no reset GPIO, do you plan to express this
> > with a "hole" for the reset GPIO ? e.g. something like
> >
> > gpios = <0>, <&gpio4 6 GPIO_ACTIVE_HIGH>;
>
> Yes.
>
> > Wouldn't it be better to split the gpios property into "reset-gpios" and
> > "te- gpios" ?
>
> Yes, I can change it. I don't have a strong preference.
>
> I've gotten similar comments for other bindings also, so I guess the
> preferred way is to use named "-gpios" properties for everything except
> the case where you really have multiple gpios with the same purpose?
That's my understanding, yes.
> The gpio binding documentation doesn't give much guidance on this.
--
Regards,
Laurent Pinchart
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
@ 2014-03-18 12:43 ` Laurent Pinchart
0 siblings, 0 replies; 207+ messages in thread
From: Laurent Pinchart @ 2014-03-18 12:43 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, dri-devel,
Andrzej Hajda, linux-arm-kernel, Sebastian Hesselbarth
[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]
Hi Tomi,
On Tuesday 18 March 2014 08:33:55 Tomi Valkeinen wrote:
> On 17/03/14 16:22, Laurent Pinchart wrote:
> >> +Example
> >> +-------
> >> +
> >> +lcd0: display {
> >> + compatible = "tpo,taal", "panel-dsi-cm";
> >> + label = "lcd0";
> >> +
> >> + gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */
> >
> > If the panel uses a TE GPIO but no reset GPIO, do you plan to express this
> > with a "hole" for the reset GPIO ? e.g. something like
> >
> > gpios = <0>, <&gpio4 6 GPIO_ACTIVE_HIGH>;
>
> Yes.
>
> > Wouldn't it be better to split the gpios property into "reset-gpios" and
> > "te- gpios" ?
>
> Yes, I can change it. I don't have a strong preference.
>
> I've gotten similar comments for other bindings also, so I guess the
> preferred way is to use named "-gpios" properties for everything except
> the case where you really have multiple gpios with the same purpose?
That's my understanding, yes.
> The gpio binding documentation doesn't give much guidance on this.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
@ 2014-03-18 12:43 ` Laurent Pinchart
0 siblings, 0 replies; 207+ messages in thread
From: Laurent Pinchart @ 2014-03-18 12:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomi,
On Tuesday 18 March 2014 08:33:55 Tomi Valkeinen wrote:
> On 17/03/14 16:22, Laurent Pinchart wrote:
> >> +Example
> >> +-------
> >> +
> >> +lcd0: display {
> >> + compatible = "tpo,taal", "panel-dsi-cm";
> >> + label = "lcd0";
> >> +
> >> + gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */
> >
> > If the panel uses a TE GPIO but no reset GPIO, do you plan to express this
> > with a "hole" for the reset GPIO ? e.g. something like
> >
> > gpios = <0>, <&gpio4 6 GPIO_ACTIVE_HIGH>;
>
> Yes.
>
> > Wouldn't it be better to split the gpios property into "reset-gpios" and
> > "te- gpios" ?
>
> Yes, I can change it. I don't have a strong preference.
>
> I've gotten similar comments for other bindings also, so I guess the
> preferred way is to use named "-gpios" properties for everything except
> the case where you really have multiple gpios with the same purpose?
That's my understanding, yes.
> The gpio binding documentation doesn't give much guidance on this.
--
Regards,
Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140318/7f542994/attachment.sig>
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
[not found] ` <5326FECF.9070104-l0cyMroinI0@public.gmane.org>
2014-03-21 15:37 ` Grant Likely
@ 2014-03-21 15:37 ` Grant Likely
0 siblings, 0 replies; 207+ messages in thread
From: Grant Likely @ 2014-03-21 15:37 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Philipp Zabel,
Laurent Pinchart, Russell King - ARM Linux, Sascha Hauer,
Sebastian Hesselbarth, Rob Clark, Inki Dae, Andrzej Hajda,
Tomasz Figa, Thierry Reding
On Mon, 17 Mar 2014 15:55:27 +0200, Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org> wrote:
> Hi Grant,
>
> Ping.
>
> Are you fine with me proceeding with the current V4L2 port/endpoint
> bindings?
Sorry, this thread didn't make it past my email filters. Yes, go ahead.
g.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-21 15:37 ` Grant Likely
0 siblings, 0 replies; 207+ messages in thread
From: Grant Likely @ 2014-03-21 15:37 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Philipp Zabel,
Laurent Pinchart, Russell King - ARM Linux, Sascha Hauer,
Sebastian Hesselbarth, Rob Clark, Inki Dae, Andrzej Hajda,
Tomasz Figa, Thierry Reding
On Mon, 17 Mar 2014 15:55:27 +0200, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Grant,
>
> Ping.
>
> Are you fine with me proceeding with the current V4L2 port/endpoint
> bindings?
Sorry, this thread didn't make it past my email filters. Yes, go ahead.
g.
^ permalink raw reply [flat|nested] 207+ messages in thread
* [PATCH 0/9] Doc/DT: DT bindings for various display components
@ 2014-03-21 15:37 ` Grant Likely
0 siblings, 0 replies; 207+ messages in thread
From: Grant Likely @ 2014-03-21 15:37 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 17 Mar 2014 15:55:27 +0200, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Grant,
>
> Ping.
>
> Are you fine with me proceeding with the current V4L2 port/endpoint
> bindings?
Sorry, this thread didn't make it past my email filters. Yes, go ahead.
g.
^ permalink raw reply [flat|nested] 207+ messages in thread
end of thread, other threads:[~2014-03-21 15:37 UTC | newest]
Thread overview: 207+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-28 12:20 [PATCH 0/9] Doc/DT: DT bindings for various display components Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:37 ` Tomasz Figa
2014-02-28 12:37 ` Tomasz Figa
2014-02-28 12:37 ` Tomasz Figa
[not found] ` <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 12:20 ` [PATCH 1/9] Doc/DT: Add OMAP DSS DT Bindings Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` [PATCH 2/9] Doc/DT: Add DT binding documentation for Analog TV Connector Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 13:43 ` Philipp Zabel
2014-02-28 13:43 ` Philipp Zabel
2014-02-28 13:43 ` Philipp Zabel
2014-03-03 6:25 ` Tomi Valkeinen
2014-03-03 6:25 ` Tomi Valkeinen
2014-03-03 6:25 ` Tomi Valkeinen
[not found] ` <1393590016-9361-4-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 15:59 ` Russell King - ARM Linux
2014-02-28 15:59 ` Russell King - ARM Linux
2014-02-28 15:59 ` Russell King - ARM Linux
2014-02-28 16:12 ` Tomi Valkeinen
2014-02-28 16:12 ` Tomi Valkeinen
2014-02-28 16:12 ` Tomi Valkeinen
[not found] ` <5310B567.7040605-l0cyMroinI0@public.gmane.org>
2014-02-28 16:23 ` Russell King - ARM Linux
2014-02-28 16:23 ` Russell King - ARM Linux
2014-02-28 16:23 ` Russell King - ARM Linux
2014-03-03 6:42 ` Tomi Valkeinen
2014-03-03 6:42 ` Tomi Valkeinen
2014-03-03 6:42 ` Tomi Valkeinen
2014-03-04 12:54 ` Daniel Vetter
2014-03-04 12:54 ` Daniel Vetter
2014-03-04 12:54 ` Daniel Vetter
[not found] ` <20140228162327.GT21483-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-02-28 16:28 ` Warner Losh
2014-02-28 16:28 ` Warner Losh
2014-02-28 16:28 ` Warner Losh
2014-03-05 8:41 ` Tomi Valkeinen
2014-03-05 8:41 ` Tomi Valkeinen
2014-03-05 8:41 ` Tomi Valkeinen
2014-03-06 8:39 ` Geert Uytterhoeven
2014-03-06 8:39 ` Geert Uytterhoeven
2014-03-06 8:39 ` Geert Uytterhoeven
[not found] ` <CAMuHMdWVSfKrudBhE7FW-ZWBvMOLWjrQZvn1qZUfRt_H+P7A2w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-06 8:52 ` Tomi Valkeinen
2014-03-06 8:52 ` Tomi Valkeinen
2014-03-06 8:52 ` Tomi Valkeinen
2014-03-07 14:17 ` Philipp Zabel
2014-03-07 14:17 ` Philipp Zabel
2014-03-07 14:17 ` Philipp Zabel
2014-03-10 10:32 ` Tomi Valkeinen
2014-03-10 10:32 ` Tomi Valkeinen
2014-03-10 10:32 ` Tomi Valkeinen
2014-02-28 16:25 ` Sebastian Reichel
2014-02-28 16:25 ` Sebastian Reichel
2014-02-28 16:25 ` Sebastian Reichel
[not found] ` <20140228155937.GQ21483-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-02-28 16:25 ` Philipp Zabel
2014-02-28 16:25 ` Philipp Zabel
2014-02-28 16:25 ` Philipp Zabel
[not found] ` <1393604717.3802.61.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
2014-03-10 21:45 ` Rob Herring
2014-03-10 21:45 ` Rob Herring
2014-03-10 21:45 ` Rob Herring
2014-03-11 6:39 ` Tomi Valkeinen
2014-03-11 6:39 ` Tomi Valkeinen
2014-03-11 6:39 ` Tomi Valkeinen
2014-03-11 8:00 ` Geert Uytterhoeven
2014-03-11 8:00 ` Geert Uytterhoeven
2014-03-11 8:00 ` Geert Uytterhoeven
2014-03-11 8:04 ` Tomi Valkeinen
2014-03-11 8:04 ` Tomi Valkeinen
2014-03-11 8:04 ` Tomi Valkeinen
2014-03-11 11:19 ` Philipp Zabel
2014-03-11 11:19 ` Philipp Zabel
2014-03-11 11:19 ` Philipp Zabel
2014-03-11 6:43 ` Tomi Valkeinen
2014-03-11 6:43 ` Tomi Valkeinen
2014-03-11 6:43 ` Tomi Valkeinen
2014-02-28 12:20 ` [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 16:06 ` Russell King - ARM Linux
2014-02-28 16:06 ` Russell King - ARM Linux
2014-02-28 16:06 ` Russell King - ARM Linux
2014-02-28 16:15 ` Tomi Valkeinen
2014-02-28 16:15 ` Tomi Valkeinen
2014-02-28 16:15 ` Tomi Valkeinen
2014-02-28 16:34 ` Russell King - ARM Linux
2014-02-28 16:34 ` Russell King - ARM Linux
2014-03-01 18:58 ` Geert Uytterhoeven
2014-03-01 18:58 ` Geert Uytterhoeven
2014-03-01 18:58 ` Geert Uytterhoeven
2014-03-03 7:23 ` Tomi Valkeinen
2014-03-03 7:23 ` Tomi Valkeinen
2014-03-03 7:23 ` Tomi Valkeinen
2014-03-05 8:42 ` Tomi Valkeinen
2014-03-05 8:42 ` Tomi Valkeinen
2014-03-05 8:42 ` Tomi Valkeinen
2014-03-04 12:59 ` Daniel Vetter
2014-03-04 12:59 ` Daniel Vetter
2014-03-04 12:59 ` Daniel Vetter
2014-02-28 12:20 ` [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 13:40 ` Philipp Zabel
2014-02-28 13:40 ` Philipp Zabel
2014-02-28 13:40 ` Philipp Zabel
2014-03-03 6:05 ` Tomi Valkeinen
2014-03-03 6:05 ` Tomi Valkeinen
2014-03-03 6:05 ` Tomi Valkeinen
2014-03-17 14:19 ` Laurent Pinchart
2014-03-17 14:19 ` Laurent Pinchart
2014-03-17 14:19 ` Laurent Pinchart
2014-03-18 6:41 ` Tomi Valkeinen
2014-03-18 6:41 ` Tomi Valkeinen
2014-03-18 6:41 ` Tomi Valkeinen
2014-03-18 7:06 ` Tomi Valkeinen
2014-03-18 7:06 ` Tomi Valkeinen
2014-03-18 7:06 ` Tomi Valkeinen
2014-02-28 12:20 ` [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-03-17 14:22 ` Laurent Pinchart
2014-03-17 14:22 ` Laurent Pinchart
2014-03-17 14:22 ` Laurent Pinchart
2014-03-18 6:33 ` Tomi Valkeinen
2014-03-18 6:33 ` Tomi Valkeinen
2014-03-18 6:33 ` Tomi Valkeinen
2014-03-18 12:43 ` Laurent Pinchart
2014-03-18 12:43 ` Laurent Pinchart
2014-03-18 12:43 ` Laurent Pinchart
2014-02-28 12:20 ` [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 13:38 ` Philipp Zabel
2014-02-28 13:38 ` Philipp Zabel
2014-02-28 13:38 ` Philipp Zabel
[not found] ` <1393594707.3802.31.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
2014-02-28 13:47 ` Tomi Valkeinen
2014-02-28 13:47 ` Tomi Valkeinen
2014-02-28 13:47 ` Tomi Valkeinen
2014-02-28 12:20 ` [PATCH 8/9] Doc/DT: Add DT binding documentation for TFP410 encoder Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 13:37 ` Philipp Zabel
2014-02-28 13:37 ` Philipp Zabel
2014-02-28 13:37 ` Philipp Zabel
2014-02-28 12:20 ` [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
2014-02-28 12:20 ` Tomi Valkeinen
[not found] ` <1393590016-9361-10-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
2014-02-28 16:13 ` Russell King - ARM Linux
2014-02-28 16:13 ` Russell King - ARM Linux
2014-02-28 16:13 ` Russell King - ARM Linux
2014-02-28 16:30 ` Tomi Valkeinen
2014-02-28 16:30 ` Tomi Valkeinen
2014-02-28 16:30 ` Tomi Valkeinen
2014-02-28 12:57 ` [PATCH 0/9] Doc/DT: DT bindings for various display components Sebastian Hesselbarth
2014-02-28 12:57 ` Sebastian Hesselbarth
2014-02-28 12:57 ` Sebastian Hesselbarth
2014-02-28 13:14 ` Tomi Valkeinen
2014-02-28 13:14 ` Tomi Valkeinen
2014-02-28 13:14 ` Tomi Valkeinen
[not found] ` <53108B9C.5000006-l0cyMroinI0@public.gmane.org>
2014-02-28 13:51 ` Sebastian Hesselbarth
2014-02-28 13:51 ` Sebastian Hesselbarth
2014-02-28 13:51 ` Sebastian Hesselbarth
2014-02-28 15:39 ` Tomi Valkeinen
2014-02-28 15:39 ` Tomi Valkeinen
2014-02-28 15:39 ` Tomi Valkeinen
2014-02-28 16:48 ` Russell King - ARM Linux
2014-02-28 16:48 ` Russell King - ARM Linux
2014-02-28 13:47 ` Philipp Zabel
2014-02-28 13:47 ` Philipp Zabel
2014-02-28 13:47 ` Philipp Zabel
[not found] ` <1393595264.3802.39.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
2014-02-28 13:56 ` Sebastian Hesselbarth
2014-02-28 13:56 ` Sebastian Hesselbarth
2014-02-28 13:56 ` Sebastian Hesselbarth
2014-02-28 16:27 ` Russell King - ARM Linux
2014-02-28 16:27 ` Russell King - ARM Linux
2014-02-28 16:27 ` Russell King - ARM Linux
[not found] ` <20140228162752.GU21483-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-02-28 16:48 ` Tomi Valkeinen
2014-02-28 16:48 ` Tomi Valkeinen
2014-02-28 16:48 ` Tomi Valkeinen
2014-02-28 16:56 ` Russell King - ARM Linux
2014-02-28 16:56 ` Russell King - ARM Linux
2014-03-03 8:04 ` Tomi Valkeinen
2014-03-03 8:04 ` Tomi Valkeinen
2014-03-03 8:04 ` Tomi Valkeinen
2014-03-07 12:56 ` Tomi Valkeinen
2014-03-07 12:56 ` Tomi Valkeinen
2014-03-07 12:56 ` Tomi Valkeinen
[not found] ` <53143796.2050309-l0cyMroinI0@public.gmane.org>
2014-03-10 16:05 ` Rob Herring
2014-03-10 16:05 ` Rob Herring
2014-03-10 16:05 ` Rob Herring
2014-03-10 16:40 ` Tomi Valkeinen
2014-03-10 16:40 ` Tomi Valkeinen
2014-03-10 16:40 ` Tomi Valkeinen
[not found] ` <531DEB1A.5090509-l0cyMroinI0@public.gmane.org>
2014-03-10 20:32 ` Rob Herring
2014-03-10 20:32 ` Rob Herring
2014-03-10 20:32 ` Rob Herring
2014-03-12 8:15 ` Tomi Valkeinen
2014-03-12 8:15 ` Tomi Valkeinen
2014-03-12 8:15 ` Tomi Valkeinen
2014-03-17 13:55 ` Tomi Valkeinen
2014-03-17 13:55 ` Tomi Valkeinen
2014-03-17 13:55 ` Tomi Valkeinen
[not found] ` <5326FECF.9070104-l0cyMroinI0@public.gmane.org>
2014-03-21 15:37 ` Grant Likely
2014-03-21 15:37 ` Grant Likely
2014-03-21 15:37 ` Grant Likely
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.