lcu14 503 - what to do about adf?
DESCRIPTION
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.orgTRANSCRIPT
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/