Hi, Based on the outcomes of the "Best practice device tree design for display subsystems" discussion I have drafted a DT binding. Comments much appreciated. At a high level, it uses a "super node" as something for the driver to bind to, needed because there is no clear one device that controls all the others, and also to distinguish between the Armada 510 possible use cases of having one video card with two outputs, or two independent video cards. It uses node-to-node linking beyond that point, V4L2 style. I have some questions still: 1. What names does the Armada 510 datasheet give to the components? Below I renamed the "LCD controllers" (which don't control LCDs on any of the current target hardware) to "display controllers". For what we were previously referring to as DCON, I renamed to "output selector". I would like to match the docs. Actually the output selector is not mentioned as per Sebastian's suggestion, but I believe it would fit in the below design once the first user comes along (e.g. it would slot in the graph between dcon0 and tda99x). 2. On that topic, what names does the Armada 510 datasheet give to the available clocks? Lets make them match the docs. 3. What is the "remote" property in the video interfaces binding? Doesn't seem to be documented. But I think I copied its usage style below. Marvell Armada Display Subsystem Design considerations --------------------- The display device that emerges from this subsystem is quite heavily componentized and the formation of the composite device will vary by SoC and by board. The DT binding is designed with this flexibility in mind. For example, there are 2 display controllers on the Armada 510. They could legitametely be used to form two independent video cards, or they could be combined into a single video card with two outputs, depending on board wiring and use case. As there is no clear component that controls the other components, especially when we wish to combine the two display controllers into one virtual device, we define a top-level "super node" that describes the basic composition of the overall display device. That node uses phandles to define the start of the graph of display components. In the bindings for the individual display components, phandle properties are used to represent direct, fixed links to other components. We use the port/endpoint abstraction from bindings/media/video-interfaces.txt to represent these links. display super node ------------------ Required properties: - compatible: "marvell,armada-display" - marvell,video-devices : List of phandles to the display controllers that form this composite device. Optional properties; - reg: Memory address and size of a RAM allocation designated as graphics memory - linux,video-memory-size: If reg is not provided, this property defines how much memory to cut out of regular available RAM to be used as graphics memory. display-controller node ----------------------- Required properties: - compatible: "marvell,armada-510-display", "marvell,mmp2-display" or "marvell,mmp3-display" - reg: Register space for this display controller - clocks: List of clocks available to this device. From common clock binding. - clock-names: Names of the given clocks (see below) - ports: From video interface binding Valid clock names for Armada 510: extclk0 extclk1 axi pll Valid clock names for MMP2: lcd1 lcd2 axi hdmi Valid clock names for MMP3: lcd1 lcd2 axi hdmi dsi lvds Example: display { Â Â compatible = "marvell,armada-display"; Â Â Â reg = <0 0x3f000000 0x1000000>; /* video-mem hole */ Â Â Â marvell,video-devices = <&dcon0>; Â Â }; dcon0: display-controller@20000 { compatible = "marvell,armada-510-display-controller"; Â Â Â reg = <0x20000 0x1000>; Â Â Â interrupts = <47>; Â Â Â clocks = <&ext_clk0>; Â Â Â clock-names = "extclk0"; port { dcon0_1: endpoint { remote = <&tda998x>; }; }; }; &i2c0 { Â Â tda998x: hdmi-transmitter@60 { Â Â Â compatible = "nxp,tda19988"; Â Â Â Â reg = <0x60>; port { tda998x_1: endpoint { remote-endpoint = <&dcon0_1>; }; }; Â Â Â }; };
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel