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

[Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]

Am Donnerstag, den 01.10.2015, 22:29 +0800 schrieb Daniel Kurtz:
> On Thu, Oct 1, 2015 at 8:58 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.

[...]
> 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

> 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.

> So, I think we should just live with the big graph.
> I would, however, recommend that you move the graph to its own
> mt8173-display-graph.dtsi file which would be #included into a board
> specific .dts file.

Separating the graph out into its own include file would help to make
the main dtsi more readable, though.

> If you let the board .dts include the graph, then we can possibly
> shrink the resulting board specific device tree -
> At first we would make the full graph in one .dtsi as above
> "mt8173-display-graph.dtsi".
> This is the full reference graph that will always work.
>
> Then, if a particular board used a fixed configuration, the system
> integrator could create a smaller graph with just the graph nodes that
> they care about.
> 
> For example, if mt8173-evb only supports a single HDMI output, then
> perhaps you would just
> set up the endpoints for this single fixed function display pipe in
> mt8173-evb-display-graph.dtsi:
[...]

Especially for development boards I'd rather keep all possibilites.
Sure, if nothing is connected to the DSIs, disable them and drop thier
possible connections, but I'd still keep ovl0 for example, because it
could be connected to hdmi, even though the driver doesn't support it.
I realize this was probably just an example, so yes, I think this is a
valid method of reducing device tree size for a given board if
necessary.

regards
Philipp


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html