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,
let's make it truly 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.
Thanks.
-- Dan
