[PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.

Scott Wood scottwood at freescale.com
Thu Sep 6 13:11:55 EST 2007


On Wed, Sep 05, 2007 at 03:27:31PM -0700, Dan Malek wrote:
> On Sep 5, 2007, at 1:59 PM, Scott Wood wrote:
> 
> >BTW, it seems I misremembered what the conflict was -- it's not with
> >ioremap space, but with the default location of the consistent memory
> >pool (at 0xff100000).
> 
> Change the configuration option to move this somewhere
> else, outside of the wired mapping.

Sure, that'd work too -- though then I'd either have to change the
default for all platforms and hope I didn't break any of them, or have
8xx be different for what might amount to be no reason.

Would any platforms have a problem with setting the default to
0xfd000000?  Anything over 0xfe000000 is particularly likely to conflict
with something.

> As I said in the last message, these lower end processors are very
> resource challenged, and we need to clever about the memory mapping and
> use of the TLBs.  This isn't a place to be creating fancy memory maps
> and algorithms to manage them.

Actually, being slightly fancier by dynamically choosing where to place
the consistent memory pool would have avoided this issue.

I agree that not using a pinned TLB entry for the IMMR sucks, and maybe
I'll do something about it later -- just not right now.  This patchset's
been floating for long enough without expanding its scope further.

> Use maximum mappings whenever possible, configure the memory controller
> to pack as much stuff into this single TLB mapping as possible. 
> Something configurable like this memory pool should not be a reason to
> give up these performance enhancements.

Sure.  I still don't think it's that big of a deal when none of the
currently supported boards have anything useful in the 8MB after the
IMMR (and pinning is only used for the debug console anyway), and custom
boards can always use custom TLB mappings, but moving the coherent region
to somewhere a little more polite is something that we should do anyway.

-Scott



More information about the Linuxppc-dev mailing list