On Fri, Oct 2, 2015 at 3:40 PM, Philipp Zabel p.zabel@pengutronix.de wrote:
Am Donnerstag, den 01.10.2015, 22:29 +0800 schrieb Daniel Kurtz:
On Thu, Oct 1, 2015 at 8:58 PM, Rob Herring robh@kernel.org wrote:
I was thinking one of the display related blocks like whatever block provides the main crtc functions.
The two "OVL" nodes correspond to the "crtc" functions of the two display pipes in this SoC, we would setup the display-subsystem node like this:
display-subsystem { compatible = "mediatek,display-subsystem";
Yes, the problem with the ovl nodes is that there are two equivalent ones. Having two equivalent ipu nodes on i.MX6 was the reason to introduce the display-subsystem node in the first place, but I'd very much prefer to avoid it, if possible.
Oh, interesting. How is it a problem that there are two equivalent ovl nodes? Why do you prefer to avoid the display-subsystem node?
BTW, what I really meant was for my example was that the 'display-subsystem' 'ports' node lists phandles representing the 'root' nodes for the for the display-subsystem graph. This matches what we did for rk3288.dtsi:
display-subsystem { compatible = "mediatek,display-subsystem"; ports = <&ovl0_out>, <&ovl1_out>; };
[...]
And, any node that needs to poke around in the mmsys_config area, like an ovl, could access it using a phandle <&mmsys> to the common "mediatek,mt8173-mmsys" device, like this:
ovl0: ovl@1400c000 { compatible = "mediatek,mt8173-ovl"; reg = <0 0x1400c000 0 0x1000>; interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_LOW>; clocks = <&mmsys CLK_MM_DISP_OVL0>; iommus = <&iommu M4U_LARB0_ID M4U_PORT_DISP_OVL0>; mediatek,mmsys = <&mmsys>; status = "disabled"; };
I think the ovl node has no business linking to mmsys_config. It's the drm driver code that sets up the pipeline, including the crtc -> encoder connections
My original thinking is that the "ovl" node should link to the mmsys_config since the mmsys_config has the ovl output select registers. An 'ovl' driver would then use the phandle to the syscon to find a regmap to safely access the registers it needs.
One idea to reduce the size of the of_graph would be to just model the entrance/exit points from the MM subsystem in dt. So, instead of: ovl0 -> color0 -> aal -> od -> ufoe -> dsi0 -> dsi-edp-bridge ovl1 -> color1 -> gamma0 -> dpi0 -> hdmi
We can do something like this: ovl0 -> dsi0 -> dsi-edp-bridge ovl1 -> dpi0 -> hdmi
But ... this might be too limiting for some applications.
I'm already worried about having left out the DISP_PATH0 and DISP_PATH1 multiplexers from my DT graph example. There are so many ways to do this slightly wrong and then having to live with the stable bindings, that I'd rather not put an approximation of the real hardware into the device tree. Now that I've heard it is acceptable for one driver to look for its components by their compatible value, I'm leaning towards not describing the graph in the DT.
Sure, it would be interesting to see how that would look, too.
-Dan