Re: [PATCH v7 3/5] dtc: Document the dynamic plugin internals

[Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Hi Pantelis,

On 05/29/16 21:22, David Gibson wrote:

< massive snip >

>>> What other properties are you envisioning?  (Looking for the architectural
>>> vision that you have.)
>>>
>>
>> Oh, there are a lot of properties that can be provided.
>>
>> For instance you can declare manufacturing info (like part numbers, version numbers,
>> serial numbers that can be used for quirking). You can declare things like load order
>> when you need precedence of overlays (i.e. on the bone the soldered on hdmi output
>> should be disabled when an add on cape with display capability is attached).
>> You can declare resources (i.e. pins or power draw figures) to make a decision
>> whether enabling an expansion board is safe.
>>
>> I’m sure more ideas will come when we put it into wide-spread use.  
> 
> Yeah.  I'm not entirely sure I'm convinced by the specific examples
> given so far.  However, in general I can see the value in providing a
> way we can extend to add more metadata.  The two level structure with
> __overlay__ gives us that, whereas the one level approach doesn't.

I'm not convinced about putting additional properties (beyond "target") in the
fragment nodes.  And I still find the two extra levels of "fragment" nodes and
"__overlay__" nodes extra complexity, and that the complexity is especially
unwelcome if the overlay dts is hand written (as the beagle cape overlays
that I have seen appear to be).  HOWEVER, I learned something new today that
makes me more comfortable with the two extra node levels.  Here is an example:

$ cat ex_1_overlay.dts 

/dts-v1/;

/plugin/;

&tree_1 {
	remote_prop = <0xfeedfeed &foo>;
};

$ dtc -@ -O dts ex_1_overlay.dts 
Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property
/dts-v1/;

/ {

	fragment@0 {
		target = <0xffffffff>;

		__overlay__ {
			remote_prop = <0xfeedfeed 0xffffffff>;
		};
	};

	__symbols__ {
	};

	__fixups__ {
		tree_1 = "/fragment@0:target:0";
		foo = "/fragment@0/__overlay__:remote_prop:4";
	};

	__local_fixups__ {
	};
};

That example is using dtc from:
  url = https://github.com/pantoniou/dtc
  branch: dt-overlays8
  as of commit: 6f4db2fc2354

I do not know if that is current or not.

So the nice thing about that is that the overlay source file does not have to
provide the fragment and __overlay__ nodes.  They just magically appear in the
compiled blob.  Is that behavior that I can count on continuing to exist in dtc?

Note the warning about no reg property in /fragment@0.

The other issue with the device tree source in my example is that I don't think
there is a way to add extra properties to node "fragment@0" in the general case
where there are multiple fragments.  It _is_ possible to add a property as I
show in the next example, but it seems fragile to be able to count on the order
and names of fragments auto generated by dtc.  (And again, I don't really want
those extra properties anyway.)

Example of adding a property to fragment@0:

$ cat ex_1b_overlay.dts

/dts-v1/;

/plugin/;

&tree_1 {
	remote_prop = <0xfeedfeed &foo>;
};

/ {
	fragment@0 {
		another_fragment_prop = "frag property";
	};
};

$ dtc -@ -O dts ex_1b_overlay.dts 
Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property
/dts-v1/;

/ {

	fragment@0 {
		target = <0xffffffff>;
		another_fragment_prop = "frag property";

		__overlay__ {
			remote_prop = <0xfeedfeed 0xffffffff>;
		};
	};

	__symbols__ {
	};

	__fixups__ {
		tree_1 = "/fragment@0:target:0";
		foo = "/fragment@0/__overlay__:remote_prop:4";
	};

	__local_fixups__ {
	};
};


>>> If load manager specific details are appropriate in the devicetree (a whole
>>> different discussion) then maybe a /chosen/load-manager node could exist to
>>> hold them instead of putting them in /, where the patch currently locates
>>> "/* various properties for loader use; i.e. part id etc. */".

-Frank