Subject: Re: mmap'ing framebuffer memory in MI drivers...
To: Chris G. Demetriou <cgd@netbsd.org>
From: Eduardo E. Horvath <eeh@one-o.com>
List: tech-kern
Date: 03/05/1999 18:50:07
On 3 Mar 1999, Chris G. Demetriou wrote:

> Jonathan Stone <jonathan@DSG.Stanford.EDU> writes:
> > >I will assert (again) that mapping the device registers is an inherently
> > >bus-specific operation and should be done by the driver through the use of
> > >bus_space*() routines rather than the VM system.
> > 
> > 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.
> 
> 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.
> 
> (there's no reason that _i_ can think of to insert Yet Another MD
> Operation there; it's _already_ an MD operation.)

Hold it -- why is (*d_mmap)() returning anything?  Why doesn't it call
pmap_enter() or the equivalent (or bus_device_whozit() that eventually
works its way down to pmap_enter()) in the first place, return success or
failure, and be done with it?  That way ports that need to can create an 
alternative MD entry point into pmap that can be passed all this extra
meta-info and we don't need to encode it into the physical address and
check for it every time pmap_enter() is called.

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me