linux-mips
[Top] [All Lists]

Re: Device Tree questions WRT MIPS/Octeon SOCs.

To: Warner Losh <imp@bsdimp.com>
Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.
From: Grant Likely <grant.likely@secretlab.ca>
Date: Thu, 14 Oct 2010 19:29:09 -0600
Cc: ddaney@caviumnetworks.com, prasun.kapoor@caviumnetworks.com, linux-mips@linux-mips.org, devicetree-discuss@lists.ozlabs.org
In-reply-to: <20101014.191309.515504596.imp@bsdimp.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4CB79D93.6090500@caviumnetworks.com> <AANLkTi=UM2p26JJMqv-cNh8xACS_KPf_dCst5cgmh5VR@mail.gmail.com> <20101014.191309.515504596.imp@bsdimp.com>
Sender: linux-mips-bounce@linux-mips.org
On Thu, Oct 14, 2010 at 7:13 PM, Warner Losh <imp@bsdimp.com> wrote:
> In message: <AANLkTi=UM2p26JJMqv-cNh8xACS_KPf_dCst5cgmh5VR@mail.gmail.com>
>            Grant Likely <grant.likely@secretlab.ca> 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.

<Prev in Thread] Current Thread [Next in Thread>