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

On Mon, Oct 06, 2014 at 03:11:11PM +0200, Boris Brezillon wrote:

quoted

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

quoted

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.

According to the MIPI website there are also control signals and a
command set to control display behaviour. Does your implementation
handle any of that?

No it doesn't, and I'm pretty sure what I call DPI does not exactly
respect the MIPI DPI standard (and as such should not be called DPI,
but this is another problem).

This infrastructure provides a way for devices connected on a DPI bus
to agree on a video_bus_format (in my case RGB888, RGB666, ...).

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