From: "Michael K. Edwards" <m.k.edwards@gmail.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: KyongHo Cho <pullip.cho@samsung.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Joerg Roedel <joro@8bytes.org>,
linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org,
Kyungmin Park <kyungmin.park@samsung.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [Linaro-mm-sig] [RFC 0/2] ARM: DMA-mapping & IOMMU integration
Date: Tue, 14 Jun 2011 11:15:38 -0700 [thread overview]
Message-ID: <BANLkTimV5ZXVTDDFqHxMpOkrgokdCp1YXA@mail.gmail.com> (raw)
In-Reply-To: <20110613115437.62824f2f@jbarnes-desktop>
On Mon, Jun 13, 2011 at 11:54 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> Well only if things are really broken. sysfs exposes _wc resource
> files to allow userland drivers to map a given PCI BAR using write
> combining, if the underlying platform supports it.
Mmm, I hadn't spotted that; that is useful, at least as sample code.
Doesn't do me any good directly, though; I'm not on a PCI device, I'm
on a SoC. And what I need to do is to allocate normal memory through
an uncacheable write-combining page table entry (with certainty that
it is not aliased by a cacheable entry for the same physical memory),
and use it for interchange of data (GPU assets, compressed video) with
other on-chip cores. (Or with off-chip PCI devices which use DMA to
transfer data to/from these buffers and then interrupt the CPU to
notify it to rotate them.)
What doesn't seem to be straightforward to do from userland is to
allocate pages that are locked to physical memory and mapped for
write-combining. The device driver shouldn't have to mediate their
allocation, just map to a physical address (or set up an IOMMU entry,
I suppose) and pass that to the hardware that needs it. Typical
userland code that could use such a mechanism would be the Qt/OpenGL
back end (which needs to store decompressed images and other
pre-rendered assets in GPU-ready buffers) and media pipelines.
> Similarly, userland mapping of GEM objects through the GTT are supposed
> to be write combined, though I need to verify this (we've had trouble
> with it in the past).
Also a nice source of sample code; though, again, I don't want this to
be driver-specific. I might want a stage in my media pipeline that
uses the GPU to perform, say, lens distortion correction. I shouldn't
have to go through contortions to use the same buffers from the GPU
and the video capture device. The two devices are likely to have
their own variants on scatter-gather DMA, with a circularly linked
list of block descriptors with ownership bits and all that jazz; but
the actual data buffers should be generic, and the userland pipeline
setup code should just allocate them (presumably as contiguous regions
in a write-combining hugepage) and feed them to the plumbing.
Cheers,
- Michael
--
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-14 18:15 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
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 [this message]
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=BANLkTimV5ZXVTDDFqHxMpOkrgokdCp1YXA@mail.gmail.com \
--to=m.k.edwards@gmail.com \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=jbarnes@virtuousgeek.org \
--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=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).