[RFC PATCH 14/19] powerpc: allow ioremap within reserved fake ram regions

[Michael Ellerman]

On Tue, 2009-11-24 at 18:09 +0100, Albert Herranz wrote:
> Michael Ellerman wrote:
> >> Would it be acceptable to create a global var __allow_ioremap_normal_ram that by default would have a value of 0 and would be set _only_ for those platforms needing it?
> >>
> >> The other solutions I see is:
> >> - add support for discontiguous memory to powerpc 32-bits (which is not something that I can look into now)
> >> - don't use the precious second 64MB area (which is a waste)
> > 
> > - Implement your own ppc_md.ioremap(), see iseries & cell for example.
> > 
> > Currently that's only called on 64-bit, but you could change that.
> > 
> > If I'm reading your patch right, you should be able to do that check in
> > your platform's ioremap() and then call the generic implementation to do
> > the actual work.
> > 
> > cheers
> 
> I could use ppc_md.ioremap to duplicate ioremap except for the ioremap ram check.
> But calling the stock ioremap without modifying it is not possible
> because it checks and bails out when ioremapping a region marked as
> ram (even if it's not real ram and it's memreserved).

OK, that wasn't clear in your patch. It looks like you're adding a check
(!__map_without_bats) - but whatever.

> Is the list of memreserved areas preserved once the kernel is running?
> If it is preserved another option would be to unban ioremapping ram if memreserved.

Yeah it is, so that might work, though it's still a bit of a hack :)
But if that's just a stop-gap until sparse mem gets going on 32-bit
maybe that's OK.

cheers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20091125/66524994/attachment.pgp>