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