Subject: Re: mmap'ing framebuffer memory in MI drivers...
To: None <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
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
>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.