Re: [PATCH 2/4] sparc: break out some prom device-tree buildingcode out into drivers/of

[Andres Salomon]

On Wed, 30 Jun 2010 15:52:51 -0600
Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:

> On Tue, Jun 29, 2010 at 5:36 PM, Andres Salomon <dilinger@xxxxxxxxxx>
> wrote:
> > On Tue, 29 Jun 2010 15:42:54 -0600
> > Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:
> >
> >> On Tue, Jun 29, 2010 at 9:03 AM, Andres Salomon
> >> <dilinger@xxxxxxxxxx> wrote:
> > [...]
> >>
> >> >  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.
> 
> >(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.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/