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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@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.
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.
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.
regards
Philipp
--
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
