No. It's not clear whether my pair of patches are both going to make it
into the kernel, or even what timeframe they're going to make it in.
Irrespective of that, we do need a solution to this problem so that this
stuff starts working again.
In any case, your patch makes complete sense through and through:
1. if other architecture/machine wants to reserve a chunk of DMA-able
memory for a specific device (eg, because of a restriction on the
number of DMA address bits available) and it's completely DMA
coherent, it shouldn't have to go through the pains of having that
memory unconditionally ioremap'd.
2. What if the memory being provided from some source where you already
have the mapping setup in a specific way for a reason?
For example, say I have an ARM design, and all peripherals are in a
single 256MB memory region, which includes a chunk of SRAM set aside
for DMA purposes. Let's say I can map that really efficiently by a
few page table entries, which means relatively little TLB usage for
accessing this region.
With the current API, it becomes difficult to pass that mapping through
the dma_declare_coherent_memory() because the physical address goes
through ioremap(), which obfuscates what's going on. However, if I
could pass the bus and virtual address, then there's no ambiguity over
what I want to do.
What if I want to declare memory to the DMA coherent allocator with
attributes different from what ioremap() gives me, maybe with write
combining properties (because it happens to be safe for the specific
device) ?
Passing the virtual address allows the API to become much more flexible.
Not only that, it allows it to be used on ARM, rather than becoming (as
it currently stands) prohibited on ARM.
I believe that putting ioremap() inside this API was the wrong thing to
do, and moving it outside makes the API much more flexible and usable.
It's something I still fully support.
--
