Hi all,
The followings are Samsung S.LSI requirement for memory provider.
1. User space API
1.1. New memory management(MM) features should includes followings
to the user space.: UMP
A. user space API for memory allocation from system memory: UMP
Any user process can allocate memory from kernel space by new MM model.
B. user space API for cache operations: flush, clean, invalidate
Any user process can do cache operation on the allocated memory.
C. user space API for mapping memory attribute as cacheable
When the system memory mapped into the user space,
user process can set its property as cacheable.
D. user space API for mapping memory attribute as non-cacheable
When the system memory mapped into the user space,
user process can set its property as non-cacheable.
1.2. Inter-process memory sharing: UMP
New MM features should provide memory sharing between user process.
A. Memory allocated by user space can be shared between user processes.
B. Memory allocated by kernel space can be shared between user processes.
2. Kernel space API
New MM features should includes followings to the kernel space.: CMA, VCMM
2-1. Physically memory allocator
A. kernel space API for contiguous memory allocation: CMA(*)
B. kernel space API for non-contiguous memory allocation: VCMM (*)
C. start address alignment: CMA, VCMM
D. selectable allocating region: CMA
*refer to the bottom's extension.
2-2. Device virtual address management: VCMM
New MM features should provide
the way of managing device virtual memory address as like followings:
A. IOMMU(System MMU) support
IOMMU is a kind of memory MMU, but IOMMU is dedicated for each device.
B. device virtual address mapping for each device
C. virtual memory allocation
D. mapping / remapping between phys and device virtual address
E. dedicated device virtual address space for each device
F. address translation between address space
U.V
/ \
K.V - P.A
\ /
D.V
U.V: User space address
K.A: Kernel space address
P.A: Physical address
D.V: Device virtual address
3. Extensions
A. extension for custom physical memory allocator
B. extension for custom MMU controller
-------------------------------------------------------------------------
You can find the implementation in the following git repository.
http://git.kernel.org/?p=linux/kernel/git/kki_ap/linux-2.6-
samsung.git;a=tree;hb=refs/heads/2.6.36-samsung
1. UMP (Unified Memory Provider)
- The UMP is an auxiliary component which enables memory to be shared
across different applications, drivers and hardware components.
- http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-
open-source/page__cid__133__show__newcomment/
- Suggested by ARM, Not submitted yet.
- implementation
drivers/media/video/samsung/ump/*
2. VCMM (Virtual Contiguous Memory Manager)
- The VCMM is a framework to deal with multiple IOMMUs in a system
with intuitive and abstract objects
- Submitted by Michal Nazarewicz @Samsung-SPRC
- Also submitted by KyongHo Cho @Samsung-SYS.LSI
- http://article.gmane.org/gmane.linux.kernel.mm/56912/match=vcm
- implementation
include/linux/vcm.h
include/linux/vcm-drv.h
mm/vcm.c
arch/arm/plat-s5p/s5p-vcm.c
arch/amr/plat-s5p/include/plat/s5p-vcm.h
3. CMA (Contiguous Memory Allocator)
- The Contiguous Memory Allocator (CMA) is a framework, which allows
setting up a machine-specific configuration for physically-contiguous
memory management. Memory for devices is then allocated according
to that configuration.
- http://lwn.net/Articles/396702/
- http://www.spinics.net/lists/linux-media/msg26486.html
- Submitted by Michal Nazarewicz @Samsung-SPRC
- implementation
mm/cma.c
include/linux/cma.h
4. SYS.MMU
- System MMU supports address transition from VA to PA.
- http://thread.gmane.org/gmane.linux.kernel.samsung-soc/3909
- Submitted by Sangbeom Kim
- Merged by Kukjin Kim, ARM/S5P ARM ARCHITECTURES maintainer
- implementation
arch/arm/plat-s5p/sysmmu.c
arch/arm/plat-s5p/include/plat/sysmmu.h
Best regards,
Jonghun Han
> -----Original Message-----
> From: linux-media-owner@xxxxxxxxxxxxxxx [mailto:linux-media-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Willy POISSON
> Sent: Tuesday, March 29, 2011 11:02 PM
> To: linux-media@xxxxxxxxxxxxxxx
> Subject: v4l: Buffer pools
>
> Hi all,
> Following to the Warsaw mini-summit action point, I would like to
open
> the thread to gather buffer pool & memory manager requirements.
> The list of requirement for buffer pool may contain:
> - Support physically contiguous and virtual memory
> - Support IPC, import/export handles (between
> processes/drivers/userland/etc)
> - Security(access rights in order to secure no one unauthorized is
> allowed to access buffers)
> - Cache flush management (by using setdomain and optimize when
flushing
> is needed)
> - Pin/unpin in order to get the actual address to be able to do
> defragmentation
> - Support pinning in user land in order to allow defragmentation while
> buffer is mmapped but not pined.
> - Both a user API and a Kernel API is needed for this module. (Kernel
> drivers needs to be able to resolve buffer handles as well from the memory
> manager module, and pin/unpin)
> - be able to support any platform specific allocator (Separate memory
> allocation from management as allocator is platform dependant)
> - Support multiple region domain (Allow to allocate from several
memory
> domain ex: DDR1, DDR2, Embedded SRAM to make for ex bandwidth load
> balancing ...)
> Another idea, but not so linked to memory management (more usage of
buffers),
> would be to have a common data container (structure to access data)
shared by
> several media (Imaging, video/still codecs, graphics, Display...) to ease
> usage of the data. This container could embed data type (video frames,
> Access Unit) , frames format, pixel format, width, height, pixel aspect
ratio,
> region of interest, CTS (composition time stamp), ColorSpace,
transparency
> (opaque, alpha, color key...), pointer on buffer(s) handle)...
> Regards,
> Willy.
> =============
> Willy Poisson
> ST-Ericsson
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
the
> body of a message to majordomo@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
