From: Christoph Hellwig <hch@lst.de>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to struct device
Date: Mon, 23 Mar 2020 13:55:30 +0100 [thread overview]
Message-ID: <20200323125530.GA17038@lst.de> (raw)
In-Reply-To: <0a6003e5-8003-4509-4014-4b286d5e8fe0@arm.com>
On Mon, Mar 23, 2020 at 12:14:08PM +0000, Robin Murphy wrote:
> On 2020-03-20 2:16 pm, Christoph Hellwig wrote:
>> Several IOMMU drivers have a bypass mode where they can use a direct
>> mapping if the devices DMA mask is large enough. Add generic support
>> to the core dma-mapping code to do that to switch those drivers to
>> a common solution.
>
> Hmm, this is _almost_, but not quite the same as the case where drivers are
> managing their own IOMMU mappings, but still need to use streaming DMA for
> cache maintenance on the underlying pages.
In that case they should simply not call the DMA API at all. We'll just
need versions of the cache maintainance APIs that tie in with the raw
IOMMU API.
> For that we need the ops bypass
> to be a "true" bypass and also avoid SWIOTLB regardless of the device's DMA
> mask. That behaviour should in fact be fine for the opportunistic bypass
> case here as well, since the mask being "big enough" implies by definition
> that this should never need to bounce either.
In practice it does. But that means adding yet another code path
vs the simple direct call to dma_direct_* vs calling the DMA ops
which I'd rather avoid.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-03-23 12:55 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-20 14:16 generic DMA bypass flag v2 Christoph Hellwig
2020-03-20 14:16 ` [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to struct device Christoph Hellwig
2020-03-20 15:02 ` Greg Kroah-Hartman
2020-03-23 1:28 ` Alexey Kardashevskiy
2020-03-23 8:37 ` Christoph Hellwig
2020-03-23 8:50 ` Christoph Hellwig
2020-03-23 15:37 ` Aneesh Kumar K.V
2020-03-23 17:22 ` Christoph Hellwig
2020-03-24 3:05 ` Alexey Kardashevskiy
2020-03-24 6:30 ` Aneesh Kumar K.V
2020-03-24 7:55 ` Christoph Hellwig
2020-03-24 7:54 ` Christoph Hellwig
2020-03-25 4:51 ` Alexey Kardashevskiy
2020-03-25 8:37 ` Christoph Hellwig
2020-03-26 1:26 ` Alexey Kardashevskiy
2020-04-03 8:38 ` Alexey Kardashevskiy
2020-04-06 11:50 ` Christoph Hellwig
2020-04-06 13:25 ` Alexey Kardashevskiy
2020-04-06 17:17 ` Christoph Hellwig
2020-04-07 10:12 ` Alexey Kardashevskiy
2020-04-14 6:21 ` Alexey Kardashevskiy
2020-04-14 6:30 ` Christoph Hellwig
2020-03-23 8:58 ` Alexey Kardashevskiy
2020-03-23 17:20 ` Christoph Hellwig
2020-03-24 3:37 ` Alexey Kardashevskiy
2020-03-24 4:55 ` Alexey Kardashevskiy
2020-03-24 7:52 ` Christoph Hellwig
2020-03-23 12:14 ` Robin Murphy
2020-03-23 12:55 ` Christoph Hellwig [this message]
2020-03-20 14:16 ` [PATCH 2/2] powerpc: use the generic dma_ops_bypass mode Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2019-11-13 13:37 generic DMA bypass flag Christoph Hellwig
2019-11-13 13:37 ` [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to struct device Christoph Hellwig
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=20200323125530.GA17038@lst.de \
--to=hch@lst.de \
--cc=gregkh@linuxfoundation.org \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=robin.murphy@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).