linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).