> From: "Chris G. Demetriou" <cgd@cs.cmu.edu>
> Date: Wed, 12 Mar 1997 11:28:59 -0500
> 
> > The driver mmap usually uses <arch>_btop() to calculate
> > the return value - how to do this mi?
> 
> You can't (yet).  There's no good way to do that currently.
> 
> Note that, as you say, drivers _usually_ use <arch>_btop(), but do not
> always.  In general, what they use is an architecture-specific
> decision, and requires cooperation between the drivers and the pmap
> module.

Right.  It depends on how the pmap defined pmap_phys_address()
which the sparc and sun3 (maybe others?) define like this:

	/* We use the PA plus some low bits for device mmap. */
	#define pmap_phys_address(addr) 	(addr)

> Right now, you _have_ to use #ifdef.

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.

> > Seems that things would be simpler if mmap returned
> > phys addresses.

Doesn't solve the need for an address space specifier...

> Perhaps.  However:
> 
> (1) Plain physical addresses mean that here's some possibility for the
> device mmap routine trying to return non-page-aligned values, which is
> broken, and

If the driver could call some cpu-dependent function to get the value
to be returned (based on address space and offset) then that problem
could be dealt with in there.  The actual return value might WANT to
have some low bits which are NOT interpreted as a page offset when
that value comes back into cpu-dependent code via pmap_enter().
(Device d_mmap return values are opaque outside of MD code.)

> (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?

Gordon