tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bus_space_physload(9)



Hi,

On Tue, Apr 6, 2010 at 10:48 AM, David Young <dyoung%pobox.com@localhost> wrote:
> You haven't mmap()'d the entire range.  Shouldn't that be:
>
>                const bus_addr_t busp = addr;
>                const bus_addr_t busq = addr + size;
>                off_t i;
>                const paddr_t physp = bus_space_mmap(t, busp, 0, prot, flags);
>                const paddr_t physq = bus_space_mmap(t, busq, 0, prot, flags);
>
>                for (i = PAGE_SIZE; i < busq - busp; i += PAGE_SIZE)
>                        (void)bus_space_mmap(t, busp, i, prot, flags);

It was a pseudo code... ;)  But thanks.

I'm thinking that bus_space_mmap() should take a range.  It's called
via d_mmap() via cdev_mmap() via device pager
(sys/uvm/uvm_device.c:udv_{attach,fault}()) via the mmap() system
call.  cdev_mmap() is called to know the physical address of a given
device address.  Device drivers know where it belongs - either device
space or main RAM (DMA)).  Now we only convert addresses here, because
we have assumed that device mapping (onto user-space) is always
non-cached and stateless.

This is not true for managed pages.  For example, DRI
(sys/external/bsd/drm/dist/bsd-core/drm_memory.c) + MTRR
(sys/arch/x86/x86/mtrr_i686.c).  mtrr_i686.c records users of
configured regions.  This matches the information of mmap() call.  I
think we can move part of hacks in drm_memory.c behind
bus_space_mmap() if we make it take a range.

(This is a on-going consideration.)

Masao


Home | Main Index | Thread Index | Old Index