Re: bus_space_physload(9)

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

On Wed, Mar 24, 2010 at 07:56:27PM +1100, matthew green wrote:
>
> i don't understand why you think framebuffers are mapped uncacheable.
>
> your proposal appears to provide no benefit for anything currently
> supported, and i'm not sure why bus_space_physload() needs to be
> in the bus_space domain, rather than plain UVM.  your XIP use-case

It's in bus_space(9) because it's API for device drivers.  Its behavior needs
UVM's help, of course.

On Wed, Mar 24, 2010 at 07:59:48PM +1100, matthew green wrote:
>    
>    "int prot" is the device's characteristic.  Audio mic devices would use
>    VM_PROT_READ.  Framebuffers would use VM_PROT_WRITE.  We need to introduce
>    BUS_SPACE_PROT_* symbols too.
> 
> i don't see why you think that reads from fb devices never occur.

I'm saying if a device region is write-only, its device driver should register
the region as write-only.  If not, don't need to do so.

The other point is, bus_space_physload(9) provides a path to tell device's
memory access characteristic to VM.  bus_space_physload(9) will replace
bus_space_mmap(9), and returns a cookie back to cdev_mmap().  The cookie is
passed from device pager (udv_fault) to pmap_enter().

I'm not familar with video devices, but my understanding is that some modern
devices need MMU's help for accelaration.  This means that those devices have
to tell their capability to VM somehow.  I guess x86/i386/amd64 are doing
some hacks to configure them in MD code, because we have no code to do pass
those information in UVM.  FreeBSD seems to have implemented vm_memattr_t
for such a purpose.

> i'm also unsure how audio devices matter for this, but i haven't
> looked closely at this part yet... they are usually implemented with
> the read/write parts combined, so there is no "mic device" separate
> from the "line-out" or "headphones" (but there are ways to choose
> between them.)

Devices have right to map their linear space for multiple functions, yes.
cdev_mmap() may return DMA memory or device memory.  My plan is to make
cdev_mmap() return either struct vm_page * (DMA == bus_space_mmap()) or struct
vm_physseg * (device memory == bus_space_mmap()).

I can't say this is a benefit, but at least more correct.

I'm also not sure about these.

        http://nxr.netbsd.org/xref/src/sys/dev/audio.c#2471
        http://nxr.netbsd.org/xref/src/sys/uvm/uvm_mmap.c#1156

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635