From: "Michel Dänzer" <michel@daenzer.net>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: Memory sharing issue by application on V4L2 based device
Date: Fri, 07 Jan 2011 08:54:25 +0000 [thread overview]
Message-ID: <1294390465.6019.212.camel@thor.local> (raw)
In-Reply-To: <AANLkTinsduJkynwwEeM5K9f3D7C6jtBgkAyZ0-_0z2X-@mail.gmail.com>
On Fre, 2011-01-07 at 11:17 +0900, InKi Dae wrote:
> thank you for your comments.
>
> your second comment has no any problem as I said before, user virtual
> addess could be translated in page unit. but the problem, as you said,
> is that when cpu access to the memory in user mode, the memory
> allocated by malloc, page fault occurs so we can't find pfn to user
> virtual address. I missed that. but I think we could resolve this one.
>
> as before, user application allocates memory through malloc function
> and then send it to device driver(using userptr feature). if the pfn
> is null when device driver translated user virtual address in page
> unit then it allocates phsical memory in page unit using some
> interface such as alloc_page() and then mapping them. when pfn is
> null, to check it and allocate physical memory in page unit could be
> processed by videobuf2.
>
> of course, videobuf2 has no any duty considered for system mmu. so
> videobuf2 just provides callback for 3rd party and any platform with
> system mmu such as Samsung SoC C210 implements the function(allocating
> physical memory and mapping it) and registers it to callback of
> videobuf2. by doing so, I think your first comment could be cleared.
FWIW, TTM (drivers/gpu/drm/ttm, include/drm/ttm) is designed and used
for managing memory between CPU/GPU and kernel/userspace access. I
haven't looked at your requirements in detail, but if you haven't looked
at TTM yet, it sounds like it might be worth a look.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
next prev parent reply other threads:[~2011-01-07 8:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-06 12:57 Memory sharing issue by application on V4L2 based device driver with daeinki
[not found] ` <AANLkTi=P8qY22saY9a_-rze1wsr-DLMgc6Lfa6qnfM7u@mail.gmail.com>
[not found] ` <002201cbadfd$6d59e490$480dadb0$%han@samsung.com>
2011-01-07 2:17 ` Memory sharing issue by application on V4L2 based device driver InKi Dae
2011-01-07 3:19 ` Jonghun Han
2011-01-07 4:19 ` daeinki
2011-01-11 17:35 ` Memory sharing issue by application on V4L2 based device Konrad Rzeszutek Wilk
2011-01-13 8:39 ` Memory sharing issue by application on V4L2 based device driver Jonghun Han
2011-01-07 8:54 ` Michel Dänzer [this message]
2011-01-07 10:02 ` daeinki
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=1294390465.6019.212.camel@thor.local \
--to=michel@daenzer.net \
--cc=linux-arm-kernel@lists.infradead.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).