Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

6 participants
3123 discussions

[PATCH 0/2] drm: add generic zpos property

by Benjamin Gaignard

The original patches have been done by Marek: https://lists.freedesktop.org/archives/dri-devel/2016-January/099572.html I have just adapt them to make zpos depend on plane and no more on drm core. Since zpos range can be define per plane normalize function takes care of the min and max before compute normalized zpos value. Benjamin Gaignard (2): drm: add generic zpos property drm: sti: use generic zpos for plane Documentation/DocBook/gpu.tmpl | 10 ++ drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic.c | 4 + drivers/gpu/drm/drm_atomic_helper.c | 6 + drivers/gpu/drm/drm_blend.c | 242 ++++++++++++++++++++++++++++++++++++ drivers/gpu/drm/drm_crtc_internal.h | 3 + drivers/gpu/drm/sti/sti_mixer.c | 2 +- drivers/gpu/drm/sti/sti_plane.c | 82 +++++------- drivers/gpu/drm/sti/sti_plane.h | 2 - include/drm/drm_crtc.h | 17 +++ 10 files changed, 314 insertions(+), 56 deletions(-) create mode 100644 drivers/gpu/drm/drm_blend.c -- 1.9.1

9 years, 7 months

[PATCH] dma-buf: Release module reference on creation failure

by Chris Wilson

If we fail to create the anon file, we need to remember to release the module reference on the owner. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-buf.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 4a2c07ee6677..6f0f0b10a241 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -333,6 +333,7 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) struct reservation_object *resv = exp_info->resv; struct file *file; size_t alloc_size = sizeof(struct dma_buf); + int ret; if (!exp_info->resv) alloc_size += sizeof(struct reservation_object); @@ -356,8 +357,8 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) dmabuf = kzalloc(alloc_size, GFP_KERNEL); if (!dmabuf) { - module_put(exp_info->owner); - return ERR_PTR(-ENOMEM); + ret = -ENOMEM; + goto free_module; } dmabuf->priv = exp_info->priv; @@ -378,8 +379,8 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, exp_info->flags); if (IS_ERR(file)) { - kfree(dmabuf); - return ERR_CAST(file); + ret = PTR_ERR(file); + goto free_dmabuf; } file->f_mode |= FMODE_LSEEK; @@ -393,6 +394,12 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) mutex_unlock(&db_list.lock); return dmabuf; + +free_dmabuf: + kfree(dmabuf); +free_module: + module_put(exp_info->owner); + return ERR_PTR(ret); } EXPORT_SYMBOL_GPL(dma_buf_export); -- 2.8.0.rc3

9 years, 7 months

Re: [Linaro-mm-sig] [PATCH] dma-buf: Update docs for SYNC ioctl

by David Herrmann

Hi On Mon, Mar 28, 2016 at 9:42 PM, Tiago Vignatti <tiago.vignatti(a)intel.com> wrote: > Do we have an agreement here after all? David? I need to know whether this > fixup is okay to go cause I'll need to submit to Chrome OS then. Sure it is fine. The code is already there, we cannot change it. Thanks David

9 years, 7 months

[PATCH] dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()

by Chris Wilson

Drivers, especially i915.ko, can fail during the initial migration of a dma-buf for CPU access. However, the error code from the driver was not being propagated back to ioctl and so userspace was blissfully ignorant of the failure. Rendering corruption ensues. Whilst fixing the ioctl to return the error code from dma_buf_start_cpu_access(), also do the same for dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access() cannot fail. i915.ko however, as most drivers would, wants to avoid being uninterruptible (as would be required to guarrantee no failure when flushing the buffer to the device). As userspace already has to handle errors from the SYNC_IOCTL, take advantage of this to be able to restart the syscall across signals. This fixes a coherency issue for i915.ko as well as reducing the uninterruptible hold upon its BKL, the struct_mutex. Fixes commit c11e391da2a8fe973c3c2398452000bed505851e Author: Daniel Vetter <daniel.vetter(a)ffwll.ch> Date: Thu Feb 11 20:04:51 2016 -0200 dma-buf: Add ioctls to allow userspace to flush Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible Testcase: igt/prime_mmap_coherency/ioctl-errors Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Tiago Vignatti <tiago.vignatti(a)intel.com> Cc: Stéphane Marchesin <marcheu(a)chromium.org> Cc: David Herrmann <dh.herrmann(a)gmail.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Daniel Vetter <daniel.vetter(a)intel.com> CC: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: intel-gfx(a)lists.freedesktop.org Cc: devel(a)driverdev.osuosl.org --- drivers/dma-buf/dma-buf.c | 17 +++++++++++------ drivers/gpu/drm/i915/i915_gem_dmabuf.c | 15 +++++---------- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 5 +++-- drivers/gpu/drm/udl/udl_fb.c | 4 ++-- drivers/staging/android/ion/ion.c | 6 ++++-- include/linux/dma-buf.h | 6 +++--- 6 files changed, 28 insertions(+), 25 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 9810d1df0691..774a60f4309a 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -259,6 +259,7 @@ static long dma_buf_ioctl(struct file *file, struct dma_buf *dmabuf; struct dma_buf_sync sync; enum dma_data_direction direction; + int ret; dmabuf = file->private_data; @@ -285,11 +286,11 @@ static long dma_buf_ioctl(struct file *file, } if (sync.flags & DMA_BUF_SYNC_END) - dma_buf_end_cpu_access(dmabuf, direction); + ret = dma_buf_end_cpu_access(dmabuf, direction); else - dma_buf_begin_cpu_access(dmabuf, direction); + ret = dma_buf_begin_cpu_access(dmabuf, direction); - return 0; + return ret; default: return -ENOTTY; } @@ -613,13 +614,17 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access); * * This call must always succeed. */ -void dma_buf_end_cpu_access(struct dma_buf *dmabuf, - enum dma_data_direction direction) +int dma_buf_end_cpu_access(struct dma_buf *dmabuf, + enum dma_data_direction direction) { + int ret = 0; + WARN_ON(!dmabuf); if (dmabuf->ops->end_cpu_access) - dmabuf->ops->end_cpu_access(dmabuf, direction); + ret = dmabuf->ops->end_cpu_access(dmabuf, direction); + + return ret; } EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access); diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/i915_gem_dmabuf.c index 1f3eef6fb345..0506016e18e0 100644 --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c @@ -228,25 +228,20 @@ static int i915_gem_begin_cpu_access(struct dma_buf *dma_buf, enum dma_data_dire return ret; } -static void i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum dma_data_direction direction) +static int i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum dma_data_direction direction) { struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf); struct drm_device *dev = obj->base.dev; - struct drm_i915_private *dev_priv = to_i915(dev); - bool was_interruptible; int ret; - mutex_lock(&dev->struct_mutex); - was_interruptible = dev_priv->mm.interruptible; - dev_priv->mm.interruptible = false; + ret = i915_mutex_lock_interruptible(dev); + if (ret) + return ret; ret = i915_gem_object_set_to_gtt_domain(obj, false); - - dev_priv->mm.interruptible = was_interruptible; mutex_unlock(&dev->struct_mutex); - if (unlikely(ret)) - DRM_ERROR("unable to flush buffer following CPU access; rendering may be corrupt\n"); + return ret; } static const struct dma_buf_ops i915_dmabuf_ops = { diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c index 3cf8aab23a39..af267c35d813 100644 --- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c +++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c @@ -97,11 +97,12 @@ static int omap_gem_dmabuf_begin_cpu_access(struct dma_buf *buffer, return omap_gem_get_pages(obj, &pages, true); } -static void omap_gem_dmabuf_end_cpu_access(struct dma_buf *buffer, - enum dma_data_direction dir) +static int omap_gem_dmabuf_end_cpu_access(struct dma_buf *buffer, + enum dma_data_direction dir) { struct drm_gem_object *obj = buffer->priv; omap_gem_put_pages(obj); + return 0; } diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c index c427499133d6..33239a2b264a 100644 --- a/drivers/gpu/drm/udl/udl_fb.c +++ b/drivers/gpu/drm/udl/udl_fb.c @@ -423,8 +423,8 @@ static int udl_user_framebuffer_dirty(struct drm_framebuffer *fb, } if (ufb->obj->base.import_attach) { - dma_buf_end_cpu_access(ufb->obj->base.import_attach->dmabuf, - DMA_FROM_DEVICE); + ret = dma_buf_end_cpu_access(ufb->obj->base.import_attach->dmabuf, + DMA_FROM_DEVICE); } unlock: diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 0754a37c9674..49436b4510f4 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -1075,14 +1075,16 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, return PTR_ERR_OR_ZERO(vaddr); } -static void ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf, - enum dma_data_direction direction) +static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf, + enum dma_data_direction direction) { struct ion_buffer *buffer = dmabuf->priv; mutex_lock(&buffer->lock); ion_buffer_kmap_put(buffer); mutex_unlock(&buffer->lock); + + return 0; } static struct dma_buf_ops dma_buf_ops = { diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 532108ea0c1c..3fe90d494edb 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -94,7 +94,7 @@ struct dma_buf_ops { void (*release)(struct dma_buf *); int (*begin_cpu_access)(struct dma_buf *, enum dma_data_direction); - void (*end_cpu_access)(struct dma_buf *, enum dma_data_direction); + int (*end_cpu_access)(struct dma_buf *, enum dma_data_direction); void *(*kmap_atomic)(struct dma_buf *, unsigned long); void (*kunmap_atomic)(struct dma_buf *, unsigned long, void *); void *(*kmap)(struct dma_buf *, unsigned long); @@ -224,8 +224,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *, enum dma_data_direction); int dma_buf_begin_cpu_access(struct dma_buf *dma_buf, enum dma_data_direction dir); -void dma_buf_end_cpu_access(struct dma_buf *dma_buf, - enum dma_data_direction dir); +int dma_buf_end_cpu_access(struct dma_buf *dma_buf, + enum dma_data_direction dir); void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long); void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *); void *dma_buf_kmap(struct dma_buf *, unsigned long); -- 2.8.0.rc3

9 years, 7 months

Re: [Linaro-mm-sig] [PATCH] fence: add missing descriptions for fence

by Javier Martinez Canillas

Hello Luis, On Sat, Mar 19, 2016 at 4:50 PM, Luis de Bethencourt <luisbg(a)osg.samsung.com> wrote: > Commit b55b54b5db33 ("staging/android: remove struct sync_pt") > added the members child_list and active_list to the fence struct, but > didn't add descriptions for these. Adding the descriptions. > Patches whose commit message mentions a specific commit that introduced and issue, usually also have a "Fixes:" tag before the S-o-B. For example this patch should have: Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt") > Signed-off-by: Luis de Bethencourt <luisbg(a)osg.samsung.com> > --- > Hi, > > Noticed this missing descriptions when running make htmldocs. > > Got the following warnings: > .//include/linux/fence.h:84: warning: No description found for parameter 'child_list' > .//include/linux/fence.h:84: warning: No description found for parameter 'active_list' > > Thanks :) > Luis > Patch looks good to me. Reviewed-by: Javier Martinez Canillas <javier(a)osg.samsung.com> Best regards, Javier

9 years, 7 months

[PATCH] dma-buf/fence: fix fence_is_later v2

by Alex Deucher

From: Christian König <christian.koenig(a)amd.com> A fence is never later than itself. This caused a bunch of overhead for AMDGPU. v2: simplify check as suggested by Michel. Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> --- include/linux/fence.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/fence.h b/include/linux/fence.h index bb52201..5aa95eb 100644 --- a/include/linux/fence.h +++ b/include/linux/fence.h @@ -292,7 +292,7 @@ static inline bool fence_is_later(struct fence *f1, struct fence *f2) if (WARN_ON(f1->context != f2->context)) return false; - return f1->seqno - f2->seqno < INT_MAX; + return (int)(f1->seqno - f2->seqno) > 0; } /** -- 2.5.0

9 years, 8 months

[PATCH 0/2] iommu: fix handling of attach/detach for default domains

by Marek Szyprowski

Hello, This patchset fixes attaching and detaching devices to a group, which has default domain configured. With both patches applied all calls to iommu's attach/detach functions will be balanced, whenever caller attaches device to the default domain or the custom one. Best regards Marek Szyprowski Samsung R&D Institute Poland Patch summary: Marek Szyprowski (2): iommu: call detach also for default_domain before attaching to new one iommu: fix default domain handling in __iommu_detach_group() drivers/iommu/iommu.c | 48 +++++++++++++++++++++++++++--------------------- 1 file changed, 27 insertions(+), 21 deletions(-) -- 1.9.2

9 years, 8 months

[PATCH] dma-buf/fence: fix fence_is_later v2

by Alex Deucher

9 years, 8 months

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

by Benjamin Gaignard

2015-10-21 16:34 GMT+02:00 James Morris <jmorris(a)namei.org>: > On Wed, 21 Oct 2015, Benjamin Gaignard wrote: > >> >> 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) >> > > Have you addressed all the questions raised by Alan here: > > https://lkml.org/lkml/2015/5/8/629 SMAF create /dev/smaf where all allocations could be done and is the owner of the dmabuf. Secure module is called to check permissions before that the CPU could access to the memory. I hope this cover what Alan expected but I can't speak form him. > > Also, is there any application of this beyond DRM? > If you don't use the secure part you can consider that SMAF is a central allocator with helpers to select the best allocator for your hardware devices. While SMAF doesn't rely on DRM concepts (crypto, CENC, keys etc...) we can use it outside this context but obviously it that been first designed for DRM uses cases. > > - James > -- > James Morris > <jmorris(a)namei.org> > -- Benjamin Gaignard Graphic Working Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

10 years

Re: [Linaro-mm-sig] [PATCH v5 1/3] create SMAF module

by Benjamin Gaignard

2015-10-21 16:32 GMT+02:00 James Morris <jmorris(a)namei.org>: > On Wed, 21 Oct 2015, Benjamin Gaignard wrote: > >> Secure Memory Allocation Framework goal is to be able >> to allocate memory that can be securing. >> There is so much ways to allocate and securing memory that SMAF >> doesn't do it by itself but need help of additional modules. >> To be sure to use the correct allocation method SMAF implement >> deferred allocation (i.e. allocate memory when only really needed) >> >> Allocation modules (smaf-alloctor.h): >> SMAF could manage with multiple allocation modules at same time. >> To select the good one SMAF call match() to be sure that a module >> can allocate memory for a given list of devices. It is to the module >> to check if the devices are compatible or not with it allocation >> method. >> >> Securing module (smaf-secure.h): >> The way of how securing memory it is done is platform specific. >> Secure module is responsible of grant/revoke memory access. >> > > This documentation is highly inadequate. If you give hints I will try to complete it and make it acceptable. > > What does "allocate memory that can be securing" mean? Maybe I could re-phrase it like that: "Secure Memory Allocation Framework goal is to be able to allocate memory that the platform can secure." I'm trying to be generic here because each could have it own method to secure buffers. > > > -- > James Morris > <jmorris(a)namei.org> > -- Benjamin Gaignard Graphic Working Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

10 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig