On Wed, 30 Jun 2010 15:52:51 -0600
Grant Likely [off-list ref] wrote:

On Tue, Jun 29, 2010 at 5:36 PM, Andres Salomon [off-list ref]
wrote:

quoted

On Tue, 29 Jun 2010 15:42:54 -0600
Grant Likely [off-list ref] wrote:

quoted

On Tue, Jun 29, 2010 at 9:03 AM, Andres Salomon
[off-list ref] wrote:

[...]

quoted

quoted

 Sparc and OLPC have very similar
mechanisms for getting device tree info from OFW, so it makes
sense to share code between them.

Other than the flattened tree step; is the powerpc method
dissimilar from the Sparc and OLPC method for talking to OFW?
 (This is not a rhetorical question, I'm want to know if I'm
missing some details). The main difference I know about is that
OFW can still kept alive at runtime for sparc, which powerpc does
not do.  However, keeping OFW callable is a separate issue from
how to extract the device tree.

After having a look at powerpc's flatten_device_tree, I don't see
any obvious reason why OLPC couldn't use this

Okay.

quoted

(though it still strikes me
as weird to go from prom->fdt->dt when the option of prom->dt is
available and less complex).

Which is why I didn't simply NACK it out of hand.  It is a valid
point.

I'd probably be happier if both fdt and pdt used a shared set of
utility functions for allocating and tying together the device_node
data structures.  Then at least there would be only one instance of
code to deal with the fiddly data structure interconnections.

The problem with unifying it is that both methods have different
assumptions; the fdt determines the size of the unflattened dt in
advance, and allocates a contiguous block of memory up front (the
memory block being smaller than the pdt memory usage because various
strings are already present in the fdt, so the unflattened tree simply
points at those strings).  The pdt, otoh, allocates more memory as the
tree is discovered (by calling into the prom).

Possible options include:

 - For the pdt, calling into the prom twice for each property/node,
   getting the size of everything during the first tree traversal,
   allocating memory, and then creating the tree during the second
   traversal. This is slow and I don't see much point to it.

 - For the pdt, calling into the prom once for each property/node to
   create a fdt, and then unflattening it.  This is better than the
   previous option, but I don't think the prom->fdt code will be very
   nice.

 - Changing the fdt code to allocate memory more dynamically; rather
   than a first run through the fdt to determine the unflattened tree
   size, simply allocate memory chunks as we run through the tree.
   Memory might still be backed the same way (calling
   early_init_dt_alloc_memory_arch to grab a chunk of memory, and then
   allocating chunks of it via unflatten_dt_alloc), but the difference
   would be that it wouldn't necessarily be contiguous, and in how it's
   done.  For example, early_init_dt_alloc_memory_arch might be called
   initially to allocate a 16k chunk, and once unflatten_dt_alloc runs
   out of memory in that chunk, another 16k chunk might be allocated.
   This would also translate to sparc's prom_early_alloc being used to
   allocate the chunk, and then node/property structs being
   allocated from those chunks.  (The 16k choice
   is completely arbitrary; people more familiar w/ the early memory
   setup of ppc/sparc might have a better suggestion)

That last option is what I think makes the most sense; however, are
there technical reasons (other than how unflatten_device_tree is
written) that the unflattened dt must be in a contiguous memory
region?  The chunk allocation code would be backed by things like
__alloc_bootmem and lmb_alloc, and the dt_alloc code would be new code
that simply tracks the amount remaining in a list of chunks, and
allocates a new chunk if necessary.

The nice thing about the powerpc version is that the tree can be
extracted really early in the boot process, before any of the core
kernel infrastructure or memory management is initialized.