consolidate swiotlb dma_map implementations

[Christoph Hellwig]

A lot of architectures have essentially identical dma_map_ops
implementations to use swiotlb.  This series adds new generic
swiotlb_alloc/free helpers that take the attrs argument exposed
in dma_map_ops, and which do an enhanced direct allocation
modelled after x86 and reused from the dma-direct code, and
then switches most architectures over to it.  The only exceptions
are mips, which requires additional cache flushing which will
need a new abstraction, and x86 itself which will be handled in
a later series with other x86 dma mapping changes.

To support the generic code a few architectures that currently
use ZONE_DMA/GFP_DMA for <= 32-bit allocations are switched to
implement ZONE_DMA32 instead.

This series is based on the previously sent series to consolidate
the direct dma mapping implementation.  A git tree with this
series as well as the prerequisites is available here:

   git://git.infradead.org/users/hch/misc.git swiotlb

Gitweb:

   http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/swiotlb

Re: consolidate swiotlb dma_map implementations

[Christian König]

Acked-by: Christian König  for the whole series.

Regards,
Christian.

Am 10.01.2018 um 09:09 schrieb Christoph Hellwig:

A lot of architectures have essentially identical dma_map_ops
implementations to use swiotlb.  This series adds new generic
swiotlb_alloc/free helpers that take the attrs argument exposed
in dma_map_ops, and which do an enhanced direct allocation
modelled after x86 and reused from the dma-direct code, and
then switches most architectures over to it.  The only exceptions
are mips, which requires additional cache flushing which will
need a new abstraction, and x86 itself which will be handled in
a later series with other x86 dma mapping changes.

To support the generic code a few architectures that currently
use ZONE_DMA/GFP_DMA for <= 32-bit allocations are switched to
implement ZONE_DMA32 instead.

This series is based on the previously sent series to consolidate
the direct dma mapping implementation.  A git tree with this
series as well as the prerequisites is available here:

git://git.infradead.org/users/hch/misc.git swiotlb

Gitweb:

http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/swiotlb

Re: consolidate swiotlb dma_map implementations

[Christoph Hellwig]

I've pulled this into the dma-mapping for-next tree, including the
missing free_pages noted.  I'd be fine to rebase another day or two
for additional reviews or important fixes.

Re: consolidate swiotlb dma_map implementations

[Christian König]

Hi Konrad,

can you send the first patch to Linus for inclusion in 4.15 if you 
haven't already done so?


I'm still getting reports from people complaining about the error message.

Thanks,
Christian.

Am 16.01.2018 um 08:53 schrieb Christoph Hellwig:

I've pulled this into the dma-mapping for-next tree, including the
missing free_pages noted.  I'd be fine to rebase another day or two
for additional reviews or important fixes.

Re: consolidate swiotlb dma_map implementations

[Christoph Hellwig]

On Tue, Jan 16, 2018 at 09:22:52AM +0100, Christian König wrote:
> Hi Konrad,
>
> can you send the first patch to Linus for inclusion in 4.15 if you haven't 
> already done so?

It's in the 4.16 queue with a cc to stable.  I guess we're ok with
a duplicate commit if we have to.

Re: consolidate swiotlb dma_map implementations

[Christian König]

Am 16.01.2018 um 09:28 schrieb Christoph Hellwig:

On Tue, Jan 16, 2018 at 09:22:52AM +0100, Christian König wrote:

Hi Konrad,

can you send the first patch to Linus for inclusion in 4.15 if you haven't
already done so?

It's in the 4.16 queue with a cc to stable.  I guess we're ok with
a duplicate commit if we have to.


Yeah, while it's only a false positive warning it would be really nice 
to have in 4.15.


It affects all drivers using TTM in the system and not just the two I'm 
the maintainer of.


Regards,
Christian.