RFC: Deprecating io_block_mapping
benh at kernel.crashing.org
Fri May 27 08:13:40 EST 2005
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.
More information about the Linuxppc-dev