530 likes | 666 Views
Tizen Linux Kernel. Sungkyunkwan University. Tizen Kernel Additional features. Memory Management CMA (Contiguous Memory Allocator), IOMMU, dma_buf, DRM (Direct Rendering Manager) ARM Linux has no DMA_ZONE on buddy
E N D
Tizen Linux Kernel Sungkyunkwan University
Tizen Kernel Additional features • Memory Management • CMA (Contiguous Memory Allocator), IOMMU, dma_buf, DRM (Direct Rendering Manager) • ARM Linux has no DMA_ZONE on buddy • Some devices require physically contiguous memory (CMA), other devices has IOMMU thus be able to use non-contiguous memory • Sharing DMA memory buffer for D/D to user • Power management (CPUfreq, Devfreq, PM-QoS, Charger-manager) • KDBUS • V4L2 (Video for Linux 2) • EXTCON
Previous Reference Kernel • Linux 3.0.15 • Obsolete LTS (Current: 3.4 & 3.10) • Support RD-PQ (Tizen 2) & RD-210 (tizen 1 & 2) • RD-PQ: Exynos4412 • RD-210: Exynos 4210 (Linux 2.6.36 for Tizen 1) • Not Good as Reference • Too many backported features. • Too OLD! No LTS/LTSI support • Many kernel hacks & dirty patches • git history removed. • Forked from production kernel. • Hard to read
Status of Tizen Reference Kernels • Two reference kernels: ARM/Intel • ARM (armv7, aarch64) • Linux 3.10.y • 3.10.33 @ 2014/05 • Full git history • Armv6 support (Raspberry Pi) Coming soon. • Test & validation phase (integration test with userspace) • Intel (x86, x86_64) • Linux 3.14.1 • Recent ATOM Soc support merged
Tizen Memory Management • Coupled with Graphics & Multimedia devices • Graphics & Multimedia devices = DMA devices with HUGE Buffers
What is DRM • DRM is not Digital Right Management • Direct Rendering Manager • Kernel-level graphics device driver that support Direct Rendering Infrastructure. • Direct Rendering • An application communicates directly with graphics device driver • Display mode setting • Graphics memory management
Why DRM • Can give display experiences similar to PC environment. • Why not use DRM until now? • DRM was designed for PC • Embedded System • Low performance • No dedicated graphics memory • Not one graphics card but separated hardware devices • Linux frame buffer driver
Why DRM (cont) • Changed embedded environment • Powerful embedded SoCs • Requirements • Display hotplug & clone, exteded mode • Unified memory management • Direct rendering • Varying device control with common interface
DRM of Tizen kernel • Currently, DRM support is only for Exynos SoCs. (ARM based) • Need Exynos specific DRM driver • Exynos DRM driver • To support graphics hardware of Exynos SoCs • First ARM SoC graphics driver to use the DRM • Merged into the mainline linux 3.2 kernel • linux/drivers/gpu/drm/exynos
Graphics (DRM / GEM) • Graphics: • DRM (Direct Rendering Manager) / GEM (Graphics Execution Manager) • GEM • Framework developed by Intel • To manage graphics memory • Framework for buffer management • Allocation and sharing
DRM / GEM Allocation GEM Allocation steps @ Tizen (Generic) • DRM_IOCTL_MODE_CREATE_DUMB • Create GEM object(global) & user GEM handle(per process) • dumb_create() of struct drm_driver • No physical memory allocated. • DRM_IOCTL_MODE_MAP_DUMB • Create fake mmap offset of a gem object and relay the object to user • A hash key of the gem object. • dumb_map_offset() of struct drm_driver • MMAP • Request mmap based on the hash key as the offset • Create user address space • Setup cache attribute. • Not mapped to physical memory, yet
DRM / GEM Allocation (cont) GEM Allocation steps @ Tizen (Generic) • On-demand Paging • Implement & Register a fault handler that • With a page fault, allocate a page and map the page. • vma->vm_ops->fault = xxx_drm_gem_fault • Use! • DRM_IOCTL_MODE_DESTROY_DUMB • Remove GEM handle & object • Free memory • Implement dumb_destroy() of struct drm_driver
DRM / GEM Allocation (cont) GEM Allocation steps @ Tizen (Exynos Only) • DRM_IOCTL_EXYNOS_GEM_CREATE • Only use user-desired size and buffer types. • Create gem object(global) & user gem handle(per process) • physical memory allocated. • DRM_IOCTL_EXYNOS_GEM_MMAP • Create user address space • Map the user address space to physical memory • LIBDRM of Exynos uses these APIs, not the generic.
DRM / GEM Sharing GEM Sharing @ Tizen • DRM_IOCTL_GEM_FLINK • “I will share this GEM to others.” • Create GEM object name for the given GEM handle • Global key vaue for sharing • DRM_IOCTL_GEM_OPEN • “I want to use the shared GEM.” • Create GEM handle based on the given GEM object name • DRM_IOCTL_GEM_CLOSE
V4L2 / VB2 • Tizen recommends to use V4L2 at Tizen kernel for Multimedia devices • Video input (codec & camera) & Radio • However, as long as the kernel has..: • Gstreamer/OpenMAX plugins • A method to share with other F/W via DMABUF of UMM • If V4L2/VB2 is used, things get easier.
OpenGL / G3D-GPU • Most ARM SoC GPUs (MALI, SGX, …) use their own memory manager • E.g., Exynos4412/4210 Tizen Reference Kernel has Mali w/ UMM. • Mali DDK modified to be compatible with UMM-DMABUF. • If GPU drivers use DRM, it would be great. • (and make them GPL)
Tizen Kernel Buffer Sharing (cont) • Requirement from Tizen platform and hardware • Different Memory Managers: GEM, VB2, GPU-adhoc, … • Share buffers • w/o memcpy • From and to users • Never expose directly to users (e.g., physical address) UMM DMABUF!
Unified Memory Management (UMM) • Introduced by Jesse Barker, 2011 • Includes • DMABUF (sharing buffer) • Export • GEM/VB2/… object DMABUF • Import • DMABUF GEM/VB2/… object • Userspace sees DMABUF as a File Descriptor • DMA mapping API for allocation • CMA (Contiguous Memory Allocator) • IOMMU (MMU for I/O devs)
DMA Buffer Sharing Example • Camera App 1)Request V4L2 camera buffer (U) 2)Allocate CMA buffer (K) 3)Request a camera frame at the V4L2 buffer (U) 4)Store the camera frame & Notify user (K) 5)Request DMABUF export for the V4L2 camera buffer (U) 6)dma_buf_exporter() (K) • Create DMABUF from V4L2 buffer 7)dma_buf_fd() (K) • Provide FD of the DMABUF to user
DMA Buffer Sharing Example (cont) • Camera App 1)Request V4L2 camera buffer (U) 2)Allocate CMA buffer (K) 3)Request a camera frame at the V4L2 buffer (U) 4)Store the camera frame & Notify user (K) 5)Request DMABUF export for the V4L2 camera buffer (U) 6)dma_buf_exporter() (K) • Create DMABUF from V4L2 buffer 7)dma_buf_fd() (K) • Provide FD of the DMABUF to user
DMA Buffer Sharing Example (cont) • Camera App 1)Request V4L2 camera buffer (U) 2)Allocate CMA buffer (K) 3)Request a camera frame at the V4L2 buffer (U) 4)Store the camera frame & Notify user (K) 5)Request DMABUF export for the V4L2 camera buffer (U) 6)dma_buf_exporter() (K) • Create DMABUF from V4L2 buffer 7)dma_buf_fd() (K) • Provide FD of the DMABUF to user
DMA Buffer Sharing Example (cont) • Camera App 8)Request FD->GEM conversion (U) 9)dma_buf_get(fd) (K) • Get DMABUF from FD 10)dma_buf_attach(dma-buf) / dma_buf_map_attachment() (K) • Get Buffer from DMABUF 11)Import as GEM, send user (K) 12)Request GEM object name (U) 13)Return GEM object name (K) 14)Send GEM object name to X (U)
DMA Buffer Sharing Example (cont) • Camera App 8)Request FD->GEM conversion (U) 9)dma_buf_get(fd) (K) • Get DMABUF from FD 10)dma_buf_attach(dma-buf) / dma_buf_map_attachment() (K) • Get Buffer from DMABUF 11)Import as GEM, send user (K) 12)Request GEM object name (U) 13)Return GEM object name (K) 14)Send GEM object name to X (U)
DMA Buffer Sharing Example (cont) • X server 15)Convert given GEM object name to GEM. Display its content. (U & K)
DMA Buffer Sharing Example (cont) • Close after usage 1)“Free” the GEM object (U) 2)Remove reference from the DMABUF (K) 3)Close(DMABUF-FD) at cam app (U) 4)(No more reference to DMABUF) Release callback executed (K)
Problem Definition • Simple Usage Scenario • 1. CPU writes to buffer1. • 2. CPU tells GPU to do something on buffer1. • 3. GPU does something on buffer1. • GPU finishes. • 4. CPU reads the buffer1 How to ensure CPU won’t use buffer 1 until step 4? CPU GPU 2 1 BUS 4 3 DRAM
Problem Definition (cont) • What if there are two threads using GPU? • And if the two look at the same buffer? • Not even aware of it? • What if the two DMA devices (GPU, FIMC) share buffer? • But hard to know it at drivers or user threads. • FIMC never knows when GPU finishes • FIMC never knows when Threads1 stops using “buffer1” • Threads2 never know when GPU stops using “buffer1”
Buffer Synchronization • TGL (Tizen Global Lock) @ Tizen 2.0 • … Let userspace handle the issue … • Kernel patch required. • Sync Framework (Google) • Jun, 2012. Resources w/o DMABUF (similar with TGL) • KDS (Kernel Dependency System, ARM) • May 2012 / DMABUF-compatible • DMA Fence Framework (Canonical/TI) • Aug 2012 / DMABUF-compatible • Work-In-Progress
Kdbus –D-bus is? • D-Bus • Message bus system • Method Call transaction • Signals • Broadcasting
Kdbus –K-dbus is? • Low-level, native kernel D-Bus transport • All communication between processes take place over special character device nodes in /dev/kdbus • Receiver buffers • Single copy to destinations • memfds • File descriptor for memory regions • Zero copy implementation
EXTCON (External Connector) • Yet Another Weird Ad-hoc Kernel Hacks Removed • Manage status of cable & ports • A port with multiple cables (docks, multi-cables, …) • A port with multiple modes (USB, HDMI, TA, …) • 3.5pi: stereo, stereo+mic, stereo+mic+buttons, stereo+buttons, mono, … • Compatible with Switch • Android Switch drivers can be easily ported • Refer to Linux/Documentation (porting guide for switch driver) • Extcon drivers export both Switch and Extcon interfaces (compat mode) • In Reference Device • MUIC (USB+HDMI+TA+DOCK+…) • 3.5Pi Jack
Charger • Charger Manager (/drivers/power/charger-manager.c) • All needed by Tizen user space are prepared • No OAL modification required • OR supply battery/charger interface with power-supply-class • Use EXTCON for Cable-Input (MUIC in mobile) • Switch class is no longer available in Linux. • Note: some SOC (state-of-charge) value is required for mobile profile. Unless, Tizen will assume that SOC is 0 Shutdown!
Power Management • Recommendation For Tizen3.0 or later • Do not use DVFS (CPUfreq/Devfreq) min/max ABIs • PASS (Power-Aware System Service in Deviced) uses • Use (keep their standard ABIs for PASS) • CPUfreq& Devfreq(DVFS for non CPU devices if you have them) • Thermal FW • PASS gives hints to DVFS/Hotplug • based on the info from user space. • based on the other kernel ABIs (e.g., Thermal) • highly configurable. (control knob of performance & power)