* [PATCH 0/9] OMAP DSS DT bindings documentation
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
Hi,
Here is DT binding documentation for OMAP Display Subsystem. I've sent these
earlier as part of the whole DSS DT series, but I'm now sending them separately
to get comments for them.
These patches are essentially the same as what I already sent earlier. The only
difference is that I added clock information for omap3 and omap4 platforms.
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
* [PATCH 1/9] Doc/DT: Add OMAP DSS DT Bindings
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add device tree bindings for OMAP Display Subsystem for the following
SoCs: OMAP2, OMAP3, OMAP4.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@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..928d3dc6f8dd
--- /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
* [PATCH 2/9] Doc/DT: Add DT binding documentation for Analog TV Connector
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for Analog TV Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@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
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for DVI Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@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
* [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for HDMI Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@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
* [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for MIPI DPI Panel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@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
* [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for MIPI DSI Command Mode Panel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/panel-dsi-cm.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
diff --git a/Documentation/devicetree/bindings/video/panel-dsi-cm.txt b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
new file mode 100644
index 000000000000..73f422556d4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
@@ -0,0 +1,26 @@
+Generic MIPI DSI Command Mode Panel
+=================+
+Required properties:
+- compatible: "panel-dsi-cm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- gpios: panel reset gpio and TE gpio
+
+Required nodes:
+- Video port for DSI input
+
+Example
+-------
+
+lcd0: display {
+ compatible = "tpo,taal", "panel-dsi-cm";
+ label = "lcd0";
+
+ gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */
+
+ lcd0_in: endpoint {
+ remote-endpoint = <&dsi1_out_ep>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for Sony acx565akm panel
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Sebastian Reichel <sre@debian.org>
---
.../devicetree/bindings/video/sony,acx565akm.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
diff --git a/Documentation/devicetree/bindings/video/sony,acx565akm.txt b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
new file mode 100644
index 000000000000..cd9cfdf7e3fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
@@ -0,0 +1,28 @@
+Sony ACX565AKM SDI Panel
+============
+
+Required properties:
+- compatible: "sony,acx565akm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- gpios: panel reset gpio
+
+Required nodes:
+- Video port for SDI input
+
+Example
+-------
+
+acx565akm@2 {
+ compatible = "sony,acx565akm";
+ spi-max-frequency = <6000000>;
+ reg = <2>;
+
+ label = "lcd";
+ gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */
+
+ lcd_in: endpoint {
+ remote-endpoint = <&sdi_out>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 8/9] Doc/DT: Add DT binding documentation for TFP410 encoder
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for TFP410 encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/ti,tfp410.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
diff --git a/Documentation/devicetree/bindings/video/ti,tfp410.txt b/Documentation/devicetree/bindings/video/ti,tfp410.txt
new file mode 100644
index 000000000000..6a5a04627584
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,tfp410.txt
@@ -0,0 +1,41 @@
+TFP410 DPI to DVI encoder
+============+
+Required properties:
+- compatible: "ti,tfp410"
+
+Optional properties:
+- gpios: power-down gpio
+
+Required nodes:
+- Video port 0 for DPI input
+- Video port 1 for DVI output
+
+Example
+-------
+
+tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@0 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for tpd12s015 encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 ++++++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
diff --git a/Documentation/devicetree/bindings/video/ti,tpd12s015.txt b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
new file mode 100644
index 000000000000..26e6d32e3f20
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
@@ -0,0 +1,44 @@
+TPD12S015 HDMI level shifter and ESD protection chip
+==========================
+
+Required properties:
+- compatible: "ti,tpd12s015"
+
+Optional properties:
+- gpios: CT CP HPD, LS OE and HPD gpios
+
+Required nodes:
+- Video port 0 for HDMI input
+- Video port 1 for HDMI output
+
+Example
+-------
+
+tpd12s015: encoder@1 {
+ compatible = "ti,tpd12s015";
+
+ gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */
+ <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */
+ <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint@0 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* Re: Fixing the kernels backlight API
From: Hans de Goede @ 2014-02-13 13:41 UTC (permalink / raw)
To: Dave Airlie, Matthew Garrett
Cc: Linux Fbdev development list, Jingoo Han,
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org, dri-devel
In-Reply-To: <CAPM=9tyYLuoTtW69-cPx-JSuar++D5WEtYRZr_-aP7uowZpVyA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On 02/12/2014 09:14 PM, Dave Airlie wrote:
>>
>> The biggest remaining stumbling block is the backlight API, because opening the
>> sysfs files requires root rights. I'll very likely write a little helper for this
>> for now, but in the long run it would be good to have a better solution.
>>
>> While discussion this in the graphics devroom at Fosdem, the general consensus
>> seemed to be that the current backlight API is in need of an overhaul anyways.
>>
>> There are several issues with the current API:
>> -there is no reliable way to determine the relation between a backlight
>> control in sysfs and the display it controls the backlight off
>> -on many laptops we end up with multiple providers of backlight control
>> all battling over control of the same backlight controller through various
>> firmware interfaces
>> -and there is no way to do acl management on it because of sysfs usage
>>
>> At Fosdem it was suggested to "simply" make the backlight a property of
>> the connector in drm/kms and let users control it that way. From an acl pov
>> this makes a ton of sense, if a user controls the other display-panel settings,
>> then he should be able to control the backlight too.
>>
>> This also nicely solves the issue of userspace having to figure out which backlight
>> control to use for a certain output.
>>
>> Last this makes it the kernels responsibility to figure out which firmware interface
>> (if any) to use and tie that to the connector, rather then just exporting all of
>> them, including conflicting ones, and just hoping that userspace will figure things out.
>>
>> Note that wrt the last point, the kernel is the one which should have all the hardware
>> knowledge to do this properly, after all hardware abstraction is one of the tasks of
>> the kernel.
>>
>> I realize moving this more into the kernel, and tying things into drm is in no means
>> easy, but it is about time we clean up this mess.
>>
>> Note that although I'm kicking of this discussion, my focus within the graphics team is
>> mostly on input devices, so I'm hoping that someone else will pick things up once we've
>> a better idea of how we would like to solve this.
>>
>
> I hate to respond with yeah no, but yeah no,
>
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-04
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-05
>
> read down that until you see me and tagr talking, read it a few times,
> and the follow on chat with dvdhrm.
I think I'm going to save myself some time and just believe you, esp.
since you ...
>
> The biggest problem with leaving the kernel to pick the correct one,
> is the kernel simply never knows which is the
> correct one, and you also have to deal with a load of problems like
> runtime module deps between very misc modules
> or using some kind of notifier mechanism that will turn into a locking
> nightmare.
>
> I don't mean to dissuade you from trying to "fix" this, but actually
> getting a solution upstream is going to require a lot of messing
> around.
>
> Talk to Matthew Garrett, if you haven't talked to him, then you
> haven't talked to anyone who understands backlights.
Also bring up Matthew Garrett, who seems to have a knack for working on things which
involve inflicting a certain amount of pain onto the developer working on them.
I still believe we need to do better, but maybe that better needs to be done
in userspace rather then in the kernel.
More about that further down in this thread.
Regards,
Hans
^ permalink raw reply
* Re: Fixing the kernels backlight API
From: Hans de Goede @ 2014-02-13 13:49 UTC (permalink / raw)
To: David Herrmann, Ville Syrjälä
Cc: xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org,
Linux Fbdev development list, Jingoo Han, Dave Airlie, dri-devel
In-Reply-To: <CANq1E4R=UVo5YVPUrdRFeobAE-qU6e-+GHZ2VJwwaa8zEO6g3Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On 02/12/2014 11:26 PM, David Herrmann wrote:
> Hi
>
> On Wed, Feb 12, 2014 at 9:43 PM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
>> On Thu, Feb 13, 2014 at 06:14:04AM +1000, Dave Airlie wrote:
>>>>
>>>> The biggest remaining stumbling block is the backlight API, because opening the
>>>> sysfs files requires root rights. I'll very likely write a little helper for this
>>>> for now, but in the long run it would be good to have a better solution.
>>>>
>>>> While discussion this in the graphics devroom at Fosdem, the general consensus
>>>> seemed to be that the current backlight API is in need of an overhaul anyways.
>>>>
>>>> There are several issues with the current API:
>>>> -there is no reliable way to determine the relation between a backlight
>>>> control in sysfs and the display it controls the backlight off
>>>> -on many laptops we end up with multiple providers of backlight control
>>>> all battling over control of the same backlight controller through various
>>>> firmware interfaces
>>>> -and there is no way to do acl management on it because of sysfs usage
>>>>
>>>> At Fosdem it was suggested to "simply" make the backlight a property of
>>>> the connector in drm/kms and let users control it that way. From an acl pov
>>>> this makes a ton of sense, if a user controls the other display-panel settings,
>>>> then he should be able to control the backlight too.
>>>>
>>>> This also nicely solves the issue of userspace having to figure out which backlight
>>>> control to use for a certain output.
>>>>
>>>> Last this makes it the kernels responsibility to figure out which firmware interface
>>>> (if any) to use and tie that to the connector, rather then just exporting all of
>>>> them, including conflicting ones, and just hoping that userspace will figure things out.
>>>>
>>>> Note that wrt the last point, the kernel is the one which should have all the hardware
>>>> knowledge to do this properly, after all hardware abstraction is one of the tasks of
>>>> the kernel.
>>>>
>>>> I realize moving this more into the kernel, and tying things into drm is in no means
>>>> easy, but it is about time we clean up this mess.
>>>>
>>>> Note that although I'm kicking of this discussion, my focus within the graphics team is
>>>> mostly on input devices, so I'm hoping that someone else will pick things up once we've
>>>> a better idea of how we would like to solve this.
>>>>
>>>
>>> I hate to respond with yeah no, but yeah no,
>>>
>>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-04
>>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-05
>>>
>>> read down that until you see me and tagr talking, read it a few times,
>>> and the follow on chat with dvdhrm.
>>>
>>> The biggest problem with leaving the kernel to pick the correct one,
>>> is the kernel simply never knows which is the
>>> correct one,
>>
>> That could be solved by still allowing userspace to change the
>> connection between the property and the actual backlight device.
>>
>> With the prop approach + atomic modeset you could also do some
>> slightly fancier things like changing the backlight at the same
>> time as doing a modeset or just adjusting some other display
>> related properties.
>
> The "attach" stuff actually sounds doable, but who decides which one
> to attach? You still need some user-space script during device-plug
> for that.
> But to be honest, the simplest way would be a "backlightd"
> bus-activatable daemon. SetBacklight() then takes a DRM-connector and
> brightness-value, which the daemon looks up in /sys and sets.. This
> has the advantage that we can do any fancy matching in user-space. We
> can provide quirks (maybe even via udev-hwdb) and other helpers for
> weird setups.
This sounds like a good idea, note that at-least gnome already has
something similar in the form of the (one-shot, not daemon)
gsd-backlight-helper which also has some code to try and figure out
what is the right backlight class device to use.
Interestingly enough the xf86-video-intel driver does this on its own
using somewhat more complex logic to find the right backlight class
device to use, and then exporting this as a property on the connector
in Xrandr.
So a first rough idea of how this would work / a plan would be:
1) We have a bus-activated backlightd running as root
2) This can be asked for backlight properties on a certain drm/kms
connector
3) If there actually is a backlight for the connector, it can also be
used to change the backlight brightness
4) The xserver will get some helper functions which drivers can call
to create a backlight property on xrandr connectors
5) In the long run gsd-backlight-helper and the xf86-video-intel
backlight code can be removed
Note there also is a step:
0) Get xf86-video-intel backlight code to work without root in some
way for now
Regards,
Hans
^ permalink raw reply
* Re: Fixing the kernels backlight API
From: Hans de Goede @ 2014-02-13 13:57 UTC (permalink / raw)
To: Alexander E. Patrakov, David Herrmann, Ville Syrjälä
Cc: Dave Airlie, Linux Fbdev development list, Jingoo Han,
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org, dri-devel
In-Reply-To: <52FC683F.10905-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi,
On 02/13/2014 07:37 AM, Alexander E. Patrakov wrote:
> 13.02.2014 04:26, David Herrmann wrote:
>> The "attach" stuff actually sounds doable, but who decides which one
>> to attach? You still need some user-space script during device-plug
>> for that.
>> But to be honest, the simplest way would be a "backlightd"
>> bus-activatable daemon. SetBacklight() then takes a DRM-connector and
>> brightness-value, which the daemon looks up in /sys and sets.. This
>> has the advantage that we can do any fancy matching in user-space. We
>> can provide quirks (maybe even via udev-hwdb) and other helpers for
>> weird setups.
>
> What would be done with Samsung monitors (like an old SyncMaster 770P) that have a DVI connection, no physical buttons and have to be controlled via DDC-CI? Currently, ddccontrol works (via /dev/i2c-*), but only from root. I would like this use case to be covered in such a way that it could work both in Xorg and in Wayland, and, if possible, without races related to i2c usage from the kernel and from userspace.
The nice thing about having a userspace daemon for this is that we can
actually add some support for DCC-CI too.
WRT races between user and kernelspace, those can be avoided by using
the I2C_RDWR ioctl, in this case you can specify multipel i2c writes /
reads which will all get executed as one transaction, note this
assumes that the protocol supports repeated START conditions,
if it needs a STOP condition and still needs everything to be in
one transaction, then things become trickier. This also assumes
that the i2c controller driver used supports I2C_FUNC_I2C
Regards,
Hans
^ permalink raw reply
* Re: Fixing the kernels backlight API
From: Matthew Garrett @ 2014-02-13 17:19 UTC (permalink / raw)
To: Hans de Goede
Cc: xorg-devel@lists.x.org, Linux Fbdev development list, Jingoo Han,
dri-devel
In-Reply-To: <52FCCBA1.3070303@redhat.com>
On Thu, Feb 13, 2014 at 02:41:53PM +0100, Hans de Goede wrote:
> I still believe we need to do better, but maybe that better needs to be done
> in userspace rather then in the kernel.
One option is to put it on the connector but provide some mechanism for
userspace to define the relationship between platform/firmware
interfaces and connectors. We ought to be able to tie connectors into
the ACPI namespace and do a better job than we currently do with the
association between backlight and connector. The bigger problem is
figuring out how platform interfaces tie into things, and that's where
heuristics are probably going to be involved.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: Fixing the kernels backlight API
From: Hans de Goede @ 2014-02-13 19:43 UTC (permalink / raw)
To: Matthew Garrett
Cc: xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org,
Linux Fbdev development list, Jingoo Han, Dave Airlie, dri-devel
In-Reply-To: <20140213171932.GB4420-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
Hi,
On 02/13/2014 06:19 PM, Matthew Garrett wrote:
> On Thu, Feb 13, 2014 at 02:41:53PM +0100, Hans de Goede wrote:
>
>> I still believe we need to do better, but maybe that better needs to be done
>> in userspace rather then in the kernel.
>
> One option is to put it on the connector but provide some mechanism for
> userspace to define the relationship between platform/firmware
> interfaces and connectors. We ought to be able to tie connectors into
> the ACPI namespace and do a better job than we currently do with the
> association between backlight and connector. The bigger problem is
> figuring out how platform interfaces tie into things, and that's where
> heuristics are probably going to be involved.
Right, but as Dave Airlie pointed out that means putting links between
two completely unrelated subsystems, causing locking and module load
ordering problems.
I can understand where Dave is coming from, from a kernel pov, so this
might really be easier to just solve in userspace. I don't know if you've
seen my very rough sketch of how this could work in userspace in my other
mail. The idea would be to still make this show up on a specific connector,
but only at the xrandr level, not at the drm level, and have the xserver
talk to some kind of backlightd for this. The backlightd API should of cource
be generic enough that it can be used in wayland too.
This sounds like a reasonable and workable plan to me, but I must admit
I'm very naive when it comes to backlight stuff.
Regards,
Hans
^ permalink raw reply
* Re: Fixing the kernels backlight API
From: Matthew Garrett @ 2014-02-13 20:12 UTC (permalink / raw)
To: Hans de Goede
Cc: xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org,
Linux Fbdev development list, Jingoo Han, Dave Airlie, dri-devel
In-Reply-To: <52FD204E.40507-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Thu, Feb 13, 2014 at 08:43:10PM +0100, Hans de Goede wrote:
> I can understand where Dave is coming from, from a kernel pov, so this
> might really be easier to just solve in userspace. I don't know if you've
> seen my very rough sketch of how this could work in userspace in my other
> mail. The idea would be to still make this show up on a specific connector,
> but only at the xrandr level, not at the drm level, and have the xserver
> talk to some kind of backlightd for this. The backlightd API should of cource
> be generic enough that it can be used in wayland too.
Sure. You should probably take a look at libbacklight, which already has
some amount of support for appropriate heuristics.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* [PATCH 1/2] OMAPDSS: use DISPC register to detect context loss
From: Tomi Valkeinen @ 2014-02-14 8:29 UTC (permalink / raw)
To: linux-fbdev, linux-omap, Archit Taneja; +Cc: Nishanth Menon, Tomi Valkeinen
Instead of relying on the OMAP specific
omap_pm_get_dev_context_loss_count() to detect register context loss, we
can achieve the same in a much simpler way by just observing the DISPC
registers.
We always set DISPC's load mode to LOAD_FRAME_ONLY, which is not the
reset value. Thus we can just observe the load mode to see if we have
lost register context.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dispc.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index bbeb8dd7f108..1659aa912d2b 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -100,8 +100,6 @@ static struct {
struct platform_device *pdev;
void __iomem *base;
- int ctx_loss_cnt;
-
int irq;
unsigned long core_clk_rate;
@@ -357,29 +355,20 @@ static void dispc_save_context(void)
if (dss_has_feature(FEAT_CORE_CLK_DIV))
SR(DIVISOR);
- dispc.ctx_loss_cnt = dss_get_ctx_loss_count();
dispc.ctx_valid = true;
- DSSDBG("context saved, ctx_loss_count %d\n", dispc.ctx_loss_cnt);
+ DSSDBG("context saved\n");
}
static void dispc_restore_context(void)
{
- int i, j, ctx;
+ int i, j;
DSSDBG("dispc_restore_context\n");
if (!dispc.ctx_valid)
return;
- ctx = dss_get_ctx_loss_count();
-
- if (ctx >= 0 && ctx = dispc.ctx_loss_cnt)
- return;
-
- DSSDBG("ctx_loss_count: saved %d, current %d\n",
- dispc.ctx_loss_cnt, ctx);
-
/*RR(IRQENABLE);*/
/*RR(CONTROL);*/
RR(CONFIG);
@@ -3768,6 +3757,15 @@ static int dispc_runtime_suspend(struct device *dev)
static int dispc_runtime_resume(struct device *dev)
{
+ /*
+ * The reset value for load mode is 0 (OMAP_DSS_LOAD_CLUT_AND_FRAME)
+ * but we always initialize it to 2 (OMAP_DSS_LOAD_FRAME_ONLY) in
+ * _omap_dispc_initial_config(). We can thus use it to detect if
+ * we have lost register context.
+ */
+ if (REG_GET(DISPC_CONFIG, 2, 1) = OMAP_DSS_LOAD_FRAME_ONLY)
+ return 0;
+
_omap_dispc_initial_config();
dispc_restore_context();
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/2] OMAPDSS: Remove unused get_context_loss_count support
From: Tomi Valkeinen @ 2014-02-14 8:29 UTC (permalink / raw)
To: linux-fbdev, linux-omap, Archit Taneja; +Cc: Nishanth Menon, Tomi Valkeinen
In-Reply-To: <1392366572-31729-1-git-send-email-tomi.valkeinen@ti.com>
The omapdss driver no longer uses get_context_loss_count call, so we can
remove it.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/display.c | 1 -
drivers/video/omap2/dss/dss.c | 16 ----------------
drivers/video/omap2/dss/dss.h | 2 --
include/video/omapdss.h | 1 -
4 files changed, 20 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 4cf165502b35..93ebb4007ea9 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -301,7 +301,6 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
board_data->version = ver;
board_data->dsi_enable_pads = omap_dsi_enable_pads;
board_data->dsi_disable_pads = omap_dsi_disable_pads;
- board_data->get_context_loss_count = omap_pm_get_dev_context_loss_count;
board_data->set_min_bus_tput = omap_dss_set_min_bus_tput;
omap_display_device.dev.platform_data = board_data;
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 9a145da35ad3..96e400c51001 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -154,22 +154,6 @@ static void dss_restore_context(void)
#undef SR
#undef RR
-int dss_get_ctx_loss_count(void)
-{
- struct platform_device *core_pdev = dss_get_core_pdev();
- struct omap_dss_board_info *board_data = core_pdev->dev.platform_data;
- int cnt;
-
- if (!board_data->get_context_loss_count)
- return -ENOENT;
-
- cnt = board_data->get_context_loss_count(&dss.pdev->dev);
-
- WARN_ONCE(cnt < 0, "get_context_loss_count failed: %d\n", cnt);
-
- return cnt;
-}
-
void dss_sdi_init(int datapairs)
{
u32 l;
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 057f24c8a332..570f7ed2bcbc 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -225,8 +225,6 @@ void dss_dump_clocks(struct seq_file *s);
void dss_debug_dump_clocks(struct seq_file *s);
#endif
-int dss_get_ctx_loss_count(void);
-
void dss_sdi_init(int datapairs);
int dss_sdi_enable(void);
void dss_sdi_disable(void);
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 3d7c51a6f9ff..1eb9aa605eee 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -323,7 +323,6 @@ enum omapdss_version {
/* Board specific data */
struct omap_dss_board_info {
- int (*get_context_loss_count)(struct device *dev);
int num_devices;
struct omap_dss_device **devices;
struct omap_dss_device *default_device;
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCHv14][ 3/4] video: Kconfig: Allow more broad selection of the imxfb framebuffer driver.
From: Tomi Valkeinen @ 2014-02-14 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390410577-22073-3-git-send-email-denis@eukrea.com>
[-- Attachment #1: Type: text/plain, Size: 944 bytes --]
Hi,
On 22/01/14 19:09, Denis Carikli wrote:
> Without that patch, a user can't select the imxfb driver when the i.MX25 and/or
> the i.MX27 device tree board are selected and that no boards that selects
> IMX_HAVE_PLATFORM_IMX_FB are compiled in.
>
> Cc: Eric Bénard <eric@eukrea.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Denis Carikli <denis@eukrea.com>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Applied for 3.14 fbdev fixes.
As a generic comment, I'd appreciate if you'd use normal formatting in
the patch descriptions (no double spaces in the beginning of the lines).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: Fixing the kernels backlight API
From: Hans de Goede @ 2014-02-14 8:45 UTC (permalink / raw)
To: Matthew Garrett
Cc: xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org,
Linux Fbdev development list, Jingoo Han, Dave Airlie, dri-devel
In-Reply-To: <20140213201237.GA19355-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
Hi,
On 02/13/2014 09:12 PM, Matthew Garrett wrote:
> On Thu, Feb 13, 2014 at 08:43:10PM +0100, Hans de Goede wrote:
>
>> I can understand where Dave is coming from, from a kernel pov, so this
>> might really be easier to just solve in userspace. I don't know if you've
>> seen my very rough sketch of how this could work in userspace in my other
>> mail. The idea would be to still make this show up on a specific connector,
>> but only at the xrandr level, not at the drm level, and have the xserver
>> talk to some kind of backlightd for this. The backlightd API should of cource
>> be generic enough that it can be used in wayland too.
>
> Sure. You should probably take a look at libbacklight, which already has
> some amount of support for appropriate heuristics.
Ah, I did not know about libbacklight, thanks for the pointer.
Note that although I believe we do need to sort out this mess, and having
something like backlightd would be a good idea, I likely won't have time to
work on this in the near future. For $dayjob I will be focussing on finishing
rootless xorg and working on libinput. And $hobbytime is all going to getting
upstream support for Allwinner ARM SoCs into place.
Still I'll put a line about this in my todo file, just don't expect anything
soon, and no promises about this at all!
Regards,
Hans
^ permalink raw reply
* [GIT PULL] fbdev fixes for 3.14
From: Tomi Valkeinen @ 2014-02-14 9:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, linux-fbdev, Jean-Christophe PLAGNIOL-VILLARD
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]
Hi Linus,
Please pull a few minor fbdev fixes for 3.14.
Tomi
The following changes since commit b28a960c42fcd9cfc987441fa6d1c1a471f0f9ed:
Linux 3.14-rc2 (2014-02-09 18:15:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-fixes-3.14
for you to fetch changes up to b359bb0d9c5132abb6fec1ef555c48daf267de59:
video: Kconfig: Allow more broad selection of the imxfb framebuffer driver. (2014-02-14 10:44:52 +0200)
----------------------------------------------------------------
Minor fbdev fixes for 3.14.
----------------------------------------------------------------
Denis Carikli (1):
video: Kconfig: Allow more broad selection of the imxfb framebuffer driver.
Sachin Kamat (1):
video: exynos: Fix S6E8AX0 LCD driver build error
Tomi Valkeinen (2):
OMAPDSS: DISPC: decimation rounding fix
OMAPDSS: fix fck field types
drivers/video/Kconfig | 2 +-
drivers/video/exynos/Kconfig | 3 ++-
drivers/video/omap2/dss/dispc.c | 16 ++++++++--------
drivers/video/omap2/dss/dpi.c | 2 +-
drivers/video/omap2/dss/sdi.c | 2 +-
5 files changed, 13 insertions(+), 12 deletions(-)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCH RFC 2/3] fbdev: move fbdev core files to separate directory
From: Tomi Valkeinen @ 2014-02-14 11:18 UTC (permalink / raw)
To: linux-fbdev, dri-devel, linux-kernel
Cc: Laurent Pinchart, Geert Uytterhoeven,
Jean-Christophe Plagniol-Villard, David Airlie, Tomi Valkeinen
In-Reply-To: <1392376711-11290-1-git-send-email-tomi.valkeinen@ti.com>
Instead of having fbdev framework core files at the root fbdev
directory, mixed with random fbdev device drivers, move the fbdev core
files to a separate core directory. This makes it much clearer which of
the files are actually part of the fbdev framework, and which are part
of device drivers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/Makefile | 16 +---------------
drivers/video/fbdev/core/Makefile | 16 ++++++++++++++++
drivers/video/fbdev/{ => core}/cfbcopyarea.c | 0
drivers/video/fbdev/{ => core}/cfbfillrect.c | 0
drivers/video/fbdev/{ => core}/cfbimgblt.c | 0
drivers/video/fbdev/{ => core}/fb_ddc.c | 2 +-
drivers/video/fbdev/{ => core}/fb_defio.c | 0
drivers/video/fbdev/{ => core}/fb_draw.h | 0
drivers/video/fbdev/{ => core}/fb_notify.c | 0
drivers/video/fbdev/{ => core}/fb_sys_fops.c | 0
drivers/video/fbdev/{ => core}/fbcmap.c | 0
drivers/video/fbdev/{ => core}/fbcvt.c | 0
drivers/video/fbdev/{ => core}/fbmem.c | 0
drivers/video/fbdev/{ => core}/fbmon.c | 2 +-
drivers/video/fbdev/{ => core}/fbsysfs.c | 0
drivers/video/fbdev/{ => core}/modedb.c | 0
drivers/video/fbdev/{ => core}/svgalib.c | 0
drivers/video/fbdev/{ => core}/syscopyarea.c | 0
drivers/video/fbdev/{ => core}/sysfillrect.c | 0
drivers/video/fbdev/{ => core}/sysimgblt.c | 0
drivers/video/fbdev/wmt_ge_rops.c | 2 +-
21 files changed, 20 insertions(+), 18 deletions(-)
create mode 100644 drivers/video/fbdev/core/Makefile
rename drivers/video/fbdev/{ => core}/cfbcopyarea.c (100%)
rename drivers/video/fbdev/{ => core}/cfbfillrect.c (100%)
rename drivers/video/fbdev/{ => core}/cfbimgblt.c (100%)
rename drivers/video/fbdev/{ => core}/fb_ddc.c (99%)
rename drivers/video/fbdev/{ => core}/fb_defio.c (100%)
rename drivers/video/fbdev/{ => core}/fb_draw.h (100%)
rename drivers/video/fbdev/{ => core}/fb_notify.c (100%)
rename drivers/video/fbdev/{ => core}/fb_sys_fops.c (100%)
rename drivers/video/fbdev/{ => core}/fbcmap.c (100%)
rename drivers/video/fbdev/{ => core}/fbcvt.c (100%)
rename drivers/video/fbdev/{ => core}/fbmem.c (100%)
rename drivers/video/fbdev/{ => core}/fbmon.c (99%)
rename drivers/video/fbdev/{ => core}/fbsysfs.c (100%)
rename drivers/video/fbdev/{ => core}/modedb.c (100%)
rename drivers/video/fbdev/{ => core}/svgalib.c (100%)
rename drivers/video/fbdev/{ => core}/syscopyarea.c (100%)
rename drivers/video/fbdev/{ => core}/sysfillrect.c (100%)
rename drivers/video/fbdev/{ => core}/sysimgblt.c (100%)
diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index 616e0975ae6e..6ef2c66110e3 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -4,25 +4,11 @@
# Each configuration option enables a list of files.
-obj-y += fb_notify.o
-obj-$(CONFIG_FB) += fb.o
-fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
- modedb.o fbcvt.o
-fb-objs := $(fb-y)
+obj-y += core/
obj-$(CONFIG_EXYNOS_VIDEO) += exynos/
-obj-$(CONFIG_FB_CFB_FILLRECT) += cfbfillrect.o
-obj-$(CONFIG_FB_CFB_COPYAREA) += cfbcopyarea.o
-obj-$(CONFIG_FB_CFB_IMAGEBLIT) += cfbimgblt.o
-obj-$(CONFIG_FB_SYS_FILLRECT) += sysfillrect.o
-obj-$(CONFIG_FB_SYS_COPYAREA) += syscopyarea.o
-obj-$(CONFIG_FB_SYS_IMAGEBLIT) += sysimgblt.o
-obj-$(CONFIG_FB_SYS_FOPS) += fb_sys_fops.o
-obj-$(CONFIG_FB_SVGALIB) += svgalib.o
obj-$(CONFIG_FB_MACMODES) += macmodes.o
-obj-$(CONFIG_FB_DDC) += fb_ddc.o
-obj-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
obj-$(CONFIG_FB_WMT_GE_ROPS) += wmt_ge_rops.o
# Hardware specific drivers go first
diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
new file mode 100644
index 000000000000..fa306538dac2
--- /dev/null
+++ b/drivers/video/fbdev/core/Makefile
@@ -0,0 +1,16 @@
+obj-y += fb_notify.o
+obj-$(CONFIG_FB) += fb.o
+fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
+ modedb.o fbcvt.o
+fb-objs := $(fb-y)
+
+obj-$(CONFIG_FB_CFB_FILLRECT) += cfbfillrect.o
+obj-$(CONFIG_FB_CFB_COPYAREA) += cfbcopyarea.o
+obj-$(CONFIG_FB_CFB_IMAGEBLIT) += cfbimgblt.o
+obj-$(CONFIG_FB_SYS_FILLRECT) += sysfillrect.o
+obj-$(CONFIG_FB_SYS_COPYAREA) += syscopyarea.o
+obj-$(CONFIG_FB_SYS_IMAGEBLIT) += sysimgblt.o
+obj-$(CONFIG_FB_SYS_FOPS) += fb_sys_fops.o
+obj-$(CONFIG_FB_SVGALIB) += svgalib.o
+obj-$(CONFIG_FB_DDC) += fb_ddc.o
+obj-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
diff --git a/drivers/video/fbdev/cfbcopyarea.c b/drivers/video/fbdev/core/cfbcopyarea.c
similarity index 100%
rename from drivers/video/fbdev/cfbcopyarea.c
rename to drivers/video/fbdev/core/cfbcopyarea.c
diff --git a/drivers/video/fbdev/cfbfillrect.c b/drivers/video/fbdev/core/cfbfillrect.c
similarity index 100%
rename from drivers/video/fbdev/cfbfillrect.c
rename to drivers/video/fbdev/core/cfbfillrect.c
diff --git a/drivers/video/fbdev/cfbimgblt.c b/drivers/video/fbdev/core/cfbimgblt.c
similarity index 100%
rename from drivers/video/fbdev/cfbimgblt.c
rename to drivers/video/fbdev/core/cfbimgblt.c
diff --git a/drivers/video/fbdev/fb_ddc.c b/drivers/video/fbdev/core/fb_ddc.c
similarity index 99%
rename from drivers/video/fbdev/fb_ddc.c
rename to drivers/video/fbdev/core/fb_ddc.c
index 2b106f046fde..94322ccfedde 100644
--- a/drivers/video/fbdev/fb_ddc.c
+++ b/drivers/video/fbdev/core/fb_ddc.c
@@ -15,7 +15,7 @@
#include <linux/i2c-algo-bit.h>
#include <linux/slab.h>
-#include "edid.h"
+#include "../edid.h"
#define DDC_ADDR 0x50
diff --git a/drivers/video/fbdev/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c
similarity index 100%
rename from drivers/video/fbdev/fb_defio.c
rename to drivers/video/fbdev/core/fb_defio.c
diff --git a/drivers/video/fbdev/fb_draw.h b/drivers/video/fbdev/core/fb_draw.h
similarity index 100%
rename from drivers/video/fbdev/fb_draw.h
rename to drivers/video/fbdev/core/fb_draw.h
diff --git a/drivers/video/fbdev/fb_notify.c b/drivers/video/fbdev/core/fb_notify.c
similarity index 100%
rename from drivers/video/fbdev/fb_notify.c
rename to drivers/video/fbdev/core/fb_notify.c
diff --git a/drivers/video/fbdev/fb_sys_fops.c b/drivers/video/fbdev/core/fb_sys_fops.c
similarity index 100%
rename from drivers/video/fbdev/fb_sys_fops.c
rename to drivers/video/fbdev/core/fb_sys_fops.c
diff --git a/drivers/video/fbdev/fbcmap.c b/drivers/video/fbdev/core/fbcmap.c
similarity index 100%
rename from drivers/video/fbdev/fbcmap.c
rename to drivers/video/fbdev/core/fbcmap.c
diff --git a/drivers/video/fbdev/fbcvt.c b/drivers/video/fbdev/core/fbcvt.c
similarity index 100%
rename from drivers/video/fbdev/fbcvt.c
rename to drivers/video/fbdev/core/fbcvt.c
diff --git a/drivers/video/fbdev/fbmem.c b/drivers/video/fbdev/core/fbmem.c
similarity index 100%
rename from drivers/video/fbdev/fbmem.c
rename to drivers/video/fbdev/core/fbmem.c
diff --git a/drivers/video/fbdev/fbmon.c b/drivers/video/fbdev/core/fbmon.c
similarity index 99%
rename from drivers/video/fbdev/fbmon.c
rename to drivers/video/fbdev/core/fbmon.c
index 6103fa6fb54f..c204ebe6187e 100644
--- a/drivers/video/fbdev/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -37,7 +37,7 @@
#include <asm/prom.h>
#include <asm/pci-bridge.h>
#endif
-#include "edid.h"
+#include "../edid.h"
/*
* EDID parser
diff --git a/drivers/video/fbdev/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
similarity index 100%
rename from drivers/video/fbdev/fbsysfs.c
rename to drivers/video/fbdev/core/fbsysfs.c
diff --git a/drivers/video/fbdev/modedb.c b/drivers/video/fbdev/core/modedb.c
similarity index 100%
rename from drivers/video/fbdev/modedb.c
rename to drivers/video/fbdev/core/modedb.c
diff --git a/drivers/video/fbdev/svgalib.c b/drivers/video/fbdev/core/svgalib.c
similarity index 100%
rename from drivers/video/fbdev/svgalib.c
rename to drivers/video/fbdev/core/svgalib.c
diff --git a/drivers/video/fbdev/syscopyarea.c b/drivers/video/fbdev/core/syscopyarea.c
similarity index 100%
rename from drivers/video/fbdev/syscopyarea.c
rename to drivers/video/fbdev/core/syscopyarea.c
diff --git a/drivers/video/fbdev/sysfillrect.c b/drivers/video/fbdev/core/sysfillrect.c
similarity index 100%
rename from drivers/video/fbdev/sysfillrect.c
rename to drivers/video/fbdev/core/sysfillrect.c
diff --git a/drivers/video/fbdev/sysimgblt.c b/drivers/video/fbdev/core/sysimgblt.c
similarity index 100%
rename from drivers/video/fbdev/sysimgblt.c
rename to drivers/video/fbdev/core/sysimgblt.c
diff --git a/drivers/video/fbdev/wmt_ge_rops.c b/drivers/video/fbdev/wmt_ge_rops.c
index b0a9f34b2e01..9df6fe78a44b 100644
--- a/drivers/video/fbdev/wmt_ge_rops.c
+++ b/drivers/video/fbdev/wmt_ge_rops.c
@@ -18,7 +18,7 @@
#include <linux/module.h>
#include <linux/fb.h>
#include <linux/platform_device.h>
-#include "fb_draw.h"
+#include "core/fb_draw.h"
#define GE_COMMAND_OFF 0x00
#define GE_DEPTH_OFF 0x04
--
1.8.3.2
^ permalink raw reply related
* [PATCH RFC 3/3] video: Kconfig: move drm and fb into separate menus
From: Tomi Valkeinen @ 2014-02-14 11:18 UTC (permalink / raw)
To: linux-fbdev, dri-devel, linux-kernel
Cc: Laurent Pinchart, Geert Uytterhoeven,
Jean-Christophe Plagniol-Villard, David Airlie, Tomi Valkeinen
In-Reply-To: <1392376711-11290-1-git-send-email-tomi.valkeinen@ti.com>
At the moment the "Device Drivers / Graphics support" kernel config page
looks rather messy, with DRM and fbdev driver selections on the same
page, some on the top level Graphics support page, some under their
respective subsystems.
If I'm not mistaken, this is caused by the drivers depending on other
things than DRM or FB, which causes Kconfig to arrange the options in
not-so-neat manner.
Both DRM and FB have a main menuconfig option for the whole DRM or FB
subsystem. Optimally, this would be enough to arrange all DRM and FB
options under the respective subsystem, but for whatever reason this
doesn't work reliably.
This patch adds an explicit submenu for DRM and FB, making it much
clearer which options are related to FB, and which to DRM.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index f0f26a0b746e..70d174090a54 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -21,9 +21,13 @@ source "drivers/gpu/vga/Kconfig"
source "drivers/gpu/host1x/Kconfig"
+menu "Direct Rendering Manager"
source "drivers/gpu/drm/Kconfig"
+endmenu
+menu "Framebuffer Devices"
source "drivers/video/fbdev/Kconfig"
+endmenu
source "drivers/video/backlight/Kconfig"
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 1/1] video: s6e8ax0: Use devm_* APIs
From: Tomi Valkeinen @ 2014-02-14 11:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1392198779-5203-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 304 bytes --]
On 12/02/14 11:52, Sachin Kamat wrote:
> devm_* APIs make the cleanup paths simpler.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> drivers/video/exynos/s6e8ax0.c | 13 ++++---------
> 1 file changed, 4 insertions(+), 9 deletions(-)
Thanks, queued for 3.15.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 2/3] fbdev: move fbdev core files to separate directory
From: Geert Uytterhoeven @ 2014-02-14 12:27 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Linux Fbdev development list, linux-kernel@vger.kernel.org,
DRI Development, Laurent Pinchart,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1392376711-11290-2-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
Thanks for doing this!
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
On Fri, Feb 14, 2014 at 12:18 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> --- a/drivers/video/fbdev/fbmon.c
> +++ b/drivers/video/fbdev/core/fbmon.c
> @@ -37,7 +37,7 @@
> #include <asm/prom.h>
> #include <asm/>
> /*
> * EDID parserpci-bridge.h>
> #endif
> -#include "edid.h"
> +#include "../edid.h"
This looks a bit asymmetrical ...
> --- a/drivers/video/fbdev/wmt_ge_rops.c
> +++ b/drivers/video/fbdev/wmt_ge_rops.c
> @@ -18,7 +18,7 @@
> #include <linux/module.h>
> #include <linux/fb.h>
> #include <linux/platform_device.h>
> -#include "fb_draw.h"
> +#include "core/fb_draw.h"
... to this.
Perhaps (the content of) edid.h belongs in include/video/edid.h?
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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox