All of lore.kernel.org
 help / color / mirror / Atom feed
From: daeinki <inki.dae@samsung.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: Memory sharing issue by application on V4L2 based device driver
Date: Fri, 07 Jan 2011 10:02:14 +0000	[thread overview]
Message-ID: <4D26E4A6.2020103@samsung.com> (raw)
In-Reply-To: <1294390465.6019.212.camel@thor.local>

Michel Dänzer 쓴 글:
> 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.
> 
> 
Thank you for your advice. I would look at TTM driver.

WARNING: multiple messages have this Message-ID (diff)
From: inki.dae@samsung.com (daeinki)
To: linux-arm-kernel@lists.infradead.org
Subject: Memory sharing issue by application on V4L2 based device driver with system mmu.
Date: Fri, 07 Jan 2011 19:02:14 +0900	[thread overview]
Message-ID: <4D26E4A6.2020103@samsung.com> (raw)
In-Reply-To: <1294390465.6019.212.camel@thor.local>

Michel D?nzer ? ?:
> 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.
> 
> 
Thank you for your advice. I would look at TTM driver.

WARNING: multiple messages have this Message-ID (diff)
From: daeinki <inki.dae@samsung.com>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: InKi Dae <daeinki@gmail.com>,
	Jonghun Han <jonghun.han@samsung.com>,
	linux-media@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-fbdev <linux-fbdev@vger.kernel.org>,
	kyungmin.park@samsung.com
Subject: Re: Memory sharing issue by application on V4L2 based device driver with system mmu.
Date: Fri, 07 Jan 2011 19:02:14 +0900	[thread overview]
Message-ID: <4D26E4A6.2020103@samsung.com> (raw)
In-Reply-To: <1294390465.6019.212.camel@thor.local>

Michel Dänzer 쓴 글:
> 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.
> 
> 
Thank you for your advice. I would look at TTM driver.

  reply	other threads:[~2011-01-07 10:02 UTC|newest]

Thread overview: 24+ 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
2011-01-06 12:57 ` Memory sharing issue by application on V4L2 based device driver with system mmu daeinki
2011-01-06 13:25 ` InKi Dae
2011-01-06 23:57   ` Jonghun Han
2011-01-07  2:17     ` Memory sharing issue by application on V4L2 based device driver InKi Dae
2011-01-07  2:17       ` Memory sharing issue by application on V4L2 based device driver with system mmu InKi Dae
2011-01-07  2:17       ` InKi Dae
2011-01-07  3:19       ` Memory sharing issue by application on V4L2 based device driver Jonghun Han
2011-01-07  3:19         ` Memory sharing issue by application on V4L2 based device driver with system mmu Jonghun Han
2011-01-07  3:19         ` Jonghun Han
2011-01-07  4:19         ` Memory sharing issue by application on V4L2 based device driver daeinki
2011-01-07  4:19           ` Memory sharing issue by application on V4L2 based device driver with system mmu daeinki
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-11 17:35           ` Memory sharing issue by application on V4L2 based device driver with system mmu Konrad Rzeszutek Wilk
2011-01-13  8:39           ` Memory sharing issue by application on V4L2 based device driver Jonghun Han
2011-01-13  8:39             ` Memory sharing issue by application on V4L2 based device driver with system mmu Jonghun Han
2011-01-13  8:39             ` Jonghun Han
2011-01-07  8:54       ` Memory sharing issue by application on V4L2 based device Michel Dänzer
2011-01-07  8:54         ` Memory sharing issue by application on V4L2 based device driver with system mmu Michel Dänzer
2011-01-07  8:54         ` Michel Dänzer
2011-01-07 10:02         ` daeinki [this message]
2011-01-07 10:02           ` daeinki
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=4D26E4A6.2020103@samsung.com \
    --to=inki.dae@samsung.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.