Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
LCU14-503: What to do about ADF? 
Daniel Thompson, LCU14 
LCU14 BURLINGAME
Atomic display framework (ADF) 
ADF is a new(ish) feature found in 3.10 AOSP kernels that provides 
dma-buf centric plumbi...
Describing buffers 
struct adf_buffer { 
struct adf_overlay_engine *overlay_engine; 
u16 w, h; 
u32 format; /* DRM-style f...
Describing atomic updates 
struct adf_post { 
size_t n_bufs; 
struct adf_buffer *bufs; 
struct adf_buffer_mapping *mapping...
Atomic updates 
1. ADF imports buffers, sanity-checks buffer sizes vs. formats 
2. Driver does hardware-specific checks an...
Why do we care “what to do about ADF?” 
ADF significantly overlaps with DRM/KMS 
Getting SoC drivers from GNU/Linux to wor...
Community activity in similar areas 
Linaro 
Android hwcomposer HAL implemented with DRM/KMS 
Rob Clark (TI/Linaro/Redhat)...
A strawman approach 
Evolution is (almost) always the Linux way... 
... we have to treat ADF motivations and features like...
A strawman approach 
Evolution is (almost) always the Linux way... 
... we have to treat ADF motivations and features like...
Gaps 
● Custom pixel formats 
● ADF uses FOURCC plus plugin validators to support custom format validation 
● Fences (a.k....
Modelling the hardware 
● Examples 
● Non-memory backed planes (e.g. single colour, HDMI RX) 
● 4k bandwidth limitations l...
Modelling the hardware - ADF 
Mixer A 
Mixer B 
Mixer C 
HDMI 
VGA 
DSI 
Overlay engine Interface 
Device 
- Greg Hackmann...
Modelling the hardware - DRM/KMS 
Frame Buffer 
(memory) 
Planes 
CRTC Encoder Connector 
- Laurent Pinchart, Ideas on Boa...
Driver LOC count 
● Internal API complexity 
● KMS drivers which use CMA benefit from significantly reduced internal compl...
User space complexity 
“One thing that makes him mad [is] being dismissive of regressions. 
If somebody responds to a regr...
More about Linaro Connect: connect.linaro.org 
Linaro members: www.linaro.org/members 
More about Linaro: www.linaro.org/a...
Upcoming SlideShare
Loading in …5
×

LCU14 503 - What To Do About ADF?

2,229 views

Published on

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

Published in: Software
  • Be the first to comment

LCU14 503 - What To Do About ADF?

  1. 1. LCU14-503: What to do about ADF? Daniel Thompson, LCU14 LCU14 BURLINGAME
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. More about Linaro Connect: connect.linaro.org Linaro members: www.linaro.org/members More about Linaro: www.linaro.org/about/

×