On Fri, Oct 2, 2015 at 3:40 PM, Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
