On Wed, 12 Mar 1997, Gordon W. Ross wrote:

> > From: "Chris G. Demetriou" <cgd@cs.cmu.edu>
> > Date: Wed, 12 Mar 1997 11:28:59 -0500
> 
> Drivers really need some function that is sort of the inverse of
> pmap_phys_address(), and which allows the driver to specify which
> address space they intend to refer to on machines with more than
> one of them.  Sun boxes have "on-board I/O", "on-board memory",
> and possibly "VME D16", "VME D32".  Which you get is determined
> by some "address space type" bits in each page table entry.

Are you explicitly using the ASI or are you using the MMU to map regions
from I/O ASIs into the kernel address space?  See below.

> 
> > > Seems that things would be simpler if mmap returned
> > > phys addresses.
> 
> Doesn't solve the need for an address space specifier...

On some machines it is quite possible that the physical address exceeds
the size of the virtual address space.  As mentioned above, the SPARC v8
physical address logically includes an 8-bit ASI (address space
identifier) which means that they have a 40-bit physical address, but
32-bit virtual addresses.

> > (2) There aren't enough bits in a physical address to express the
> > return value of the device mmap properly, in all cases, from what I
> > understand, and a plain physical address isn't necessarily all that
> > you want to return.  E.g. on various sun boxes, don't you need a few
> > bits of 'space' information in addition to the physical address?
> 
> Isn't a "long" value always large enough to hold any physical address?
> If we can count on that, then the driver mmap entry point could just be
> redefined to return a u_long and that would avoid punishing the 32-bit
> ports with quad_t return values.  Would that work?

The answer to this question is "no".  SPARC v9 machines have 40-bit PAs,
and all I/O space is in the "standard physical" asi but well above the 4GB
limit.  Since I have not been able to compile a 64-bit gcc, all PAs for
I/O space need to be stored in a int64_t (long long).  My solution is to
provide an alternate entry to pmap_enter that accepts a 64-bit physical address.
Luckily RAM starts at physical address 0 and until you exceed 4GB RAM you
can manage these with a standard long.  Of course, this problem will go
away if I can get gcc to spit out 64-bit SPARC v9 code.  I wouldn't be
surprised if the MIPS R4K+ ports suffer from the same problem.  

The VM subsystem should really be cleaned up pa_offset_t or something
equivalent instead of vm_offset_t to handle physical addresses.  That way
this can all be handled in the proper place, the machine dependent code.

=========================================================================
Eduardo Horvath				eeh@btr.com
"Cliffs are for climbing.  That's why God invented grappling hooks."
					- Benton Frasier