Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

3.
• Intentions of this session:
• Share the changes likely to happen as part of UMM initiative that
would affect how userspace works with allocation and buffers
• Share idea of central buffer allocator helpers
• Understand from the audience if the steps make any sense to their
experience domain; if not, what are the gaps.
• Try to find ways to fulfill the gaps; or at least document them clearly
Discussion, not presentation :)

4.
• Pre-UMM days, a sample userspace application, eg. one
working with a camera with v4l2 interface and a DRM
based display, would need to:
• know about the v4l2 and drm buffer structs,
• know who (or decide) will allocate, and sometimes have that fixed for
each platform,
• have some middleware component (like GStreamer) which could
handle conversions from one type of buffers to the other,
• in some cases, copy over data across buffers.
Pre-UMM State

7.
• dma-buf framework
• added to make sharing buffers across frameworks easier;
• no longer need to know all the buffer structs, if all participating
subsystems use the dma-buf API
• Also allows to defer allocation of backing storage till first
map_attachment() request from one of the attached devices
• There is interest in having central dmabuf allocator
helpers
• These can help in the userspace not having to worry about which
device’s allocator function to invoke;
• Userspace might be able to just:
• use a generic dma-buf exporter device,
• have each participating importer share their constraints during attach(),
• have the exporter device use these constraints to decide on where to
allocate from.
Changes post UMM initiative

9.
• With dma-buf, now the same sample userspace
application would need to:
• still know about the v4l2 and drm buffer formats,
• still know who will allocate, and sometimes have that fixed for each
platform,
• the allocator will also be the exporter of dma-buf, and the other ‘users’
of the buffers can just be ‘attached’ to the same exported buffer, and
use the same underlying memory
• no copying needed!
• have some middleware component (like GStreamer) which would not
need to do any conversions across types of buffers for zero-copy
purposes. (middleware would still be needed for other uses though -
cap negotiation etc).
Current State

10.
• Create a set of constraint aware dma-buf allocation
helper functions
• On dma_buf_attach(), store compatible constraints flags
for that device in dma-buf
• Provide helper functions that will look at constraints flags
on dma-buf and allocate memory from the compatible
heap
• userspace could be just one central dma-buf allocator,
which could be supplied with platform-specific heaps
Idea of Central dma-buf allocator helpers

14.
More about Linaro Connect: http://connect.linaro.org
More about Linaro: http://www.linaro.org/about/
More about Linaro engineering: http://www.linaro.org/engineering/
Linaro members: www.linaro.org/members