Subject: Re: mmap'ing framebuffer memory in MI drivers...
To: Chris G. Demetriou <cgd@netbsd.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 03/03/1999 14:50:15
overflowtext="",overflowoffset=0
date:component="Your message dated",formatfield=""
body:component=">",overflowtext=">",overflowoffset=0
In message <87emn65kzy.fsf@redmail.redback.com>Chris G. Demetriou writes

>Except, it should _not_ return a "system physical address," it should
>return whatever needs to be returned from mmap() for that
>architecture.  that's kinda the whole point.

Yes, Chris, that is EXACTLY the point.

Whether the PA is in the high- or low-order bits, and whether
the VM protection bits are in the high- or low-order bits is MD.
That makes it impossible to write, eg., truly MI framebuffer drivers,
because there's no MI way to say

   ``take this system physical address I got from bus_space_mmap()
     [or wherever], and do any  machine-dependent shifting to turn
     it into a valid **d_mmap)() entrypoint return value for this
     machine''.

see, eg., sys/dev/tc/sfb.c and the kludges in there to fake
up a ``machine_btop()'' to do exactly this.


>(there's no reason that _i_ can think of to insert Yet Another MD
>Operation there; it's _already_ an MD operation.)


Um, thats the whole point. it _is_ an MD operation, yet *ALL* MI
drivers which provide a d_mmap entrypoint need a way to do it.

And we aint got no way for them to do it.