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

[Rob Herring]

On Fri, Oct 2, 2015 at 2:18 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> Am Donnerstag, den 01.10.2015, 07:58 -0500 schrieb Rob Herring:
>> On Thu, Oct 1, 2015 at 3:59 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
>> > Am Mittwoch, den 30.09.2015, 12:13 -0500 schrieb Rob Herring:
>> >> On Mon, Sep 21, 2015 at 3:11 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
>> >> > Note how the display-subsystem node overlaps the larb node. Is that
>> >> > acceptable?
>> >>
>> >> Given what the graph looks like, perhaps. However, do you really need
>> >> a container node? It only serves to provide a list of nodes (e.g. all
>> >> the children) to include as components. There are other ways to
>> >> determine this list. You could find all nodes just searching
>> >> compatible strings for each component. You just need to bind the drm
>> >> driver to some other DT node. Is there no node you can pick as the
>> >> master component?
>> >
>> > There is the mmsys clock-controller node at the top of the MMSYS address
>> > space (0x14000000-0x14ffffff):
>> >
>> >         mmsys: clock-controller at 14000000 {
>> >                 compatible = "mediatek,mt8173-mmsys", "syscon";
>> >                 reg = <0 0x14000000 0 0x1000>;
>> >                 #clock-cells = <1>;
>> >         };
>> >
>> > Its register space also contains the MMSYS_CONFIG region that controls
>> > the multiplexers between the display function blocks, so that would be a
>> > good candidate.
>> > No driver binds to this node yet, the clocks are registered with
>> > CLK_OF_DECLARE.
>> >
>> > I'll try to bind to this node and have the driver find sibling nodes
>> > using their compatible strings.
>>
>> That doesn't seem like a good choice since there are other functions
>> in the block. I was thinking one of the display related blocks like
>> whatever block provides the main crtc functions.
>
> Why exactly isn't this a good choice? Since all display function blocks
> are spread throughout the MMSYS address space, using the mmsys driver to
> create the DRM/component master platform driver that collects its
> subdevices sounded logical.

Given it is a syscon, I was assuming there are other unrelated
functions. If everything in it is display related, then it would be a
fine choice.

> Another candidate would be the mutex node, which can synchronize the
> configuration updates to the function blocks in the MMSYS region to
> frame borders.
>
> The hardware blocks that most closely correspond to crtc functionality
> are the two OVL blocks, as Daniel points out. They provide DMA and plane
> composition. But they are equivalent, and there is no single central
> node, same as with the two IPUs on i.MX6.

Just curious, are 2 IPUs represented as 1 or 2 struct drm_device?

> Also, I'd like to keep the possibility of not tying OVL blocks to crtc
> functionality too closely, because there are three more separate RDMA
> units, at least one of which could be used to implement a third pipe in
> the future.
>
> Either way, if we go this path (one driver scanning DT for known
> component driver compatible values), whichever node the master driver
> binds to is a Linux implementation detail, and it should be completely
> hidden from the device tree and binding specs.

Agreed.

Rob