[parisc-linux] Strange newest LAB msg?

[James Bottomley]

On Sun, 2006-04-02 at 19:28 -0600, Grant Grundler wrote:
> Unfortunately not. Not unless you want to disable IO Port space access.
> Each PCI bus controller routes 64MB of GMMIO space to 64KB of IO port space.
> The first 4 bytes of each page maps to a unique 4 byte in IO Port space.
> 
> On Astro platforms, we can use 64KB in LMMIO space to access
> IO Port space for all busses. The difference is Astro only
> has one SBA and IOC. N-class has two. There's more to this
> and I'm not sure of all the details at the moment.
> 
> 240MB is clearly not going to be enough on that machine.
> Even on a "normal" machine, a couple of graphics cards
> would exhaust the 240MB.  A single infiniband card could
> exhaust the 240MB space we have now.

OK, could someone explain what we're trying to do and why?

The original PA implementation of ioremap actually had I/O space and
memory space separated (this is almost essential on 32 bit machines with
lots of memory).

The new implementation is trying to map our I/O space directly into
memory.  Because of the way PA is implemented: no highmem, entire memory
offset mapped at 0x1000000; that means the only space we have for kernel
VM is 0-0x10000000 (On 32 bits, this offset mapping loses us the top
256k on 4GB machines, but that's f space anyway).  However, our vmalloc
space is very squeezed at 240k (remember, all modules have to be in
vmalloc space), so trying to share it with I/O mappings looks to be a
bit of a non-starter.

I suggest that on 32 bits, we really shouldn't alter the current scheme
(i.e. keep the separated I/O and  memory mappings).  On 64 bits, we
could allocate a far different VM range to vmalloc (somewhere up beyond
the maximum possible physical memory) and thus make it far bigger, which
would allow us to keep a mapped ioremap implementation.

Oh, and just before anyone suggests it, we'd have incredible difficulty
moving __PAGE_OFFSET because of the absolute<->virtual equivalence
requirements.

James