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.