RFC: device tree ports, connectors and panels

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

Hello,
while porting the allwinner graphic drivers from arm/allwinner to arm/sunxi,
I had to deal with ports and endpoinds defined in the device tree.
ports and endpoinds defines how the different elements of a video pipeline
are connected together, and are defined in
linux/Documentation/devicetree/bindings/graph.txt

I came up with the API and implementation available at
http://www.netbsd.org/~bouyer/fdt_video.tgz
For details about the port/endpoint API see comments in fdt_port.h

For completeness I also had to implement a connector driver.
This one is quite trivial, it's only there to register its endpoint,
so that e.g. the upper level in the pipeline can know if the HDMI output
is useable. It is incomplete at this time, as e.g. it doesn't deal
with getting the video timings from an external i2c controller
(the allwinner hdmi controller has its own i2c driver). This can be adder
later, by someone with the right hardware to test.

With this I could get the HDMI output on an A20 board working as well as
the old allwinner kernel.

I'm now working on LVDS panel support. For this I had to implement a
panel driver. This one will get the display timing from the device tree,
and control the power and (if needed) backlight of the panel.
Here I had a problem: the linux specifications and drivers don't say anything
about dual-link lvds panels. The few drivers that support dual-link do
it in an ad-hoc way (e.g. with a driver-specific property in the controller's
device tree to enable/disable the dual-lvds interface), and their
sunxi driver doesn't support dual-lvds at all. Of course my panel is
dual-lvds. Anyway this is a physical feature of the panel so I think
this information should be in the panel entry, not the LVDS controller entry.
To solve this I added a new compatible type: panel-dual-lvds, in addtition to
the specified panel-lvds. There could be other ways to do it, like
different data-mapping. As this is a different physical interface I think
a different panel type is more appropriate, but suggestions are welcome.

I've not finished the tcon part of the LVDS at this time but I'm confident
that this panel interface won't need much changes to get a working display.

The panel driver is incomplete (it misses the backlight handling, and could
also support non-lvds panels) but I'll leave this to someone with the hardware.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--