From: Christoph Hellwig <hch@lst.de>
To: Oliver O'Halloran <oohall@gmail.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Shawn Anastasio <shawn@anastas.io>,
Christoph Hellwig <hch@lst.de>,
Sam Bobroff <sbobroff@linux.ibm.com>
Subject: Re: [PATCH] powerpc/dma: Fix invalid DMA mmap behavior
Date: Thu, 18 Jul 2019 10:49:34 +0200 [thread overview]
Message-ID: <20190718084934.GF24562@lst.de> (raw)
In-Reply-To: <CAOSf1CGA_fDH7aAqRkc4maJUByaX7adGcjyt3cj4KFsMJNnocA@mail.gmail.com>
On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote:
> > Other than m68k, mips, and arm64, everybody else that doesn't have
> > ARCH_NO_COHERENT_DMA_MMAP set uses this default implementation, so
> > I assume this behavior is acceptable on those architectures.
>
> It might be acceptable, but there's no reason to use pgport_noncached
> if the platform supports cache-coherent DMA.
>
> Christoph (+cc) made the change so maybe he saw something we're missing.
I always found the forcing of noncached access even for coherent
devices a little odd, but this was inherited from the previous
implementation, which surprised me a bit as the different attributes
are usually problematic even on x86. Let me dig into the history a
bit more, but I suspect the righ fix is to default to cached mappings
for coherent devices.
next prev parent reply other threads:[~2019-07-18 8:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-17 23:54 [PATCH] powerpc/dma: Fix invalid DMA mmap behavior Shawn Anastasio
2019-07-18 2:59 ` Alexey Kardashevskiy
2019-07-18 3:14 ` Shawn Anastasio
2019-07-18 3:45 ` Oliver O'Halloran
2019-07-18 8:49 ` Christoph Hellwig [this message]
2019-07-18 9:52 ` Christoph Hellwig
2019-07-18 9:52 ` Christoph Hellwig
2019-07-18 19:46 ` Shawn Anastasio via iommu
2019-07-18 19:46 ` Shawn Anastasio
2019-07-19 7:06 ` Christoph Hellwig
2019-07-19 7:06 ` Christoph Hellwig
2019-07-19 7:36 ` Shawn Anastasio via iommu
2019-07-19 7:36 ` Shawn Anastasio
2019-07-19 11:18 ` Arnd Bergmann
2019-07-19 11:18 ` Arnd Bergmann
2019-07-22 12:16 ` Michael Ellerman
2019-07-22 12:16 ` Michael Ellerman
2019-07-22 19:23 ` Shawn Anastasio via iommu
2019-07-22 19:23 ` Shawn Anastasio
2019-07-22 23:09 ` Michael Ellerman
2019-07-22 23:09 ` Michael Ellerman
2019-07-22 2:48 ` Michael Ellerman
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=20190718084934.GF24562@lst.de \
--to=hch@lst.de \
--cc=aik@ozlabs.ru \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=oohall@gmail.com \
--cc=sbobroff@linux.ibm.com \
--cc=shawn@anastas.io \
/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.