RFC: Deprecating io_block_mapping

Benjamin Herrenschmidt benh at kernel.crashing.org
Wed May 25 12:21:39 EST 2005


On Tue, 2005-05-24 at 21:17 -0500, Kumar Gala wrote:
> On May 24, 2005, at 8:30 PM, Benjamin Herrenschmidt wrote:
> 
> > As the subject says ... it's the source of endless headaches, is used 
> > in
> > a way that often prevents moving TASK_SIZE freely, etc etc etc...
> >
> > What are the good and unavoidable uses of it currently that cannot be
> > replaced by some sort of ioremap ?
> 
> Do you propose to fixup ioremap to allocate large page resources (BATs 
> and CAMs) going forward?

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

> > (Note that if the answer to the above is: page tables exist too late, I
> > already have a reply: our initialisations happen too early, let's move
> > things around so that ioremap is useable... pretty much everything
> > needed to setup kernel page tables & have working ioremap can be done
> > without any HW device access so ...)
> 
> Do you have any proposed solution for early console access?  I'm 
> guessing that most of the need for early access is for some sort of 
> console (serial) for early debug output.

How do we implement io_block_mapping() on CPUs without a hash table ? We
need page tables for these so we can have ioremap working. 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.

> Also does this mean we would drop ppc_md.setup_io_mappings() complete?

Does it really make sense ? I always disliked it.

Ben.






More information about the Linuxppc-embedded mailing list