tree 85275a8939d5fce4ca85dc2cef8a2fd1c17143dc
parent d3910e1c9ffcfc0df36c7687c6779275c5bc91b9
author Barret Rhoden <brho@cs.berkeley.edu> 1569938674 -0400
committer Barret Rhoden <brho@cs.berkeley.edu> 1570569071 -0400

dma: rewrite DMA allocations with arenas and KMCs

A dma_pool is now just a slab allocator on top of a struct dma_arena.
These allocators provide device-accessible memory *allocations*.  You
can still 'DMA-map' kernel memory for drivers.  This is just for the
Linux DMA alloc APIs, for now.

The reason for some of the kpages->paddr->kaddr acrobatics is I want to
support address spaces other than physical and kernel virtual.
Specifically, I'd like to try to keep a driver in the kernel, but with
the device operating in the user's address space, i.e. behind an IOMMU.
In that sense, the driver *code* is like a syscall in the user's address
space, and the device is like a processor in Ring 3.  We'll see.

Eventually, we could make all of our drivers use these, and perhaps sort
out how to do DMA pinning with the same sense of device addresses.

If it turns out this is a horrible idea, we can make the dma_pool just
pull from kpages and be done with all the to_cpu_addr() translations.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>