Subject: Re: user mapping pci memory
To: None <eeh@one-o.com>
From: Gordon W. Ross <gwr@mc.com>
List: tech-kern
Date: 03/13/1997 12:16:42
> Date: Thu, 13 Mar 1997 09:00:34 -0800 (PST)
> From: "Eduardo E. Horvath" <eeh@one-o.com>

> 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.

The d_map return value includes the ASI.
Maybe it should return a PTE...

> 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.

I'm aware of that.  How large is a page-table entry?
If a PTE fits in a long, then d_map could return a PTE.
(pmap_enter gets a PTE as the "pa" argument)

Gordon