aboutsummaryrefslogtreecommitdiff
path: root/include/math-emu
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2013-04-16 13:45:37 -0700
committerBen Hutchings <ben@decadent.org.uk>2013-05-13 15:02:33 +0100
commit4d3c99057cd2c18272dbb730cd31f1cd817d7379 (patch)
treebbeb87d31ecfa8e4837073e1fd7e2c1d8f8ce165 /include/math-emu
parent782809063b0deaf76c8f9665b4b793516c39504d (diff)
vm: add vm_iomap_memory() helper function
commit b4cbb197c7e7a68dbad0d491242e3ca67420c13e upstream. Various drivers end up replicating the code to mmap() their memory buffers into user space, and our core memory remapping function may be very flexible but it is unnecessarily complicated for the common cases to use. Our internal VM uses pfn's ("page frame numbers") which simplifies things for the VM, and allows us to pass physical addresses around in a denser and more efficient format than passing a "phys_addr_t" around, and having to shift it up and down by the page size. But it just means that drivers end up doing that shifting instead at the interface level. It also means that drivers end up mucking around with internal VM things like the vma details (vm_pgoff, vm_start/end) way more than they really need to. So this just exports a function to map a certain physical memory range into user space (using a phys_addr_t based interface that is much more natural for a driver) and hides all the complexity from the driver. Some drivers will still end up tweaking the vm_page_prot details for things like prefetching or cacheability etc, but that's actually relevant to the driver, rather than caring about what the page offset of the mapping is into the particular IO memory region. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Diffstat (limited to 'include/math-emu')
0 files changed, 0 insertions, 0 deletions