From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Inki Dae <inki.dae@samsung.com>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Arnd Bergmann <arnd@arndb.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Kyungmin Park <kyungmin.park@samsung.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
linux-tegra@vger.kernel.org
Subject: Re: [Linaro-mm-sig] [RFC 0/2] DMA-mapping & IOMMU - physically contiguous allocations
Date: Tue, 16 Oct 2012 11:31:09 +0100 [thread overview]
Message-ID: <20121016103109.GA21164@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAAQKjZNQFfxpr-7dFb4cgNB2Gkrxxrswds_fSrYgssxXaqRF7g@mail.gmail.com>
On Tue, Oct 16, 2012 at 07:12:49PM +0900, Inki Dae wrote:
> Hi Hiroshi,
>
> I'm not sure I understand what you mean but we had already tried this
> way and for this, you can refer to below link,
> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg22555.html
>
> but this way had been pointed out by drm guys because the pages could
> be used through gem object after that pages had been freed by free()
> anyway their pointing was reasonable and I'm trying another way, this
> is the way that the pages to user space has same life time with dma
> operation. in other word, if dma completed access to that pages then
> also that pages will be freed. actually drm-based via driver of
> mainline kernel is using same way
I don't know about Hiroshi, but the above "sentence" - and I mean the 7
line sentence - is very difficult to understand and wears readers out.
If your GPU hardware has a MMU, then the problem of dealing with userspace
pages is very easy. Do it the same way that the i915 driver and the rest
of DRM does. Use shmem backed memory.
I'm doing that for the Dove DRM driver and it works a real treat, and as
the pages are backed by page cache pages, you can use all the normal
page refcounting on them to prevent them being freed until your DMA has
completed. All my X pixmaps are shmem backed drm objects, except for
the scanout buffers which are dumb drm objects (because they must be
contiguous.)
In fact, get_user_pages() will take the reference for you before you pass
them over to dma_map_sg(). On completion of DMA, you just need to use
dma_unmap_sg() and release each page.
If you don't want to use get_user_pages() (which other drivers don't) then
you need to following the i915 example and get each page out of shmem
individually.
(My situation on the Dove hardware is a little different, because the
kernel DRM driver isn't involved with the GPU - it merely provides the
memory for pixmaps. The GPU software stack, being a chunk of closed
source userspace library with open source kernel driver, means that
things are more complicated; the kernel side GPU driver uses
get_user_pages() to pin them prior to building the GPU's MMU table.)
--
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:[~2012-10-16 10:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-15 14:03 Marek Szyprowski
2012-10-15 14:03 ` [RFC 1/2] common: DMA-mapping: add DMA_ATTR_FORCE_CONTIGUOUS attribute Marek Szyprowski
2012-10-15 14:03 ` [RFC 2/2] ARM: dma-mapping: add support for " Marek Szyprowski
2012-10-16 0:50 ` [RFC 0/2] DMA-mapping & IOMMU - physically contiguous allocations Inki Dae
2012-10-16 6:04 ` [Linaro-mm-sig] " Hiroshi Doyu
2012-10-16 8:59 ` Russell King - ARM Linux
2012-10-16 10:04 ` Catalin Marinas
2012-10-16 10:27 ` Hiroshi Doyu
2012-10-16 10:37 ` Russell King - ARM Linux
2012-10-16 10:12 ` Inki Dae
2012-10-16 10:31 ` Russell King - ARM Linux [this message]
2012-10-16 11:11 ` Inki Dae
2012-10-16 14:13 ` Hiroshi Doyu
2012-10-16 22:54 ` Inki Dae
2012-10-16 9:30 ` Daniel Vetter
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=20121016103109.GA21164@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=arnd@arndb.de \
--cc=hdoyu@nvidia.com \
--cc=inki.dae@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-tegra@vger.kernel.org \
--cc=m.szyprowski@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