LCA13: Common Display Framework (CDF)
Upcoming SlideShare
Loading in...5

LCA13: Common Display Framework (CDF)



Resource: LCA13

Resource: LCA13
Name: Common Display Framework (CDF)
Date: 05-03-2013
Speaker: Tom Gall



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    LCA13: Common Display Framework (CDF) LCA13: Common Display Framework (CDF) Presentation Transcript

    •  Introduction to CDF (V2)  Limitations of Existing Display Subsystem  CDF(v2) Internals  CDF(v2) Architecture  Exynos5250 MIPI DSI Driver prototyping using CDF
    • LAURENT PINCHART proposed that display panel implementation based on platform code based callbacks would need to be replaced by a driver-based panel framework. Several driver-based panel support solution already exist in the kernel. - The LCD device class is implemented in drivers/video/backlight/lcd.c and exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV API for historical reason, uses platform code callback for reset and power management, and doesn't include support for standard features available in today's "smart panels". - OMAP2+ based systems use custom panel drivers available in drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display controller) specific APIs. - Similarly, Exynos based systems use custom panel drivers available in drivers/video/exynos. single driver (s6e8ax0) is currently available. That driver is based on Exynos display controller specific APIs and on the LCD device class API.
    •  There is no provision of supporting panels which support multiple resolutions  Tied up with FBDEV framework  No generic methods for HOT Plug/Unplug.  No generic methods exposed to other driver (like DRM/FBDEV/V4L2)
    • Display entity represents any hardware block that processes or sinks display- related video streams. Display entities are abstract object that must be implemented by a real device. When a display entity driver probes a device it must create an  Instance of the display_entity structure,  Initialize it and  Register it with the CDF core. The display entity exposes abstract operations through function pointers, and the entity driver must implement those operations. They are divided in 2 groups  Control operations  Video operations.
    • Control operations are called by upper-level drivers, usually in response to a request originating from userspace. They control the Display Entity State and Operation. Currently defined control operations are set_state(), to control the state of the entity (off, standby or on) get_modes(), to retrieve the video modes supported by the entity get_params(), to retrive the data bus parameters at the entity input (sink) get_size(), to retrive the entity physical size (applicable to panels only)
    • Video operations are called by downstream entities on upstream entities (from a video data bus point of view) to control the video operation. The only currently defined video operation is set_stream(), to start (in continuous or single-shot mode) the video stream
    •  Video source entity pumps video data to the display entities.  It has display interface specific operation like  Enabling the video source  Disabling  Read/Write cmds to Display Entity
    • Panel Driver FBDEV DRM DSI DBI DPI HDMI/DVI Panel driver Registration with I/F driver • Power on • Reset • Backlight on/off Display I/F drivers
    • Panel Driver FBDEV DRM DSI DBI DPI HDMI/DVI CDF Display I/F drivers Video Source registration Display Entity Registration
    • MIPI DSI Framework LCD Panel Driver Registers driver with Exynos MIPI framework In machine init LCD Panel Device is registered with Exynos MIPI Framework MIPI DSI Driver - probe Find matching driver for LCD panel registered during machine init, attach the control ops to the panel data structure Call the probe of the LCD panel driver Power on LCD panel Call the init sequence of the LCD panel using the control ops LCD Panel Ready 1 2 3 4 5 6
    • LCD driver registers with MIPI DSI framework, MIPI driver probe gets called and it will in turn  Binds the LCD device with MIPI DSI Device  Calls the probe of the LCD driver  Puts the LCD on  And sets the initial sequence
    • MIPI DSI Platform Driver LCD Panel Platform Driver Power on LCD panel Return video source and ops LCD Panel Ready Common Display FrameworkRegisters the “Video Source along with control ops” with CDF Find “video source” by name. Call the init sequence of the LCD panel using video source ops Registers the “Display Entity” with CDF 2 6 5 4 31
    •  MIPI DSI registers a “video source” with control ops with Common Display Framework  Display Panel registers a “Display Entity” with control ops with Common Display Framework  So during the probe of the PANEL driver, it finds its video source by name, and uses the video source’s control ops to initialise the LCD panel
    •   