Subject: Re: mmap'ing framebuffer memory in MI drivers...
To: Jason Thorpe <>
From: Eduardo E. Horvath <>
List: tech-kern
Date: 03/04/1999 08:46:06
On Wed, 3 Mar 1999, Jason Thorpe wrote:

> On Wed, 03 Mar 1999 12:42:45 -0800 
>  Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:
>  > Agreed. What I'm saying is that that after a bus_space_mmap() has done
>  > its thing, then converting the ``system physical address'' it returns
>  > to a (*d_mmap)() entrypoint is an MD operation.  if we want MI drivers
>  > for mmap'able devices we need an MI hook to do that conversion; end of
>  > story.
> Um, pmap_phys_address() currently does it.  It's an icky interface, but it
> "works".

No, it doesn't.  I have a 42-bit physical address (really 64-bit but the
H/W currently ignores the upper bits) that (in the LP32 case) needs to be
encoded in a 32-bit value.  Since I have 8K pages (12-bits) I can stuff
the necessary bits into the address and have 2 bits left over.  Wow!  I
can encode all of 4 different special cases!  Consider I need to specify
wheter the address range is virtually cacheable, physically cacheable,
or has sideffects, and/or needs endianness flipping, I really don't have
space to encode the page size.

Eduardo Horvath
	"I need to find a pithy new quote." -- me