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 19:08:19 -0700 Message-ID: References: <1222460748-20127-3-git-send-email-jdl@jdl.com> <20100222013004.GM29038@yookeroo> <9696D7A991D0824DBA8DFAC74A9C5FA305B2021A@az33exm25.fsl.freescale.net> <4288fc0b-79a4-42fd-9e77-573dbad79210@SG2EHSMHS004.ehs.local> <4B8C2C4C.8070901@freescale.com> <1012f9aa-1642-41ab-b8cd-a4ab4a7b269e@VA3EHSMHS024.ehs.local> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: 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: Stephen Neuendorffer Cc: Wood Scott-B07421 , devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org, Yoder Stuart-B08248 , Scott Wood , Jeremy Kerr , John Williams List-Id: devicetree@vger.kernel.org On Mon, Mar 1, 2010 at 5:13 PM, Stephen Neuendorffer wrote: >> >> 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. >> > >> > Aside: I always pictured this the other way round, where the DTS for an >> > FPGA design includes the DTS for the board. =A0Then again, as long as = they >> > are independent, it probably doesn't matter. >> >> Heh, interesting. =A0Yeah, I suppose it could be done that way too. =A0T= he >> /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. =A0I 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 de= sign... :) > Or maybe 'some' FPGA designs are that way and others are not. Ah, but even the board file has to change depending on the FPGA design, and nodes will move around depending on the FPGA internal bus structure, but I understand what you're saying. This is why being able to redefine labelled nodes is a critical feature. For instance, the following isn't actually very useful because it assumes knowledge of the exact location of the i2c bus node: / { plb@0 { ranges; i2c@c0000000 { #address-cells =3D <1>; #size-cells =3D <1>; reg =3D <0xc0000000 0x1000>; }; }; }; / { plb@0 { i2c@c0000000 { rtc@0 { reg =3D <0>; }; eeprom@1 { reg =3D <1>; }; }; }; }; However, the following is really useful because the xilinx toolchain already generates the device labels, and the i2c node can move without breaking the board devices: / { plb@0 { ranges; i2c-bus-0: i2c@c0000000 { #address-cells =3D <1>; #size-cells =3D <1>; reg =3D <0xc0000000 0x1000>; }; }; }; &i2c-bus-0 { rtc@0 { reg =3D <0>; }; eeprom@1 { reg =3D <1>; }; }; And this way the Platform Studio toolchain doesn't need to be taught anything about the board layout. A board file could look something like this: /include/ "fpga-design-file.dts" &i2c-bus-0 { rtc@0 { reg =3D <0>; }; eeprom@1 { reg =3D <1>; }; }; Now, if we're talking about Xilinx eval boards, I can see the argument for having a stock file like ml507.dts, and then a project .dts file might look something like this: /include/ "fpga-design-file.dts" /* Map between FPGA device names and ML507 board file labels by applying the ml507 labels to the nodes from the FPGA file */ ml507-i2c-bus-0: &fpga-i2c-bus-0 { }; ml507-i2c-bus-1: &fpga-i2c-bus-1 { }; /include/ "ml507.dts" This needs new syntax of course, but you get the idea, and it doesn't require teaching the FPGA toochain all kinds of details about the board or project files. > Yes... I think this should just be allowed... or at the very least I don'= t see a > reason to make this an error... =A0It does occur to me that it might be u= seful to > explicitly note the 'extension' of a previous node, which asserts that it= *must* > exist. =A0i.e. > > foo { > =A0 =A0 =A0 =A0bar + { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bar =3D 3; > =A0 =A0 =A0 =A0} > } > > Here it is explicitly clear that bar is an incomplete definition? hmmm... I don't think I like this so much, and I don't yet see a use case where this is really a required feature. g.