Re: [PATCH] 8xx: map_page() skip pinned region and tlbie debugging aid

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Thu, 2005-06-30 at 14:05 -0400, Dan Malek wrote:
> On Jun 29, 2005, at 7:31 PM, Benjamin Herrenschmidt wrote:
> 
> >  - The debate between Dan and me here is about the semantics of
> > io_block_mapping().
> 
> My point of discussion is this function needs to be much smarter than
> simply allocating a virtual address space.  We need to track the calls
> so that we can "grow" previous spaces.  A single io_block_mapping()
> should not always allocate a new BAT, CAM or otherwise wired entry.
> It has to know the alignment, size and amount of resource available.
> For example, if an io_block_mapping() requests a 4M space, and it
> isn't possible to wire such a size, we still need to keep track of that
> such that a subsequent 4M request is combined into a space that
> can be wired with an 8M entry.  We need to make it smart enough
> to coalesce the spaces to maximize the use of the available and
> minimal mapping resources.  If io_block_mapping() is just a simple
> functions that decrements a pointer and sets a value in a register,
> then you have already required the caller to know everything about
> the mapping details, so why bother performing "hidden" arithmetic
> that is likely to be known by the caller?  If we are going to change 
> this

Everyting ... but the virtual address, which is quite a bit :) My
problem is really with virtual addresses beeing hard coded, which makes
things complicated every time we try to do something with the kenrel
virtual space. But ....

> let's make it tru
> y useful, so it understands the capabilities of the
> processor, optimizes the resources, and keeps generic mapping
> information so ioremap() doesn't care if it is mapped by BATs, CAMs,
> or large pages.

 ... I do agree that making it even smarter so it can coalesce block
mappings with the same attributes would be "interesting".

Ben.