LCU14 503 - What To Do About ADF? --------------------------------------------------- Speaker: Daniel Thompson Date: September 19, 2014 --------------------------------------------------- ★ Session Summary ★ ADF is Android's Atomic Display Framework, which has been relatively recently developed and optionally replaces KMS and the framebuffer for forthcoming Android devices based on 3.10. It provides integration between Android's syncpoints to provide atomic display updates. This functionality is related to the atomic page flipping that has been proposed for KMS, but which hasn't yet been merged. This talk will cover a brief technical overview, and provide space for discussion as to how we should approach trying to unify these two implementations upstream, to avoid having totally forked display systems between Android and other Linux environments. --------------------------------------------------- ★ Resources ★ Zerista: http://lcu14.zerista.com/event/member/137790 Google Event: https://plus.google.com/u/0/events/cf8n0au00jkhodhmme5fk980mns Video: https://www.youtube.com/watch?v=umnEXIBULnQ&list=UUIVqQKxCyQLJS6xvSmfndLA Etherpad: http://pad.linaro.org/p/lcu14-503 --------------------------------------------------- ★ Event Details ★ Linaro Connect USA - #LCU14 September 15-19th, 2014 Hyatt Regency San Francisco Airport --------------------------------------------------- http://www.linaro.org http://connect.linaro.org

1. LCU14-503: What to do about ADF?
Daniel Thompson, LCU14
LCU14 BURLINGAME

2. Atomic display framework (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)

3. Describing buffers
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 */
};
- Greg Hackmann, Google (from Linux Plumbers Conference 2013)

4. Describing atomic updates
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;
};
- Greg Hackmann, Google (from Linux Plumbers Conference 2013)

5. Atomic updates
1. ADF imports buffers, sanity-checks buffer sizes vs. formats
2. 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 queue
4. ADF worker dequeues config, waits for fences to fire
5. 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 buffers
7. Driver cleans up internal state
void (*state_free)(struct adf_device *dev, void *driver_state);
- Greg Hackmann, Google (from Linux Plumbers Conference 2013)

6. Why do we care “what to do about ADF?”
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.

7. Community activity in similar areas
Linaro
Android hwcomposer HAL implemented with DRM/KMS
Rob Clark (TI/Linaro/Redhat)
Atomic/nuclear modeset/pageflip
Emil Velikov
Upstream 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

8. A strawman approach
Evolution is (almost) always the Linux way...
... we have to treat ADF motivations and features like a shopping list
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
- Greg Hackmann, Google (from Linux Plumbers Conference 2013)

9. A strawman approach
Evolution is (almost) always the Linux way...
... we have to treat ADF motivations and features like a shopping list
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
Can’t model
hardware
Driver
LOC count
Gaps
Driver
LOC count
User space
complexity
- Greg Hackmann, Google (from Linux Plumbers Conference 2013)

10. Gaps
● 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

11. Modelling the hardware
● Examples
● Non-memory backed planes (e.g. single colour, HDMI RX)
● 4k bandwidth limitations leading to quirky data paths such as mixer groups
● ADF model
Overlays to scan out data and interfaces to display it
A 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

12. Modelling the hardware - ADF
Mixer A
Mixer B
Mixer C
HDMI
VGA
DSI
Overlay engine Interface
Device
- Greg Hackmann, Google (from Linux Plumbers Conference 2013)

13. Modelling the hardware - DRM/KMS
Frame Buffer
(memory)
Planes
CRTC Encoder Connector
- Laurent Pinchart, Ideas on Board (from LinuxCon Japan 2013)
Connector
Encoder Connector
Planes
(memory)

14. Driver LOC count
● 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

15. User space complexity
“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
DRM is a capability based API.
Is a modern subset or an
embedded subset possible?

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