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.
