Subject: Re: user mapping pci memory
To: None <email@example.com>
From: Gordon W. Ross <firstname.lastname@example.org>
Date: 03/13/1997 12:16:42
> Date: Thu, 13 Mar 1997 09:00:34 -0800 (PST)
> From: "Eduardo E. Horvath" <email@example.com>
> On Wed, 12 Mar 1997, Gordon W. Ross wrote:
> > > From: "Chris G. Demetriou" <firstname.lastname@example.org>
> > > 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)