Re: RFC: Deprecating io_block_mapping

On Wed, 2005-05-25 at 01:14 -0400, Dan Malek wrote:

On May 24, 2005, at 10:21 PM, Benjamin Herrenschmidt wrote:

quoted

Do we really ever need them for anything but RAM mapping ?

Of course.  We use BATs and CAMs to address a variety of
mapping options.

quoted

How do we implement io_block_mapping() on CPUs without a hash table ?

What does a hash table have to do with anything?  The io_block_mapping()
is most important on processors that don't have them, like 8xx, 82xx, 
83xx,
and 85xx.   The hash table in Linux is just an unfortunate staging area 
for PTEs.

Sorry, I meant BATs or equivalent... (see POWER4 for example who has
none of this)

The io_block_mapping() simply loads BATs, CAMs, or init's page tables.

Ok, that was my point... since init page tables can be loaded by it, why
not make ioremap work that early and do the same ? The problem is of
course allocating the pte pages but how does io_block_mapping() do on
CPUS without BAT/CAMs/whatever ?

quoted

.....  We
need page tables for these so we can have ioremap working.

The problem is you need more than page tables.  We have kernel page
tables very early in the initialization.  

We have the pgdir, but not the PTE pages...

The problem with ioremap() is if you
haven't done something (like io_block_mapping()) to set up BATs or CAMs,
it will call vmalloc() to get some VM space.  This is where the problem 
lies.

No, we have a trick with ioremap_bot, we don't need to get vmalloc space
for ioremap to work early. In fact, it would be nice to just have
io_block_mapping be able to "dynamically" allocate virtual space using
the same mecanism instead of beeing passed a virtual address. That would
fix most of the problems with hard coded 1:1 mappings.

quoted

... On CPUs with
a hash, we could just shove entries in the hash... though we may need a
mecanism to bolt them or convert those mappings to page tables once
those are available.

We don't need anything that complicated.  As I said, this already works 
on
all processors that don't have hash tables.

We need to make ioremap() much, much smarter, plus we need some kind
of board specific function to set up the BATs or CAMs, like 
io_block_mapping()
does today.

Well, my problem is with hard-coded v:p mappings... If we can simply
have io_block_mapping take, for example, 0 for v (or -1) and use the
ioremap_bot trick to "allocate" virtual space, that would make me happy
(it needs to return the allocated address too).

Ben.