RFC: Deprecating io_block_mapping

[Benjamin Herrenschmidt]

On Thu, 2005-05-26 at 13:30 -0700, Mark A. Greer wrote:
> Benjamin Herrenschmidt wrote:
> 
> > - There is _one_ important point to keep in mind, but that has always
> >been true: None of this work before MMU_init(), 
> >  
> >
> 
> This is very true and raises a couple issues that we should fix while 
> we're at it:
> 
> 1) There are progress calls in MMU_init which will try to access the 
> uart before its possible to create a mapping to the uart's regs 
> (assuming you don't make a hack to map them and that you set up 
> ppc_md.progress in your platform_init routine).  We should either get 
> rid of those calls in MMU_init, provide an acceptable way to make 
> temporary pre-MMU_init mappings, or make sure nobody sets up 
> ppc_md.progress until ioremap is working (and also get rid of the calls 
> in MMU_init b/c they're never used).

Or have the implementation of progress() check if the mapping was done
or not ... In any ways, I always disliked ppc_md.progress deeply. It's
ugly and clutters the code. It has never proven very useful to me vs.
having an early console.

> 2) Some firmwares don't provide any info on how much memory is in the 
> system but MMU_init needs to know that.  So the platform code has to 
> read the SPD from the mem sticks via i2c, read the mem ctlr, or read a 
> board reg that has the info.  All of those require access to hw regs 
> before or during MMU_init.  I should be able to get rid of this one by 
> figuring out the amount of memory in the bootwrapper and passing it in 
> to the kernel.  I am assuming that all the boards with this problem use 
> the bootwrapper.  I think that's a safe assumption but I'll have to verify.

Yes, the boot wrapper is the way to go here.

> BTW, these are the reasons that I made that set_bat hack that Dan is so 
> fond of.  :)  I'll get rid of that hack but I need an answer to 1) first.
> 
> Mark