From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Zach Pfeffer <zpfeffer@codeaurora.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
linux-arch@vger.kernel.org, dwalker@codeaurora.org,
mel@csn.ul.ie, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
andi@firstfloor.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
Date: Thu, 8 Jul 2010 00:07:10 +0100 [thread overview]
Message-ID: <20100707230710.GA31792@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <4C35034B.6040906@codeaurora.org>
On Wed, Jul 07, 2010 at 03:44:27PM -0700, Zach Pfeffer wrote:
> The DMA API handles the allocation and use of DMA channels. It can
> configure physical transfer settings, manage scatter-gather lists,
> etc.
You're confused about what the DMA API is. You're talking about
the DMA engine subsystem (drivers/dma) not the DMA API (see
Documentation/DMA-API.txt, include/linux/dma-mapping.h, and
arch/arm/include/asm/dma-mapping.h)
> The VCM allows all device buffers to be passed between all devices in
> the system without passing those buffers through each domain's
> API. This means that instead of writing code to interoperate between
> DMA engines, IOMMU mapped spaces, CPUs and physically addressed
> devices the user can simply target a device with a buffer using the
> same API regardless of how that device maps or otherwise accesses the
> buffer.
With the DMA API, if we have a SG list which refers to the physical
pages (as a struct page, offset, length tuple), the DMA API takes
care of dealing with CPU caches and IOMMUs to make the data in the
buffer visible to the target device. It provides you with a set of
cookies referring to the SG lists, which may be coalesced if the
IOMMU can do so.
If you have a kernel virtual address, the DMA API has single buffer
mapping/unmapping functions to do the same thing, and provide you
with a cookie to pass to the device to refer to that buffer.
These cookies are whatever the device needs to be able to access
the buffer - for instance, if system SDRAM is located at 0xc0000000
virtual, 0x80000000 physical and 0x40000000 as far as the DMA device
is concerned, then the cookie for a buffer at 0xc0000000 virtual will
be 0x40000000 and not 0x80000000.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-07-07 23:08 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-03 5:38 [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management Zach Pfeffer
2010-07-03 19:06 ` Eric W. Biederman
2010-07-07 22:44 ` Zach Pfeffer
2010-07-07 23:07 ` Russell King - ARM Linux [this message]
2010-07-08 23:59 ` Zach Pfeffer
2010-07-12 1:25 ` FUJITA Tomonori
2010-07-13 5:57 ` Zach Pfeffer
2010-07-13 6:03 ` FUJITA Tomonori
2010-07-13 12:14 ` Zach Pfeffer
2010-07-14 1:59 ` FUJITA Tomonori
2010-07-14 20:11 ` Zach Pfeffer
2010-07-14 22:05 ` Russell King - ARM Linux
2010-07-15 1:29 ` Zach Pfeffer
2010-07-15 1:47 ` Eric W. Biederman
2010-07-15 5:40 ` Zach Pfeffer
2010-07-15 5:35 ` Zach Pfeffer
2010-07-15 8:55 ` Russell King - ARM Linux
2010-07-16 0:48 ` Tim HRM
2010-07-16 7:58 ` Russell King - ARM Linux
2010-07-17 0:01 ` Larry Bassel
2010-07-19 9:21 ` Tim HRM
2010-07-21 0:44 ` Zach Pfeffer
2010-07-21 1:44 ` Timothy Meade
2010-07-22 4:06 ` Zach Pfeffer
2010-07-19 17:55 ` Michael Bohan
2010-07-19 18:40 ` Russell King - ARM Linux
2010-07-20 22:02 ` stepanm
2010-07-20 22:29 ` Russell King - ARM Linux
2010-07-21 5:49 ` Shilimkar, Santosh
2010-07-21 7:28 ` Russell King - ARM Linux
2010-07-21 7:45 ` Shilimkar, Santosh
2010-07-21 18:04 ` stepanm
2010-07-20 20:45 ` Zach Pfeffer
2010-07-20 20:54 ` Russell King - ARM Linux
2010-07-20 21:56 ` Zach Pfeffer
2010-07-19 6:52 ` Zach Pfeffer
2010-07-19 7:44 ` Eric W. Biederman
2010-07-22 4:25 ` Zach Pfeffer
2010-07-22 7:34 ` Russell King - ARM Linux
2010-07-22 16:25 ` Zach Pfeffer
2010-07-14 23:07 ` FUJITA Tomonori
2010-07-15 1:41 ` Zach Pfeffer
2010-07-19 8:22 ` Russell King - ARM Linux
2010-07-20 10:09 ` FUJITA Tomonori
2010-07-20 22:20 ` Zach Pfeffer
2010-07-21 1:44 ` FUJITA Tomonori
2010-07-22 4:30 ` Zach Pfeffer
2010-07-22 4:43 ` FUJITA Tomonori
2010-07-22 16:44 ` Zach Pfeffer
2010-07-22 7:39 ` Russell King - ARM Linux
2010-07-22 16:28 ` Zach Pfeffer
-- strict thread matches above, loose matches on Subject: below --
2010-07-06 15:42 Zach Pfeffer
2010-07-21 5:18 stepanm
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=20100707230710.GA31792@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=andi@firstfloor.org \
--cc=dwalker@codeaurora.org \
--cc=ebiederm@xmission.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-omap@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=zpfeffer@codeaurora.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).