From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: [PATCH 8/9 V3] Add documentation for the new DTS language. Date: Mon, 1 Mar 2010 17:10:19 -0700 Message-ID: References: <1222460748-20127-3-git-send-email-jdl@jdl.com> <20081001034656.GF30810@yookeroo.seuss> <20100222013004.GM29038@yookeroo> <9696D7A991D0824DBA8DFAC74A9C5FA305B2021A@az33exm25.fsl.freescale.net> <4288fc0b-79a4-42fd-9e77-573dbad79210@SG2EHSMHS004.ehs.local> <4B8C2C4C.8070901@freescale.com> <4B8C44C8.6000105@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4B8C44C8.6000105-KZfg59tc24xl57MIdRCFDg@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: Scott Wood Cc: Wood Scott-B07421 , devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org, Yoder Stuart-B08248 , Jeremy Kerr , John Williams List-Id: devicetree@vger.kernel.org On Mon, Mar 1, 2010 at 3:50 PM, Scott Wood wrote: > Grant Likely wrote: >> >> On Mon, Mar 1, 2010 at 2:06 PM, Scott Wood >> wrote: >>> >>> Hmm, I'd think it would be useful to e.g. include a template and >>> subsequently modify it within the same node, rather than a more verbose >>> and >>> error-prone process of referencing labels later. >>> >>> If sequential operations within a tree are supported, I'm not sure that >>> there's any remaining need for separate top-level trees -- you could >>> express >>> the same thing as top-level property/node redefinitions. >>> >>> What are the problems with supporting this? >> >> The main problem is that it doesn't fit the use cases I need to solve. >> =A0I need to start with a 'stock' or 'vanilla' tree, and then add into >> it board details. =A0ie. lay down a generic MPC5200 tree (include a .dts >> file), and then fill it in with i2c and spi devices. =A0Or include the >> .dts file generated by the XIlinx FPGA toolchain, and then populate it >> with board details. =A0Sequential 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. >> >> To reverse the question, what is the use case that is best solved with >> sequential operations within the root tree? > > The case I had in mind was having includable templates for fragments of t= he > tree, rather than starting with a generic full tree. =A0Though I'd probab= ly > end up wanting things like template arguments and math as well (is any > existing macro language going to do cell arithmetic?), so the focus on th= at > kind of use case at this point should probably be limited to not defining > syntax that's going to make things harder on future language extensions. > =A0The only thing that immediately comes to mind from that perspective is= that > symbols are a more limited resource than keywords. Right. I thought about that too, and came to the conclusion that while it might be nice to have templates and the like, it isn't as big a deal as handling all the crazy board files duplicating the SoC bits and subtly changing bits all through the tree. At least after the SoC .dts is written, even if it has a lot of similar nodes, it doesn't really need to have bits added or removed from it on a regular basis. And on the FPGA, we've got a real programming language (well, TCL) to do complex tree generation with. >>> If you don't reuse the label, but bar is redefined, where does bar-label >>> point? >> >> It doesn't point to anything because when a property is deleted, the >> label also goes away. > > Is it the same way with node labels? yes > =A0What happens to previous references? They are either already resolved (in the case of node redefines at the top level), or they will fail. > =A0Is it detected by dtc, or does a bad phandle/path stick around to be f= ound > at runtime? =A0And what if the node is added back? All phandles are resolved after the tree is fully parsed. This could probably use more thought/discussion to think about the implications. >>> =A0There may be cases where a dts fragment A doesn't know whether >>> fragment B will have defined something, and fragment A wants to make su= re >>> it >>> ends up undefined one way or another. >> >> Later fragments should always override earlier ones. =A0So if A is >> defined before B, then B can override anything that A does. > > Sorry for the confusing enumeration -- A comes after B. > > To put it in more concrete terms, suppose you're writing an update wrapper > around the autogenerated FPGA dts. =A0In some configurations a given > node/property will be autogenerated, in others not -- but you want the > wrapper to make sure it's gone, because it doesn't work with the system t= he > FPGA is connected to. > > If it's an error to delete something that doesn't exist, you'd have to ha= ve > two update trees, first adding/replacing the thing in question to make su= re > it's there, and the second to delete it. > > Allowing such an operation also lines up better with your suggestion to > think of it as masking, rather than deleting. This is a good argument. Let me think about it for a bit, but I think you're probably right. -- = Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.