LCU14 BURLINGAME

Daniel Thompson, LCU14

LCU14-503: What to do about ADF?

ADF is a new(ish) feature found in 3.10 AOSP kernels that provides dma-buf centric plumbing framework between Android’s hwcomposer HAL and kernel driver

● Focuses heavily on data -> buffer validation, mapping and fencing

● Meta data (scaling, z-order, alpha...) is effectively out-of-scope; binary blob passed from HAL to driver

● Atomic display update (all buffers can hit the glass in one shot)

Atomic display framework (ADF)

- Greg Hackmann, Google (from Linux Plumbers Conference 2013)

struct adf_buffer { struct adf_overlay_engine *overlay_engine; u16 w, h; u32 format; /* DRM-style fourcc */

struct dma_buf *dma_bufs[ADF_MAX_PLANES]; u32 offset[ADF_MAX_PLANES]; u32 pitch[ADF_MAX_PLANES]; u8 n_planes;

struct sync_fence *acquire_fence; /* optional */};

Describing buffers

- Greg Hackmann, Google (from Linux Plumbers Conference 2013)

struct adf_post {

size_t n_bufs;

struct adf_buffer *bufs;

struct adf_buffer_mapping *mappings; /* ADF-provided */

size_t custom_data_size;

void *custom_data;

};

Describing atomic updates

- Greg Hackmann, Google (from Linux Plumbers Conference 2013)

1. ADF imports buffers, sanity-checks buffer sizes vs. formats2. Driver does hardware-specific checks and assembles internal state

int (*validate)(struct adf_device *dev, struct adf_post *cfg, void **driver_state);

3. ADF places config in queue4. ADF worker dequeues config, waits for fences to fire5. Driver updates hardware state and waits for flip

void (*post)(struct adf_device *dev, struct adf_post *cfg, void *driver_state);

6. ADF worker advances sync timeline and releases old buffers7. Driver cleans up internal state

void (*state_free)(struct adf_device *dev, void *driver_state);

Atomic updates

ADF significantly overlaps with DRM/KMS

Getting SoC drivers from GNU/Linux to work on Android/Linux (and vice versa) is simplified when GFX stack is unified. Want to avoid fragmented driver delivery and degraded bringup.

Even companies strongly engaged with upstream GFX developers may still end up with forked GFX drivers to support Android; a poor ROI on upstreaming effort.

Why do we care “what to do about ADF?”

LinaroAndroid hwcomposer HAL implemented with DRM/KMS

Rob Clark (TI/Linaro/Redhat)Atomic/nuclear modeset/pageflip

Emil VelikovUpstream libdrm for Android “Inspired by the work of Chih-Wei Huang, from the Android-x86 project”

“If there's community interest, moving forward I'd like to merge its functionality into KMS rather than keep it as a separate thing.” - Greg Hackmann

Community activity in similar areas

Evolution is (almost) always the Linux way... ... we have to treat ADF motivations and features like a shopping list

A strawman approach

- Greg Hackmann, Google (from Linux Plumbers Conference 2013)

Experiences with DRM/KMS

● Complex API geared toward incremental updates● CRTC + planes -> encoder(s) -> connector model doesn’t fit some

embedded hardware● Lots of boilerplate GEM + framebuffer code, duplicates dma-buf

functionality● Need support for custom pixel formats and explicit sync

Experiences with DRM/KMS

● Complex API geared toward incremental updates● CRTC + planes -> encoder(s) -> connector model doesn’t fit some

embedded hardware● Lots of boilerplate GEM + framebuffer code, duplicates dma-buf

functionality● Need support for custom pixel formats and explicit sync

A strawman approach

Gaps

Driver LOC count

Can’t model hardware

Driver LOC count

User space complexity

- Greg Hackmann, Google (from Linux Plumbers Conference 2013)

Evolution is (almost) always the Linux way... ... we have to treat ADF motivations and features like a shopping list

● Custom pixel formats● ADF uses FOURCC plus plugin validators to support custom format validation

● Fences (a.k.a. implict versus explicit sync)● Fence management is part of ADF not driver; by time driver is asked to “post” an

update the fences have already fired

● dma-buf without GEM

Gaps

● Examples● Non-memory backed planes (e.g. single colour, HDMI RX)● 4k bandwidth limitations leading to quirky data paths such as mixer groups

● ADF modelOverlays to scan out data and interfaces to display itA collection of overlays and interfaces for a “display” and are atomically managed

● KMS model● CRTC + planes + encoders + connector● Multiple CRTCs cannot drive a single encoder

Modelling the hardware

- Greg Hackmann, Google (from Linux Plumbers Conference 2013)

Modelling the hardware - ADF

Mixer A

Mixer B

Mixer C

HDMI

VGA

DSI

Overlay engine Interface

Device

- Laurent Pinchart, Ideas on Board (from LinuxCon Japan 2013)

Modelling the hardware - DRM/KMS

Frame Buffer(memory)

Planes

CRTC Encoder Connector

Connector

ConnectorEncoder

Planes(memory)

● Internal API complexity● KMS drivers which use CMA benefit from significantly reduced internal complexity

● GEM boilerplate● Framebuffer

● KMS can put an image on display in generic way without using fb (plymouth does this)● drm_fbdev_cma_init() gives a CMA based driver fbdev support in a single statement

● Copy-update-commit properties versus all-at-once meta-data● And to a lesser extent binary blobs versus properties

Driver LOC count

“One thing that makes him mad [is] being dismissive of regressions. If somebody responds to a regression report by telling the reporter to upgrade their user space, he will come down on them.”

- LWN reporting of “What makes Linus happy (or not)?” at Kernel Summit 2014

User space complexity

DRM is a capability based API. Is a modern subset or an

embedded subset possible?

More about Linaro Connect: connect.linaro.org Linaro members: www.linaro.org/membersMore about Linaro: www.linaro.org/about/