From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Grant Grundler <grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Cho KyongHo <pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] devicetree: Add generic IOMMU device tree bindings
Date: Wed, 21 May 2014 20:11:19 +0200 [thread overview]
Message-ID: <4393962.rf2bYfTJVU@wuerfel> (raw)
In-Reply-To: <20140521170954.GC3830-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
On Wednesday 21 May 2014 18:09:54 Dave Martin wrote:
> On Wed, May 21, 2014 at 11:00:38AM +0200, Thierry Reding wrote:
> > On Wed, May 21, 2014 at 10:50:38AM +0200, Arnd Bergmann wrote:
> > > On Wednesday 21 May 2014 10:26:11 Thierry Reding wrote:
> > > >
> > > > Similarily, should the IOMMU not be treated like any other device here?
> > > > Its DMA mask should determine what address range it can access.
> > >
> > > Right. But for that we need a dma-ranges property in the parent of the
> > > iommu, just so the mask can be set correctly and we don't have to
> > > rely on the 32-bit fallback case.
> >
> > Shouldn't the IOMMU driver be the one to set the DMA mask for the device
> > in exactly the same way that other drivers override the 32-bit default?
> >
>
> Are we confusing the "next-hop DMA mask" with the "end-to-end DMA mask"
> here? The device has a next-hop mask which may be non-trivial. The
> IOMMU also has a next-hop mask and/or remapping, but I think we agree
> that in sensible systems that will be trivial. There might be other
> non-trivial remappings between the IOMMU and memory (but again, not
> in the common case).
>
> If we just use the same name for all these, we are liable to get
> confused.
>
> To answer the question "what memory can the kernel allocate for DMA
> with this device", it is the end-to-end transformation that is
> important.
Yes, but that is not the same as the dma mask of the device. The DMA
mask gets set by the device according to its capabilities, and may
get limited by what the bus to either memory or to the iommu can do,
if one is in use.
Without an IOMMU, the mask is used for allocations, with an IOMMU,
The iommu code makes the decision what to allocate without taking
dev->dma_mask into account.
As mentioned, this is currently not handled well for SCSI and network,
where we use a smaller mask than necessary and can end up copying
data.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
Pawel Moll <pawel.moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Grant Grundler <grundler@chromium.org>,
Joerg Roedel <joro@8bytes.org>,
Stephen Warren <swarren@wwwdotorg.org>,
Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org, Marc Zyngier <marc.zyngier@arm.com>,
iommu@lists.linux-foundation.org,
Rob Herring <robh+dt@kernel.org>,
Kumar Gala <galak@codeaurora.org>,
linux-tegra@vger.kernel.org, Cho KyongHo <pullip.cho@samsung.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] devicetree: Add generic IOMMU device tree bindings
Date: Wed, 21 May 2014 20:11:19 +0200 [thread overview]
Message-ID: <4393962.rf2bYfTJVU@wuerfel> (raw)
In-Reply-To: <20140521170954.GC3830@e103592.cambridge.arm.com>
On Wednesday 21 May 2014 18:09:54 Dave Martin wrote:
> On Wed, May 21, 2014 at 11:00:38AM +0200, Thierry Reding wrote:
> > On Wed, May 21, 2014 at 10:50:38AM +0200, Arnd Bergmann wrote:
> > > On Wednesday 21 May 2014 10:26:11 Thierry Reding wrote:
> > > >
> > > > Similarily, should the IOMMU not be treated like any other device here?
> > > > Its DMA mask should determine what address range it can access.
> > >
> > > Right. But for that we need a dma-ranges property in the parent of the
> > > iommu, just so the mask can be set correctly and we don't have to
> > > rely on the 32-bit fallback case.
> >
> > Shouldn't the IOMMU driver be the one to set the DMA mask for the device
> > in exactly the same way that other drivers override the 32-bit default?
> >
>
> Are we confusing the "next-hop DMA mask" with the "end-to-end DMA mask"
> here? The device has a next-hop mask which may be non-trivial. The
> IOMMU also has a next-hop mask and/or remapping, but I think we agree
> that in sensible systems that will be trivial. There might be other
> non-trivial remappings between the IOMMU and memory (but again, not
> in the common case).
>
> If we just use the same name for all these, we are liable to get
> confused.
>
> To answer the question "what memory can the kernel allocate for DMA
> with this device", it is the end-to-end transformation that is
> important.
Yes, but that is not the same as the dma mask of the device. The DMA
mask gets set by the device according to its capabilities, and may
get limited by what the bus to either memory or to the iommu can do,
if one is in use.
Without an IOMMU, the mask is used for allocations, with an IOMMU,
The iommu code makes the decision what to allocate without taking
dev->dma_mask into account.
As mentioned, this is currently not handled well for SCSI and network,
where we use a smaller mask than necessary and can end up copying
data.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] devicetree: Add generic IOMMU device tree bindings
Date: Wed, 21 May 2014 20:11:19 +0200 [thread overview]
Message-ID: <4393962.rf2bYfTJVU@wuerfel> (raw)
In-Reply-To: <20140521170954.GC3830@e103592.cambridge.arm.com>
On Wednesday 21 May 2014 18:09:54 Dave Martin wrote:
> On Wed, May 21, 2014 at 11:00:38AM +0200, Thierry Reding wrote:
> > On Wed, May 21, 2014 at 10:50:38AM +0200, Arnd Bergmann wrote:
> > > On Wednesday 21 May 2014 10:26:11 Thierry Reding wrote:
> > > >
> > > > Similarily, should the IOMMU not be treated like any other device here?
> > > > Its DMA mask should determine what address range it can access.
> > >
> > > Right. But for that we need a dma-ranges property in the parent of the
> > > iommu, just so the mask can be set correctly and we don't have to
> > > rely on the 32-bit fallback case.
> >
> > Shouldn't the IOMMU driver be the one to set the DMA mask for the device
> > in exactly the same way that other drivers override the 32-bit default?
> >
>
> Are we confusing the "next-hop DMA mask" with the "end-to-end DMA mask"
> here? The device has a next-hop mask which may be non-trivial. The
> IOMMU also has a next-hop mask and/or remapping, but I think we agree
> that in sensible systems that will be trivial. There might be other
> non-trivial remappings between the IOMMU and memory (but again, not
> in the common case).
>
> If we just use the same name for all these, we are liable to get
> confused.
>
> To answer the question "what memory can the kernel allocate for DMA
> with this device", it is the end-to-end transformation that is
> important.
Yes, but that is not the same as the dma mask of the device. The DMA
mask gets set by the device according to its capabilities, and may
get limited by what the bus to either memory or to the iommu can do,
if one is in use.
Without an IOMMU, the mask is used for allocations, with an IOMMU,
The iommu code makes the decision what to allocate without taking
dev->dma_mask into account.
As mentioned, this is currently not handled well for SCSI and network,
where we use a smaller mask than necessary and can end up copying
data.
Arnd
next prev parent reply other threads:[~2014-05-21 18:11 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-16 12:23 [PATCH] devicetree: Add generic IOMMU device tree bindings Thierry Reding
2014-05-16 12:23 ` Thierry Reding
2014-05-16 12:23 ` Thierry Reding
[not found] ` <1400242998-437-1-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-17 8:04 ` Cho KyongHo
2014-05-17 8:04 ` Cho KyongHo
2014-05-17 8:04 ` Cho KyongHo
2014-05-17 20:48 ` Thierry Reding
2014-05-17 20:48 ` Thierry Reding
2014-05-19 10:26 ` Arnd Bergmann
2014-05-19 10:26 ` Arnd Bergmann
2014-05-19 10:26 ` Arnd Bergmann
2014-05-19 12:53 ` Thierry Reding
2014-05-19 12:53 ` Thierry Reding
2014-05-19 17:22 ` Dave Martin
2014-05-19 17:22 ` Dave Martin
2014-05-19 17:22 ` Dave Martin
[not found] ` <20140519172113.GA13858-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-19 20:32 ` Thierry Reding
2014-05-19 20:32 ` Thierry Reding
2014-05-19 20:32 ` Thierry Reding
2014-05-20 10:08 ` Arnd Bergmann
2014-05-20 10:08 ` Arnd Bergmann
2014-05-20 10:08 ` Arnd Bergmann
2014-05-20 13:07 ` Dave Martin
2014-05-20 13:07 ` Dave Martin
2014-05-20 13:07 ` Dave Martin
[not found] ` <20140520130659.GA5041-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-20 13:23 ` Arnd Bergmann
2014-05-20 13:23 ` Arnd Bergmann
2014-05-20 13:23 ` Arnd Bergmann
2014-05-20 15:26 ` Will Deacon
2014-05-20 15:26 ` Will Deacon
2014-05-20 15:26 ` Will Deacon
[not found] ` <20140520152659.GA30404-5wv7dgnIgG8@public.gmane.org>
2014-05-20 16:39 ` Dave Martin
2014-05-20 16:39 ` Dave Martin
2014-05-20 16:39 ` Dave Martin
[not found] ` <20140520163912.GC5041-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-20 20:40 ` Arnd Bergmann
2014-05-20 20:40 ` Arnd Bergmann
2014-05-20 20:40 ` Arnd Bergmann
2014-05-19 18:34 ` Arnd Bergmann
2014-05-19 18:34 ` Arnd Bergmann
2014-05-19 20:59 ` Thierry Reding
2014-05-19 20:59 ` Thierry Reding
2014-05-19 20:59 ` Thierry Reding
2014-05-20 10:04 ` Arnd Bergmann
2014-05-20 10:04 ` Arnd Bergmann
2014-05-20 11:05 ` Thierry Reding
2014-05-20 11:05 ` Thierry Reding
2014-05-20 11:05 ` Thierry Reding
2014-05-20 11:15 ` Arnd Bergmann
2014-05-20 11:15 ` Arnd Bergmann
2014-05-20 12:02 ` Thierry Reding
2014-05-20 12:02 ` Thierry Reding
2014-05-20 12:02 ` Thierry Reding
2014-05-20 12:41 ` Arnd Bergmann
2014-05-20 12:41 ` Arnd Bergmann
2014-05-20 12:41 ` Arnd Bergmann
2014-05-20 13:17 ` Thierry Reding
2014-05-20 13:17 ` Thierry Reding
2014-05-20 13:17 ` Thierry Reding
2014-05-20 13:34 ` Arnd Bergmann
2014-05-20 13:34 ` Arnd Bergmann
2014-05-20 13:34 ` Arnd Bergmann
2014-05-20 14:00 ` Thierry Reding
2014-05-20 14:00 ` Thierry Reding
2014-05-20 14:00 ` Thierry Reding
2014-05-20 20:31 ` Arnd Bergmann
2014-05-20 20:31 ` Arnd Bergmann
2014-05-21 8:16 ` Thierry Reding
2014-05-21 8:16 ` Thierry Reding
2014-05-21 8:16 ` Thierry Reding
2014-05-21 8:54 ` Arnd Bergmann
2014-05-21 8:54 ` Arnd Bergmann
2014-05-21 8:54 ` Arnd Bergmann
2014-05-21 9:02 ` Thierry Reding
2014-05-21 9:02 ` Thierry Reding
2014-05-21 9:02 ` Thierry Reding
2014-05-21 9:32 ` Arnd Bergmann
2014-05-21 9:32 ` Arnd Bergmann
2014-05-21 15:44 ` Grant Grundler
2014-05-21 15:44 ` Grant Grundler
2014-05-21 15:44 ` Grant Grundler
2014-05-21 16:01 ` Arnd Bergmann
2014-05-21 16:01 ` Arnd Bergmann
2014-05-21 16:01 ` Arnd Bergmann
2014-05-20 15:24 ` Dave Martin
2014-05-20 15:24 ` Dave Martin
2014-05-20 15:24 ` Dave Martin
[not found] ` <20140520152458.GB5041-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-20 20:26 ` Arnd Bergmann
2014-05-20 20:26 ` Arnd Bergmann
2014-05-20 20:26 ` Arnd Bergmann
2014-05-21 8:26 ` Thierry Reding
2014-05-21 8:26 ` Thierry Reding
2014-05-21 8:26 ` Thierry Reding
2014-05-21 8:50 ` Arnd Bergmann
2014-05-21 8:50 ` Arnd Bergmann
2014-05-21 8:50 ` Arnd Bergmann
2014-05-21 9:00 ` Thierry Reding
2014-05-21 9:00 ` Thierry Reding
2014-05-21 9:00 ` Thierry Reding
2014-05-21 9:36 ` Arnd Bergmann
2014-05-21 9:36 ` Arnd Bergmann
2014-05-21 9:36 ` Arnd Bergmann
2014-05-21 10:50 ` Thierry Reding
2014-05-21 10:50 ` Thierry Reding
2014-05-21 10:50 ` Thierry Reding
2014-05-21 14:01 ` Arnd Bergmann
2014-05-21 14:01 ` Arnd Bergmann
2014-05-21 14:01 ` Arnd Bergmann
2014-05-21 17:09 ` Dave Martin
2014-05-21 17:09 ` Dave Martin
2014-05-21 17:09 ` Dave Martin
[not found] ` <20140521170954.GC3830-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-21 18:11 ` Arnd Bergmann [this message]
2014-05-21 18:11 ` Arnd Bergmann
2014-05-21 18:11 ` Arnd Bergmann
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=4393962.rf2bYfTJVU@wuerfel \
--to=arnd-r2ngtmty4d4@public.gmane.org \
--cc=Dave.Martin-5wv7dgnIgG8@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.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 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.