[RFC v2 1/4] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding

[Daniel Kurtz]

On Fri, Oct 2, 2015 at 3:40 PM, Philipp Zabel <p.zabel at 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 at 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 at 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