Subject: Re: mmap'ing framebuffer memory in MI drivers...
To: None <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 03/03/1999 12:42:45
date:component="Your message dated",formatfield=""
In message <Pine.GSO.3.95.990303115114.28811A-100000@jericho>"Eduardo E. Horvat
h" writes
>On Tue, 2 Mar 1999, Jonathan Stone wrote:

>Yes, I noted this when I split vm_offset_t into paddr_t and vaddr_t.  One
>solution would be to define a paddr_t with all the extra fields to define
>whether it's cacheable, etc.  

Yup, I noticed it ~2 years ago when writing d_mmap() entrypoints for a
gigabit NIC we built. A similar proposal then got stalled on
objections about VME space bits.

>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

>[N.B. It would be really nice if pmap_enter() recieved a list of pages and
>could use large TLB entries if they were appropriate.  But this opens a
>whole other kettle of fish and requires large changes to the VM system.]

Yes. That is exactly why i suggested a `backdoor' for the specific
case of handing large PTEs for nonpaged, device memory.
Think of it as a `hint' between a d_mmap routine and a pmap.

Suppose you take a miss on a framebuffer page.  The driver returns a
paddr_t with a bit set which tells the PTE ``well, actually, you can
expand this PA to an N-megabyte boundary''.  If drivers only do this
for linearly-mapped, aligned memory, and user clients always map such
devices linearly (rather than mmap()ing a page into one VA here, and a
page into another VA there) then this would work with*out* any changes
to the VM subsystem.

Works for framebuffers and is cleanly extensible if/when we address
all those `kettle of fish' issues.