Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1575478 > unrolled thread

[PATCH v2 0/7] drm/rockchip: switch to drm_mm for support arm64 iommu

Started byMark Yao <mark.yao@rock-chips.com>
First post2017-02-07 09:40 +0100
Last post2017-02-09 00:40 +0100
Articles 10 — 5 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v2 0/7] drm/rockchip: switch to drm_mm for support arm64 iommu Mark Yao <mark.yao@rock-chips.com> - 2017-02-07 09:40 +0100
    [PATCH v2 6/7] drm/rockchip: Respect page offset in IOMMU mmap Mark Yao <mark.yao@rock-chips.com> - 2017-02-07 09:40 +0100
      Re: [PATCH v2 6/7] drm/rockchip: Respect page offset in IOMMU mmap Thierry Reding <thierry.reding@gmail.com> - 2017-02-07 13:40 +0100
    [PATCH v2 1/7] drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain Mark Yao <mark.yao@rock-chips.com> - 2017-02-07 09:40 +0100
    [PATCH v2 7/7] drm/rockchip: Call drm_gem_object_release() to destroy GEM base Mark Yao <mark.yao@rock-chips.com> - 2017-02-07 09:40 +0100
      Re: [PATCH v2 7/7] drm/rockchip: Call drm_gem_object_release() to  destroy GEM base Thierry Reding <thierry.reding@gmail.com> - 2017-02-07 13:40 +0100
        Re: [PATCH v2 7/7] drm/rockchip: Call drm_gem_object_release() to  destroy GEM base Tomasz Figa <tfiga@chromium.org> - 2017-02-07 14:10 +0100
    Re: [PATCH v2 0/7] drm/rockchip: switch to drm_mm for support arm64  iommu Thierry Reding <thierry.reding@gmail.com> - 2017-02-07 13:40 +0100
      Re: [PATCH v2 0/7] drm/rockchip: switch to drm_mm for support arm64  iommu Mark yao <mark.yao@rock-chips.com> - 2017-02-08 02:20 +0100
    Re: [PATCH v2 0/7] drm/rockchip: switch to drm_mm for support arm64 iommu Heiko Stübner <heiko@sntech.de> - 2017-02-09 00:40 +0100

#1575478 — [PATCH v2 0/7] drm/rockchip: switch to drm_mm for support arm64 iommu

FromMark Yao <mark.yao@rock-chips.com>
Date2017-02-07 09:40 +0100
Subject[PATCH v2 0/7] drm/rockchip: switch to drm_mm for support arm64 iommu
Message-ID<t89tD-rN-3@gated-at.bofh.it>
Some iommu patches on the series[0] "iommu/rockchip: Fix bugs and
enable on ARM64" already landed, So drm/rockchip related patches [1] and [2]
ready to landed, this series just rebase them to lastest drm-next.

And fix some bugs for drm/rockchip drm_mm

[0]: http://www.spinics.net/lists/arm-kernel/msg513781.html
[1]: https://patchwork.kernel.org/patch/9196367
[2]: https://patchwork.kernel.org/patch/9196369

Changes in v2:
Advices by Tomasz:
  add some fixes patches from chromeos project.

Mark Yao (2):
  drm/rockchip: gem: add mutex lock for drm mm
  drm/rockchip: gem: fixup iommu_map_sg error path

Shunqian Zheng (1):
  drm/rockchip: Use common IOMMU API to attach devices

Tomasz Figa (3):
  drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain
  drm/rockchip: Fix the call to drm_gem_put_pages()
  drm/rockchip: Call drm_gem_object_release() to destroy GEM base

Ørjan Eide (1):
  drm/rockchip: Respect page offset in IOMMU mmap

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 101 ++++++------
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   6 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 244 ++++++++++++++++++++++++++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   8 +
 4 files changed, 298 insertions(+), 61 deletions(-)

-- 
1.9.1

[toc] | [next] | [standalone]


#1575480 — [PATCH v2 6/7] drm/rockchip: Respect page offset in IOMMU mmap

FromMark Yao <mark.yao@rock-chips.com>
Date2017-02-07 09:40 +0100
Subject[PATCH v2 6/7] drm/rockchip: Respect page offset in IOMMU mmap
Message-ID<t89tE-rN-23@gated-at.bofh.it>
In reply to#1575478
From: Ørjan Eide <orjan.eide@arm.com>

When mapping buffers through the PRIME DMA-buf mmap path we might be
given an offset which has to be respected. The DRM GEM mmap path already
takes care of zeroing out the fake mmap offset, so we can just make the
IOMMU mmap implementation always respect the offset.

TEST=graphics_GLBench

Signed-off-by: rjan Eide <orjan.eide@arm.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/386477
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 1daa531..1769146 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -221,12 +221,16 @@ static int rockchip_drm_gem_object_mmap_iommu(struct drm_gem_object *obj,
 	unsigned int i, count = obj->size >> PAGE_SHIFT;
 	unsigned long user_count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
 	unsigned long uaddr = vma->vm_start;
+	unsigned long offset = vma->vm_pgoff;
+	unsigned long end = user_count + offset;
 	int ret;
 
-	if (user_count == 0 || user_count > count)
+	if (user_count == 0)
+		return -ENXIO;
+	if (end > count)
 		return -ENXIO;
 
-	for (i = 0; i < user_count; i++) {
+	for (i = offset; i < end; i++) {
 		ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
 		if (ret)
 			return ret;
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]


#1575623 — Re: [PATCH v2 6/7] drm/rockchip: Respect page offset in IOMMU mmap

FromThierry Reding <thierry.reding@gmail.com>
Date2017-02-07 13:40 +0100
SubjectRe: [PATCH v2 6/7] drm/rockchip: Respect page offset in IOMMU mmap
Message-ID<t8ddU-2Qi-27@gated-at.bofh.it>
In reply to#1575480

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 07, 2017 at 04:39:09PM +0800, Mark Yao wrote:
> From: Ørjan Eide <orjan.eide@arm.com>
> 
> When mapping buffers through the PRIME DMA-buf mmap path we might be
> given an offset which has to be respected. The DRM GEM mmap path already
> takes care of zeroing out the fake mmap offset, so we can just make the
> IOMMU mmap implementation always respect the offset.
> 
> TEST=graphics_GLBench

This is useless in an upstream context, please remove.

Thierry

[toc] | [prev] | [next] | [standalone]


#1575481 — [PATCH v2 1/7] drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

FromMark Yao <mark.yao@rock-chips.com>
Date2017-02-07 09:40 +0100
Subject[PATCH v2 1/7] drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain
Message-ID<t89tE-rN-29@gated-at.bofh.it>
In reply to#1575478
From: Tomasz Figa <tfiga@chromium.org>

The API is not suitable for subsystems consisting of multiple devices
and requires severe hacks to use it. To mitigate this, this patch
implements allocation and address space management locally by using
helpers provided by DRM framework, like other DRM drivers do, e.g.
Tegra.

This patch should not introduce any functional changes until the driver
is made to attach subdevices into an IOMMU domain with the generic IOMMU
API, which will happen in following patch. Based heavily on GEM
implementation of Tegra DRM driver.

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Acked-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   4 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 217 ++++++++++++++++++++++++++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   8 +
 3 files changed, 219 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index fb6226c..7c123d9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -30,6 +30,7 @@
 
 struct drm_device;
 struct drm_connector;
+struct iommu_domain;
 
 /*
  * Rockchip drm private crtc funcs.
@@ -60,7 +61,8 @@ struct rockchip_drm_private {
 	struct drm_gem_object *fbdev_bo;
 	const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
 	struct drm_atomic_state *state;
-
+	struct iommu_domain *domain;
+	struct drm_mm mm;
 	struct list_head psr_list;
 	spinlock_t psr_list_lock;
 };
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index b70f942..5209392 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -16,11 +16,135 @@
 #include <drm/drmP.h>
 #include <drm/drm_gem.h>
 #include <drm/drm_vma_manager.h>
+#include <linux/iommu.h>
 
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_gem.h"
 
-static int rockchip_gem_alloc_buf(struct rockchip_gem_object *rk_obj,
+static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj)
+{
+	struct drm_device *drm = rk_obj->base.dev;
+	struct rockchip_drm_private *private = drm->dev_private;
+	int prot = IOMMU_READ | IOMMU_WRITE;
+	ssize_t ret;
+
+	ret = drm_mm_insert_node_generic(&private->mm, &rk_obj->mm,
+					 rk_obj->base.size, PAGE_SIZE,
+					 0, 0);
+	if (ret < 0) {
+		DRM_ERROR("out of I/O virtual memory: %zd\n", ret);
+		return ret;
+	}
+
+	rk_obj->dma_addr = rk_obj->mm.start;
+
+	ret = iommu_map_sg(private->domain, rk_obj->dma_addr, rk_obj->sgt->sgl,
+			   rk_obj->sgt->nents, prot);
+	if (ret < 0) {
+		DRM_ERROR("failed to map buffer: %zd\n", ret);
+		goto err_remove_node;
+	}
+
+	rk_obj->size = ret;
+
+	return 0;
+
+err_remove_node:
+	drm_mm_remove_node(&rk_obj->mm);
+
+	return ret;
+}
+
+static int rockchip_gem_iommu_unmap(struct rockchip_gem_object *rk_obj)
+{
+	struct drm_device *drm = rk_obj->base.dev;
+	struct rockchip_drm_private *private = drm->dev_private;
+
+	iommu_unmap(private->domain, rk_obj->dma_addr, rk_obj->size);
+	drm_mm_remove_node(&rk_obj->mm);
+
+	return 0;
+}
+
+static int rockchip_gem_get_pages(struct rockchip_gem_object *rk_obj)
+{
+	struct drm_device *drm = rk_obj->base.dev;
+	int ret, i;
+	struct scatterlist *s;
+
+	rk_obj->pages = drm_gem_get_pages(&rk_obj->base);
+	if (IS_ERR(rk_obj->pages))
+		return PTR_ERR(rk_obj->pages);
+
+	rk_obj->num_pages = rk_obj->base.size >> PAGE_SHIFT;
+
+	rk_obj->sgt = drm_prime_pages_to_sg(rk_obj->pages, rk_obj->num_pages);
+	if (IS_ERR(rk_obj->sgt)) {
+		ret = PTR_ERR(rk_obj->sgt);
+		goto err_put_pages;
+	}
+
+	/*
+	 * Fake up the SG table so that dma_sync_sg_for_device() can be used
+	 * to flush the pages associated with it.
+	 *
+	 * TODO: Replace this by drm_clflush_sg() once it can be implemented
+	 * without relying on symbols that are not exported.
+	 */
+	for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i)
+		sg_dma_address(s) = sg_phys(s);
+
+	dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl, rk_obj->sgt->nents,
+			       DMA_TO_DEVICE);
+
+	return 0;
+
+err_put_pages:
+	drm_gem_put_pages(&rk_obj->base, rk_obj->pages, false, false);
+	return ret;
+}
+
+static void rockchip_gem_put_pages(struct rockchip_gem_object *rk_obj)
+{
+	sg_free_table(rk_obj->sgt);
+	kfree(rk_obj->sgt);
+	drm_gem_put_pages(&rk_obj->base, rk_obj->pages, false, false);
+}
+
+static int rockchip_gem_alloc_iommu(struct rockchip_gem_object *rk_obj,
+				    bool alloc_kmap)
+{
+	int ret;
+
+	ret = rockchip_gem_get_pages(rk_obj);
+	if (ret < 0)
+		return ret;
+
+	ret = rockchip_gem_iommu_map(rk_obj);
+	if (ret < 0)
+		goto err_free;
+
+	if (alloc_kmap) {
+		rk_obj->kvaddr = vmap(rk_obj->pages, rk_obj->num_pages, VM_MAP,
+				      pgprot_writecombine(PAGE_KERNEL));
+		if (!rk_obj->kvaddr) {
+			DRM_ERROR("failed to vmap() buffer\n");
+			ret = -ENOMEM;
+			goto err_unmap;
+		}
+	}
+
+	return 0;
+
+err_unmap:
+	rockchip_gem_iommu_unmap(rk_obj);
+err_free:
+	rockchip_gem_put_pages(rk_obj);
+
+	return ret;
+}
+
+static int rockchip_gem_alloc_dma(struct rockchip_gem_object *rk_obj,
 				  bool alloc_kmap)
 {
 	struct drm_gem_object *obj = &rk_obj->base;
@@ -42,7 +166,27 @@ static int rockchip_gem_alloc_buf(struct rockchip_gem_object *rk_obj,
 	return 0;
 }
 
-static void rockchip_gem_free_buf(struct rockchip_gem_object *rk_obj)
+static int rockchip_gem_alloc_buf(struct rockchip_gem_object *rk_obj,
+				  bool alloc_kmap)
+{
+	struct drm_gem_object *obj = &rk_obj->base;
+	struct drm_device *drm = obj->dev;
+	struct rockchip_drm_private *private = drm->dev_private;
+
+	if (private->domain)
+		return rockchip_gem_alloc_iommu(rk_obj, alloc_kmap);
+	else
+		return rockchip_gem_alloc_dma(rk_obj, alloc_kmap);
+}
+
+static void rockchip_gem_free_iommu(struct rockchip_gem_object *rk_obj)
+{
+	vunmap(rk_obj->kvaddr);
+	rockchip_gem_iommu_unmap(rk_obj);
+	rockchip_gem_put_pages(rk_obj);
+}
+
+static void rockchip_gem_free_dma(struct rockchip_gem_object *rk_obj)
 {
 	struct drm_gem_object *obj = &rk_obj->base;
 	struct drm_device *drm = obj->dev;
@@ -51,23 +195,64 @@ static void rockchip_gem_free_buf(struct rockchip_gem_object *rk_obj)
 		       rk_obj->dma_attrs);
 }
 
-static int rockchip_drm_gem_object_mmap(struct drm_gem_object *obj,
-					struct vm_area_struct *vma)
+static void rockchip_gem_free_buf(struct rockchip_gem_object *rk_obj)
+{
+	if (rk_obj->pages)
+		rockchip_gem_free_iommu(rk_obj);
+	else
+		rockchip_gem_free_dma(rk_obj);
+}
 
+static int rockchip_drm_gem_object_mmap_iommu(struct drm_gem_object *obj,
+					      struct vm_area_struct *vma)
 {
+	struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
+	unsigned int i, count = obj->size >> PAGE_SHIFT;
+	unsigned long user_count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+	unsigned long uaddr = vma->vm_start;
 	int ret;
+
+	if (user_count == 0 || user_count > count)
+		return -ENXIO;
+
+	for (i = 0; i < user_count; i++) {
+		ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
+		if (ret)
+			return ret;
+		uaddr += PAGE_SIZE;
+	}
+
+	return 0;
+}
+
+static int rockchip_drm_gem_object_mmap_dma(struct drm_gem_object *obj,
+					    struct vm_area_struct *vma)
+{
 	struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
 	struct drm_device *drm = obj->dev;
 
+	return dma_mmap_attrs(drm->dev, vma, rk_obj->kvaddr, rk_obj->dma_addr,
+			      obj->size, rk_obj->dma_attrs);
+}
+
+static int rockchip_drm_gem_object_mmap(struct drm_gem_object *obj,
+					struct vm_area_struct *vma)
+{
+	int ret;
+	struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
+
 	/*
-	 * dma_alloc_attrs() allocated a struct page table for rk_obj, so clear
+	 * We allocated a struct page table for rk_obj, so clear
 	 * VM_PFNMAP flag that was set by drm_gem_mmap_obj()/drm_gem_mmap().
 	 */
 	vma->vm_flags &= ~VM_PFNMAP;
 	vma->vm_pgoff = 0;
 
-	ret = dma_mmap_attrs(drm->dev, vma, rk_obj->kvaddr, rk_obj->dma_addr,
-			     obj->size, rk_obj->dma_attrs);
+	if (rk_obj->pages)
+		ret = rockchip_drm_gem_object_mmap_iommu(obj, vma);
+	else
+		ret = rockchip_drm_gem_object_mmap_dma(obj, vma);
+
 	if (ret)
 		drm_gem_vm_close(vma);
 
@@ -117,7 +302,7 @@ struct rockchip_gem_object *
 
 	obj = &rk_obj->base;
 
-	drm_gem_private_object_init(drm, obj, size);
+	drm_gem_object_init(drm, obj, size);
 
 	ret = rockchip_gem_alloc_buf(rk_obj, alloc_kmap);
 	if (ret)
@@ -253,6 +438,9 @@ struct sg_table *rockchip_gem_prime_get_sg_table(struct drm_gem_object *obj)
 	struct sg_table *sgt;
 	int ret;
 
+	if (rk_obj->pages)
+		return drm_prime_pages_to_sg(rk_obj->pages, rk_obj->num_pages);
+
 	sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
 	if (!sgt)
 		return ERR_PTR(-ENOMEM);
@@ -273,6 +461,10 @@ void *rockchip_gem_prime_vmap(struct drm_gem_object *obj)
 {
 	struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
 
+	if (rk_obj->pages)
+		return vmap(rk_obj->pages, rk_obj->num_pages, VM_MAP,
+			    pgprot_writecombine(PAGE_KERNEL));
+
 	if (rk_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING)
 		return NULL;
 
@@ -281,5 +473,12 @@ void *rockchip_gem_prime_vmap(struct drm_gem_object *obj)
 
 void rockchip_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
 {
-	/* Nothing to do */
+	struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
+
+	if (rk_obj->pages) {
+		vunmap(vaddr);
+		return;
+	}
+
+	/* Nothing to do if allocated by DMA mapping API. */
 }
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
index 18b3488..3f6ea4d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
@@ -23,7 +23,15 @@ struct rockchip_gem_object {
 
 	void *kvaddr;
 	dma_addr_t dma_addr;
+	/* Used when IOMMU is disabled */
 	unsigned long dma_attrs;
+
+	/* Used when IOMMU is enabled */
+	struct drm_mm_node mm;
+	unsigned long num_pages;
+	struct page **pages;
+	struct sg_table *sgt;
+	size_t size;
 };
 
 struct sg_table *rockchip_gem_prime_get_sg_table(struct drm_gem_object *obj);
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]


#1575482 — [PATCH v2 7/7] drm/rockchip: Call drm_gem_object_release() to destroy GEM base

FromMark Yao <mark.yao@rock-chips.com>
Date2017-02-07 09:40 +0100
Subject[PATCH v2 7/7] drm/rockchip: Call drm_gem_object_release() to destroy GEM base
Message-ID<t89tE-rN-31@gated-at.bofh.it>
In reply to#1575478
From: Tomasz Figa <tfiga@chromium.org>

When converting the driver to use shmem-backed GEMs for IOMMU-enabled
systems, we forgot to add calls to drm_gem_object_release(), which gave
us a quite nice memory leak. This patch adds the missing calls.

Fixes: f11d5f0 ("FROMLIST: drm/rockchip: Do not use DMA mapping API if
attached to IOMMU domain")

TEST=while true; do backlight_dbus_tool --set --percent=0 && sleep 8 &&
 backlight_dbus_tool --set --percent=100 && sleep 3 ; done

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/385456
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 1769146..df9e570 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -301,6 +301,12 @@ int rockchip_gem_mmap(struct file *filp, struct vm_area_struct *vma)
 	return rockchip_drm_gem_object_mmap(obj, vma);
 }
 
+static void rockchip_gem_release_object(struct rockchip_gem_object *rk_obj)
+{
+	drm_gem_object_release(&rk_obj->base);
+	kfree(rk_obj);
+}
+
 struct rockchip_gem_object *
 	rockchip_gem_create_object(struct drm_device *drm, unsigned int size,
 				   bool alloc_kmap)
@@ -326,7 +332,7 @@ struct rockchip_gem_object *
 	return rk_obj;
 
 err_free_rk_obj:
-	kfree(rk_obj);
+	rockchip_gem_release_object(rk_obj);
 	return ERR_PTR(ret);
 }
 
@@ -338,13 +344,11 @@ void rockchip_gem_free_object(struct drm_gem_object *obj)
 {
 	struct rockchip_gem_object *rk_obj;
 
-	drm_gem_free_mmap_offset(obj);
-
 	rk_obj = to_rockchip_obj(obj);
 
 	rockchip_gem_free_buf(rk_obj);
 
-	kfree(rk_obj);
+	rockchip_gem_release_object(rk_obj);
 }
 
 /*
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]


#1575622 — Re: [PATCH v2 7/7] drm/rockchip: Call drm_gem_object_release() to destroy GEM base

FromThierry Reding <thierry.reding@gmail.com>
Date2017-02-07 13:40 +0100
SubjectRe: [PATCH v2 7/7] drm/rockchip: Call drm_gem_object_release() to destroy GEM base
Message-ID<t8ddT-2Qi-11@gated-at.bofh.it>
In reply to#1575482

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 07, 2017 at 04:39:33PM +0800, Mark Yao wrote:
> From: Tomasz Figa <tfiga@chromium.org>
> 
> When converting the driver to use shmem-backed GEMs for IOMMU-enabled
> systems, we forgot to add calls to drm_gem_object_release(), which gave
> us a quite nice memory leak. This patch adds the missing calls.
> 
> Fixes: f11d5f0 ("FROMLIST: drm/rockchip: Do not use DMA mapping API if
> attached to IOMMU domain")
> 
> TEST=while true; do backlight_dbus_tool --set --percent=0 && sleep 8 &&
>  backlight_dbus_tool --set --percent=100 && sleep 3 ; done

Ugh... please clean up your commit messages before posting to the
mailing list. FROMLIST: patches clearly aren't what will be merged
upstream and the SHA1 isn't going to match, so nobody but you will
find this anywhere.

> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
> Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
> Reviewed-on: https://chromium-review.googlesource.com/385456

This is also present in some of the patches you posted, but it's not
typical for these to be included in upstream patches because usually
by the time patches from some gerrit make it to upstream, upstream
can have diverged significantly enough for the review to no longer
apply.

Thierry

[toc] | [prev] | [next] | [standalone]


#1575709 — Re: [PATCH v2 7/7] drm/rockchip: Call drm_gem_object_release() to destroy GEM base

FromTomasz Figa <tfiga@chromium.org>
Date2017-02-07 14:10 +0100
SubjectRe: [PATCH v2 7/7] drm/rockchip: Call drm_gem_object_release() to destroy GEM base
Message-ID<t8dGZ-3hn-111@gated-at.bofh.it>
In reply to#1575622
Hi Mark,

On Tue, Feb 7, 2017 at 9:37 PM, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Feb 07, 2017 at 04:39:33PM +0800, Mark Yao wrote:
>> From: Tomasz Figa <tfiga@chromium.org>
>>
>> When converting the driver to use shmem-backed GEMs for IOMMU-enabled
>> systems, we forgot to add calls to drm_gem_object_release(), which gave
>> us a quite nice memory leak. This patch adds the missing calls.
>>
>> Fixes: f11d5f0 ("FROMLIST: drm/rockchip: Do not use DMA mapping API if
>> attached to IOMMU domain")

Since the patch being fixed is also a part of this series, the fix
could be just squashed directly (with sign-off lists merged). Same for
patch 6/7.

Best regards,
Tomasz

[toc] | [prev] | [next] | [standalone]


#1575626 — Re: [PATCH v2 0/7] drm/rockchip: switch to drm_mm for support arm64 iommu

FromThierry Reding <thierry.reding@gmail.com>
Date2017-02-07 13:40 +0100
SubjectRe: [PATCH v2 0/7] drm/rockchip: switch to drm_mm for support arm64 iommu
Message-ID<t8ddV-2Qi-41@gated-at.bofh.it>
In reply to#1575478

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 07, 2017 at 04:35:35PM +0800, Mark Yao wrote:
> Some iommu patches on the series[0] "iommu/rockchip: Fix bugs and
> enable on ARM64" already landed, So drm/rockchip related patches [1] and [2]
> ready to landed, this series just rebase them to lastest drm-next.
> 
> And fix some bugs for drm/rockchip drm_mm
> 
> [0]: http://www.spinics.net/lists/arm-kernel/msg513781.html
> [1]: https://patchwork.kernel.org/patch/9196367
> [2]: https://patchwork.kernel.org/patch/9196369
> 
> Changes in v2:
> Advices by Tomasz:
>   add some fixes patches from chromeos project.

I think those fixes should've been squashed into the patches that they
fix. It's very unusual to merge patches upstream that are know to have
been fixed already.

Thierry

[toc] | [prev] | [next] | [standalone]


#1576209 — Re: [PATCH v2 0/7] drm/rockchip: switch to drm_mm for support arm64 iommu

FromMark yao <mark.yao@rock-chips.com>
Date2017-02-08 02:20 +0100
SubjectRe: [PATCH v2 0/7] drm/rockchip: switch to drm_mm for support arm64 iommu
Message-ID<t8p5o-1Ze-13@gated-at.bofh.it>
In reply to#1575626
On 2017年02月07日 20:38, Thierry Reding wrote:
> On Tue, Feb 07, 2017 at 04:35:35PM +0800, Mark Yao wrote:
>> Some iommu patches on the series[0] "iommu/rockchip: Fix bugs and
>> enable on ARM64" already landed, So drm/rockchip related patches [1] and [2]
>> ready to landed, this series just rebase them to lastest drm-next.
>>
>> And fix some bugs for drm/rockchip drm_mm
>>
>> [0]: http://www.spinics.net/lists/arm-kernel/msg513781.html
>> [1]: https://patchwork.kernel.org/patch/9196367
>> [2]: https://patchwork.kernel.org/patch/9196369
>>
>> Changes in v2:
>> Advices by Tomasz:
>>    add some fixes patches from chromeos project.
> I think those fixes should've been squashed into the patches that they
> fix. It's very unusual to merge patches upstream that are know to have
> been fixed already.
>
> Thierry
Got it, I will fix them at v3 version.

Thanks for review.

-- 
Mark Yao

[toc] | [prev] | [next] | [standalone]


#1577194

FromHeiko Stübner <heiko@sntech.de>
Date2017-02-09 00:40 +0100
Message-ID<t8K0a-6KO-11@gated-at.bofh.it>
In reply to#1575478
Am Dienstag, 7. Februar 2017, 16:35:35 CET schrieb Mark Yao:
> Some iommu patches on the series[0] "iommu/rockchip: Fix bugs and
> enable on ARM64" already landed, So drm/rockchip related patches [1] and [2]
> ready to landed, this series just rebase them to lastest drm-next.
> 
> And fix some bugs for drm/rockchip drm_mm
> 
> [0]: http://www.spinics.net/lists/arm-kernel/msg513781.html
> [1]: https://patchwork.kernel.org/patch/9196367
> [2]: https://patchwork.kernel.org/patch/9196369

I've managed to get some output on my rk3399-gru with this series ;-)
and rk3288 also kept on working, so

On rk3288 and rk3399
Tested-by: Heiko Stuebner <heiko@sntech.de>

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web