From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson Subject: Re: dtsi vs dts files, where to better understand this Date: Thu, 22 Mar 2012 12:01:45 +1100 Message-ID: <20120322010145.GH15997@truffala.fritz.box> References: <89736f85-54aa-4f71-814e-91ae5ce33bdc@VA3EHSMHS017.ehs.local> <4F6A3BD3.4040805@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: John Linn Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org List-Id: devicetree@vger.kernel.org On Wed, Mar 21, 2012 at 02:50:09PM -0600, John Linn wrote: > > -----Original Message----- > > From: Stephen Warren [mailto:swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org] > > Sent: Wednesday, March 21, 2012 1:37 PM > > To: John Linn > > Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org > > Subject: Re: dtsi vs dts files, where to better understand this > > > > On 03/21/2012 12:36 PM, John Linn wrote: > > > Hi, > > > > > > I've done some digging and not found any info, maybe I looked in the > > > wrong places. > > > > > > I'm trying to better understand how the dtsi file works with the dts > > > file and what can go in each file. > > > > The basic idea is that what's inside the SoC is identical across all > > boards using that SoC. This information is put into the .dtsi file so > > it > > can be included by the .dts file for any boards using the SoC. > > > > Anything that's board-specific goes into the board's individual .dts > > file. This might be new nodes to e.g. define which chips are connected > > to an I2C bus hosted by the SoC, and much more. > > > > Where properties existing in both, the most recent value in parsing > > order overrides any earlier values. So for example, if the .dtsi file > > said that 'status = "disabled"' for a particular HW module, the board > > .dts could later override it by saying 'status = "okay"' within the > > same > > node. > > > > One other factor: Something like an SDHCI controller may have > > properties > > that are defined by the SoC (e.g. compatible, reg, interrupts), and > > properties that are defined by the board (e.g. the GPIO ID to use for > > CD, WP, etc.). Just set the relevant properties in the .dtsi and .dts > > files and they'll get merged together to form the final device tree. > > > > Was that what you were looking for? > > That was very helpful. I was hoping there were details written > somewhere I had missed. My apologies if I'm just not getting it yet :) > > It's not clear to me how the hierarchy is maintained across both files > such as an i2c controller would be in the dtsi, while the i2c eeprom on > the bus is in the board file. > > Do I have to duplicate the i2c controller (and the bus it's on also) in > the board file? It's not clear how smart the merge is. > > The examples in the 3.3 tree don't seem that clear to me yet. The model used by dtc for this is a "stack of overlays". Once the /include/s are processed you effectively have one big dts file with several partial trees specified one after another. The first one always starts at /, the later ones can start at / but more likely start at a subtree of the first tree, specified by a path or a label. dtc then starts with the first tree and lays the later trees over it in order. If the same property is specified in a later tree, it replaces the value from an earlier tree. If the same node is specified, its properties and subnodes are merged into the existing version. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson