On Mon, 6 Oct 2014 14:40:15 +0200 Thierry Reding thierry.reding@gmail.com wrote:
On Mon, Oct 06, 2014 at 02:25:38PM +0200, Boris Brezillon wrote:
On Mon, 6 Oct 2014 13:01:16 +0200 Thierry Reding thierry.reding@gmail.com wrote:
On Wed, Oct 01, 2014 at 04:53:07PM +0200, Boris Brezillon wrote: [...]
diff --git a/arch/arm/boot/dts/sama5d3xdm.dtsi b/arch/arm/boot/dts/sama5d3xdm.dtsi
[...]
backlight = <&backlight>;power-supply = <&panel_reg>;#address-cells = <1>;#size-cells = <0>;status = "disabled";port@0 {#address-cells = <1>;#size-cells = <0>;panel_input: endpoint@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.