Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

6 participants
2911 discussions

Re: [Linaro-mm-sig] [PATCH v4 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

I have mind few uses cases: - the basic one when an HW device need contiguous memory. - I have a device that could not cross some memory boundaries so I need a specific allocator for it. - when allocating memory for security some platform have address constraints or need to allocate memory in specific areas (most of the time because of firewall limited capacities in terms of regions) 2015-10-06 4:07 GMT+02:00 Laura Abbott <labbott(a)redhat.com>: > On 10/05/2015 03:11 AM, Benjamin Gaignard wrote: >> >> version 4 changes: >> - rebased on kernel 4.3-rc3 >> - fix missing EXPORT_SYMBOL for smaf_create_handle() >> >> 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. >> > > Overall I like the abstraction. Do you have a use case in mind right now for > the best allocation method? Some of the classic examples (mmu vs. no mmu) > are gradually becoming less relevant as the systems have evolved. I was > discussing constraints with Sumit w.r.t. Ion at plumbers so I'm curious > about > your uses. > > Thanks, > Laura > > -- Benjamin Gaignard Graphic Working Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

9 years, 9 months

[PATCH v4 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

version 4 changes: - rebased on kernel 4.3-rc3 - fix missing EXPORT_SYMBOL for smaf_create_handle() 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 | 736 +++++++++++++++++++++++++++++++++++++++++ include/linux/smaf-allocator.h | 54 +++ include/linux/smaf-secure.h | 72 ++++ include/uapi/linux/smaf.h | 52 +++ 9 files changed, 1130 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

9 years, 9 months

[PATCH weston v2 0/8] Generic Wayland dmabuf protocol

by Pekka Paalanen

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

9 years, 10 months

[PATCH v3 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

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

9 years, 11 months

Re: [Linaro-mm-sig] [PATCH v2 1/2] create SMAF module

by Benjamin Gaignard

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/>

9 years, 12 months

[PATCH v2 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

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

9 years, 12 months

[GIT PULL]: dma-buf changes for 4.2

by Sumit Semwal

Hi Linus, Very small pull request on dma-buf for 4.2 merge window. May I request you to please pull? The following changes since commit 5ebe6afaf0057ac3eaeb98defd5456894b446d22: Linux 4.1-rc2 (2015-05-03 19:22:23 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/dma-buf-for-4.2 for you to fetch changes up to 5136629dc5a19701746abd7c8ad98ce0b84dda1d: dma-buf: Minor coding style fixes (2015-05-21 11:29:59 +0530) ---------------------------------------------------------------- Minor changes for 4.2 - add ref-counting for kernel modules as exporters - minor code style fixes ---------------------------------------------------------------- Jagan Teki (1): dma-buf: Minor coding style fixes Sumit Semwal (1): dma-buf: add ref counting for module as exporter drivers/dma-buf/dma-buf.c | 19 ++++++++++++++++--- drivers/dma-buf/reservation.c | 9 ++++++--- drivers/dma-buf/seqno-fence.c | 8 +++++++- include/linux/dma-buf.h | 10 ++++++++-- 4 files changed, 37 insertions(+), 9 deletions(-) Thanks and best regards, Sumit.

10 years

[PATCH 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

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 | 198 ++++++++++++ drivers/smaf/smaf-core.c | 674 +++++++++++++++++++++++++++++++++++++++++ include/linux/smaf-allocator.h | 43 +++ include/linux/smaf-secure.h | 62 ++++ include/uapi/linux/smaf.h | 48 +++ 9 files changed, 1041 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

10 years

[RFCv3 1/2] device: add dma_params->max_segment_count

by Sumit Semwal

From: Rob Clark <robdclark(a)gmail.com> For devices which have constraints about maximum number of segments in an sglist. For example, a device which could only deal with contiguous buffers would set max_segment_count to 1. The initial motivation is for devices sharing buffers via dma-buf, to allow the buffer exporter to know the constraints of other devices which have attached to the buffer. The dma_mask and fields in 'struct device_dma_parameters' tell the exporter everything else that is needed, except whether the importer has constraints about maximum number of segments. Signed-off-by: Rob Clark <robdclark(a)gmail.com> [sumits: Minor updates wrt comments] Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org> --- v3: include Robin Murphy's fix[1] for handling '0' as a value for max_segment_count v2: minor updates wrt comments on the first version [1]: http://article.gmane.org/gmane.linux.kernel.iommu/8175/ include/linux/device.h | 1 + include/linux/dma-mapping.h | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+) diff --git a/include/linux/device.h b/include/linux/device.h index fb506738f7b7..a32f9b67315c 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -647,6 +647,7 @@ struct device_dma_parameters { * sg limitations. */ unsigned int max_segment_size; + unsigned int max_segment_count; /* INT_MAX for unlimited */ unsigned long segment_boundary_mask; }; diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index c3007cb4bfa6..d3351a36d5ec 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -154,6 +154,25 @@ static inline unsigned int dma_set_max_seg_size(struct device *dev, return -EIO; } +#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX) + +static inline unsigned int dma_get_max_seg_count(struct device *dev) +{ + if (dev->dma_parms && dev->dma_parms->max_segment_count) + return dev->dma_parms->max_segment_count; + return DMA_SEGMENTS_MAX_SEG_COUNT; +} + +static inline int dma_set_max_seg_count(struct device *dev, + unsigned int count) +{ + if (dev->dma_parms) { + dev->dma_parms->max_segment_count = count; + return 0; + } + return -EIO; +} + static inline unsigned long dma_get_seg_boundary(struct device *dev) { return dev->dma_parms ? -- 1.9.1

10 years

[PATCH v7 00/25] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem

by Marek Szyprowski

Hello Everyone, This is yet another attempt to get Exynos SYSMMU driver with integrated with IOMMU & DMA-mapping subsystems. This version includes minor fixes suggested by Joerg Roedel, Cho KyongHo and Robin Murphy. All patches are also available in the following git repository: https://git.linaro.org/people/marek.szyprowski/linux-srpol.git branch v4.1-exynos-iommu-v7. My plan for merging this patchset is as follows: - DTS changes and power domain changes should go via Samsung tree to avoid conflicts with other pending DTS patches - all exynos-iommu patches and dma-mapping/reserved iommu region should go via IOMMU tree, - all Exynos DRM patches should go via DRM/Exynos tree. There are no build cross-subsystem dependencies and IOMMU on Exynos is already nonfunctional (and disabled in defconfig), so merging patches in parts doesn't break anything. There are knowns issues with Exynos DRM driver and IOMMU support (i.e. Xorg freeze reported by Javier Martinez Canillas: http://www.spinics.net/lists/linux-samsung-soc/msg44350.html ). They will be handled by a separate fixes to Exynos DRM drivers. This patchset fixes only those issues in Exynos DRM FIMD driver, which prevents booting to console. Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v7: - rebased onto v4.1-rc4 - restored iommu_gruops support - added missing suspend/resume support patch - rearanged patch order and squashed some patches for better code readability - changed patch prefixes to match maintainer's requirements - fixed minor issues pointed by Joerg Roedel, Cho KyongHo and Robin Murphy - added Krzysztof's acks for dts patches v6: http://www.spinics.net/lists/linux-samsung-soc/msg44065.html - rebased onto v4.1-rc2 with 'arm: dma-mapping: fix off-by-one check in arm_setup_iommu_dma_ops' patch - added exynos 3250 and 4415 dts patches - added support for devices, which have been left enabled by bootloader (i.e. framebuffer displaying slash screen) - fixed freeze in fimd iommu initialization caused by lack of proper runtime pm management - resolved issues with power domains by moving pd initialization to core_initcall v5: https://lists.linaro.org/pipermail/linaro-mm-sig/2015-February/004442.html - rebased onto 'Add HDMI support for Exynos5420 platform' patchset - fixed 'const' issue in 'iommu: exynos: init from dt-specific callback instead of initcall' patch, thanks to Tobias Jakobi for reporting it - fixed copy-paste typo in exynos5250 dts patch v4: http://www.spinics.net/lists/linux-samsung-soc/msg41177.html - rebased onto v3.19-rc4 and other Exynos DTS queued patches - added DTS patch for Exynos 5250 & 5420/5422/5800 v3: http://www.spinics.net/lists/linux-samsung-soc/msg39168.html - rebased onto "[RFC PATCH v4 0/8] Introduce automatic DMA configuration for IOMMU masters" - added some minor fixes for iommu and dma-mapping frameworks v2: http://thread.gmane.org/gmane.linux.kernel.iommu/6472/ - rebased onto "[RFC PATCH v3 0/7] Introduce automatic DMA configuration for IOMMU masters" patches: http://www.spinics.net/lists/arm-kernel/msg362076.html - changed initialization from bus notifiers to DT related callbacks - removed support for separate IO address spaces - this will be discussed separately after the basic support gets merged - removed support for power domain notifier-based runtime power management - this also will be discussed separately later v1: https://lkml.org/lkml/2014/8/5/183 - initial version, feature complete, completely rewrote integration approach Patch summary: Marek Szyprowski (25): drm/exynos: iommu: detach from default dma-mapping domain on init drm/exynos: fimd: ensure proper hw state in fimd_clear_channel() iommu: Init iommu-groups support earlier, in core_initcall iommu/exynos: Don't read version register on every tlb operation iommu/exynos: Remove unused functions iommu/exynos: Remove useless members from exynos_iommu_owner structure iommu/exynos: Refactor function parameters to simplify code iommu/exynos: Rename variables to reflect their purpose iommu/exynos: Use struct exynos_iommu_domain in internal structures iommu/exynos: Remove excessive includes and sort others alphabetically iommu/exynos: Document internal structures iommu/exynos: Add/remove callbacks should fail if no iommu is available iommu/exynos: Add support for binding more than one sysmmu to master device iommu/exynos: Add support for runtime_pm iommu/exynos: Add system suspend/resume support iommu/exynos: Init from dt-specific callback instead of initcall iommu/exynos: Add callback for initializing devices from device tree ARM: Exynos: pm_domains: register power domain driver from core_initcall ARM: dts: exynos4: add sysmmu nodes ARM: dts: exynos3250: add sysmmu nodes ARM: dts: exynos4415: add sysmmu nodes ARM: dts: exynos5250: add sysmmu nodes ARM: dts: exynos5420: add sysmmu nodes ARM: DMA-mapping: add support for creating reserved mappings in iova space ARM: dts: exynos: add iommu reserved regions for bootloader's splash screen Documentation/devicetree/bindings/iommu/iommu.txt | 44 ++ arch/arm/boot/dts/exynos3250-rinato.dts | 1 + arch/arm/boot/dts/exynos3250.dtsi | 22 + arch/arm/boot/dts/exynos4.dtsi | 118 +++++ arch/arm/boot/dts/exynos4210-trats.dts | 1 + arch/arm/boot/dts/exynos4210-universal_c210.dts | 1 + arch/arm/boot/dts/exynos4210.dtsi | 23 + arch/arm/boot/dts/exynos4412-trats2.dts | 1 + arch/arm/boot/dts/exynos4415.dtsi | 11 + arch/arm/boot/dts/exynos4x12.dtsi | 82 ++++ arch/arm/boot/dts/exynos5250-snow.dts | 1 + arch/arm/boot/dts/exynos5250-spring.dts | 1 + arch/arm/boot/dts/exynos5250.dtsi | 250 ++++++++++ arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 + arch/arm/boot/dts/exynos5420.dtsi | 181 ++++++++ arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 + arch/arm/mach-exynos/pm_domains.c | 18 +- arch/arm/mm/dma-mapping.c | 121 +++++ drivers/gpu/drm/exynos/exynos_drm_fimd.c | 27 +- drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 + drivers/iommu/exynos-iommu.c | 526 +++++++++++----------- drivers/iommu/iommu.c | 2 +- 22 files changed, 1156 insertions(+), 280 deletions(-) -- 1.9.2

10 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig