From: Christoph Hellwig <hch@lst.de>
To: Alex Smith <alex.smith@imgtec.com>
Cc: James Hogan <jhogan@kernel.org>,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
linux-mips@vger.kernel.org, Paul Burton <paul.burton@mips.com>,
Sadegh Abbasi <Sadegh.Abbasi@imgtec.com>
Subject: DMA_ATTR_WRITE_COMBINE on mips
Date: Fri, 2 Aug 2019 08:37:12 +0200 [thread overview]
Message-ID: <20190802063712.GA7553@lst.de> (raw)
[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
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Alex Smith <alex.smith@imgtec.com>
Cc: Sadegh Abbasi <Sadegh.Abbasi@imgtec.com>,
Paul Burton <paul.burton@mips.com>,
James Hogan <jhogan@kernel.org>,
linux-mips@vger.kernel.org, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: DMA_ATTR_WRITE_COMBINE on mips
Date: Fri, 2 Aug 2019 08:37:12 +0200 [thread overview]
Message-ID: <20190802063712.GA7553@lst.de> (raw)
[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?
next reply other threads:[~2019-08-02 6:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-02 6:37 Christoph Hellwig [this message]
2019-08-02 6:37 ` DMA_ATTR_WRITE_COMBINE on mips Christoph Hellwig
2019-09-18 19:48 ` Maciej W. Rozycki
2019-09-18 19:48 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190802063712.GA7553@lst.de \
--to=hch@lst.de \
--cc=Sadegh.Abbasi@imgtec.com \
--cc=alex.smith@imgtec.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jhogan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=paul.burton@mips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.