[RFC/PATCH v2] powerpc: add ioremap_early() function for mapping IO regions before MMU_init()

[Grant Likely]

On Thu, Aug 14, 2008 at 1:59 PM, Kumar Gala <galak at kernel.crashing.org> wrote:
>
> On Aug 14, 2008, at 11:43 AM, Grant Likely wrote:
>
>> On Thu, Aug 14, 2008 at 10:24 AM, Kumar Gala <galak at kernel.crashing.org>
>> wrote:
>>>>>
>>>>> what happens if we run out of bats?
>>>>
>>>> Then it returns NULL and the caller must handle it.  The board port
>>>> maintainer needs understand the board/CPU/SoC and not depend on more
>>>> BATs than are available.  They also need to understand that there is a
>>>> tradeoff between BATs for IO and BATs for RAM.  If the board port uses
>>>> up all the BATs for IO, then RAM above 256MB ends up getting mapped
>>>> with PTEs and there is a performance hit.  My expectation is that only
>>>> platform code will use this facility.  Device drivers should continue
>>>> to use ioremap() and will gain the benefit of the BATs if platform
>>>> code already set them up.  I can add some text to the documentation to
>>>> describe this.
>>>>
>>>> I'm not going to make any attempt to fallback to PTEs for IO when
>>>> there isn't enough BATs.  Doing so adds an order of magnitude more
>>>> complexity.
>>>
>>> that's fine.. I just didn't look at setbat() to see it errors out.
>>>
>>> Also can we get rid of LOAD_BAT in head_32.S?
>>
>> Mostly.  It is still needed for BAT0 when setting up RAM, but the rest
>> of it can be dumped.
>
> Can we not do BAT0 in C code?

Not easily.  Currently BAT0 gives us the first 16M of RAM during early
boot.  The new code protects BAT0 and makes sure it can only be used
for mapping RAM.  If it got chosen for an IO mapping, then it would
get blown away immediately and the kernel would crash.  Its okay for
BAT0 to be used for RAM because RAM doesn't need to be immediately
mapped.  It can wait just setup the data and wait for LOAD_BAT to fix
it up.

An alternate solution is to reserve a second BAT higher up to use as
the 'real' RAM mapping so that 'real' mapping of RAM could be
performed immediately while leaving the old one intact.  That would
eliminate the need for LOAD_BAT, but it also leaves only 2 BAT slots
available for IO and memory above 256M.  On the other hand, it might
be okay to release the reserved BATs after the first real RAM mapping
is established, but doing so adds some complexity to the handling of
__map_without_bats because the initial mapping still needs to be
disabled in head_32.S.

g.