Subject: Re: mmap'ing framebuffer memory in MI drivers...
To: Jason Thorpe <email@example.com>
From: Eduardo E. Horvath <firstname.lastname@example.org>
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
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 email@example.com
"I need to find a pithy new quote." -- me