Hi all,
this series contains just the cleanup parts from the previous
"a saner API for allocating DMA addressable pages" series. The
intent is to get this in to reduce the amount of patchbombing
for iterations of the real API work.
___
iommu mailing lis
On 05/18/2018 06:45 AM, Christoph Hellwig wrote:
Hi all,
this series continues consolidating the dma-mapping code, with a focus
on architectures that do not (always) provide cache coherence for DMA.
Three architectures (arm, mips and powerpc) are still left to be
converted later due to complexit
On Fri, May 18, 2018 at 02:49:36PM +, Alexey Brodkin wrote:
> So if we set aside my complaints about direction in
> arch_sync_dma_for_{device|cpu}()...
Many other architectures use the argument. Various of those look bogus,
but for now I want to be able to do straight forward conversions. I
Hi Christoph,
On Fri, 2018-05-18 at 15:45 +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series continues consolidating the dma-mapping code, with a focus
> on architectures that do not (always) provide cache coherence for DMA.
> Three architectures (arm, mips and powerpc) are still left to b
Hi all,
this series continues consolidating the dma-mapping code, with a focus
on architectures that do not (always) provide cache coherence for DMA.
Three architectures (arm, mips and powerpc) are still left to be
converted later due to complexity of their dma ops selection.
The dma-noncoherent
