On Mon, 6 Oct 2014 14:40:15 +0200
Thierry Reding [off-list ref] wrote:

On Mon, Oct 06, 2014 at 02:25:38PM +0200, Boris Brezillon wrote:

quoted

On Mon, 6 Oct 2014 13:01:16 +0200 Thierry Reding [off-list ref] wrote:

quoted

On Wed, Oct 01, 2014 at 04:53:07PM +0200, Boris Brezillon wrote:
[...]

quoted

diff --git a/arch/arm/boot/dts/sama5d3xdm.dtsi b/arch/arm/boot/dts/sama5d3xdm.dtsi

[...]

quoted

quoted

quoted

+		backlight = <&backlight>;
+		power-supply = <&panel_reg>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+
+		port at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			panel_input: endpoint at 0 {
+				reg = <0>;
+				remote-endpoint = <&hlcdc_panel_output>;
+			};
 		};

There's no support for OF graphs in simple-panel, so this is unused,
isn't it?

Actually I use it in my atmel_hlcdc_ouput implementation to figure out
the link between a panel and a device connected on the RGB/DPI bus. 

That's kind of weird and one of the reasons why I can't make myself like
the OF graph bindings. It requires drivers for one device to reach into
the device tree node of some other device and look for content. Or put
another way, a DT node for a panel that works on one platform doesn't
work on another because the display controller needs additional DT
content that isn't required by the original binding for the panel.

I also have a working POC of a DPI bus implementation (with DPI support
in panel-simple driver).

This is a solution I developed to provide a generic DPI implementation
in my HLCDC driver and rely on generic external implementations for
slave devices (panels, encoders, ...).

But, IIRC, Laurent was not in favor of a bus approach because the DPI
bus is just a data bus and not a control bus.

Anyway, I'll clean it up and post an RFC.

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com