linux-mips
[Top] [All Lists]

Re: Device Tree questions WRT MIPS/Octeon SOCs.

To: David Daney <ddaney@caviumnetworks.com>
Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.
From: Grant Likely <grant.likely@secretlab.ca>
Date: Thu, 14 Oct 2010 18:32:00 -0600
Cc: devicetree-discuss@lists.ozlabs.org, linux-mips <linux-mips@linux-mips.org>, Prasun Kapoor <prasun.kapoor@caviumnetworks.com>
In-reply-to: <4CB79D93.6090500@caviumnetworks.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4CB79D93.6090500@caviumnetworks.com>
Sender: linux-mips-bounce@linux-mips.org
Hi David.

On Thu, Oct 14, 2010 at 6:17 PM, David Daney <ddaney@caviumnetworks.com> wrote:
[...]
> I want to convert this to use the device tree and related functions.
>
> Since none of the existing hardware has an existing device tree I plan on
> taking a two pronged approach.
>
> Modify platform drivers to get configuration information from the device
> tree.  Then:
>
> 1) Load and use a dtb blob as specified on the kernel command line.
>
> 2) If no command line dtb specified, use a default dtb embedded in the
> kernel image and then edit or patch it using of_attach_node(),
> of_detach_node(), prom_remove_property(), and prom_add_property() based on
> some of the the same ad hoc code we currently use.
>
> Q: As a very high level plan does this make any sense?

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.

g.

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