From: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk>
Hi all,
here is the v2 iteration of the Wayland protocol extension for generic sharing
of dmabufs between clients and the compositor.
The RFCv1 can be found at
http://lists.freedesktop.org/archives/wayland-devel/2014-December/019006.ht…
The related tracking bug is
https://bugs.freedesktop.org/show_bug.cgi?id=83881
The major changes compared to RFCv1 are:
- use drm_fourcc.h to define format codes
- support FB modifiers and y-flip
- simplified protocol
- improved documentation
- flags for interlaced buffer content
As you can see, we have dropped the "RFC" status from this series now. We think
this is in a good enough shape to be merged into Weston as an experimental
protocol and implementation. Obviously we are still lacking on:
- agreed ways to flush caches (what can we cache? EGLImages? DRM FBs?)
- enumerating supported formats
- supported FB modifiers?
- do all imports in compositor before-hand, not as-needed
(the import as DRM FB)
- EGL doesn't support dmabuf import with modifiers yet
- a test application not specific to (Intel) hardware (vivid?)
- compositor-drm.c's import of dmabuf needs a rewrite to bypass GBM
(to be done after atomic lands)
- compositor-drm.c support for multi-planar buffers
This patch series is also available at:
https://git.collabora.com/cgit/user/pq/weston.git/log/?h=dmabuf-v2
Cc: Daniel Stone <daniel(a)fooishbar.org>
Cc: Louis-Francis Ratté-Boulianne <lfrb(a)collabora.com>
Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
Cc: Axel Davy <axel.davy(a)ens.fr>
Cc: linaro-mm-sig(a)lists.linaro.org
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Cc: Thomas Hellstrom <thellstrom(a)vmware.com>
Cc: Rob Clark <robdclark(a)gmail.com>
Cc: George Kiagiadakis <george.kiagiadakis(a)collabora.com>
George Kiagiadakis (1):
clients: add simple-dmabuf client
Louis-Francis Ratté-Boulianne (1):
gl-renderer: introduce struct egl_image
Pekka Paalanen (6):
protocol: add linux_dmabuf extension (v2)
dmabuf: implement linux_dmabuf extension
gl-renderer: add dmabuf import
compositor-x11: init linux_dmabuf support
compositor-drm: init linux_dmabuf support
compositor-drm: dmabuf GBM import
.gitignore | 1 +
Makefile.am | 25 +-
clients/simple-dmabuf.c | 591 ++++++++++++++++++++++++++++++++++++++++++++++
configure.ac | 10 +
protocol/linux-dmabuf.xml | 279 ++++++++++++++++++++++
src/compositor-drm.c | 49 +++-
src/compositor-x11.c | 7 +
src/compositor.c | 28 +++
src/compositor.h | 9 +
src/gl-renderer.c | 303 +++++++++++++++++++++++-
src/linux-dmabuf.c | 497 ++++++++++++++++++++++++++++++++++++++
src/linux-dmabuf.h | 84 +++++++
src/weston-egl-ext.h | 16 ++
13 files changed, 1885 insertions(+), 14 deletions(-)
create mode 100644 clients/simple-dmabuf.c
create mode 100644 protocol/linux-dmabuf.xml
create mode 100644 src/linux-dmabuf.c
create mode 100644 src/linux-dmabuf.h
--
2.3.6
Thanks,
pq
version 3 changes:
- Remove ioctl for allocator selection instead provide the name of
the targeted allocator with allocation request.
Selecting allocator from userland isn't the prefered way of working
but is needed when the first user of the buffer is a software component.
- Fix issues in case of error while creating smaf handle.
- Fix module license.
- Update libsmaf and tests to care of the SMAF API evolution
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
version 2 changes:
- Add one ioctl to allow allocator selection from userspace.
This is required for the uses case where the first user of
the buffer is a software IP which can't perform dma_buf attachement.
- Add name and ranking to allocator structure to be able to sort them.
- Create a tiny library to test SMAF:
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
- Fix one issue when try to secure buffer without secure module registered
The outcome of the previous RFC about how do secure data path was the need
of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
SMAF goal is to provide a framework that allow allocating and securing
memory by using dma_buf. Each platform have it own way to perform those two
features so SMAF design allow to register helper modules to perform them.
To be sure to select the best allocation method for devices SMAF implement
deferred allocation mechanism: memory allocation is only done when the first
device effectively required it.
Allocator modules have to implement a match() to let SMAF know if they are
compatibles with devices needs.
This patch set provide an example of allocator module which use
dma_{alloc/free/mmap}_attrs() and check if at least one device have
coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
a better name could be found for this file.
Secure modules are responsibles of granting and revoking devices access rights
on the memory. Secure module is also called to check if CPU map memory into
kernel and user address spaces.
An example of secure module implementation can be found here:
http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
This code isn't yet part of the patch set because it depends on generic TEE
which is still under discussion (https://lwn.net/Articles/644646/)
For allocation part of SMAF code I get inspirated by Sumit Semwal work about
constraint aware allocator.
Benjamin Gaignard (2):
create SMAF module
SMAF: add CMA allocator
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/smaf/Kconfig | 11 +
drivers/smaf/Makefile | 2 +
drivers/smaf/smaf-cma.c | 200 +++++++++++
drivers/smaf/smaf-core.c | 735 +++++++++++++++++++++++++++++++++++++++++
include/linux/smaf-allocator.h | 54 +++
include/linux/smaf-secure.h | 62 ++++
include/uapi/linux/smaf.h | 52 +++
9 files changed, 1119 insertions(+)
create mode 100644 drivers/smaf/Kconfig
create mode 100644 drivers/smaf/Makefile
create mode 100644 drivers/smaf/smaf-cma.c
create mode 100644 drivers/smaf/smaf-core.c
create mode 100644 include/linux/smaf-allocator.h
create mode 100644 include/linux/smaf-secure.h
create mode 100644 include/uapi/linux/smaf.h
--
1.9.1
I will change the ident in the macro.
Thanks,
Benjamin
2015-07-07 9:59 GMT+02:00 Paul Bolle <pebolle(a)tiscali.nl>:
> A nit only, I'm afraid: a license mismatch.
>
> On ma, 2015-07-06 at 13:40 +0200, Benjamin Gaignard wrote:
> > --- /dev/null
> > +++ b/drivers/smaf/smaf-core.c
>
> > + * License terms: GNU General Public License (GPL), version 2
>
> > +MODULE_LICENSE("GPL");
>
> The comment at the top of this file states, succinctly, that the license
> is GPL v2. And, according to include/linux/module.h, the
> MODULE_LICENSE() macro here states that the license is GPL v2 or later.
> So I think that either that comment or the ident used in that macro
> needs to change.
>
> Ditto for 2/2.
>
> Thanks,
>
>
> Paul Bolle
>
--
Benjamin Gaignard
Graphic Working Group
Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter
<http://twitter.com/#!/linaroorg> | Blog
<http://www.linaro.org/linaro-blog/>
version 2 changes:
- Add one ioctl to allow allocator selection from userspace.
This is required for the uses case where the first user of
the buffer is a software IP which can't perform dma_buf attachement.
- Add name and ranking to allocator structure to be able to sort them.
- Create a tiny library to test SMAF:
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
- Fix one issue when try to secure buffer without secure module registered
The outcome of the previous RFC about how do secure data path was the need
of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
SMAF goal is to provide a framework that allow allocating and securing
memory by using dma_buf. Each platform have it own way to perform those two
features so SMAF design allow to register helper modules to perform them.
To be sure to select the best allocation method for devices SMAF implement
deferred allocation mechanism: memory allocation is only done when the first
device effectively required it.
Allocator modules have to implement a match() to let SMAF know if they are
compatibles with devices needs.
This patch set provide an example of allocator module which use
dma_{alloc/free/mmap}_attrs() and check if at least one device have
coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
a better name could be found for this file.
Secure modules are responsibles of granting and revoking devices access rights
on the memory. Secure module is also called to check if CPU map memory into
kernel and user address spaces.
An example of secure module implementation can be found here:
http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
This code isn't yet part of the patch set because it depends on generic TEE
which is still under discussion (https://lwn.net/Articles/644646/)
For allocation part of SMAF code I get inspirated by Sumit Semwal work about
constraint aware allocator.
Benjamin Gaignard (2):
create SMAF module
SMAF: add CMA allocator
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/smaf/Kconfig | 11 +
drivers/smaf/Makefile | 2 +
drivers/smaf/smaf-cma.c | 200 +++++++++++
drivers/smaf/smaf-core.c | 751 +++++++++++++++++++++++++++++++++++++++++
include/linux/smaf-allocator.h | 54 +++
include/linux/smaf-secure.h | 62 ++++
include/uapi/linux/smaf.h | 61 ++++
9 files changed, 1144 insertions(+)
create mode 100644 drivers/smaf/Kconfig
create mode 100644 drivers/smaf/Makefile
create mode 100644 drivers/smaf/smaf-cma.c
create mode 100644 drivers/smaf/smaf-core.c
create mode 100644 include/linux/smaf-allocator.h
create mode 100644 include/linux/smaf-secure.h
create mode 100644 include/uapi/linux/smaf.h
--
1.9.1