Hello,

That's not a translation issue. What I mention is the size of allocation.
The malloc uses 4KB page allocation and SYS.MMU can handle it.
But 64KB or 1MB physically contiguous memory is better than 4KB page in the
point of performance.

Best regards,

-----Original Message-----
From: linux-media-owner at vger.kernel.org [mailto:linux-media-
owner at vger.kernel.org] On Behalf Of InKi Dae
Sent: Friday, January 07, 2011 11:17 AM
To: Jonghun Han
Cc: linux-media at vger.kernel.org; linux-arm-kernel at lists.infradead.org;

linux-fbdev;

kyungmin.park at samsung.com
Subject: Re: Memory sharing issue by application on V4L2 based device

driver

with system mmu.

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.

please, feel free to give me your opinion and pointing out.

thank you.

2011? 1? 7? ?? 8:57, Jonghun Han [off-list ref]?? ?:

quoted

Hello,

There are two reasons why malloc isn't suitable for it.

The first is that malloc doesn't allocate memory when malloc is called.
So driver or vb2 cannot find PFN for it in the VIDIOC_QBUF.

The second is that malloc uses 4KB page allocation.
SYS.MMU(IO-MMU) can handle scattered memory. But it has a penalty when
TLB miss is occurred.
So as possible as physically contiguous pages are needed for
performance enhancement.

So new allocator which can clear two main issues is needed.

Best regards,

quoted

-----Original Message-----
From: linux-media-owner at vger.kernel.org [mailto:linux-media-
owner at vger.kernel.org] On Behalf Of InKi Dae
Sent: Thursday, January 06, 2011 10:25 PM
To: linux-media at vger.kernel.org
Subject: Memory sharing issue by application on V4L2 based device
driver

with

quoted

system mmu.

Hello, all.

I'd like to discuss memory sharing issue by application on v4l2 based

device driver

quoted

with system mmu and get some advices about that.

Now I am working on Samsung SoC C210 platform and this platform has
some multimedia devices with system mmu such as fimc, and mfc also we
have implemented device drivers for them. those drivers are based on
V4L2

framework

quoted

with videobuf2. for system mmu of each device, we used VCM(Virtual

Contiguous

quoted

Memory) framework.

Simply, VCM framework provides  physical memory, device virtual
memory allocation and memory mapping between them. when device driver
is

initialized or

quoted

operated by user application, each driver allocates physical memory
and

device

quoted

virtual memory and then mapping using VCM interface.

refer to below link for more detail.
http://www.spinics.net/lists/linux-media/msg26548.html

Physical memory access process is as the following.
           DVA                          PA
device --------------> system mmu ------------------> physical memory

DVA : device virtual address.
PA : physical address.

like this, device virtual address should be set to buffer(source or
destination) register of multimedia device.

the problem is that application want to share own memory with any
device

driver to

quoted

avoid memory copy. in other words, user-allocated memory could be
source

or

quoted

destination memory of multimedia device driver.


let's see the diagram below.

               user application

                     |
                     |
                     |
                     |
                     |  1. UVA(allocated by malloc)
                     |
                     |
                   ?|/                   2. UVA(in page unit)

       -----> multimedia device driver -------------------> videobuf2
       |
       |        |     ^                                         |
       |        |     |                                         |
       |        |     -------------------------------------------
       |        |                    3. PA(in page unit)
       |        |
       |        | 4. PA(in page unit)
6. DVA  |        |
       |        |
       |        |
       |      ?|/
       |
       |       Virtual Contiguous Memory ---------
       |                                         |
       |           |     ^                       |
       |           |     |                       | 5. map PA to DVA
       |           |     |                       |
       |           |     |                       |
       -------------     -------------------------

PA : physical address.
UVA : user virtual address.
DVA : device virtual address.

1. user application allocates user space memory through malloc
function

and

quoted

sending it to multimedia device driver based on v4l2 framework
through

userptr

quoted

feature.

2, 3. multimedia device driver gets translated physical address from
videobuf2 framework in page unit.

4, 5. multimedia device driver gets allocated device virtual address
and

mapping it

quoted

to physical address and then mapping them through VCM interface.

6. multimedia device driver sets device virtual address from VCM to

buffer register.

quoted

the diagram above is fully theoretical so I wonder that this way is

reasonable and

quoted

has some problems also what should be considered.

thank you for your interesting.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe
linux-media" in

the body

quoted

of a message to majordomo at vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in

the body

of a message to majordomo at vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html