Re: consolidate swiotlb dma_map implementations
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.
Re: consolidate swiotlb dma_map implementations
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
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
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
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
consolidate swiotlb dma_map implementations
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