[PATCH 1/2] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.

David Gibson dwg at au1.ibm.com
Thu Nov 6 12:48:56 EST 2008


On Wed, Nov 05, 2008 at 11:33:28AM -0600, Hollis Blanchard wrote:
> On Mon, 2008-11-03 at 15:00 -0500, Josh Boyer wrote:
> > On Mon, 03 Nov 2008 13:55:21 -0600
> > Hollis Blanchard <hollisb at us.ibm.com> wrote:
> > 
> > > On Mon, 2008-11-03 at 11:43 +1100, Benjamin Herrenschmidt wrote:
> > > > > Cropping the size of the memory node.  That was simplest to do from the
> > > > > cuboot wrapper at the time.  If marking it reserved via a reserve map
> > > > > is more elegant and correct, we could do that.
> > > > > 
> > > > > But I will still like to know what about the other way is hairy please.
> > > > 
> > > > I don't like it :-) Bad feeling ... don't like having a memory
> > > > node entry that isn't aligned to some large power of two typically.
> > > 
> > > More specifically, mm/bootmem.c seems to be making the implicit
> > > assumption that memory size is an even multiple of PAGE_SIZE. With 4K
> > > pages, 0xffff000 bytes of RAM fits; with 64K pages it does not.
> > 
> > Hmm..  I dunno what to think about that.  Again, how does mem= play
> > into this?  (I will look myself in a bit, but if someone knows offhand
> > that would be nice..)
> > 
> > > Using the device tree reserve map stuff does indeed seem to solve the
> > > problem. However, I really don't understand the layering in
> > > arch/powerpc/boot at all, so I'll just put this patch out here and
> > > people can play with wrappers and prototypes all they want:
> > 
> > This actually looks pretty nice.  I'll wait for David to Ack the fdt
> > parts.
> 
> David?

Sorry, I've been on leave for a few days.

I assume you mean the new call through to fdt_add_mem_rsv().

Hrm.. currently all the things in fdt_wrapper are hooks called through
dt_ops.  Adding such a trivial wrapper seems a little silly.  There
have been other people wanting to use other libfdt features directly,
knowing that they have a flat tree on their system.  I think it would
be more sensible, I think, to just expose the global fdt pointer, so
that people can use the libfdt functions directly, without having to
go through the wrapper code.

Unless of course there is occasion to use this "add reserve" callback
on real OF systems, in which case it should be a new dt_ops hook.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson



More information about the Linuxppc-dev mailing list