Subject: Re: mmap'ing framebuffer memory in MI drivers...
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Eduardo E. Horvath <eeh@one-o.com>
List: tech-kern
Date: 03/06/1999 12:36:25
On Sat, 6 Mar 1999, Jason Thorpe wrote:
> On Sat, 6 Mar 1999 07:49:26 -0800 (PST)
> "Eduardo E. Horvath" <eeh@one-o.com> wrote:
>
> > And it immediately calls pmap_enter() if the mapping would succeed. There
> > is no instance I can find where if the d_mmap() routine is called and
> > returns a success, pmap_enter is not immediately called. I see no other
> > calls just to check for permissions.
>
> BZZT :-)
>
> That's the FAULT handler you're looking at.
>
> Now, take a look udv_attach().
I looked there. All I see is:
mapfn = cdevsw[major(device)].d_mmap;
if (mapfn == NULL ||
mapfn == (int (*) __P((dev_t, int, int))) enodev
||
mapfn == (int (*) __P((dev_t, int, int))) nullop)
return(NULL);
Never seems to call the function, just checks to see if it's a valid
routine.
>
> > That would also work. Probably good to have it called for unmapping
> > (pmap_remove()) so the driver (and bus_space*()) can free up any resources
> > they may have needed to allocate for the mapping.
>
> No, not pmap_remove(), but rather when the device is munmap'd (this is
> a different operation).
Arguably, if the process is swapped out the driver could reallocate
whatever resources it's using until it's swapped back in and the mappings
are restored.
=========================================================================
Eduardo Horvath eeh@one-o.com
"I need to find a pithy new quote." -- me