* DMA_ATTR_WRITE_COMBINE on mips
@ 2019-08-02 6:37 ` Christoph Hellwig
0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2019-08-02 6:37 UTC (permalink / raw)
To: Alex Smith
Cc: Sadegh Abbasi, Paul Burton, James Hogan, linux-mips, iommu, linux-kernel
[I hope the imgtec address still works, but maybe the mips folks know
if it moved to mips]
Hi Alex,
you added DMA_ATTR_WRITE_COMBINE support in dma_mmap_attrs to mips
in commit 8c172467be36f7c9591e59b647e4cd342ce2ef41
("MIPS: Add implementation of dma_map_ops.mmap()"), but that commit
only added the support in mmap, not in dma_alloc_attrs. This means
the memory is now used in kernel space through KSEG1, and thus uncached,
while for userspace mappings through dma_mmap_* pgprot_writebombine
is used, which creates a write combine mapping, which on some MIPS CPUs
sets the _CACHE_UNCACHED_ACCELERATED pte bit instead of the
_CACHE_UNCACHED one. I know at least on arm, powerpc and x86 such
mixed page cachability attributes can cause pretty severe problems.
Are they ok on mips? Or was the DMA_ATTR_WRITE_COMBINE supported
unintended and not correct and we should remove it?
^ permalink raw reply [flat|nested] 4+ messages in thread* DMA_ATTR_WRITE_COMBINE on mips @ 2019-08-02 6:37 ` Christoph Hellwig 0 siblings, 0 replies; 4+ messages in thread From: Christoph Hellwig @ 2019-08-02 6:37 UTC (permalink / raw) To: Alex Smith Cc: James Hogan, linux-kernel, iommu, linux-mips, Paul Burton, Sadegh Abbasi [I hope the imgtec address still works, but maybe the mips folks know if it moved to mips] Hi Alex, you added DMA_ATTR_WRITE_COMBINE support in dma_mmap_attrs to mips in commit 8c172467be36f7c9591e59b647e4cd342ce2ef41 ("MIPS: Add implementation of dma_map_ops.mmap()"), but that commit only added the support in mmap, not in dma_alloc_attrs. This means the memory is now used in kernel space through KSEG1, and thus uncached, while for userspace mappings through dma_mmap_* pgprot_writebombine is used, which creates a write combine mapping, which on some MIPS CPUs sets the _CACHE_UNCACHED_ACCELERATED pte bit instead of the _CACHE_UNCACHED one. I know at least on arm, powerpc and x86 such mixed page cachability attributes can cause pretty severe problems. Are they ok on mips? Or was the DMA_ATTR_WRITE_COMBINE supported unintended and not correct and we should remove it? _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: DMA_ATTR_WRITE_COMBINE on mips 2019-08-02 6:37 ` Christoph Hellwig @ 2019-09-18 19:48 ` Maciej W. Rozycki -1 siblings, 0 replies; 4+ messages in thread From: Maciej W. Rozycki @ 2019-09-18 19:48 UTC (permalink / raw) To: Christoph Hellwig Cc: Alex Smith, Sadegh Abbasi, Paul Burton, James Hogan, linux-mips, iommu, linux-kernel Hi Christoph, > [I hope the imgtec address still works, but maybe the mips folks know > if it moved to mips] Alex left Imagination long before the transition to the interim MIPS company. > you added DMA_ATTR_WRITE_COMBINE support in dma_mmap_attrs to mips > in commit 8c172467be36f7c9591e59b647e4cd342ce2ef41 > ("MIPS: Add implementation of dma_map_ops.mmap()"), but that commit > only added the support in mmap, not in dma_alloc_attrs. This means > the memory is now used in kernel space through KSEG1, and thus uncached, > while for userspace mappings through dma_mmap_* pgprot_writebombine > is used, which creates a write combine mapping, which on some MIPS CPUs > sets the _CACHE_UNCACHED_ACCELERATED pte bit instead of the > _CACHE_UNCACHED one. I know at least on arm, powerpc and x86 such > mixed page cachability attributes can cause pretty severe problems. > Are they ok on mips? The uncached accelerated mode is implementation-specific, so you won't find its definition in the architecture, however the original R10000 implementation explicitly documents[1] interactions between bus accesses using the two modes (essentially a _CACHE_UNCACHED store acts as a barrier for any outstanding _CACHE_UNCACHED_ACCELERATED stores; for loads the modes are equivalent), so that's clearly supported. I've glanced over the interAptiv manual[2] too and it seems to define the caching modes similarly. > Or was the DMA_ATTR_WRITE_COMBINE supported > unintended and not correct and we should remove it? I don't know, so regrettably I can't comment on this. References: [1] "MIPS R10000 Microprocessor", Version 2.0, MIPS Technologies, Inc., January 29, 1997 <http://techpubs.sgi.com/library/manuals/2000/007-2490-001/pdf/007-2490-001.pdf> [2] "MIPS32 interAptiv Multiprocessing System Software User's Manual", Imagination Technologies Ltd., Document Number: MD00904, Revision 02.01, June 15, 2016 Maciej ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: DMA_ATTR_WRITE_COMBINE on mips @ 2019-09-18 19:48 ` Maciej W. Rozycki 0 siblings, 0 replies; 4+ messages in thread From: Maciej W. Rozycki @ 2019-09-18 19:48 UTC (permalink / raw) To: Christoph Hellwig Cc: James Hogan, Paul Burton, iommu, linux-mips, Alex Smith, Sadegh Abbasi, linux-kernel Hi Christoph, > [I hope the imgtec address still works, but maybe the mips folks know > if it moved to mips] Alex left Imagination long before the transition to the interim MIPS company. > you added DMA_ATTR_WRITE_COMBINE support in dma_mmap_attrs to mips > in commit 8c172467be36f7c9591e59b647e4cd342ce2ef41 > ("MIPS: Add implementation of dma_map_ops.mmap()"), but that commit > only added the support in mmap, not in dma_alloc_attrs. This means > the memory is now used in kernel space through KSEG1, and thus uncached, > while for userspace mappings through dma_mmap_* pgprot_writebombine > is used, which creates a write combine mapping, which on some MIPS CPUs > sets the _CACHE_UNCACHED_ACCELERATED pte bit instead of the > _CACHE_UNCACHED one. I know at least on arm, powerpc and x86 such > mixed page cachability attributes can cause pretty severe problems. > Are they ok on mips? The uncached accelerated mode is implementation-specific, so you won't find its definition in the architecture, however the original R10000 implementation explicitly documents[1] interactions between bus accesses using the two modes (essentially a _CACHE_UNCACHED store acts as a barrier for any outstanding _CACHE_UNCACHED_ACCELERATED stores; for loads the modes are equivalent), so that's clearly supported. I've glanced over the interAptiv manual[2] too and it seems to define the caching modes similarly. > Or was the DMA_ATTR_WRITE_COMBINE supported > unintended and not correct and we should remove it? I don't know, so regrettably I can't comment on this. References: [1] "MIPS R10000 Microprocessor", Version 2.0, MIPS Technologies, Inc., January 29, 1997 <http://techpubs.sgi.com/library/manuals/2000/007-2490-001/pdf/007-2490-001.pdf> [2] "MIPS32 interAptiv Multiprocessing System Software User's Manual", Imagination Technologies Ltd., Document Number: MD00904, Revision 02.01, June 15, 2016 Maciej _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-09-18 20:01 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-02 6:37 DMA_ATTR_WRITE_COMBINE on mips Christoph Hellwig 2019-08-02 6:37 ` Christoph Hellwig 2019-09-18 19:48 ` Maciej W. Rozycki 2019-09-18 19:48 ` Maciej W. Rozycki
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.