From: Arnd Bergmann <arnd@arndb.de>
To: linaro-mm-sig@lists.linaro.org
Cc: KyongHo Cho <pullip.cho@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Joerg Roedel <joro@8bytes.org>,
linux-mm@kvack.org, Kyungmin Park <kyungmin.park@samsung.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 0/2] ARM: DMA-mapping & IOMMU integration
Date: Mon, 13 Jun 2011 17:07:49 +0200 [thread overview]
Message-ID: <201106131707.49217.arnd@arndb.de> (raw)
In-Reply-To: <BANLkTi=HtrFETnjk1Zu0v9wqa==r0OALvA@mail.gmail.com>
On Monday 13 June 2011 16:12:05 KyongHo Cho wrote:
> Of course, the mapping created by by dma_alloc_writecombine()
> may be more efficient for CPU to update the DMA buffer.
> But I think mapping with dma_alloc_coherent() is not such a
> performance bottleneck.
>
> I think it is better to remove dma_alloc_writecombine() and replace
> all of it with dma_alloc_coherent().
I'm sure that the graphics people will disagree with you on that.
Having the frame buffer mapped in write-combine mode is rather
important when you want to efficiently output videos from your
CPU.
> In addition, IMHO, mapping to user's address is not a duty of dma_map_ops.
> dma_mmap_*() is not suitable for a system that has IOMMU
> because a DMA address does not equal to its correspondent physical
> address semantically.
>
> I think DMA APIs of ARM must be changed drastically to support IOMMU
> because IOMMU API does not manage virtual address space.
I can understand that there are arguments why mapping a DMA buffer into
user space doesn't belong into dma_map_ops, but I don't see how the
presence of an IOMMU is one of them.
The entire purpose of dma_map_ops is to hide from the user whether
you have an IOMMU or not, so that would be the main argument for
putting it in there, not against doing so.
Arnd
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-06-13 15:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-25 7:35 [RFC 0/2] ARM: DMA-mapping & IOMMU integration Marek Szyprowski
2011-05-25 7:35 ` [RFC 1/2] ARM: Move dma related inlines into arm_dma_ops methods Marek Szyprowski
2011-05-25 7:35 ` [RFC 2/2] ARM: initial proof-of-concept IOMMU mapper for DMA-mapping Marek Szyprowski
2011-06-13 14:12 ` [RFC 0/2] ARM: DMA-mapping & IOMMU integration KyongHo Cho
2011-06-13 15:07 ` Arnd Bergmann [this message]
2011-06-13 15:30 ` KyongHo Cho
2011-06-13 15:40 ` Catalin Marinas
2011-06-13 16:00 ` [Linaro-mm-sig] " KyongHo Cho
2011-06-13 17:55 ` Michael K. Edwards
2011-06-13 18:54 ` Jesse Barnes
2011-06-14 18:15 ` Michael K. Edwards
2011-06-14 18:21 ` Jesse Barnes
2011-06-14 19:10 ` Zach Pfeffer
2011-06-14 20:59 ` Michael K. Edwards
2011-06-13 18:01 ` Catalin Marinas
2011-06-13 15:46 ` Arnd Bergmann
2011-06-13 15:58 ` [Linaro-mm-sig] " KyongHo Cho
2011-06-14 7:46 ` Marek Szyprowski
2011-06-20 14:31 ` Subash Patel
2011-06-20 14:59 ` Marek Szyprowski
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=201106131707.49217.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=joro@8bytes.org \
--cc=kyungmin.park@samsung.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux@arm.linux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=pullip.cho@samsung.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).