On Fri, Oct 2, 2015 at 2:18 AM, Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> 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@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.
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
--
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
