On Fri, Oct 15, 2010 at 12:30:48PM -0500, David VomLehn (dvomlehn) wrote: > If this is really a question of needing to dynamically generate the > device tree, then you have no choice. It's worth mentioning, though, > that the device tree compiler (dtc) does have the ability to include > files, making it easier to create and maintain device trees that are > static but which share devices. Yes. In fact, John Bonesio is working right now of polishing the last details of this to allow for example a board-level .dts file to include an SoC level .dts and add/remove/modify nodes as needed. Should be sorted out in a week or two. Once that is done then we'll update the copy of dtc in the kernel (probably looking at the 2.6.38 timeframe realistically). g. > > > -----Original Message----- > > From: linux-mips-bounce@xxxxxxxxxxxxxx [mailto:linux-mips-bounce@linux- > > mips.org] On Behalf Of Grant Likely > > Sent: Thursday, October 14, 2010 6:29 PM > > To: Warner Losh > > Cc: ddaney@xxxxxxxxxxxxxxxxxx; prasun.kapoor@xxxxxxxxxxxxxxxxxx; linux- > > mips@xxxxxxxxxxxxxx; devicetree-discuss@xxxxxxxxxxxxxxxx > > Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs. > > > > On Thu, Oct 14, 2010 at 7:13 PM, Warner Losh <imp@xxxxxxxxxx> wrote: > > > In message: <AANLkTi=UM2p26JJMqv- > > cNh8xACS_KPf_dCst5cgmh5VR@xxxxxxxxxxxxxx> > > > Grant Likely <grant.likely@xxxxxxxxxxxx> writes: > > > : Overall the plan makes sense, however I would suggest the > > following. > > > : instead of 'live' modifying the tree, another option is to carry a > > set > > > : of 'stock' device trees in the kernel; one per board. Of course > > this > > > : assumes that your current ad-hoc code is keying on the specific > > board. > > > : If it is interpreting data provided by the firmware, then your > > > : suggestion of modifying a single stock tree probably makes more > > sense, > > > : or possibly a combination of the too. In general you should avoid > > > : live modification as much as possible. > > > > > > The one draw back on this is that there's lots of different "stock" > > > boards that the Cavium Octeon SDK supports. These will be difficult > > > to drag along for every kernel. And they'd be mostly the same to, > > > which is why I think that David is suggesting the live modification > > > thing... > > > > Okay. Do what makes the most sense for your platform. > > > > g. >
