RFC: Deprecating io_block_mapping

[Benjamin Herrenschmidt]

On Wed, 2005-05-25 at 01:49 -0400, Dan Malek wrote:
> On May 25, 2005, at 1:20 AM, Benjamin Herrenschmidt wrote:
> 
> > 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 ?
> 
> Because you lose the efficiency of mapping with BATs or CAMs.
> 
> > ... The problem is of
> > course allocating the pte pages but how does io_block_mapping() do on
> > CPUS without BAT/CAMs/whatever ?
> 
> It just loads init's page tables directly.
>
> > We have the pgdir, but not the PTE pages...
> 
> The PTE pages are allocated as they are needed.  The PTE pages
> are there :-)

Well, you say "loads init's page tables directly"... well, init starts
with a pgdir, it needs to allocate PTE pages in order to "load" the page
tables with PTEs, thus my question, how does io_block_mapping does
this ? It use the bootmem allocator ? If yes, then that means we can
have ioremap working as well. I'm not completely arguing against
io_block_mapping() but I think it's abused, and thus looking into
encouraging different approaches.

> > No, we have a trick with ioremap_bot, we don't need to get vmalloc 
> > space
> > for ioremap to work early.
> 
> That's only if you have already done something to already allocate BATs
> or CAMs.  On processors that don't  have these, ioremap() would fail 
> because it would think it has to allocate VM space.

The ioremap_bot trick works in whatever case provided MMU_init has been
called so ioremap_bot & ioremap_base are initialized. It would be fairly
easy to turn that into a static init though.

> >  ....  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.
> 
> I think we should make ioremap() smarter and have some board 
> initialization that helps it by setting up BATs, CAMs, or unique page table
> mappings. There is also an interdependence between ioremap() and other IO
> initialization.  In the past some of the fixed addressing was necessary 
> due to assumptions built into IO setup, mapping functions, or macros.  I 
> don't know how much of this is still present.

It depends on the platform I suppose. There is still a few bits in PReP
that I can fix, I'm not sure about embedded.

> > 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).
> 
> Somewhere, at some point, prior to VM setup, we need to forcibly map
> virtual to physical addresses.  These are going to be "hard coded"
> mappings, that's exactly how ioremap_bot is set.  This is why
> io_block_mapping was created in the first place.  Somehow you have
> to specify this mapping before you have a VM allocator to give it to 
> you. :-)

No, you just need to have ioremap_bot (which is in fact "top" not
"bottom", bad naming) initialized to something sane. This is currently
done in MMU_init() but could probably be initialized statically instead.
I do just that on ppc64 and thus can ioremap at any time without needing
to allocate vmalloc space. The vmalloc space is automatically "cap'd" by
ioremap_bot anyway.

> Even if you don't call it io_block_mapping(), you are going to need
> a function that does exactly this.