[PATCH 8/9 V3] Add documentation for the new DTS language.

[Stephen Neuendorffer]

> >> The main problem is that it doesn't fit the use cases I need to solve.
> >>  I need to start with a 'stock' or 'vanilla' tree, and then add into
> >> it board details.  ie. lay down a generic MPC5200 tree (include a .dts
> >> file), and then fill it in with i2c and spi devices.  Or include the
> >> .dts file generated by the XIlinx FPGA toolchain, and then populate it
> >> with board details.  Sequential operations within the tree doesn't do
> >> anything to support this use case because the board level fixups will
> >> be applied all over the tree.
> >
> > Aside: I always pictured this the other way round, where the DTS for an
> > FPGA design includes the DTS for the board.  Then again, as long as they
> > are independent, it probably doesn't matter.
> 
> Heh, interesting.  Yeah, I suppose it could be done that way too.  The
> /include/ directive works pretty much anywhere in the input file, so a
> file could either lay down a structure and then include a modifer, or
> include a structure and then modify it.  I was thinking in terms of
> the board file including the FPGA file because it matches the pattern
> for say an SoC where there would be a common SoC .dts file and all the
> boards using that SoC would include it.

Yeah, but in FPGA, the board is likely to be more stable than the FPGA design... :)
Or maybe 'some' FPGA designs are that way and others are not.  

> Also, I was thinking that the SoC or FPGA structure needs to be layed
> down first so that the board file has nodes in the tree to anchor new
> nodes to.  For example, the FPGA's i2c controller needs to be in place
> so that i2c devices can be grafted onto it.

Hmm... I think we should try it and make sure that things will work... 
I started to make a 'test case' based on a real system, but all the
device trees I have lying around are moldy and full of dry rot.  I think it should be able
to work either way...

> >> > There may be cases where a dts fragment A doesn't know whether
> >> > fragment B will have defined something, and fragment A wants to make sure it
> >> > ends up undefined one way or another.
> >>
> >> Later fragments should always override earlier ones.  So if A is
> >> defined before B, then B can override anything that A does.
> >
> > So the idiom to do this safely would be:
> >
> > foo {
> >        bar {} // Ensure that bar exists.
> > }
> > foo {
> >        delete(bar);
> > }
> >
> > Seems baroque, but OK...
> 
> Just to make sure I understand you, what bit is striking you as
> baroque?  The bit about the node needing to exist before it can be
> deleted?

Yes, since there is a bizarre workaround I show above, which basically ensures that
the error never occurs.

> Scott does make a good point in one of his emails, especially within
> the 'stack of overlays' model.  Maybe it should be perfectly fine to
> mask a node or property, regardless of whether or not it exists in the
> previous tree.  Maybe this should be just fine:
> foo {
> };
> foo {
>        mask-node(bar);
> };

Yes... I think this should just be allowed... or at the very least I don't see a
reason to make this an error...  It does occur to me that it might be useful to
explicitly note the 'extension' of a previous node, which asserts that it *must*
exist.  i.e.

foo {
	bar + {
		bar = 3;
	}
}

Here it is explicitly clear that bar is an incomplete definition?

Steve




This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.