bus_space_physload(9)

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

I'd like to propose a new function in bus_space(9) API, bus_space_physload(9).

        void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
            bus_size_t size);

This function is provided for device drivers to register its linear memory
region to be managed by VM.  When user process maps these regions, VM will
take care of detailed treatment.

bus_space(9) implementations internally call uvm_page_physload_device(9)
(added in uebayasi-xip), which allocates one struct vm_physseg.  Note that
we don't allocate struct vm_page for device regions (pages) because device
regions are considered to 

- be linear
- have uniform characteristic,
- *not* involve paging activity

*

Most typical users are frame buffers.  Those devices have internal memory
which is directly mapped to user processes.  Now those drivers implement
"mmap" operations which returns physical address.  VM knows nothing about
those regions, because it only keeps track of RAM regions, and when it sees
a physical address of a frame buffer memory, "this is not RAM, let's treat
this as unknown region", which will end up as uncached access.

After introducing bus_space_physload(), VM is given knowledge of device
regions.  If device, user, and MMU all agree that they support / prefer
write accelaration, VM decides to enable it.

NOR FlashROM can be used for XIP.  The flash driver registers its region
as managed.  When part of it is mmap'ed, VM knows its part of one of registered
regions, so can decide to map it as cacheable.

*

Any comments are appreciated.  Thanks.

Masao

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