From: Jerome Glisse <jglisse@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Alex Deucher <alexander.deucher@amd.com>,
Dave Airlie <airlied@redhat.com>,
iommu@lists.linux-foundation.org, Joerg Roedel <jroedel@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] dma/swiotlb: Add helper for device driver to opt-out from swiotlb.
Date: Thu, 17 Sep 2015 15:11:14 -0400 [thread overview]
Message-ID: <20150917191113.GB6699@redhat.com> (raw)
In-Reply-To: <20150917190656.GF20952@x230.dumpdata.com>
On Thu, Sep 17, 2015 at 03:06:57PM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 17, 2015 at 03:02:51PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 17, 2015 at 02:22:38PM -0400, jglisse@redhat.com wrote:
> > > From: Jérôme Glisse <jglisse@redhat.com>
> > >
> > > The swiotlb dma backend is not appropriate for some devices like
> > > GPU where bounce buffer or slow dma page allocations is just not
> > > acceptable. With that helper device drivers can opt-out from the
> > > swiotlb and just do sane things without wasting CPU cycles inside
> > > the swiotlb code.
> >
> > What if SWIOTLB is the only one available?
> >
> > And what can't the devices use the TTM DMA backend which sets up
> > buffers which don't need bounce buffer or slow dma page allocations?
>
> And then the followup question. If it opts out - how can it do
> sane things without an DMA API available? It would assume physical
> addresses match the bus addresses which is not always the sane
> thing.
This is why this is an arch specific function, on x86 with pci device,
the driver knows what is the dma mask and thus if it can access directly
all the memory or not. So in the end swiotlb vs no_mmu gives the same
physical address to the device so there is no difference there.
Obviously device driver needs to know what it is doing depending on the
arch and bus the device is use in.
Cheers,
Jérôme
next prev parent reply other threads:[~2015-09-17 19:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-17 18:22 [RFC PATCH] dma/swiotlb: Add helper for device driver to opt-out from swiotlb jglisse
2015-09-17 19:02 ` Konrad Rzeszutek Wilk
2015-09-17 19:06 ` Konrad Rzeszutek Wilk
2015-09-17 19:11 ` Jerome Glisse [this message]
2015-09-17 19:24 ` Konrad Rzeszutek Wilk
2015-09-17 19:27 ` Jerome Glisse
2015-09-17 19:07 ` Jerome Glisse
2015-09-17 19:31 ` Konrad Rzeszutek Wilk
2015-09-17 19:40 ` Jerome Glisse
2015-09-22 15:43 ` Jerome Glisse
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=20150917191113.GB6699@redhat.com \
--to=jglisse@redhat.com \
--cc=airlied@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jroedel@suse.de \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
/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).