[PATCH 00/15] Retire dma_buf_k(un)map

[PATCH 00/15] Retire dma_buf_k(un)map

[Daniel Vetter]

Hi all,

Way back when we created the dma-buf spec it made sense to have kmap/unmap
interfaces, since 32bit kernels with limited vmalloc space were still
rather ubiquitous. But that idea (like many others) never caught on, was
quickly replaced by vmaps covering the entire buffer for all real uses,
and nowadays 64bit kernels rule the world. Currently merged upstream
drivers (and we have a pile now) don't even bother to kmap for their
private buffers, much less for anything shared.

So since it was never used, and this idea's time is clearly over, let's
remove it all.

Only real change I had to do (aside from deleting lots of dead code) was
in the tegra driver. But even there I suspect the dma-buf kmap path has
never been run in anger anywhere, it just doesn't make sense to put relocs
into a dma-buf (as opposed to using a dma-buf for the target address of a
reloc).

Comments, reviews and testing very much appreciated.

Cheers, Daniel

Daniel Vetter (15):
  drm/tegra: Map cmdbuf once for reloc processing
  drm/tegra: Delete host1x_bo_ops->k(un)map
  drm/i915: Remove dma_buf_kmap selftest
  staging/android/ion: delete dma_buf->kmap/unmap implemenation
  drm/armada: Delete dma_buf->k(un)map implemenation
  drm/i915: Drop dma_buf->k(un)map
  drm/omapdrm: Drop dma_buf->k(un)map
  drm/tegra: Remove dma_buf->k(un)map
  dma-buf: Drop dma_buf_k(un)map
  drm/vmwgfx: Delete mmaping functions
  media/videobuf2: Drop dma_buf->k(un)map support
  drm/tee_shm: Drop dma_buf_k(unmap) support
  xen/gntdev-dmabuf: Ditch dummy map functions
  sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support
  dma-buf: Remove kernel map/unmap hooks

 drivers/dma-buf/dma-buf.c                     |  63 +----------
 drivers/gpu/drm/armada/armada_gem.c           |  12 ---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c    |  36 -------
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 101 ------------------
 .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  |  16 ---
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c     |  21 ----
 drivers/gpu/drm/tegra/gem.c                   |  40 -------
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c         |  33 ------
 drivers/gpu/host1x/job.c                      |  21 ++--
 .../common/videobuf2/videobuf2-dma-contig.c   |   8 --
 .../media/common/videobuf2/videobuf2-dma-sg.c |   8 --
 .../common/videobuf2/videobuf2-vmalloc.c      |   8 --
 drivers/misc/fastrpc.c                        |   8 --
 drivers/staging/android/ion/ion.c             |  14 ---
 drivers/tee/tee_shm.c                         |   6 --
 drivers/xen/gntdev-dmabuf.c                   |  23 ----
 include/linux/dma-buf.h                       |  27 -----
 include/linux/host1x.h                        |  13 ---
 samples/vfio-mdev/mbochs.c                    |  16 ---
 19 files changed, 10 insertions(+), 464 deletions(-)

-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH 00/15] Retire dma_buf_k(un)map

[Daniel Vetter]

Hi all,

Way back when we created the dma-buf spec it made sense to have kmap/unmap
interfaces, since 32bit kernels with limited vmalloc space were still
rather ubiquitous. But that idea (like many others) never caught on, was
quickly replaced by vmaps covering the entire buffer for all real uses,
and nowadays 64bit kernels rule the world. Currently merged upstream
drivers (and we have a pile now) don't even bother to kmap for their
private buffers, much less for anything shared.

So since it was never used, and this idea's time is clearly over, let's
remove it all.

Only real change I had to do (aside from deleting lots of dead code) was
in the tegra driver. But even there I suspect the dma-buf kmap path has
never been run in anger anywhere, it just doesn't make sense to put relocs
into a dma-buf (as opposed to using a dma-buf for the target address of a
reloc).

Comments, reviews and testing very much appreciated.

Cheers, Daniel

Daniel Vetter (15):
  drm/tegra: Map cmdbuf once for reloc processing
  drm/tegra: Delete host1x_bo_ops->k(un)map
  drm/i915: Remove dma_buf_kmap selftest
  staging/android/ion: delete dma_buf->kmap/unmap implemenation
  drm/armada: Delete dma_buf->k(un)map implemenation
  drm/i915: Drop dma_buf->k(un)map
  drm/omapdrm: Drop dma_buf->k(un)map
  drm/tegra: Remove dma_buf->k(un)map
  dma-buf: Drop dma_buf_k(un)map
  drm/vmwgfx: Delete mmaping functions
  media/videobuf2: Drop dma_buf->k(un)map support
  drm/tee_shm: Drop dma_buf_k(unmap) support
  xen/gntdev-dmabuf: Ditch dummy map functions
  sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support
  dma-buf: Remove kernel map/unmap hooks

 drivers/dma-buf/dma-buf.c                     |  63 +----------
 drivers/gpu/drm/armada/armada_gem.c           |  12 ---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c    |  36 -------
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 101 ------------------
 .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  |  16 ---
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c     |  21 ----
 drivers/gpu/drm/tegra/gem.c                   |  40 -------
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c         |  33 ------
 drivers/gpu/host1x/job.c                      |  21 ++--
 .../common/videobuf2/videobuf2-dma-contig.c   |   8 --
 .../media/common/videobuf2/videobuf2-dma-sg.c |   8 --
 .../common/videobuf2/videobuf2-vmalloc.c      |   8 --
 drivers/misc/fastrpc.c                        |   8 --
 drivers/staging/android/ion/ion.c             |  14 ---
 drivers/tee/tee_shm.c                         |   6 --
 drivers/xen/gntdev-dmabuf.c                   |  23 ----
 include/linux/dma-buf.h                       |  27 -----
 include/linux/host1x.h                        |  13 ---
 samples/vfio-mdev/mbochs.c                    |  16 ---
 19 files changed, 10 insertions(+), 464 deletions(-)

-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

[Daniel Vetter]

A few reasons to drop kmap:

- For native objects all we do is look at obj->vaddr anyway, so might
  as well not call functions for every page.

- Reloc-processing on dma-buf is ... questionable.

- Plus most dma-buf that bother kernel cpu mmaps give you at least
  vmap, much less kmaps. And all the ones relevant for arm-soc are
  again doing a obj->vaddr game anyway, there's no real kmap going on
  on arm it seems.

Plus this seems to be the only real in-tree user of dma_buf_kmap, and
I'd like to get rid of that.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org
---
 drivers/gpu/host1x/job.c | 21 +++++++--------------
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 25ca54de8fc5..60b2fedd0061 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
 
 static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
 {
-	u32 last_page = ~0;
-	void *cmdbuf_page_addr = NULL;
+	void *cmdbuf_addr = NULL;
 	struct host1x_bo *cmdbuf = g->bo;
 	unsigned int i;
 
@@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
 			goto patch_reloc;
 		}
 
-		if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
-			if (cmdbuf_page_addr)
-				host1x_bo_kunmap(cmdbuf, last_page,
-						 cmdbuf_page_addr);
+		if (!cmdbuf_addr) {
+			cmdbuf_addr = host1x_bo_mmap(cmdbuf);
 
-			cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
-					reloc->cmdbuf.offset >> PAGE_SHIFT);
-			last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
-
-			if (unlikely(!cmdbuf_page_addr)) {
+			if (unlikely(!cmdbuf_addr)) {
 				pr_err("Could not map cmdbuf for relocation\n");
 				return -ENOMEM;
 			}
 		}
 
-		target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
+		target = cmdbuf_addr + reloc->cmdbuf.offset;
 patch_reloc:
 		*target = reloc_addr;
 	}
 
-	if (cmdbuf_page_addr)
-		host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
+	if (cmdbuf_addr)
+		host1x_bo_munmap(cmdbuf, cmdbuf_addr);
 
 	return 0;
 }
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

[Daniel Vetter]

A few reasons to drop kmap:

- For native objects all we do is look at obj->vaddr anyway, so might
  as well not call functions for every page.

- Reloc-processing on dma-buf is ... questionable.

- Plus most dma-buf that bother kernel cpu mmaps give you at least
  vmap, much less kmaps. And all the ones relevant for arm-soc are
  again doing a obj->vaddr game anyway, there's no real kmap going on
  on arm it seems.

Plus this seems to be the only real in-tree user of dma_buf_kmap, and
I'd like to get rid of that.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org
---
 drivers/gpu/host1x/job.c | 21 +++++++--------------
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 25ca54de8fc5..60b2fedd0061 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
 
 static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
 {
-	u32 last_page = ~0;
-	void *cmdbuf_page_addr = NULL;
+	void *cmdbuf_addr = NULL;
 	struct host1x_bo *cmdbuf = g->bo;
 	unsigned int i;
 
@@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
 			goto patch_reloc;
 		}
 
-		if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
-			if (cmdbuf_page_addr)
-				host1x_bo_kunmap(cmdbuf, last_page,
-						 cmdbuf_page_addr);
+		if (!cmdbuf_addr) {
+			cmdbuf_addr = host1x_bo_mmap(cmdbuf);
 
-			cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
-					reloc->cmdbuf.offset >> PAGE_SHIFT);
-			last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
-
-			if (unlikely(!cmdbuf_page_addr)) {
+			if (unlikely(!cmdbuf_addr)) {
 				pr_err("Could not map cmdbuf for relocation\n");
 				return -ENOMEM;
 			}
 		}
 
-		target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
+		target = cmdbuf_addr + reloc->cmdbuf.offset;
 patch_reloc:
 		*target = reloc_addr;
 	}
 
-	if (cmdbuf_page_addr)
-		host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
+	if (cmdbuf_addr)
+		host1x_bo_munmap(cmdbuf, cmdbuf_addr);
 
 	return 0;
 }
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

[Daniel Vetter]

A few reasons to drop kmap:

- For native objects all we do is look at obj->vaddr anyway, so might
  as well not call functions for every page.

- Reloc-processing on dma-buf is ... questionable.

- Plus most dma-buf that bother kernel cpu mmaps give you at least
  vmap, much less kmaps. And all the ones relevant for arm-soc are
  again doing a obj->vaddr game anyway, there's no real kmap going on
  on arm it seems.

Plus this seems to be the only real in-tree user of dma_buf_kmap, and
I'd like to get rid of that.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org
---
 drivers/gpu/host1x/job.c | 21 +++++++--------------
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 25ca54de8fc5..60b2fedd0061 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
 
 static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
 {
-	u32 last_page = ~0;
-	void *cmdbuf_page_addr = NULL;
+	void *cmdbuf_addr = NULL;
 	struct host1x_bo *cmdbuf = g->bo;
 	unsigned int i;
 
@@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
 			goto patch_reloc;
 		}
 
-		if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
-			if (cmdbuf_page_addr)
-				host1x_bo_kunmap(cmdbuf, last_page,
-						 cmdbuf_page_addr);
+		if (!cmdbuf_addr) {
+			cmdbuf_addr = host1x_bo_mmap(cmdbuf);
 
-			cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
-					reloc->cmdbuf.offset >> PAGE_SHIFT);
-			last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
-
-			if (unlikely(!cmdbuf_page_addr)) {
+			if (unlikely(!cmdbuf_addr)) {
 				pr_err("Could not map cmdbuf for relocation\n");
 				return -ENOMEM;
 			}
 		}
 
-		target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
+		target = cmdbuf_addr + reloc->cmdbuf.offset;
 patch_reloc:
 		*target = reloc_addr;
 	}
 
-	if (cmdbuf_page_addr)
-		host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
+	if (cmdbuf_addr)
+		host1x_bo_munmap(cmdbuf, cmdbuf_addr);
 
 	return 0;
 }
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

[Daniel Vetter]

On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote:
> A few reasons to drop kmap:
> 
> - For native objects all we do is look at obj->vaddr anyway, so might
>   as well not call functions for every page.
> 
> - Reloc-processing on dma-buf is ... questionable.
> 
> - Plus most dma-buf that bother kernel cpu mmaps give you at least
>   vmap, much less kmaps. And all the ones relevant for arm-soc are
>   again doing a obj->vaddr game anyway, there's no real kmap going on
>   on arm it seems.
> 
> Plus this seems to be the only real in-tree user of dma_buf_kmap, and
> I'd like to get rid of that.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: linux-tegra@vger.kernel.org

Ping for testing/review on these first 2 tegra patches. They're holding up
the entire series, and I got acks for all the other bits surprisingly
fast. So would like to land this rather sooner than later. I'm also
working on a lot more dma-buf patches ...

Thanks, Daniel

> ---
>  drivers/gpu/host1x/job.c | 21 +++++++--------------
>  1 file changed, 7 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> index 25ca54de8fc5..60b2fedd0061 100644
> --- a/drivers/gpu/host1x/job.c
> +++ b/drivers/gpu/host1x/job.c
> @@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
>  
>  static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>  {
> -	u32 last_page = ~0;
> -	void *cmdbuf_page_addr = NULL;
> +	void *cmdbuf_addr = NULL;
>  	struct host1x_bo *cmdbuf = g->bo;
>  	unsigned int i;
>  
> @@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>  			goto patch_reloc;
>  		}
>  
> -		if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
> -			if (cmdbuf_page_addr)
> -				host1x_bo_kunmap(cmdbuf, last_page,
> -						 cmdbuf_page_addr);
> +		if (!cmdbuf_addr) {
> +			cmdbuf_addr = host1x_bo_mmap(cmdbuf);
>  
> -			cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
> -					reloc->cmdbuf.offset >> PAGE_SHIFT);
> -			last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
> -
> -			if (unlikely(!cmdbuf_page_addr)) {
> +			if (unlikely(!cmdbuf_addr)) {
>  				pr_err("Could not map cmdbuf for relocation\n");
>  				return -ENOMEM;
>  			}
>  		}
>  
> -		target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
> +		target = cmdbuf_addr + reloc->cmdbuf.offset;
>  patch_reloc:
>  		*target = reloc_addr;
>  	}
>  
> -	if (cmdbuf_page_addr)
> -		host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
> +	if (cmdbuf_addr)
> +		host1x_bo_munmap(cmdbuf, cmdbuf_addr);
>  
>  	return 0;
>  }
> -- 
> 2.24.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

[Daniel Vetter]

On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote:
> A few reasons to drop kmap:
> 
> - For native objects all we do is look at obj->vaddr anyway, so might
>   as well not call functions for every page.
> 
> - Reloc-processing on dma-buf is ... questionable.
> 
> - Plus most dma-buf that bother kernel cpu mmaps give you at least
>   vmap, much less kmaps. And all the ones relevant for arm-soc are
>   again doing a obj->vaddr game anyway, there's no real kmap going on
>   on arm it seems.
> 
> Plus this seems to be the only real in-tree user of dma_buf_kmap, and
> I'd like to get rid of that.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: linux-tegra@vger.kernel.org

Ping for testing/review on these first 2 tegra patches. They're holding up
the entire series, and I got acks for all the other bits surprisingly
fast. So would like to land this rather sooner than later. I'm also
working on a lot more dma-buf patches ...

Thanks, Daniel

> ---
>  drivers/gpu/host1x/job.c | 21 +++++++--------------
>  1 file changed, 7 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> index 25ca54de8fc5..60b2fedd0061 100644
> --- a/drivers/gpu/host1x/job.c
> +++ b/drivers/gpu/host1x/job.c
> @@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
>  
>  static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>  {
> -	u32 last_page = ~0;
> -	void *cmdbuf_page_addr = NULL;
> +	void *cmdbuf_addr = NULL;
>  	struct host1x_bo *cmdbuf = g->bo;
>  	unsigned int i;
>  
> @@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>  			goto patch_reloc;
>  		}
>  
> -		if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
> -			if (cmdbuf_page_addr)
> -				host1x_bo_kunmap(cmdbuf, last_page,
> -						 cmdbuf_page_addr);
> +		if (!cmdbuf_addr) {
> +			cmdbuf_addr = host1x_bo_mmap(cmdbuf);
>  
> -			cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
> -					reloc->cmdbuf.offset >> PAGE_SHIFT);
> -			last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
> -
> -			if (unlikely(!cmdbuf_page_addr)) {
> +			if (unlikely(!cmdbuf_addr)) {
>  				pr_err("Could not map cmdbuf for relocation\n");
>  				return -ENOMEM;
>  			}
>  		}
>  
> -		target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
> +		target = cmdbuf_addr + reloc->cmdbuf.offset;
>  patch_reloc:
>  		*target = reloc_addr;
>  	}
>  
> -	if (cmdbuf_page_addr)
> -		host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
> +	if (cmdbuf_addr)
> +		host1x_bo_munmap(cmdbuf, cmdbuf_addr);
>  
>  	return 0;
>  }
> -- 
> 2.24.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

[Daniel Vetter]

On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote:
> A few reasons to drop kmap:
> 
> - For native objects all we do is look at obj->vaddr anyway, so might
>   as well not call functions for every page.
> 
> - Reloc-processing on dma-buf is ... questionable.
> 
> - Plus most dma-buf that bother kernel cpu mmaps give you at least
>   vmap, much less kmaps. And all the ones relevant for arm-soc are
>   again doing a obj->vaddr game anyway, there's no real kmap going on
>   on arm it seems.
> 
> Plus this seems to be the only real in-tree user of dma_buf_kmap, and
> I'd like to get rid of that.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: linux-tegra@vger.kernel.org

Ping for testing/review on these first 2 tegra patches. They're holding up
the entire series, and I got acks for all the other bits surprisingly
fast. So would like to land this rather sooner than later. I'm also
working on a lot more dma-buf patches ...

Thanks, Daniel

> ---
>  drivers/gpu/host1x/job.c | 21 +++++++--------------
>  1 file changed, 7 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> index 25ca54de8fc5..60b2fedd0061 100644
> --- a/drivers/gpu/host1x/job.c
> +++ b/drivers/gpu/host1x/job.c
> @@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
>  
>  static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>  {
> -	u32 last_page = ~0;
> -	void *cmdbuf_page_addr = NULL;
> +	void *cmdbuf_addr = NULL;
>  	struct host1x_bo *cmdbuf = g->bo;
>  	unsigned int i;
>  
> @@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>  			goto patch_reloc;
>  		}
>  
> -		if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
> -			if (cmdbuf_page_addr)
> -				host1x_bo_kunmap(cmdbuf, last_page,
> -						 cmdbuf_page_addr);
> +		if (!cmdbuf_addr) {
> +			cmdbuf_addr = host1x_bo_mmap(cmdbuf);
>  
> -			cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
> -					reloc->cmdbuf.offset >> PAGE_SHIFT);
> -			last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
> -
> -			if (unlikely(!cmdbuf_page_addr)) {
> +			if (unlikely(!cmdbuf_addr)) {
>  				pr_err("Could not map cmdbuf for relocation\n");
>  				return -ENOMEM;
>  			}
>  		}
>  
> -		target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
> +		target = cmdbuf_addr + reloc->cmdbuf.offset;
>  patch_reloc:
>  		*target = reloc_addr;
>  	}
>  
> -	if (cmdbuf_page_addr)
> -		host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
> +	if (cmdbuf_addr)
> +		host1x_bo_munmap(cmdbuf, cmdbuf_addr);
>  
>  	return 0;
>  }
> -- 
> 2.24.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 3173 bytes --]

On Mon, Nov 25, 2019 at 10:58:56AM +0100, Daniel Vetter wrote:
> On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote:
> > A few reasons to drop kmap:
> > 
> > - For native objects all we do is look at obj->vaddr anyway, so might
> >   as well not call functions for every page.
> > 
> > - Reloc-processing on dma-buf is ... questionable.
> > 
> > - Plus most dma-buf that bother kernel cpu mmaps give you at least
> >   vmap, much less kmaps. And all the ones relevant for arm-soc are
> >   again doing a obj->vaddr game anyway, there's no real kmap going on
> >   on arm it seems.
> > 
> > Plus this seems to be the only real in-tree user of dma_buf_kmap, and
> > I'd like to get rid of that.
> > 
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Thierry Reding <thierry.reding@gmail.com>
> > Cc: linux-tegra@vger.kernel.org
> 
> Ping for testing/review on these first 2 tegra patches. They're holding up
> the entire series, and I got acks for all the other bits surprisingly
> fast. So would like to land this rather sooner than later. I'm also
> working on a lot more dma-buf patches ...

Right, I had forgotten about this series. Let me go test it right away.

Thierry

> > ---
> >  drivers/gpu/host1x/job.c | 21 +++++++--------------
> >  1 file changed, 7 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> > index 25ca54de8fc5..60b2fedd0061 100644
> > --- a/drivers/gpu/host1x/job.c
> > +++ b/drivers/gpu/host1x/job.c
> > @@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
> >  
> >  static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
> >  {
> > -	u32 last_page = ~0;
> > -	void *cmdbuf_page_addr = NULL;
> > +	void *cmdbuf_addr = NULL;
> >  	struct host1x_bo *cmdbuf = g->bo;
> >  	unsigned int i;
> >  
> > @@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
> >  			goto patch_reloc;
> >  		}
> >  
> > -		if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
> > -			if (cmdbuf_page_addr)
> > -				host1x_bo_kunmap(cmdbuf, last_page,
> > -						 cmdbuf_page_addr);
> > +		if (!cmdbuf_addr) {
> > +			cmdbuf_addr = host1x_bo_mmap(cmdbuf);
> >  
> > -			cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
> > -					reloc->cmdbuf.offset >> PAGE_SHIFT);
> > -			last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
> > -
> > -			if (unlikely(!cmdbuf_page_addr)) {
> > +			if (unlikely(!cmdbuf_addr)) {
> >  				pr_err("Could not map cmdbuf for relocation\n");
> >  				return -ENOMEM;
> >  			}
> >  		}
> >  
> > -		target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
> > +		target = cmdbuf_addr + reloc->cmdbuf.offset;
> >  patch_reloc:
> >  		*target = reloc_addr;
> >  	}
> >  
> > -	if (cmdbuf_page_addr)
> > -		host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
> > +	if (cmdbuf_addr)
> > +		host1x_bo_munmap(cmdbuf, cmdbuf_addr);
> >  
> >  	return 0;
> >  }
> > -- 
> > 2.24.0
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 3173 bytes --]

On Mon, Nov 25, 2019 at 10:58:56AM +0100, Daniel Vetter wrote:
> On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote:
> > A few reasons to drop kmap:
> > 
> > - For native objects all we do is look at obj->vaddr anyway, so might
> >   as well not call functions for every page.
> > 
> > - Reloc-processing on dma-buf is ... questionable.
> > 
> > - Plus most dma-buf that bother kernel cpu mmaps give you at least
> >   vmap, much less kmaps. And all the ones relevant for arm-soc are
> >   again doing a obj->vaddr game anyway, there's no real kmap going on
> >   on arm it seems.
> > 
> > Plus this seems to be the only real in-tree user of dma_buf_kmap, and
> > I'd like to get rid of that.
> > 
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Thierry Reding <thierry.reding@gmail.com>
> > Cc: linux-tegra@vger.kernel.org
> 
> Ping for testing/review on these first 2 tegra patches. They're holding up
> the entire series, and I got acks for all the other bits surprisingly
> fast. So would like to land this rather sooner than later. I'm also
> working on a lot more dma-buf patches ...

Right, I had forgotten about this series. Let me go test it right away.

Thierry

> > ---
> >  drivers/gpu/host1x/job.c | 21 +++++++--------------
> >  1 file changed, 7 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> > index 25ca54de8fc5..60b2fedd0061 100644
> > --- a/drivers/gpu/host1x/job.c
> > +++ b/drivers/gpu/host1x/job.c
> > @@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
> >  
> >  static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
> >  {
> > -	u32 last_page = ~0;
> > -	void *cmdbuf_page_addr = NULL;
> > +	void *cmdbuf_addr = NULL;
> >  	struct host1x_bo *cmdbuf = g->bo;
> >  	unsigned int i;
> >  
> > @@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
> >  			goto patch_reloc;
> >  		}
> >  
> > -		if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
> > -			if (cmdbuf_page_addr)
> > -				host1x_bo_kunmap(cmdbuf, last_page,
> > -						 cmdbuf_page_addr);
> > +		if (!cmdbuf_addr) {
> > +			cmdbuf_addr = host1x_bo_mmap(cmdbuf);
> >  
> > -			cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
> > -					reloc->cmdbuf.offset >> PAGE_SHIFT);
> > -			last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
> > -
> > -			if (unlikely(!cmdbuf_page_addr)) {
> > +			if (unlikely(!cmdbuf_addr)) {
> >  				pr_err("Could not map cmdbuf for relocation\n");
> >  				return -ENOMEM;
> >  			}
> >  		}
> >  
> > -		target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
> > +		target = cmdbuf_addr + reloc->cmdbuf.offset;
> >  patch_reloc:
> >  		*target = reloc_addr;
> >  	}
> >  
> > -	if (cmdbuf_page_addr)
> > -		host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
> > +	if (cmdbuf_addr)
> > +		host1x_bo_munmap(cmdbuf, cmdbuf_addr);
> >  
> >  	return 0;
> >  }
> > -- 
> > 2.24.0
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 3173 bytes --]

On Mon, Nov 25, 2019 at 10:58:56AM +0100, Daniel Vetter wrote:
> On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote:
> > A few reasons to drop kmap:
> > 
> > - For native objects all we do is look at obj->vaddr anyway, so might
> >   as well not call functions for every page.
> > 
> > - Reloc-processing on dma-buf is ... questionable.
> > 
> > - Plus most dma-buf that bother kernel cpu mmaps give you at least
> >   vmap, much less kmaps. And all the ones relevant for arm-soc are
> >   again doing a obj->vaddr game anyway, there's no real kmap going on
> >   on arm it seems.
> > 
> > Plus this seems to be the only real in-tree user of dma_buf_kmap, and
> > I'd like to get rid of that.
> > 
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Thierry Reding <thierry.reding@gmail.com>
> > Cc: linux-tegra@vger.kernel.org
> 
> Ping for testing/review on these first 2 tegra patches. They're holding up
> the entire series, and I got acks for all the other bits surprisingly
> fast. So would like to land this rather sooner than later. I'm also
> working on a lot more dma-buf patches ...

Right, I had forgotten about this series. Let me go test it right away.

Thierry

> > ---
> >  drivers/gpu/host1x/job.c | 21 +++++++--------------
> >  1 file changed, 7 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> > index 25ca54de8fc5..60b2fedd0061 100644
> > --- a/drivers/gpu/host1x/job.c
> > +++ b/drivers/gpu/host1x/job.c
> > @@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
> >  
> >  static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
> >  {
> > -	u32 last_page = ~0;
> > -	void *cmdbuf_page_addr = NULL;
> > +	void *cmdbuf_addr = NULL;
> >  	struct host1x_bo *cmdbuf = g->bo;
> >  	unsigned int i;
> >  
> > @@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
> >  			goto patch_reloc;
> >  		}
> >  
> > -		if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
> > -			if (cmdbuf_page_addr)
> > -				host1x_bo_kunmap(cmdbuf, last_page,
> > -						 cmdbuf_page_addr);
> > +		if (!cmdbuf_addr) {
> > +			cmdbuf_addr = host1x_bo_mmap(cmdbuf);
> >  
> > -			cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
> > -					reloc->cmdbuf.offset >> PAGE_SHIFT);
> > -			last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
> > -
> > -			if (unlikely(!cmdbuf_page_addr)) {
> > +			if (unlikely(!cmdbuf_addr)) {
> >  				pr_err("Could not map cmdbuf for relocation\n");
> >  				return -ENOMEM;
> >  			}
> >  		}
> >  
> > -		target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
> > +		target = cmdbuf_addr + reloc->cmdbuf.offset;
> >  patch_reloc:
> >  		*target = reloc_addr;
> >  	}
> >  
> > -	if (cmdbuf_page_addr)
> > -		host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
> > +	if (cmdbuf_addr)
> > +		host1x_bo_munmap(cmdbuf, cmdbuf_addr);
> >  
> >  	return 0;
> >  }
> > -- 
> > 2.24.0
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 2716 bytes --]

On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote:
> A few reasons to drop kmap:
> 
> - For native objects all we do is look at obj->vaddr anyway, so might
>   as well not call functions for every page.
> 
> - Reloc-processing on dma-buf is ... questionable.
> 
> - Plus most dma-buf that bother kernel cpu mmaps give you at least
>   vmap, much less kmaps. And all the ones relevant for arm-soc are
>   again doing a obj->vaddr game anyway, there's no real kmap going on
>   on arm it seems.
> 
> Plus this seems to be the only real in-tree user of dma_buf_kmap, and
> I'd like to get rid of that.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: linux-tegra@vger.kernel.org
> ---
>  drivers/gpu/host1x/job.c | 21 +++++++--------------
>  1 file changed, 7 insertions(+), 14 deletions(-)

This looks correct to me, and running some of the grate project's tests
against this works just fine, so:

Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>

> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> index 25ca54de8fc5..60b2fedd0061 100644
> --- a/drivers/gpu/host1x/job.c
> +++ b/drivers/gpu/host1x/job.c
> @@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
>  
>  static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>  {
> -	u32 last_page = ~0;
> -	void *cmdbuf_page_addr = NULL;
> +	void *cmdbuf_addr = NULL;
>  	struct host1x_bo *cmdbuf = g->bo;
>  	unsigned int i;
>  
> @@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>  			goto patch_reloc;
>  		}
>  
> -		if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
> -			if (cmdbuf_page_addr)
> -				host1x_bo_kunmap(cmdbuf, last_page,
> -						 cmdbuf_page_addr);
> +		if (!cmdbuf_addr) {
> +			cmdbuf_addr = host1x_bo_mmap(cmdbuf);
>  
> -			cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
> -					reloc->cmdbuf.offset >> PAGE_SHIFT);
> -			last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
> -
> -			if (unlikely(!cmdbuf_page_addr)) {
> +			if (unlikely(!cmdbuf_addr)) {
>  				pr_err("Could not map cmdbuf for relocation\n");
>  				return -ENOMEM;
>  			}
>  		}
>  
> -		target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
> +		target = cmdbuf_addr + reloc->cmdbuf.offset;
>  patch_reloc:
>  		*target = reloc_addr;
>  	}
>  
> -	if (cmdbuf_page_addr)
> -		host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
> +	if (cmdbuf_addr)
> +		host1x_bo_munmap(cmdbuf, cmdbuf_addr);
>  
>  	return 0;
>  }
> -- 
> 2.24.0
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 2716 bytes --]

On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote:
> A few reasons to drop kmap:
> 
> - For native objects all we do is look at obj->vaddr anyway, so might
>   as well not call functions for every page.
> 
> - Reloc-processing on dma-buf is ... questionable.
> 
> - Plus most dma-buf that bother kernel cpu mmaps give you at least
>   vmap, much less kmaps. And all the ones relevant for arm-soc are
>   again doing a obj->vaddr game anyway, there's no real kmap going on
>   on arm it seems.
> 
> Plus this seems to be the only real in-tree user of dma_buf_kmap, and
> I'd like to get rid of that.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: linux-tegra@vger.kernel.org
> ---
>  drivers/gpu/host1x/job.c | 21 +++++++--------------
>  1 file changed, 7 insertions(+), 14 deletions(-)

This looks correct to me, and running some of the grate project's tests
against this works just fine, so:

Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>

> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> index 25ca54de8fc5..60b2fedd0061 100644
> --- a/drivers/gpu/host1x/job.c
> +++ b/drivers/gpu/host1x/job.c
> @@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
>  
>  static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>  {
> -	u32 last_page = ~0;
> -	void *cmdbuf_page_addr = NULL;
> +	void *cmdbuf_addr = NULL;
>  	struct host1x_bo *cmdbuf = g->bo;
>  	unsigned int i;
>  
> @@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>  			goto patch_reloc;
>  		}
>  
> -		if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
> -			if (cmdbuf_page_addr)
> -				host1x_bo_kunmap(cmdbuf, last_page,
> -						 cmdbuf_page_addr);
> +		if (!cmdbuf_addr) {
> +			cmdbuf_addr = host1x_bo_mmap(cmdbuf);
>  
> -			cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
> -					reloc->cmdbuf.offset >> PAGE_SHIFT);
> -			last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
> -
> -			if (unlikely(!cmdbuf_page_addr)) {
> +			if (unlikely(!cmdbuf_addr)) {
>  				pr_err("Could not map cmdbuf for relocation\n");
>  				return -ENOMEM;
>  			}
>  		}
>  
> -		target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
> +		target = cmdbuf_addr + reloc->cmdbuf.offset;
>  patch_reloc:
>  		*target = reloc_addr;
>  	}
>  
> -	if (cmdbuf_page_addr)
> -		host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
> +	if (cmdbuf_addr)
> +		host1x_bo_munmap(cmdbuf, cmdbuf_addr);
>  
>  	return 0;
>  }
> -- 
> 2.24.0
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 2716 bytes --]

On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote:
> A few reasons to drop kmap:
> 
> - For native objects all we do is look at obj->vaddr anyway, so might
>   as well not call functions for every page.
> 
> - Reloc-processing on dma-buf is ... questionable.
> 
> - Plus most dma-buf that bother kernel cpu mmaps give you at least
>   vmap, much less kmaps. And all the ones relevant for arm-soc are
>   again doing a obj->vaddr game anyway, there's no real kmap going on
>   on arm it seems.
> 
> Plus this seems to be the only real in-tree user of dma_buf_kmap, and
> I'd like to get rid of that.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: linux-tegra@vger.kernel.org
> ---
>  drivers/gpu/host1x/job.c | 21 +++++++--------------
>  1 file changed, 7 insertions(+), 14 deletions(-)

This looks correct to me, and running some of the grate project's tests
against this works just fine, so:

Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>

> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> index 25ca54de8fc5..60b2fedd0061 100644
> --- a/drivers/gpu/host1x/job.c
> +++ b/drivers/gpu/host1x/job.c
> @@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
>  
>  static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>  {
> -	u32 last_page = ~0;
> -	void *cmdbuf_page_addr = NULL;
> +	void *cmdbuf_addr = NULL;
>  	struct host1x_bo *cmdbuf = g->bo;
>  	unsigned int i;
>  
> @@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>  			goto patch_reloc;
>  		}
>  
> -		if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
> -			if (cmdbuf_page_addr)
> -				host1x_bo_kunmap(cmdbuf, last_page,
> -						 cmdbuf_page_addr);
> +		if (!cmdbuf_addr) {
> +			cmdbuf_addr = host1x_bo_mmap(cmdbuf);
>  
> -			cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
> -					reloc->cmdbuf.offset >> PAGE_SHIFT);
> -			last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
> -
> -			if (unlikely(!cmdbuf_page_addr)) {
> +			if (unlikely(!cmdbuf_addr)) {
>  				pr_err("Could not map cmdbuf for relocation\n");
>  				return -ENOMEM;
>  			}
>  		}
>  
> -		target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
> +		target = cmdbuf_addr + reloc->cmdbuf.offset;
>  patch_reloc:
>  		*target = reloc_addr;
>  	}
>  
> -	if (cmdbuf_page_addr)
> -		host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
> +	if (cmdbuf_addr)
> +		host1x_bo_munmap(cmdbuf, cmdbuf_addr);
>  
>  	return 0;
>  }
> -- 
> 2.24.0
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/15] drm/tegra: Delete host1x_bo_ops->k(un)map

[Daniel Vetter]

It doesn't have any callers anymore.

Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't
do userspace mmaps, but a kernel vmap. I think most places use vmap
for this, except ttm, which uses kmap for vmap for added confusion.
mmap seems entirely for userspace mappings set up through mmap(2)
syscall.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: linux-tegra@vger.kernel.org
---
 drivers/gpu/drm/tegra/gem.c | 28 ----------------------------
 include/linux/host1x.h      | 13 -------------
 2 files changed, 41 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 746dae32c484..662cb7c87ef5 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -103,32 +103,6 @@ static void tegra_bo_munmap(struct host1x_bo *bo, void *addr)
 		vunmap(addr);
 }
 
-static void *tegra_bo_kmap(struct host1x_bo *bo, unsigned int page)
-{
-	struct tegra_bo *obj = host1x_to_tegra_bo(bo);
-
-	if (obj->vaddr)
-		return obj->vaddr + page * PAGE_SIZE;
-	else if (obj->gem.import_attach)
-		return dma_buf_kmap(obj->gem.import_attach->dmabuf, page);
-	else
-		return vmap(obj->pages + page, 1, VM_MAP,
-			    pgprot_writecombine(PAGE_KERNEL));
-}
-
-static void tegra_bo_kunmap(struct host1x_bo *bo, unsigned int page,
-			    void *addr)
-{
-	struct tegra_bo *obj = host1x_to_tegra_bo(bo);
-
-	if (obj->vaddr)
-		return;
-	else if (obj->gem.import_attach)
-		dma_buf_kunmap(obj->gem.import_attach->dmabuf, page, addr);
-	else
-		vunmap(addr);
-}
-
 static struct host1x_bo *tegra_bo_get(struct host1x_bo *bo)
 {
 	struct tegra_bo *obj = host1x_to_tegra_bo(bo);
@@ -145,8 +119,6 @@ static const struct host1x_bo_ops tegra_bo_ops = {
 	.unpin = tegra_bo_unpin,
 	.mmap = tegra_bo_mmap,
 	.munmap = tegra_bo_munmap,
-	.kmap = tegra_bo_kmap,
-	.kunmap = tegra_bo_kunmap,
 };
 
 static int tegra_bo_iommu_map(struct tegra_drm *tegra, struct tegra_bo *bo)
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index 6f8d772591ba..6edeb9228c4e 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -72,8 +72,6 @@ struct host1x_bo_ops {
 	void (*unpin)(struct device *dev, struct sg_table *sgt);
 	void *(*mmap)(struct host1x_bo *bo);
 	void (*munmap)(struct host1x_bo *bo, void *addr);
-	void *(*kmap)(struct host1x_bo *bo, unsigned int pagenum);
-	void (*kunmap)(struct host1x_bo *bo, unsigned int pagenum, void *addr);
 };
 
 struct host1x_bo {
@@ -119,17 +117,6 @@ static inline void host1x_bo_munmap(struct host1x_bo *bo, void *addr)
 	bo->ops->munmap(bo, addr);
 }
 
-static inline void *host1x_bo_kmap(struct host1x_bo *bo, unsigned int pagenum)
-{
-	return bo->ops->kmap(bo, pagenum);
-}
-
-static inline void host1x_bo_kunmap(struct host1x_bo *bo,
-				    unsigned int pagenum, void *addr)
-{
-	bo->ops->kunmap(bo, pagenum, addr);
-}
-
 /*
  * host1x syncpoints
  */
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 02/15] drm/tegra: Delete host1x_bo_ops->k(un)map

[Daniel Vetter]

It doesn't have any callers anymore.

Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't
do userspace mmaps, but a kernel vmap. I think most places use vmap
for this, except ttm, which uses kmap for vmap for added confusion.
mmap seems entirely for userspace mappings set up through mmap(2)
syscall.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: linux-tegra@vger.kernel.org
---
 drivers/gpu/drm/tegra/gem.c | 28 ----------------------------
 include/linux/host1x.h      | 13 -------------
 2 files changed, 41 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 746dae32c484..662cb7c87ef5 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -103,32 +103,6 @@ static void tegra_bo_munmap(struct host1x_bo *bo, void *addr)
 		vunmap(addr);
 }
 
-static void *tegra_bo_kmap(struct host1x_bo *bo, unsigned int page)
-{
-	struct tegra_bo *obj = host1x_to_tegra_bo(bo);
-
-	if (obj->vaddr)
-		return obj->vaddr + page * PAGE_SIZE;
-	else if (obj->gem.import_attach)
-		return dma_buf_kmap(obj->gem.import_attach->dmabuf, page);
-	else
-		return vmap(obj->pages + page, 1, VM_MAP,
-			    pgprot_writecombine(PAGE_KERNEL));
-}
-
-static void tegra_bo_kunmap(struct host1x_bo *bo, unsigned int page,
-			    void *addr)
-{
-	struct tegra_bo *obj = host1x_to_tegra_bo(bo);
-
-	if (obj->vaddr)
-		return;
-	else if (obj->gem.import_attach)
-		dma_buf_kunmap(obj->gem.import_attach->dmabuf, page, addr);
-	else
-		vunmap(addr);
-}
-
 static struct host1x_bo *tegra_bo_get(struct host1x_bo *bo)
 {
 	struct tegra_bo *obj = host1x_to_tegra_bo(bo);
@@ -145,8 +119,6 @@ static const struct host1x_bo_ops tegra_bo_ops = {
 	.unpin = tegra_bo_unpin,
 	.mmap = tegra_bo_mmap,
 	.munmap = tegra_bo_munmap,
-	.kmap = tegra_bo_kmap,
-	.kunmap = tegra_bo_kunmap,
 };
 
 static int tegra_bo_iommu_map(struct tegra_drm *tegra, struct tegra_bo *bo)
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index 6f8d772591ba..6edeb9228c4e 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -72,8 +72,6 @@ struct host1x_bo_ops {
 	void (*unpin)(struct device *dev, struct sg_table *sgt);
 	void *(*mmap)(struct host1x_bo *bo);
 	void (*munmap)(struct host1x_bo *bo, void *addr);
-	void *(*kmap)(struct host1x_bo *bo, unsigned int pagenum);
-	void (*kunmap)(struct host1x_bo *bo, unsigned int pagenum, void *addr);
 };
 
 struct host1x_bo {
@@ -119,17 +117,6 @@ static inline void host1x_bo_munmap(struct host1x_bo *bo, void *addr)
 	bo->ops->munmap(bo, addr);
 }
 
-static inline void *host1x_bo_kmap(struct host1x_bo *bo, unsigned int pagenum)
-{
-	return bo->ops->kmap(bo, pagenum);
-}
-
-static inline void host1x_bo_kunmap(struct host1x_bo *bo,
-				    unsigned int pagenum, void *addr)
-{
-	bo->ops->kunmap(bo, pagenum, addr);
-}
-
 /*
  * host1x syncpoints
  */
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 02/15] drm/tegra: Delete host1x_bo_ops->k(un)map

[Daniel Vetter]

It doesn't have any callers anymore.

Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't
do userspace mmaps, but a kernel vmap. I think most places use vmap
for this, except ttm, which uses kmap for vmap for added confusion.
mmap seems entirely for userspace mappings set up through mmap(2)
syscall.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: linux-tegra@vger.kernel.org
---
 drivers/gpu/drm/tegra/gem.c | 28 ----------------------------
 include/linux/host1x.h      | 13 -------------
 2 files changed, 41 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 746dae32c484..662cb7c87ef5 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -103,32 +103,6 @@ static void tegra_bo_munmap(struct host1x_bo *bo, void *addr)
 		vunmap(addr);
 }
 
-static void *tegra_bo_kmap(struct host1x_bo *bo, unsigned int page)
-{
-	struct tegra_bo *obj = host1x_to_tegra_bo(bo);
-
-	if (obj->vaddr)
-		return obj->vaddr + page * PAGE_SIZE;
-	else if (obj->gem.import_attach)
-		return dma_buf_kmap(obj->gem.import_attach->dmabuf, page);
-	else
-		return vmap(obj->pages + page, 1, VM_MAP,
-			    pgprot_writecombine(PAGE_KERNEL));
-}
-
-static void tegra_bo_kunmap(struct host1x_bo *bo, unsigned int page,
-			    void *addr)
-{
-	struct tegra_bo *obj = host1x_to_tegra_bo(bo);
-
-	if (obj->vaddr)
-		return;
-	else if (obj->gem.import_attach)
-		dma_buf_kunmap(obj->gem.import_attach->dmabuf, page, addr);
-	else
-		vunmap(addr);
-}
-
 static struct host1x_bo *tegra_bo_get(struct host1x_bo *bo)
 {
 	struct tegra_bo *obj = host1x_to_tegra_bo(bo);
@@ -145,8 +119,6 @@ static const struct host1x_bo_ops tegra_bo_ops = {
 	.unpin = tegra_bo_unpin,
 	.mmap = tegra_bo_mmap,
 	.munmap = tegra_bo_munmap,
-	.kmap = tegra_bo_kmap,
-	.kunmap = tegra_bo_kunmap,
 };
 
 static int tegra_bo_iommu_map(struct tegra_drm *tegra, struct tegra_bo *bo)
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index 6f8d772591ba..6edeb9228c4e 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -72,8 +72,6 @@ struct host1x_bo_ops {
 	void (*unpin)(struct device *dev, struct sg_table *sgt);
 	void *(*mmap)(struct host1x_bo *bo);
 	void (*munmap)(struct host1x_bo *bo, void *addr);
-	void *(*kmap)(struct host1x_bo *bo, unsigned int pagenum);
-	void (*kunmap)(struct host1x_bo *bo, unsigned int pagenum, void *addr);
 };
 
 struct host1x_bo {
@@ -119,17 +117,6 @@ static inline void host1x_bo_munmap(struct host1x_bo *bo, void *addr)
 	bo->ops->munmap(bo, addr);
 }
 
-static inline void *host1x_bo_kmap(struct host1x_bo *bo, unsigned int pagenum)
-{
-	return bo->ops->kmap(bo, pagenum);
-}
-
-static inline void host1x_bo_kunmap(struct host1x_bo *bo,
-				    unsigned int pagenum, void *addr)
-{
-	bo->ops->kunmap(bo, pagenum, addr);
-}
-
 /*
  * host1x syncpoints
  */
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/15] drm/tegra: Delete host1x_bo_ops->k(un)map

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 967 bytes --]

On Mon, Nov 18, 2019 at 11:35:23AM +0100, Daniel Vetter wrote:
> It doesn't have any callers anymore.
> 
> Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't
> do userspace mmaps, but a kernel vmap. I think most places use vmap
> for this, except ttm, which uses kmap for vmap for added confusion.
> mmap seems entirely for userspace mappings set up through mmap(2)
> syscall.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Jonathan Hunter <jonathanh@nvidia.com>
> Cc: linux-tegra@vger.kernel.org
> ---
>  drivers/gpu/drm/tegra/gem.c | 28 ----------------------------
>  include/linux/host1x.h      | 13 -------------
>  2 files changed, 41 deletions(-)

Tested along with the rest of the series and this is obviously right now
that the only user is gone, so:

Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/15] drm/tegra: Delete host1x_bo_ops->k(un)map

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 967 bytes --]

On Mon, Nov 18, 2019 at 11:35:23AM +0100, Daniel Vetter wrote:
> It doesn't have any callers anymore.
> 
> Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't
> do userspace mmaps, but a kernel vmap. I think most places use vmap
> for this, except ttm, which uses kmap for vmap for added confusion.
> mmap seems entirely for userspace mappings set up through mmap(2)
> syscall.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Jonathan Hunter <jonathanh@nvidia.com>
> Cc: linux-tegra@vger.kernel.org
> ---
>  drivers/gpu/drm/tegra/gem.c | 28 ----------------------------
>  include/linux/host1x.h      | 13 -------------
>  2 files changed, 41 deletions(-)

Tested along with the rest of the series and this is obviously right now
that the only user is gone, so:

Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 02/15] drm/tegra: Delete host1x_bo_ops->k(un)map

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 967 bytes --]

On Mon, Nov 18, 2019 at 11:35:23AM +0100, Daniel Vetter wrote:
> It doesn't have any callers anymore.
> 
> Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't
> do userspace mmaps, but a kernel vmap. I think most places use vmap
> for this, except ttm, which uses kmap for vmap for added confusion.
> mmap seems entirely for userspace mappings set up through mmap(2)
> syscall.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Jonathan Hunter <jonathanh@nvidia.com>
> Cc: linux-tegra@vger.kernel.org
> ---
>  drivers/gpu/drm/tegra/gem.c | 28 ----------------------------
>  include/linux/host1x.h      | 13 -------------
>  2 files changed, 41 deletions(-)

Tested along with the rest of the series and this is obviously right now
that the only user is gone, so:

Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/15] drm/i915: Remove dma_buf_kmap selftest

[Daniel Vetter]

It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
Delete it, before we start garbage-collecting the various
implementations.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Dave Airlie <airlied@gmail.com>
---
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 101 ------------------
 1 file changed, 101 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index d85d1ce273ca..2a52b92586b9 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -254,106 +254,6 @@ static int igt_dmabuf_export_vmap(void *arg)
 	return err;
 }
 
-static int igt_dmabuf_export_kmap(void *arg)
-{
-	struct drm_i915_private *i915 = arg;
-	struct drm_i915_gem_object *obj;
-	struct dma_buf *dmabuf;
-	void *ptr;
-	int err;
-
-	obj = i915_gem_object_create_shmem(i915, 2 * PAGE_SIZE);
-	if (IS_ERR(obj))
-		return PTR_ERR(obj);
-
-	dmabuf = i915_gem_prime_export(&obj->base, 0);
-	i915_gem_object_put(obj);
-	if (IS_ERR(dmabuf)) {
-		err = PTR_ERR(dmabuf);
-		pr_err("i915_gem_prime_export failed with err=%d\n", err);
-		return err;
-	}
-
-	ptr = dma_buf_kmap(dmabuf, 0);
-	if (!ptr) {
-		pr_err("dma_buf_kmap failed\n");
-		err = -ENOMEM;
-		goto err;
-	}
-
-	if (memchr_inv(ptr, 0, PAGE_SIZE)) {
-		dma_buf_kunmap(dmabuf, 0, ptr);
-		pr_err("Exported page[0] not initialiased to zero!\n");
-		err = -EINVAL;
-		goto err;
-	}
-
-	memset(ptr, 0xc5, PAGE_SIZE);
-	dma_buf_kunmap(dmabuf, 0, ptr);
-
-	ptr = i915_gem_object_pin_map(obj, I915_MAP_WB);
-	if (IS_ERR(ptr)) {
-		err = PTR_ERR(ptr);
-		pr_err("i915_gem_object_pin_map failed with err=%d\n", err);
-		goto err;
-	}
-	memset(ptr + PAGE_SIZE, 0xaa, PAGE_SIZE);
-	i915_gem_object_flush_map(obj);
-	i915_gem_object_unpin_map(obj);
-
-	ptr = dma_buf_kmap(dmabuf, 1);
-	if (!ptr) {
-		pr_err("dma_buf_kmap failed\n");
-		err = -ENOMEM;
-		goto err;
-	}
-
-	if (memchr_inv(ptr, 0xaa, PAGE_SIZE)) {
-		dma_buf_kunmap(dmabuf, 1, ptr);
-		pr_err("Exported page[1] not set to 0xaa!\n");
-		err = -EINVAL;
-		goto err;
-	}
-
-	memset(ptr, 0xc5, PAGE_SIZE);
-	dma_buf_kunmap(dmabuf, 1, ptr);
-
-	ptr = dma_buf_kmap(dmabuf, 0);
-	if (!ptr) {
-		pr_err("dma_buf_kmap failed\n");
-		err = -ENOMEM;
-		goto err;
-	}
-	if (memchr_inv(ptr, 0xc5, PAGE_SIZE)) {
-		dma_buf_kunmap(dmabuf, 0, ptr);
-		pr_err("Exported page[0] did not retain 0xc5!\n");
-		err = -EINVAL;
-		goto err;
-	}
-	dma_buf_kunmap(dmabuf, 0, ptr);
-
-	ptr = dma_buf_kmap(dmabuf, 2);
-	if (ptr) {
-		pr_err("Erroneously kmapped beyond the end of the object!\n");
-		dma_buf_kunmap(dmabuf, 2, ptr);
-		err = -EINVAL;
-		goto err;
-	}
-
-	ptr = dma_buf_kmap(dmabuf, -1);
-	if (ptr) {
-		pr_err("Erroneously kmapped before the start of the object!\n");
-		dma_buf_kunmap(dmabuf, -1, ptr);
-		err = -EINVAL;
-		goto err;
-	}
-
-	err = 0;
-err:
-	dma_buf_put(dmabuf);
-	return err;
-}
-
 int i915_gem_dmabuf_mock_selftests(void)
 {
 	static const struct i915_subtest tests[] = {
@@ -362,7 +262,6 @@ int i915_gem_dmabuf_mock_selftests(void)
 		SUBTEST(igt_dmabuf_import),
 		SUBTEST(igt_dmabuf_import_ownership),
 		SUBTEST(igt_dmabuf_export_vmap),
-		SUBTEST(igt_dmabuf_export_kmap),
 	};
 	struct drm_i915_private *i915;
 	int err;
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 03/15] drm/i915: Remove dma_buf_kmap selftest

[Daniel Vetter]

It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
Delete it, before we start garbage-collecting the various
implementations.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Dave Airlie <airlied@gmail.com>
---
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 101 ------------------
 1 file changed, 101 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index d85d1ce273ca..2a52b92586b9 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -254,106 +254,6 @@ static int igt_dmabuf_export_vmap(void *arg)
 	return err;
 }
 
-static int igt_dmabuf_export_kmap(void *arg)
-{
-	struct drm_i915_private *i915 = arg;
-	struct drm_i915_gem_object *obj;
-	struct dma_buf *dmabuf;
-	void *ptr;
-	int err;
-
-	obj = i915_gem_object_create_shmem(i915, 2 * PAGE_SIZE);
-	if (IS_ERR(obj))
-		return PTR_ERR(obj);
-
-	dmabuf = i915_gem_prime_export(&obj->base, 0);
-	i915_gem_object_put(obj);
-	if (IS_ERR(dmabuf)) {
-		err = PTR_ERR(dmabuf);
-		pr_err("i915_gem_prime_export failed with err=%d\n", err);
-		return err;
-	}
-
-	ptr = dma_buf_kmap(dmabuf, 0);
-	if (!ptr) {
-		pr_err("dma_buf_kmap failed\n");
-		err = -ENOMEM;
-		goto err;
-	}
-
-	if (memchr_inv(ptr, 0, PAGE_SIZE)) {
-		dma_buf_kunmap(dmabuf, 0, ptr);
-		pr_err("Exported page[0] not initialiased to zero!\n");
-		err = -EINVAL;
-		goto err;
-	}
-
-	memset(ptr, 0xc5, PAGE_SIZE);
-	dma_buf_kunmap(dmabuf, 0, ptr);
-
-	ptr = i915_gem_object_pin_map(obj, I915_MAP_WB);
-	if (IS_ERR(ptr)) {
-		err = PTR_ERR(ptr);
-		pr_err("i915_gem_object_pin_map failed with err=%d\n", err);
-		goto err;
-	}
-	memset(ptr + PAGE_SIZE, 0xaa, PAGE_SIZE);
-	i915_gem_object_flush_map(obj);
-	i915_gem_object_unpin_map(obj);
-
-	ptr = dma_buf_kmap(dmabuf, 1);
-	if (!ptr) {
-		pr_err("dma_buf_kmap failed\n");
-		err = -ENOMEM;
-		goto err;
-	}
-
-	if (memchr_inv(ptr, 0xaa, PAGE_SIZE)) {
-		dma_buf_kunmap(dmabuf, 1, ptr);
-		pr_err("Exported page[1] not set to 0xaa!\n");
-		err = -EINVAL;
-		goto err;
-	}
-
-	memset(ptr, 0xc5, PAGE_SIZE);
-	dma_buf_kunmap(dmabuf, 1, ptr);
-
-	ptr = dma_buf_kmap(dmabuf, 0);
-	if (!ptr) {
-		pr_err("dma_buf_kmap failed\n");
-		err = -ENOMEM;
-		goto err;
-	}
-	if (memchr_inv(ptr, 0xc5, PAGE_SIZE)) {
-		dma_buf_kunmap(dmabuf, 0, ptr);
-		pr_err("Exported page[0] did not retain 0xc5!\n");
-		err = -EINVAL;
-		goto err;
-	}
-	dma_buf_kunmap(dmabuf, 0, ptr);
-
-	ptr = dma_buf_kmap(dmabuf, 2);
-	if (ptr) {
-		pr_err("Erroneously kmapped beyond the end of the object!\n");
-		dma_buf_kunmap(dmabuf, 2, ptr);
-		err = -EINVAL;
-		goto err;
-	}
-
-	ptr = dma_buf_kmap(dmabuf, -1);
-	if (ptr) {
-		pr_err("Erroneously kmapped before the start of the object!\n");
-		dma_buf_kunmap(dmabuf, -1, ptr);
-		err = -EINVAL;
-		goto err;
-	}
-
-	err = 0;
-err:
-	dma_buf_put(dmabuf);
-	return err;
-}
-
 int i915_gem_dmabuf_mock_selftests(void)
 {
 	static const struct i915_subtest tests[] = {
@@ -362,7 +262,6 @@ int i915_gem_dmabuf_mock_selftests(void)
 		SUBTEST(igt_dmabuf_import),
 		SUBTEST(igt_dmabuf_import_ownership),
 		SUBTEST(igt_dmabuf_export_vmap),
-		SUBTEST(igt_dmabuf_export_kmap),
 	};
 	struct drm_i915_private *i915;
 	int err;
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 03/15] drm/i915: Remove dma_buf_kmap selftest

[Daniel Vetter]

It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
Delete it, before we start garbage-collecting the various
implementations.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Dave Airlie <airlied@gmail.com>
---
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 101 ------------------
 1 file changed, 101 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index d85d1ce273ca..2a52b92586b9 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -254,106 +254,6 @@ static int igt_dmabuf_export_vmap(void *arg)
 	return err;
 }
 
-static int igt_dmabuf_export_kmap(void *arg)
-{
-	struct drm_i915_private *i915 = arg;
-	struct drm_i915_gem_object *obj;
-	struct dma_buf *dmabuf;
-	void *ptr;
-	int err;
-
-	obj = i915_gem_object_create_shmem(i915, 2 * PAGE_SIZE);
-	if (IS_ERR(obj))
-		return PTR_ERR(obj);
-
-	dmabuf = i915_gem_prime_export(&obj->base, 0);
-	i915_gem_object_put(obj);
-	if (IS_ERR(dmabuf)) {
-		err = PTR_ERR(dmabuf);
-		pr_err("i915_gem_prime_export failed with err=%d\n", err);
-		return err;
-	}
-
-	ptr = dma_buf_kmap(dmabuf, 0);
-	if (!ptr) {
-		pr_err("dma_buf_kmap failed\n");
-		err = -ENOMEM;
-		goto err;
-	}
-
-	if (memchr_inv(ptr, 0, PAGE_SIZE)) {
-		dma_buf_kunmap(dmabuf, 0, ptr);
-		pr_err("Exported page[0] not initialiased to zero!\n");
-		err = -EINVAL;
-		goto err;
-	}
-
-	memset(ptr, 0xc5, PAGE_SIZE);
-	dma_buf_kunmap(dmabuf, 0, ptr);
-
-	ptr = i915_gem_object_pin_map(obj, I915_MAP_WB);
-	if (IS_ERR(ptr)) {
-		err = PTR_ERR(ptr);
-		pr_err("i915_gem_object_pin_map failed with err=%d\n", err);
-		goto err;
-	}
-	memset(ptr + PAGE_SIZE, 0xaa, PAGE_SIZE);
-	i915_gem_object_flush_map(obj);
-	i915_gem_object_unpin_map(obj);
-
-	ptr = dma_buf_kmap(dmabuf, 1);
-	if (!ptr) {
-		pr_err("dma_buf_kmap failed\n");
-		err = -ENOMEM;
-		goto err;
-	}
-
-	if (memchr_inv(ptr, 0xaa, PAGE_SIZE)) {
-		dma_buf_kunmap(dmabuf, 1, ptr);
-		pr_err("Exported page[1] not set to 0xaa!\n");
-		err = -EINVAL;
-		goto err;
-	}
-
-	memset(ptr, 0xc5, PAGE_SIZE);
-	dma_buf_kunmap(dmabuf, 1, ptr);
-
-	ptr = dma_buf_kmap(dmabuf, 0);
-	if (!ptr) {
-		pr_err("dma_buf_kmap failed\n");
-		err = -ENOMEM;
-		goto err;
-	}
-	if (memchr_inv(ptr, 0xc5, PAGE_SIZE)) {
-		dma_buf_kunmap(dmabuf, 0, ptr);
-		pr_err("Exported page[0] did not retain 0xc5!\n");
-		err = -EINVAL;
-		goto err;
-	}
-	dma_buf_kunmap(dmabuf, 0, ptr);
-
-	ptr = dma_buf_kmap(dmabuf, 2);
-	if (ptr) {
-		pr_err("Erroneously kmapped beyond the end of the object!\n");
-		dma_buf_kunmap(dmabuf, 2, ptr);
-		err = -EINVAL;
-		goto err;
-	}
-
-	ptr = dma_buf_kmap(dmabuf, -1);
-	if (ptr) {
-		pr_err("Erroneously kmapped before the start of the object!\n");
-		dma_buf_kunmap(dmabuf, -1, ptr);
-		err = -EINVAL;
-		goto err;
-	}
-
-	err = 0;
-err:
-	dma_buf_put(dmabuf);
-	return err;
-}
-
 int i915_gem_dmabuf_mock_selftests(void)
 {
 	static const struct i915_subtest tests[] = {
@@ -362,7 +262,6 @@ int i915_gem_dmabuf_mock_selftests(void)
 		SUBTEST(igt_dmabuf_import),
 		SUBTEST(igt_dmabuf_import_ownership),
 		SUBTEST(igt_dmabuf_export_vmap),
-		SUBTEST(igt_dmabuf_export_kmap),
 	};
 	struct drm_i915_private *i915;
 	int err;
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/15] drm/i915: Remove dma_buf_kmap selftest

[Chris Wilson]

Quoting Daniel Vetter (2019-11-18 10:35:24)
> It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
> Delete it, before we start garbage-collecting the various
> implementations.

Ok then, I'm still mourning the loss of kmap. I definitely do not think
we should _only_ have a whole-object-at-a-time interface as we may have
to deal with objects larger than the aperture, or even larger than
system memory. I feel we have a bridge to cross in future...

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 03/15] drm/i915: Remove dma_buf_kmap selftest

[Chris Wilson]

Quoting Daniel Vetter (2019-11-18 10:35:24)
> It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
> Delete it, before we start garbage-collecting the various
> implementations.

Ok then, I'm still mourning the loss of kmap. I definitely do not think
we should _only_ have a whole-object-at-a-time interface as we may have
to deal with objects larger than the aperture, or even larger than
system memory. I feel we have a bridge to cross in future...

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 03/15] drm/i915: Remove dma_buf_kmap selftest

[Chris Wilson]

Quoting Daniel Vetter (2019-11-18 10:35:24)
> It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
> Delete it, before we start garbage-collecting the various
> implementations.

Ok then, I'm still mourning the loss of kmap. I definitely do not think
we should _only_ have a whole-object-at-a-time interface as we may have
to deal with objects larger than the aperture, or even larger than
system memory. I feel we have a bridge to cross in future...

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

[Daniel Vetter]

There's no callers in-tree anymore.

For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: devel@driverdev.osuosl.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/staging/android/ion/ion.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index e6b1ca141b93..bb4ededc1150 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -274,18 +274,6 @@ static void ion_dma_buf_release(struct dma_buf *dmabuf)
 	_ion_buffer_destroy(buffer);
 }
 
-static void *ion_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)
-{
-	struct ion_buffer *buffer = dmabuf->priv;
-
-	return buffer->vaddr + offset * PAGE_SIZE;
-}
-
-static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
-			       void *ptr)
-{
-}
-
 static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
 					enum dma_data_direction direction)
 {
@@ -349,8 +337,6 @@ static const struct dma_buf_ops dma_buf_ops = {
 	.detach = ion_dma_buf_detatch,
 	.begin_cpu_access = ion_dma_buf_begin_cpu_access,
 	.end_cpu_access = ion_dma_buf_end_cpu_access,
-	.map = ion_dma_buf_kmap,
-	.unmap = ion_dma_buf_kunmap,
 };
 
 static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
-- 
2.24.0

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[Intel-gfx] [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

[Daniel Vetter]

There's no callers in-tree anymore.

For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: devel@driverdev.osuosl.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/staging/android/ion/ion.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index e6b1ca141b93..bb4ededc1150 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -274,18 +274,6 @@ static void ion_dma_buf_release(struct dma_buf *dmabuf)
 	_ion_buffer_destroy(buffer);
 }
 
-static void *ion_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)
-{
-	struct ion_buffer *buffer = dmabuf->priv;
-
-	return buffer->vaddr + offset * PAGE_SIZE;
-}
-
-static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
-			       void *ptr)
-{
-}
-
 static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
 					enum dma_data_direction direction)
 {
@@ -349,8 +337,6 @@ static const struct dma_buf_ops dma_buf_ops = {
 	.detach = ion_dma_buf_detatch,
 	.begin_cpu_access = ion_dma_buf_begin_cpu_access,
 	.end_cpu_access = ion_dma_buf_end_cpu_access,
-	.map = ion_dma_buf_kmap,
-	.unmap = ion_dma_buf_kunmap,
 };
 
 static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

[Daniel Vetter]

There's no callers in-tree anymore.

For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: devel@driverdev.osuosl.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/staging/android/ion/ion.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index e6b1ca141b93..bb4ededc1150 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -274,18 +274,6 @@ static void ion_dma_buf_release(struct dma_buf *dmabuf)
 	_ion_buffer_destroy(buffer);
 }
 
-static void *ion_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)
-{
-	struct ion_buffer *buffer = dmabuf->priv;
-
-	return buffer->vaddr + offset * PAGE_SIZE;
-}
-
-static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
-			       void *ptr)
-{
-}
-
 static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
 					enum dma_data_direction direction)
 {
@@ -349,8 +337,6 @@ static const struct dma_buf_ops dma_buf_ops = {
 	.detach = ion_dma_buf_detatch,
 	.begin_cpu_access = ion_dma_buf_begin_cpu_access,
 	.end_cpu_access = ion_dma_buf_end_cpu_access,
-	.map = ion_dma_buf_kmap,
-	.unmap = ion_dma_buf_kunmap,
 };
 
 static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

[Greg KH]

On Mon, Nov 18, 2019 at 11:35:25AM +0100, Daniel Vetter wrote:
> There's no callers in-tree anymore.
> 
> For merging probably best to stuff this into drm-misc, since that's
> where the dma-buf heaps will land too. And the resulting conflict
> hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
> implemenation.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Laura Abbott <labbott@redhat.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: devel@driverdev.osuosl.org
> Cc: linaro-mm-sig@lists.linaro.org
> ---
>  drivers/staging/android/ion/ion.c | 14 --------------
>  1 file changed, 14 deletions(-)

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Intel-gfx] [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

[Greg KH]

On Mon, Nov 18, 2019 at 11:35:25AM +0100, Daniel Vetter wrote:
> There's no callers in-tree anymore.
> 
> For merging probably best to stuff this into drm-misc, since that's
> where the dma-buf heaps will land too. And the resulting conflict
> hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
> implemenation.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Laura Abbott <labbott@redhat.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: devel@driverdev.osuosl.org
> Cc: linaro-mm-sig@lists.linaro.org
> ---
>  drivers/staging/android/ion/ion.c | 14 --------------
>  1 file changed, 14 deletions(-)

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

[Greg KH]

On Mon, Nov 18, 2019 at 11:35:25AM +0100, Daniel Vetter wrote:
> There's no callers in-tree anymore.
> 
> For merging probably best to stuff this into drm-misc, since that's
> where the dma-buf heaps will land too. And the resulting conflict
> hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
> implemenation.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Laura Abbott <labbott@redhat.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: devel@driverdev.osuosl.org
> Cc: linaro-mm-sig@lists.linaro.org
> ---
>  drivers/staging/android/ion/ion.c | 14 --------------
>  1 file changed, 14 deletions(-)

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

[Greg KH]

On Mon, Nov 18, 2019 at 11:35:25AM +0100, Daniel Vetter wrote:
> There's no callers in-tree anymore.
> 
> For merging probably best to stuff this into drm-misc, since that's
> where the dma-buf heaps will land too. And the resulting conflict
> hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
> implemenation.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Laura Abbott <labbott@redhat.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: devel@driverdev.osuosl.org
> Cc: linaro-mm-sig@lists.linaro.org
> ---
>  drivers/staging/android/ion/ion.c | 14 --------------
>  1 file changed, 14 deletions(-)

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

[Laura Abbott]

On 11/18/19 5:35 AM, Daniel Vetter wrote:
> There's no callers in-tree anymore.
> 
> For merging probably best to stuff this into drm-misc, since that's
> where the dma-buf heaps will land too. And the resulting conflict
> hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
> implemenation.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Laura Abbott <labbott@redhat.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: devel@driverdev.osuosl.org
> Cc: linaro-mm-sig@lists.linaro.org
> ---
>   drivers/staging/android/ion/ion.c | 14 --------------
>   1 file changed, 14 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
> index e6b1ca141b93..bb4ededc1150 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -274,18 +274,6 @@ static void ion_dma_buf_release(struct dma_buf *dmabuf)
>   	_ion_buffer_destroy(buffer);
>   }
>   
> -static void *ion_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)
> -{
> -	struct ion_buffer *buffer = dmabuf->priv;
> -
> -	return buffer->vaddr + offset * PAGE_SIZE;
> -}
> -
> -static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
> -			       void *ptr)
> -{
> -}
> -
>   static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>   					enum dma_data_direction direction)
>   {
> @@ -349,8 +337,6 @@ static const struct dma_buf_ops dma_buf_ops = {
>   	.detach = ion_dma_buf_detatch,
>   	.begin_cpu_access = ion_dma_buf_begin_cpu_access,
>   	.end_cpu_access = ion_dma_buf_end_cpu_access,
> -	.map = ion_dma_buf_kmap,
> -	.unmap = ion_dma_buf_kunmap,
>   };
>   
>   static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
> 

Acked-by: Laura Abbott <labbott@redhat.com>

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Intel-gfx] [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

[Laura Abbott]

On 11/18/19 5:35 AM, Daniel Vetter wrote:
> There's no callers in-tree anymore.
> 
> For merging probably best to stuff this into drm-misc, since that's
> where the dma-buf heaps will land too. And the resulting conflict
> hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
> implemenation.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Laura Abbott <labbott@redhat.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: devel@driverdev.osuosl.org
> Cc: linaro-mm-sig@lists.linaro.org
> ---
>   drivers/staging/android/ion/ion.c | 14 --------------
>   1 file changed, 14 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
> index e6b1ca141b93..bb4ededc1150 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -274,18 +274,6 @@ static void ion_dma_buf_release(struct dma_buf *dmabuf)
>   	_ion_buffer_destroy(buffer);
>   }
>   
> -static void *ion_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)
> -{
> -	struct ion_buffer *buffer = dmabuf->priv;
> -
> -	return buffer->vaddr + offset * PAGE_SIZE;
> -}
> -
> -static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
> -			       void *ptr)
> -{
> -}
> -
>   static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>   					enum dma_data_direction direction)
>   {
> @@ -349,8 +337,6 @@ static const struct dma_buf_ops dma_buf_ops = {
>   	.detach = ion_dma_buf_detatch,
>   	.begin_cpu_access = ion_dma_buf_begin_cpu_access,
>   	.end_cpu_access = ion_dma_buf_end_cpu_access,
> -	.map = ion_dma_buf_kmap,
> -	.unmap = ion_dma_buf_kunmap,
>   };
>   
>   static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
> 

Acked-by: Laura Abbott <labbott@redhat.com>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

[Laura Abbott]

On 11/18/19 5:35 AM, Daniel Vetter wrote:
> There's no callers in-tree anymore.
> 
> For merging probably best to stuff this into drm-misc, since that's
> where the dma-buf heaps will land too. And the resulting conflict
> hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
> implemenation.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Laura Abbott <labbott@redhat.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: devel@driverdev.osuosl.org
> Cc: linaro-mm-sig@lists.linaro.org
> ---
>   drivers/staging/android/ion/ion.c | 14 --------------
>   1 file changed, 14 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
> index e6b1ca141b93..bb4ededc1150 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -274,18 +274,6 @@ static void ion_dma_buf_release(struct dma_buf *dmabuf)
>   	_ion_buffer_destroy(buffer);
>   }
>   
> -static void *ion_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)
> -{
> -	struct ion_buffer *buffer = dmabuf->priv;
> -
> -	return buffer->vaddr + offset * PAGE_SIZE;
> -}
> -
> -static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
> -			       void *ptr)
> -{
> -}
> -
>   static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>   					enum dma_data_direction direction)
>   {
> @@ -349,8 +337,6 @@ static const struct dma_buf_ops dma_buf_ops = {
>   	.detach = ion_dma_buf_detatch,
>   	.begin_cpu_access = ion_dma_buf_begin_cpu_access,
>   	.end_cpu_access = ion_dma_buf_end_cpu_access,
> -	.map = ion_dma_buf_kmap,
> -	.unmap = ion_dma_buf_kunmap,
>   };
>   
>   static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
> 

Acked-by: Laura Abbott <labbott@redhat.com>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

[Daniel Vetter]

It's a dummy anyway.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Russell King <linux@armlinux.org.uk>
---
 drivers/gpu/drm/armada/armada_gem.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c
index 93cf8b8bfcff..976685f2939e 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -461,16 +461,6 @@ static void armada_gem_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
 	kfree(sgt);
 }
 
-static void *armada_gem_dmabuf_no_kmap(struct dma_buf *buf, unsigned long n)
-{
-	return NULL;
-}
-
-static void
-armada_gem_dmabuf_no_kunmap(struct dma_buf *buf, unsigned long n, void *addr)
-{
-}
-
 static int
 armada_gem_dmabuf_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
 {
@@ -481,8 +471,6 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
 	.map_dma_buf	= armada_gem_prime_map_dma_buf,
 	.unmap_dma_buf	= armada_gem_prime_unmap_dma_buf,
 	.release	= drm_gem_dmabuf_release,
-	.map		= armada_gem_dmabuf_no_kmap,
-	.unmap		= armada_gem_dmabuf_no_kunmap,
 	.mmap		= armada_gem_dmabuf_mmap,
 };
 
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

[Daniel Vetter]

It's a dummy anyway.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Russell King <linux@armlinux.org.uk>
---
 drivers/gpu/drm/armada/armada_gem.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c
index 93cf8b8bfcff..976685f2939e 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -461,16 +461,6 @@ static void armada_gem_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
 	kfree(sgt);
 }
 
-static void *armada_gem_dmabuf_no_kmap(struct dma_buf *buf, unsigned long n)
-{
-	return NULL;
-}
-
-static void
-armada_gem_dmabuf_no_kunmap(struct dma_buf *buf, unsigned long n, void *addr)
-{
-}
-
 static int
 armada_gem_dmabuf_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
 {
@@ -481,8 +471,6 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
 	.map_dma_buf	= armada_gem_prime_map_dma_buf,
 	.unmap_dma_buf	= armada_gem_prime_unmap_dma_buf,
 	.release	= drm_gem_dmabuf_release,
-	.map		= armada_gem_dmabuf_no_kmap,
-	.unmap		= armada_gem_dmabuf_no_kunmap,
 	.mmap		= armada_gem_dmabuf_mmap,
 };
 
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

[Daniel Vetter]

It's a dummy anyway.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Russell King <linux@armlinux.org.uk>
---
 drivers/gpu/drm/armada/armada_gem.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c
index 93cf8b8bfcff..976685f2939e 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -461,16 +461,6 @@ static void armada_gem_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
 	kfree(sgt);
 }
 
-static void *armada_gem_dmabuf_no_kmap(struct dma_buf *buf, unsigned long n)
-{
-	return NULL;
-}
-
-static void
-armada_gem_dmabuf_no_kunmap(struct dma_buf *buf, unsigned long n, void *addr)
-{
-}
-
 static int
 armada_gem_dmabuf_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
 {
@@ -481,8 +471,6 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
 	.map_dma_buf	= armada_gem_prime_map_dma_buf,
 	.unmap_dma_buf	= armada_gem_prime_unmap_dma_buf,
 	.release	= drm_gem_dmabuf_release,
-	.map		= armada_gem_dmabuf_no_kmap,
-	.unmap		= armada_gem_dmabuf_no_kunmap,
 	.mmap		= armada_gem_dmabuf_mmap,
 };
 
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

[Daniel Vetter]

On Mon, Nov 18, 2019 at 11:35:26AM +0100, Daniel Vetter wrote:
> It's a dummy anyway.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Russell King <linux@armlinux.org.uk>

I merged the entire series except this one and the final patch, sill
waiting a bit more for an ack on this perhaps.
-Daniel

> ---
>  drivers/gpu/drm/armada/armada_gem.c | 12 ------------
>  1 file changed, 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c
> index 93cf8b8bfcff..976685f2939e 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -461,16 +461,6 @@ static void armada_gem_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
>  	kfree(sgt);
>  }
>  
> -static void *armada_gem_dmabuf_no_kmap(struct dma_buf *buf, unsigned long n)
> -{
> -	return NULL;
> -}
> -
> -static void
> -armada_gem_dmabuf_no_kunmap(struct dma_buf *buf, unsigned long n, void *addr)
> -{
> -}
> -
>  static int
>  armada_gem_dmabuf_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
>  {
> @@ -481,8 +471,6 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
>  	.map_dma_buf	= armada_gem_prime_map_dma_buf,
>  	.unmap_dma_buf	= armada_gem_prime_unmap_dma_buf,
>  	.release	= drm_gem_dmabuf_release,
> -	.map		= armada_gem_dmabuf_no_kmap,
> -	.unmap		= armada_gem_dmabuf_no_kunmap,
>  	.mmap		= armada_gem_dmabuf_mmap,
>  };
>  
> -- 
> 2.24.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

[Daniel Vetter]

On Mon, Nov 18, 2019 at 11:35:26AM +0100, Daniel Vetter wrote:
> It's a dummy anyway.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Russell King <linux@armlinux.org.uk>

I merged the entire series except this one and the final patch, sill
waiting a bit more for an ack on this perhaps.
-Daniel

> ---
>  drivers/gpu/drm/armada/armada_gem.c | 12 ------------
>  1 file changed, 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c
> index 93cf8b8bfcff..976685f2939e 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -461,16 +461,6 @@ static void armada_gem_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
>  	kfree(sgt);
>  }
>  
> -static void *armada_gem_dmabuf_no_kmap(struct dma_buf *buf, unsigned long n)
> -{
> -	return NULL;
> -}
> -
> -static void
> -armada_gem_dmabuf_no_kunmap(struct dma_buf *buf, unsigned long n, void *addr)
> -{
> -}
> -
>  static int
>  armada_gem_dmabuf_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
>  {
> @@ -481,8 +471,6 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
>  	.map_dma_buf	= armada_gem_prime_map_dma_buf,
>  	.unmap_dma_buf	= armada_gem_prime_unmap_dma_buf,
>  	.release	= drm_gem_dmabuf_release,
> -	.map		= armada_gem_dmabuf_no_kmap,
> -	.unmap		= armada_gem_dmabuf_no_kunmap,
>  	.mmap		= armada_gem_dmabuf_mmap,
>  };
>  
> -- 
> 2.24.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

[Russell King - ARM Linux admin]

On Mon, Nov 25, 2019 at 10:44:43PM +0100, Daniel Vetter wrote:
> On Mon, Nov 18, 2019 at 11:35:26AM +0100, Daniel Vetter wrote:
> > It's a dummy anyway.
> > 
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Russell King <linux@armlinux.org.uk>
> 
> I merged the entire series except this one and the final patch, sill
> waiting a bit more for an ack on this perhaps.

Acked-by: Russell King <rmk+kernel@armlinux.org.uk>

I thought drm trees closed around -rc6?

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/armada/armada_gem.c | 12 ------------
> >  1 file changed, 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c
> > index 93cf8b8bfcff..976685f2939e 100644
> > --- a/drivers/gpu/drm/armada/armada_gem.c
> > +++ b/drivers/gpu/drm/armada/armada_gem.c
> > @@ -461,16 +461,6 @@ static void armada_gem_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
> >  	kfree(sgt);
> >  }
> >  
> > -static void *armada_gem_dmabuf_no_kmap(struct dma_buf *buf, unsigned long n)
> > -{
> > -	return NULL;
> > -}
> > -
> > -static void
> > -armada_gem_dmabuf_no_kunmap(struct dma_buf *buf, unsigned long n, void *addr)
> > -{
> > -}
> > -
> >  static int
> >  armada_gem_dmabuf_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
> >  {
> > @@ -481,8 +471,6 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
> >  	.map_dma_buf	= armada_gem_prime_map_dma_buf,
> >  	.unmap_dma_buf	= armada_gem_prime_unmap_dma_buf,
> >  	.release	= drm_gem_dmabuf_release,
> > -	.map		= armada_gem_dmabuf_no_kmap,
> > -	.unmap		= armada_gem_dmabuf_no_kunmap,
> >  	.mmap		= armada_gem_dmabuf_mmap,
> >  };
> >  
> > -- 
> > 2.24.0
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

[Russell King - ARM Linux admin]

On Mon, Nov 25, 2019 at 10:44:43PM +0100, Daniel Vetter wrote:
> On Mon, Nov 18, 2019 at 11:35:26AM +0100, Daniel Vetter wrote:
> > It's a dummy anyway.
> > 
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Russell King <linux@armlinux.org.uk>
> 
> I merged the entire series except this one and the final patch, sill
> waiting a bit more for an ack on this perhaps.

Acked-by: Russell King <rmk+kernel@armlinux.org.uk>

I thought drm trees closed around -rc6?

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/armada/armada_gem.c | 12 ------------
> >  1 file changed, 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c
> > index 93cf8b8bfcff..976685f2939e 100644
> > --- a/drivers/gpu/drm/armada/armada_gem.c
> > +++ b/drivers/gpu/drm/armada/armada_gem.c
> > @@ -461,16 +461,6 @@ static void armada_gem_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
> >  	kfree(sgt);
> >  }
> >  
> > -static void *armada_gem_dmabuf_no_kmap(struct dma_buf *buf, unsigned long n)
> > -{
> > -	return NULL;
> > -}
> > -
> > -static void
> > -armada_gem_dmabuf_no_kunmap(struct dma_buf *buf, unsigned long n, void *addr)
> > -{
> > -}
> > -
> >  static int
> >  armada_gem_dmabuf_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
> >  {
> > @@ -481,8 +471,6 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
> >  	.map_dma_buf	= armada_gem_prime_map_dma_buf,
> >  	.unmap_dma_buf	= armada_gem_prime_unmap_dma_buf,
> >  	.release	= drm_gem_dmabuf_release,
> > -	.map		= armada_gem_dmabuf_no_kmap,
> > -	.unmap		= armada_gem_dmabuf_no_kunmap,
> >  	.mmap		= armada_gem_dmabuf_mmap,
> >  };
> >  
> > -- 
> > 2.24.0
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

[Daniel Vetter]

On Tue, Nov 26, 2019 at 1:35 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Mon, Nov 25, 2019 at 10:44:43PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 18, 2019 at 11:35:26AM +0100, Daniel Vetter wrote:
> > > It's a dummy anyway.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Russell King <linux@armlinux.org.uk>
> >
> > I merged the entire series except this one and the final patch, sill
> > waiting a bit more for an ack on this perhaps.
>
> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>

Thanks for taking a look.

> I thought drm trees closed around -rc6?

drm.git closes for pull request. But drm-misc is open all the time, so
that committers can push patches whenever the patches are ready,
instead of having to remember that there's something in the queue. The
script used for drm-misc pushes then makes sure that drm-misc-next
doesn't show up in linux-next until after -rc1. So this is all going
into 5.6.
-Daniel

>
> > -Daniel
> >
> > > ---
> > >  drivers/gpu/drm/armada/armada_gem.c | 12 ------------
> > >  1 file changed, 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c
> > > index 93cf8b8bfcff..976685f2939e 100644
> > > --- a/drivers/gpu/drm/armada/armada_gem.c
> > > +++ b/drivers/gpu/drm/armada/armada_gem.c
> > > @@ -461,16 +461,6 @@ static void armada_gem_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
> > >     kfree(sgt);
> > >  }
> > >
> > > -static void *armada_gem_dmabuf_no_kmap(struct dma_buf *buf, unsigned long n)
> > > -{
> > > -   return NULL;
> > > -}
> > > -
> > > -static void
> > > -armada_gem_dmabuf_no_kunmap(struct dma_buf *buf, unsigned long n, void *addr)
> > > -{
> > > -}
> > > -
> > >  static int
> > >  armada_gem_dmabuf_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
> > >  {
> > > @@ -481,8 +471,6 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
> > >     .map_dma_buf    = armada_gem_prime_map_dma_buf,
> > >     .unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
> > >     .release        = drm_gem_dmabuf_release,
> > > -   .map            = armada_gem_dmabuf_no_kmap,
> > > -   .unmap          = armada_gem_dmabuf_no_kunmap,
> > >     .mmap           = armada_gem_dmabuf_mmap,
> > >  };
> > >
> > > --
> > > 2.24.0
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

[Daniel Vetter]

On Tue, Nov 26, 2019 at 1:35 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Mon, Nov 25, 2019 at 10:44:43PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 18, 2019 at 11:35:26AM +0100, Daniel Vetter wrote:
> > > It's a dummy anyway.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Russell King <linux@armlinux.org.uk>
> >
> > I merged the entire series except this one and the final patch, sill
> > waiting a bit more for an ack on this perhaps.
>
> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>

Thanks for taking a look.

> I thought drm trees closed around -rc6?

drm.git closes for pull request. But drm-misc is open all the time, so
that committers can push patches whenever the patches are ready,
instead of having to remember that there's something in the queue. The
script used for drm-misc pushes then makes sure that drm-misc-next
doesn't show up in linux-next until after -rc1. So this is all going
into 5.6.
-Daniel

>
> > -Daniel
> >
> > > ---
> > >  drivers/gpu/drm/armada/armada_gem.c | 12 ------------
> > >  1 file changed, 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c
> > > index 93cf8b8bfcff..976685f2939e 100644
> > > --- a/drivers/gpu/drm/armada/armada_gem.c
> > > +++ b/drivers/gpu/drm/armada/armada_gem.c
> > > @@ -461,16 +461,6 @@ static void armada_gem_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
> > >     kfree(sgt);
> > >  }
> > >
> > > -static void *armada_gem_dmabuf_no_kmap(struct dma_buf *buf, unsigned long n)
> > > -{
> > > -   return NULL;
> > > -}
> > > -
> > > -static void
> > > -armada_gem_dmabuf_no_kunmap(struct dma_buf *buf, unsigned long n, void *addr)
> > > -{
> > > -}
> > > -
> > >  static int
> > >  armada_gem_dmabuf_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
> > >  {
> > > @@ -481,8 +471,6 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
> > >     .map_dma_buf    = armada_gem_prime_map_dma_buf,
> > >     .unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
> > >     .release        = drm_gem_dmabuf_release,
> > > -   .map            = armada_gem_dmabuf_no_kmap,
> > > -   .unmap          = armada_gem_dmabuf_no_kunmap,
> > >     .mmap           = armada_gem_dmabuf_mmap,
> > >  };
> > >
> > > --
> > > 2.24.0
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

[Daniel Vetter]

On Tue, Nov 26, 2019 at 1:35 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Mon, Nov 25, 2019 at 10:44:43PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 18, 2019 at 11:35:26AM +0100, Daniel Vetter wrote:
> > > It's a dummy anyway.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Russell King <linux@armlinux.org.uk>
> >
> > I merged the entire series except this one and the final patch, sill
> > waiting a bit more for an ack on this perhaps.
>
> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>

Thanks for taking a look.

> I thought drm trees closed around -rc6?

drm.git closes for pull request. But drm-misc is open all the time, so
that committers can push patches whenever the patches are ready,
instead of having to remember that there's something in the queue. The
script used for drm-misc pushes then makes sure that drm-misc-next
doesn't show up in linux-next until after -rc1. So this is all going
into 5.6.
-Daniel

>
> > -Daniel
> >
> > > ---
> > >  drivers/gpu/drm/armada/armada_gem.c | 12 ------------
> > >  1 file changed, 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c
> > > index 93cf8b8bfcff..976685f2939e 100644
> > > --- a/drivers/gpu/drm/armada/armada_gem.c
> > > +++ b/drivers/gpu/drm/armada/armada_gem.c
> > > @@ -461,16 +461,6 @@ static void armada_gem_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
> > >     kfree(sgt);
> > >  }
> > >
> > > -static void *armada_gem_dmabuf_no_kmap(struct dma_buf *buf, unsigned long n)
> > > -{
> > > -   return NULL;
> > > -}
> > > -
> > > -static void
> > > -armada_gem_dmabuf_no_kunmap(struct dma_buf *buf, unsigned long n, void *addr)
> > > -{
> > > -}
> > > -
> > >  static int
> > >  armada_gem_dmabuf_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
> > >  {
> > > @@ -481,8 +471,6 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
> > >     .map_dma_buf    = armada_gem_prime_map_dma_buf,
> > >     .unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
> > >     .release        = drm_gem_dmabuf_release,
> > > -   .map            = armada_gem_dmabuf_no_kmap,
> > > -   .unmap          = armada_gem_dmabuf_no_kunmap,
> > >     .mmap           = armada_gem_dmabuf_mmap,
> > >  };
> > >
> > > --
> > > 2.24.0
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 06/15] drm/i915: Drop dma_buf->k(un)map

[Daniel Vetter]

No in-tree users left.

Aside, I think mock_dmabuf would be a nice addition to drm
mock/selftest helpers (we have some already), with an
EXPORT_SYMBOL_FOR_TESTS_ONLY.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: "Christian König" <christian.koenig@amd.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c    | 36 -------------------
 .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  | 16 ---------
 2 files changed, 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index eaea49d08eb5..372b57ca0efc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -93,40 +93,6 @@ static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
 	i915_gem_object_unpin_map(obj);
 }
 
-static void *i915_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
-{
-	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
-	struct page *page;
-
-	if (page_num >= obj->base.size >> PAGE_SHIFT)
-		return NULL;
-
-	if (!i915_gem_object_has_struct_page(obj))
-		return NULL;
-
-	if (i915_gem_object_pin_pages(obj))
-		return NULL;
-
-	/* Synchronisation is left to the caller (via .begin_cpu_access()) */
-	page = i915_gem_object_get_page(obj, page_num);
-	if (IS_ERR(page))
-		goto err_unpin;
-
-	return kmap(page);
-
-err_unpin:
-	i915_gem_object_unpin_pages(obj);
-	return NULL;
-}
-
-static void i915_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num, void *addr)
-{
-	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
-
-	kunmap(virt_to_page(addr));
-	i915_gem_object_unpin_pages(obj);
-}
-
 static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma)
 {
 	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
@@ -195,8 +161,6 @@ static const struct dma_buf_ops i915_dmabuf_ops =  {
 	.map_dma_buf = i915_gem_map_dma_buf,
 	.unmap_dma_buf = i915_gem_unmap_dma_buf,
 	.release = drm_gem_dmabuf_release,
-	.map = i915_gem_dmabuf_kmap,
-	.unmap = i915_gem_dmabuf_kunmap,
 	.mmap = i915_gem_dmabuf_mmap,
 	.vmap = i915_gem_dmabuf_vmap,
 	.vunmap = i915_gem_dmabuf_vunmap,
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
index b9e059d4328a..9272bef57092 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
@@ -76,20 +76,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
 	vm_unmap_ram(vaddr, mock->npages);
 }
 
-static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
-{
-	struct mock_dmabuf *mock = to_mock(dma_buf);
-
-	return kmap(mock->pages[page_num]);
-}
-
-static void mock_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num, void *addr)
-{
-	struct mock_dmabuf *mock = to_mock(dma_buf);
-
-	return kunmap(mock->pages[page_num]);
-}
-
 static int mock_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma)
 {
 	return -ENODEV;
@@ -99,8 +85,6 @@ static const struct dma_buf_ops mock_dmabuf_ops =  {
 	.map_dma_buf = mock_map_dma_buf,
 	.unmap_dma_buf = mock_unmap_dma_buf,
 	.release = mock_dmabuf_release,
-	.map = mock_dmabuf_kmap,
-	.unmap = mock_dmabuf_kunmap,
 	.mmap = mock_dmabuf_mmap,
 	.vmap = mock_dmabuf_vmap,
 	.vunmap = mock_dmabuf_vunmap,
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 06/15] drm/i915: Drop dma_buf->k(un)map

[Daniel Vetter]

No in-tree users left.

Aside, I think mock_dmabuf would be a nice addition to drm
mock/selftest helpers (we have some already), with an
EXPORT_SYMBOL_FOR_TESTS_ONLY.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: "Christian König" <christian.koenig@amd.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c    | 36 -------------------
 .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  | 16 ---------
 2 files changed, 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index eaea49d08eb5..372b57ca0efc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -93,40 +93,6 @@ static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
 	i915_gem_object_unpin_map(obj);
 }
 
-static void *i915_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
-{
-	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
-	struct page *page;
-
-	if (page_num >= obj->base.size >> PAGE_SHIFT)
-		return NULL;
-
-	if (!i915_gem_object_has_struct_page(obj))
-		return NULL;
-
-	if (i915_gem_object_pin_pages(obj))
-		return NULL;
-
-	/* Synchronisation is left to the caller (via .begin_cpu_access()) */
-	page = i915_gem_object_get_page(obj, page_num);
-	if (IS_ERR(page))
-		goto err_unpin;
-
-	return kmap(page);
-
-err_unpin:
-	i915_gem_object_unpin_pages(obj);
-	return NULL;
-}
-
-static void i915_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num, void *addr)
-{
-	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
-
-	kunmap(virt_to_page(addr));
-	i915_gem_object_unpin_pages(obj);
-}
-
 static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma)
 {
 	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
@@ -195,8 +161,6 @@ static const struct dma_buf_ops i915_dmabuf_ops =  {
 	.map_dma_buf = i915_gem_map_dma_buf,
 	.unmap_dma_buf = i915_gem_unmap_dma_buf,
 	.release = drm_gem_dmabuf_release,
-	.map = i915_gem_dmabuf_kmap,
-	.unmap = i915_gem_dmabuf_kunmap,
 	.mmap = i915_gem_dmabuf_mmap,
 	.vmap = i915_gem_dmabuf_vmap,
 	.vunmap = i915_gem_dmabuf_vunmap,
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
index b9e059d4328a..9272bef57092 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
@@ -76,20 +76,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
 	vm_unmap_ram(vaddr, mock->npages);
 }
 
-static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
-{
-	struct mock_dmabuf *mock = to_mock(dma_buf);
-
-	return kmap(mock->pages[page_num]);
-}
-
-static void mock_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num, void *addr)
-{
-	struct mock_dmabuf *mock = to_mock(dma_buf);
-
-	return kunmap(mock->pages[page_num]);
-}
-
 static int mock_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma)
 {
 	return -ENODEV;
@@ -99,8 +85,6 @@ static const struct dma_buf_ops mock_dmabuf_ops =  {
 	.map_dma_buf = mock_map_dma_buf,
 	.unmap_dma_buf = mock_unmap_dma_buf,
 	.release = mock_dmabuf_release,
-	.map = mock_dmabuf_kmap,
-	.unmap = mock_dmabuf_kunmap,
 	.mmap = mock_dmabuf_mmap,
 	.vmap = mock_dmabuf_vmap,
 	.vunmap = mock_dmabuf_vunmap,
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 06/15] drm/i915: Drop dma_buf->k(un)map

[Daniel Vetter]

No in-tree users left.

Aside, I think mock_dmabuf would be a nice addition to drm
mock/selftest helpers (we have some already), with an
EXPORT_SYMBOL_FOR_TESTS_ONLY.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: "Christian König" <christian.koenig@amd.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c    | 36 -------------------
 .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  | 16 ---------
 2 files changed, 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index eaea49d08eb5..372b57ca0efc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -93,40 +93,6 @@ static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
 	i915_gem_object_unpin_map(obj);
 }
 
-static void *i915_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
-{
-	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
-	struct page *page;
-
-	if (page_num >= obj->base.size >> PAGE_SHIFT)
-		return NULL;
-
-	if (!i915_gem_object_has_struct_page(obj))
-		return NULL;
-
-	if (i915_gem_object_pin_pages(obj))
-		return NULL;
-
-	/* Synchronisation is left to the caller (via .begin_cpu_access()) */
-	page = i915_gem_object_get_page(obj, page_num);
-	if (IS_ERR(page))
-		goto err_unpin;
-
-	return kmap(page);
-
-err_unpin:
-	i915_gem_object_unpin_pages(obj);
-	return NULL;
-}
-
-static void i915_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num, void *addr)
-{
-	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
-
-	kunmap(virt_to_page(addr));
-	i915_gem_object_unpin_pages(obj);
-}
-
 static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma)
 {
 	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
@@ -195,8 +161,6 @@ static const struct dma_buf_ops i915_dmabuf_ops =  {
 	.map_dma_buf = i915_gem_map_dma_buf,
 	.unmap_dma_buf = i915_gem_unmap_dma_buf,
 	.release = drm_gem_dmabuf_release,
-	.map = i915_gem_dmabuf_kmap,
-	.unmap = i915_gem_dmabuf_kunmap,
 	.mmap = i915_gem_dmabuf_mmap,
 	.vmap = i915_gem_dmabuf_vmap,
 	.vunmap = i915_gem_dmabuf_vunmap,
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
index b9e059d4328a..9272bef57092 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
@@ -76,20 +76,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
 	vm_unmap_ram(vaddr, mock->npages);
 }
 
-static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
-{
-	struct mock_dmabuf *mock = to_mock(dma_buf);
-
-	return kmap(mock->pages[page_num]);
-}
-
-static void mock_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num, void *addr)
-{
-	struct mock_dmabuf *mock = to_mock(dma_buf);
-
-	return kunmap(mock->pages[page_num]);
-}
-
 static int mock_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma)
 {
 	return -ENODEV;
@@ -99,8 +85,6 @@ static const struct dma_buf_ops mock_dmabuf_ops =  {
 	.map_dma_buf = mock_map_dma_buf,
 	.unmap_dma_buf = mock_unmap_dma_buf,
 	.release = mock_dmabuf_release,
-	.map = mock_dmabuf_kmap,
-	.unmap = mock_dmabuf_kunmap,
 	.mmap = mock_dmabuf_mmap,
 	.vmap = mock_dmabuf_vmap,
 	.vunmap = mock_dmabuf_vunmap,
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/15] drm/i915: Drop dma_buf->k(un)map

[Christian König]

Am 18.11.19 um 11:35 schrieb Daniel Vetter:
> No in-tree users left.

Good to know, thanks.

>
> Aside, I think mock_dmabuf would be a nice addition to drm
> mock/selftest helpers (we have some already), with an
> EXPORT_SYMBOL_FOR_TESTS_ONLY.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: "Christian König" <christian.koenig@amd.com>

Acked-by: Christian König <christian.koenig@amd.com>

> ---
>   drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c    | 36 -------------------
>   .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  | 16 ---------
>   2 files changed, 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index eaea49d08eb5..372b57ca0efc 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -93,40 +93,6 @@ static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
>   	i915_gem_object_unpin_map(obj);
>   }
>   
> -static void *i915_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
> -{
> -	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> -	struct page *page;
> -
> -	if (page_num >= obj->base.size >> PAGE_SHIFT)
> -		return NULL;
> -
> -	if (!i915_gem_object_has_struct_page(obj))
> -		return NULL;
> -
> -	if (i915_gem_object_pin_pages(obj))
> -		return NULL;
> -
> -	/* Synchronisation is left to the caller (via .begin_cpu_access()) */
> -	page = i915_gem_object_get_page(obj, page_num);
> -	if (IS_ERR(page))
> -		goto err_unpin;
> -
> -	return kmap(page);
> -
> -err_unpin:
> -	i915_gem_object_unpin_pages(obj);
> -	return NULL;
> -}
> -
> -static void i915_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num, void *addr)
> -{
> -	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> -
> -	kunmap(virt_to_page(addr));
> -	i915_gem_object_unpin_pages(obj);
> -}
> -
>   static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma)
>   {
>   	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> @@ -195,8 +161,6 @@ static const struct dma_buf_ops i915_dmabuf_ops =  {
>   	.map_dma_buf = i915_gem_map_dma_buf,
>   	.unmap_dma_buf = i915_gem_unmap_dma_buf,
>   	.release = drm_gem_dmabuf_release,
> -	.map = i915_gem_dmabuf_kmap,
> -	.unmap = i915_gem_dmabuf_kunmap,
>   	.mmap = i915_gem_dmabuf_mmap,
>   	.vmap = i915_gem_dmabuf_vmap,
>   	.vunmap = i915_gem_dmabuf_vunmap,
> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> index b9e059d4328a..9272bef57092 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> @@ -76,20 +76,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
>   	vm_unmap_ram(vaddr, mock->npages);
>   }
>   
> -static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
> -{
> -	struct mock_dmabuf *mock = to_mock(dma_buf);
> -
> -	return kmap(mock->pages[page_num]);
> -}
> -
> -static void mock_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num, void *addr)
> -{
> -	struct mock_dmabuf *mock = to_mock(dma_buf);
> -
> -	return kunmap(mock->pages[page_num]);
> -}
> -
>   static int mock_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma)
>   {
>   	return -ENODEV;
> @@ -99,8 +85,6 @@ static const struct dma_buf_ops mock_dmabuf_ops =  {
>   	.map_dma_buf = mock_map_dma_buf,
>   	.unmap_dma_buf = mock_unmap_dma_buf,
>   	.release = mock_dmabuf_release,
> -	.map = mock_dmabuf_kmap,
> -	.unmap = mock_dmabuf_kunmap,
>   	.mmap = mock_dmabuf_mmap,
>   	.vmap = mock_dmabuf_vmap,
>   	.vunmap = mock_dmabuf_vunmap,

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/15] drm/i915: Drop dma_buf->k(un)map

[Christian König]

Am 18.11.19 um 11:35 schrieb Daniel Vetter:
> No in-tree users left.

Good to know, thanks.

>
> Aside, I think mock_dmabuf would be a nice addition to drm
> mock/selftest helpers (we have some already), with an
> EXPORT_SYMBOL_FOR_TESTS_ONLY.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: "Christian König" <christian.koenig@amd.com>

Acked-by: Christian König <christian.koenig@amd.com>

> ---
>   drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c    | 36 -------------------
>   .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  | 16 ---------
>   2 files changed, 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index eaea49d08eb5..372b57ca0efc 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -93,40 +93,6 @@ static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
>   	i915_gem_object_unpin_map(obj);
>   }
>   
> -static void *i915_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
> -{
> -	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> -	struct page *page;
> -
> -	if (page_num >= obj->base.size >> PAGE_SHIFT)
> -		return NULL;
> -
> -	if (!i915_gem_object_has_struct_page(obj))
> -		return NULL;
> -
> -	if (i915_gem_object_pin_pages(obj))
> -		return NULL;
> -
> -	/* Synchronisation is left to the caller (via .begin_cpu_access()) */
> -	page = i915_gem_object_get_page(obj, page_num);
> -	if (IS_ERR(page))
> -		goto err_unpin;
> -
> -	return kmap(page);
> -
> -err_unpin:
> -	i915_gem_object_unpin_pages(obj);
> -	return NULL;
> -}
> -
> -static void i915_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num, void *addr)
> -{
> -	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> -
> -	kunmap(virt_to_page(addr));
> -	i915_gem_object_unpin_pages(obj);
> -}
> -
>   static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma)
>   {
>   	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> @@ -195,8 +161,6 @@ static const struct dma_buf_ops i915_dmabuf_ops =  {
>   	.map_dma_buf = i915_gem_map_dma_buf,
>   	.unmap_dma_buf = i915_gem_unmap_dma_buf,
>   	.release = drm_gem_dmabuf_release,
> -	.map = i915_gem_dmabuf_kmap,
> -	.unmap = i915_gem_dmabuf_kunmap,
>   	.mmap = i915_gem_dmabuf_mmap,
>   	.vmap = i915_gem_dmabuf_vmap,
>   	.vunmap = i915_gem_dmabuf_vunmap,
> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> index b9e059d4328a..9272bef57092 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> @@ -76,20 +76,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
>   	vm_unmap_ram(vaddr, mock->npages);
>   }
>   
> -static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
> -{
> -	struct mock_dmabuf *mock = to_mock(dma_buf);
> -
> -	return kmap(mock->pages[page_num]);
> -}
> -
> -static void mock_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num, void *addr)
> -{
> -	struct mock_dmabuf *mock = to_mock(dma_buf);
> -
> -	return kunmap(mock->pages[page_num]);
> -}
> -
>   static int mock_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma)
>   {
>   	return -ENODEV;
> @@ -99,8 +85,6 @@ static const struct dma_buf_ops mock_dmabuf_ops =  {
>   	.map_dma_buf = mock_map_dma_buf,
>   	.unmap_dma_buf = mock_unmap_dma_buf,
>   	.release = mock_dmabuf_release,
> -	.map = mock_dmabuf_kmap,
> -	.unmap = mock_dmabuf_kunmap,
>   	.mmap = mock_dmabuf_mmap,
>   	.vmap = mock_dmabuf_vmap,
>   	.vunmap = mock_dmabuf_vunmap,

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 06/15] drm/i915: Drop dma_buf->k(un)map

[Christian König]

Am 18.11.19 um 11:35 schrieb Daniel Vetter:
> No in-tree users left.

Good to know, thanks.

>
> Aside, I think mock_dmabuf would be a nice addition to drm
> mock/selftest helpers (we have some already), with an
> EXPORT_SYMBOL_FOR_TESTS_ONLY.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: "Christian König" <christian.koenig@amd.com>

Acked-by: Christian König <christian.koenig@amd.com>

> ---
>   drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c    | 36 -------------------
>   .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  | 16 ---------
>   2 files changed, 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index eaea49d08eb5..372b57ca0efc 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -93,40 +93,6 @@ static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
>   	i915_gem_object_unpin_map(obj);
>   }
>   
> -static void *i915_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
> -{
> -	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> -	struct page *page;
> -
> -	if (page_num >= obj->base.size >> PAGE_SHIFT)
> -		return NULL;
> -
> -	if (!i915_gem_object_has_struct_page(obj))
> -		return NULL;
> -
> -	if (i915_gem_object_pin_pages(obj))
> -		return NULL;
> -
> -	/* Synchronisation is left to the caller (via .begin_cpu_access()) */
> -	page = i915_gem_object_get_page(obj, page_num);
> -	if (IS_ERR(page))
> -		goto err_unpin;
> -
> -	return kmap(page);
> -
> -err_unpin:
> -	i915_gem_object_unpin_pages(obj);
> -	return NULL;
> -}
> -
> -static void i915_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num, void *addr)
> -{
> -	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> -
> -	kunmap(virt_to_page(addr));
> -	i915_gem_object_unpin_pages(obj);
> -}
> -
>   static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma)
>   {
>   	struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> @@ -195,8 +161,6 @@ static const struct dma_buf_ops i915_dmabuf_ops =  {
>   	.map_dma_buf = i915_gem_map_dma_buf,
>   	.unmap_dma_buf = i915_gem_unmap_dma_buf,
>   	.release = drm_gem_dmabuf_release,
> -	.map = i915_gem_dmabuf_kmap,
> -	.unmap = i915_gem_dmabuf_kunmap,
>   	.mmap = i915_gem_dmabuf_mmap,
>   	.vmap = i915_gem_dmabuf_vmap,
>   	.vunmap = i915_gem_dmabuf_vunmap,
> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> index b9e059d4328a..9272bef57092 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> @@ -76,20 +76,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
>   	vm_unmap_ram(vaddr, mock->npages);
>   }
>   
> -static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
> -{
> -	struct mock_dmabuf *mock = to_mock(dma_buf);
> -
> -	return kmap(mock->pages[page_num]);
> -}
> -
> -static void mock_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num, void *addr)
> -{
> -	struct mock_dmabuf *mock = to_mock(dma_buf);
> -
> -	return kunmap(mock->pages[page_num]);
> -}
> -
>   static int mock_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma)
>   {
>   	return -ENODEV;
> @@ -99,8 +85,6 @@ static const struct dma_buf_ops mock_dmabuf_ops =  {
>   	.map_dma_buf = mock_map_dma_buf,
>   	.unmap_dma_buf = mock_unmap_dma_buf,
>   	.release = mock_dmabuf_release,
> -	.map = mock_dmabuf_kmap,
> -	.unmap = mock_dmabuf_kunmap,
>   	.mmap = mock_dmabuf_mmap,
>   	.vmap = mock_dmabuf_vmap,
>   	.vunmap = mock_dmabuf_vunmap,

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/15] drm/i915: Drop dma_buf->k(un)map

[Chris Wilson]

Quoting Daniel Vetter (2019-11-18 10:35:27)
> No in-tree users left.

Fair enough then,
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

> Aside, I think mock_dmabuf would be a nice addition to drm
> mock/selftest helpers (we have some already), with an
> EXPORT_SYMBOL_FOR_TESTS_ONLY.

We've also started on some dmabuf selftests, so maybe we can go further
and make mock objects and EXPORT_SYMBOL_FOR_TESTS_ONLY global. And of
course, make sure the efforts align with kunit...
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/15] drm/i915: Drop dma_buf->k(un)map

[Chris Wilson]

Quoting Daniel Vetter (2019-11-18 10:35:27)
> No in-tree users left.

Fair enough then,
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

> Aside, I think mock_dmabuf would be a nice addition to drm
> mock/selftest helpers (we have some already), with an
> EXPORT_SYMBOL_FOR_TESTS_ONLY.

We've also started on some dmabuf selftests, so maybe we can go further
and make mock objects and EXPORT_SYMBOL_FOR_TESTS_ONLY global. And of
course, make sure the efforts align with kunit...
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 06/15] drm/i915: Drop dma_buf->k(un)map

[Chris Wilson]

Quoting Daniel Vetter (2019-11-18 10:35:27)
> No in-tree users left.

Fair enough then,
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

> Aside, I think mock_dmabuf would be a nice addition to drm
> mock/selftest helpers (we have some already), with an
> EXPORT_SYMBOL_FOR_TESTS_ONLY.

We've also started on some dmabuf selftests, so maybe we can go further
and make mock objects and EXPORT_SYMBOL_FOR_TESTS_ONLY global. And of
course, make sure the efforts align with kunit...
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/15] drm/omapdrm: Drop dma_buf->k(un)map

[Daniel Vetter]

No in-tree users left.

Note that this is one of the few (if only) implementations of dma-buf
that provided a kmap, but not a vmap implemenation. Given that the
only real user (in-tree at least) of kmap was tegra, and it's
impossible to buy a chip with tegra host1x and ompadrm on the same
SoC, there's no problem here.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 21 ---------------------
 1 file changed, 21 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 7344bb61936c..b319fe7f2371 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -85,25 +85,6 @@ static int omap_gem_dmabuf_end_cpu_access(struct dma_buf *buffer,
 	return 0;
 }
 
-static void *omap_gem_dmabuf_kmap(struct dma_buf *buffer,
-		unsigned long page_num)
-{
-	struct drm_gem_object *obj = buffer->priv;
-	struct page **pages;
-	omap_gem_get_pages(obj, &pages, false);
-	omap_gem_cpu_sync_page(obj, page_num);
-	return kmap(pages[page_num]);
-}
-
-static void omap_gem_dmabuf_kunmap(struct dma_buf *buffer,
-		unsigned long page_num, void *addr)
-{
-	struct drm_gem_object *obj = buffer->priv;
-	struct page **pages;
-	omap_gem_get_pages(obj, &pages, false);
-	kunmap(pages[page_num]);
-}
-
 static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
 		struct vm_area_struct *vma)
 {
@@ -123,8 +104,6 @@ static const struct dma_buf_ops omap_dmabuf_ops = {
 	.release = drm_gem_dmabuf_release,
 	.begin_cpu_access = omap_gem_dmabuf_begin_cpu_access,
 	.end_cpu_access = omap_gem_dmabuf_end_cpu_access,
-	.map = omap_gem_dmabuf_kmap,
-	.unmap = omap_gem_dmabuf_kunmap,
 	.mmap = omap_gem_dmabuf_mmap,
 };
 
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH 07/15] drm/omapdrm: Drop dma_buf->k(un)map

[Daniel Vetter]

No in-tree users left.

Note that this is one of the few (if only) implementations of dma-buf
that provided a kmap, but not a vmap implemenation. Given that the
only real user (in-tree at least) of kmap was tegra, and it's
impossible to buy a chip with tegra host1x and ompadrm on the same
SoC, there's no problem here.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 21 ---------------------
 1 file changed, 21 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 7344bb61936c..b319fe7f2371 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -85,25 +85,6 @@ static int omap_gem_dmabuf_end_cpu_access(struct dma_buf *buffer,
 	return 0;
 }
 
-static void *omap_gem_dmabuf_kmap(struct dma_buf *buffer,
-		unsigned long page_num)
-{
-	struct drm_gem_object *obj = buffer->priv;
-	struct page **pages;
-	omap_gem_get_pages(obj, &pages, false);
-	omap_gem_cpu_sync_page(obj, page_num);
-	return kmap(pages[page_num]);
-}
-
-static void omap_gem_dmabuf_kunmap(struct dma_buf *buffer,
-		unsigned long page_num, void *addr)
-{
-	struct drm_gem_object *obj = buffer->priv;
-	struct page **pages;
-	omap_gem_get_pages(obj, &pages, false);
-	kunmap(pages[page_num]);
-}
-
 static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
 		struct vm_area_struct *vma)
 {
@@ -123,8 +104,6 @@ static const struct dma_buf_ops omap_dmabuf_ops = {
 	.release = drm_gem_dmabuf_release,
 	.begin_cpu_access = omap_gem_dmabuf_begin_cpu_access,
 	.end_cpu_access = omap_gem_dmabuf_end_cpu_access,
-	.map = omap_gem_dmabuf_kmap,
-	.unmap = omap_gem_dmabuf_kunmap,
 	.mmap = omap_gem_dmabuf_mmap,
 };
 
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 07/15] drm/omapdrm: Drop dma_buf->k(un)map

[Tomi Valkeinen]

On 18/11/2019 12:35, Daniel Vetter wrote:
> No in-tree users left.
> 
> Note that this is one of the few (if only) implementations of dma-buf
> that provided a kmap, but not a vmap implemenation. Given that the
> only real user (in-tree at least) of kmap was tegra, and it's
> impossible to buy a chip with tegra host1x and ompadrm on the same
> SoC, there's no problem here.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>   drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 21 ---------------------
>   1 file changed, 21 deletions(-)

We're using dma_buf_kmap in TI kernel, in some rpmsg code:

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/rpmsg/rpmsg_rpc_dmabuf.c?h=ti-linux-4.19.y

I'm not familiar with the code, Cc'ing Suman.

In any case, if no one else needs dmabuf kmap, I would guess that TI doesn't need it either... Presuming that's the case, for the omapdrm part:

Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Also, don't downplay the 32bit kernels, there are still plenty of users for arm32, and will be for a long time =)

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/15] drm/omapdrm: Drop dma_buf->k(un)map

[Tomi Valkeinen]

On 18/11/2019 12:35, Daniel Vetter wrote:
> No in-tree users left.
> 
> Note that this is one of the few (if only) implementations of dma-buf
> that provided a kmap, but not a vmap implemenation. Given that the
> only real user (in-tree at least) of kmap was tegra, and it's
> impossible to buy a chip with tegra host1x and ompadrm on the same
> SoC, there's no problem here.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>   drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 21 ---------------------
>   1 file changed, 21 deletions(-)

We're using dma_buf_kmap in TI kernel, in some rpmsg code:

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/rpmsg/rpmsg_rpc_dmabuf.c?h=ti-linux-4.19.y

I'm not familiar with the code, Cc'ing Suman.

In any case, if no one else needs dmabuf kmap, I would guess that TI doesn't need it either... Presuming that's the case, for the omapdrm part:

Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Also, don't downplay the 32bit kernels, there are still plenty of users for arm32, and will be for a long time =)

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 07/15] drm/omapdrm: Drop dma_buf->k(un)map

[Tomi Valkeinen]

On 18/11/2019 12:35, Daniel Vetter wrote:
> No in-tree users left.
> 
> Note that this is one of the few (if only) implementations of dma-buf
> that provided a kmap, but not a vmap implemenation. Given that the
> only real user (in-tree at least) of kmap was tegra, and it's
> impossible to buy a chip with tegra host1x and ompadrm on the same
> SoC, there's no problem here.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>   drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 21 ---------------------
>   1 file changed, 21 deletions(-)

We're using dma_buf_kmap in TI kernel, in some rpmsg code:

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/rpmsg/rpmsg_rpc_dmabuf.c?h=ti-linux-4.19.y

I'm not familiar with the code, Cc'ing Suman.

In any case, if no one else needs dmabuf kmap, I would guess that TI doesn't need it either... Presuming that's the case, for the omapdrm part:

Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Also, don't downplay the 32bit kernels, there are still plenty of users for arm32, and will be for a long time =)

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/15] drm/tegra: Remove dma_buf->k(un)map

[Daniel Vetter]

No in-tree users left.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: linux-tegra@vger.kernel.org
---
 drivers/gpu/drm/tegra/gem.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 662cb7c87ef5..84bb29070536 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -585,16 +585,6 @@ static int tegra_gem_prime_end_cpu_access(struct dma_buf *buf,
 	return 0;
 }
 
-static void *tegra_gem_prime_kmap(struct dma_buf *buf, unsigned long page)
-{
-	return NULL;
-}
-
-static void tegra_gem_prime_kunmap(struct dma_buf *buf, unsigned long page,
-				   void *addr)
-{
-}
-
 static int tegra_gem_prime_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
 {
 	struct drm_gem_object *gem = buf->priv;
@@ -625,8 +615,6 @@ static const struct dma_buf_ops tegra_gem_prime_dmabuf_ops = {
 	.release = tegra_gem_prime_release,
 	.begin_cpu_access = tegra_gem_prime_begin_cpu_access,
 	.end_cpu_access = tegra_gem_prime_end_cpu_access,
-	.map = tegra_gem_prime_kmap,
-	.unmap = tegra_gem_prime_kunmap,
 	.mmap = tegra_gem_prime_mmap,
 	.vmap = tegra_gem_prime_vmap,
 	.vunmap = tegra_gem_prime_vunmap,
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 08/15] drm/tegra: Remove dma_buf->k(un)map

[Daniel Vetter]

No in-tree users left.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: linux-tegra@vger.kernel.org
---
 drivers/gpu/drm/tegra/gem.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 662cb7c87ef5..84bb29070536 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -585,16 +585,6 @@ static int tegra_gem_prime_end_cpu_access(struct dma_buf *buf,
 	return 0;
 }
 
-static void *tegra_gem_prime_kmap(struct dma_buf *buf, unsigned long page)
-{
-	return NULL;
-}
-
-static void tegra_gem_prime_kunmap(struct dma_buf *buf, unsigned long page,
-				   void *addr)
-{
-}
-
 static int tegra_gem_prime_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
 {
 	struct drm_gem_object *gem = buf->priv;
@@ -625,8 +615,6 @@ static const struct dma_buf_ops tegra_gem_prime_dmabuf_ops = {
 	.release = tegra_gem_prime_release,
 	.begin_cpu_access = tegra_gem_prime_begin_cpu_access,
 	.end_cpu_access = tegra_gem_prime_end_cpu_access,
-	.map = tegra_gem_prime_kmap,
-	.unmap = tegra_gem_prime_kunmap,
 	.mmap = tegra_gem_prime_mmap,
 	.vmap = tegra_gem_prime_vmap,
 	.vunmap = tegra_gem_prime_vunmap,
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 08/15] drm/tegra: Remove dma_buf->k(un)map

[Daniel Vetter]

No in-tree users left.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: linux-tegra@vger.kernel.org
---
 drivers/gpu/drm/tegra/gem.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 662cb7c87ef5..84bb29070536 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -585,16 +585,6 @@ static int tegra_gem_prime_end_cpu_access(struct dma_buf *buf,
 	return 0;
 }
 
-static void *tegra_gem_prime_kmap(struct dma_buf *buf, unsigned long page)
-{
-	return NULL;
-}
-
-static void tegra_gem_prime_kunmap(struct dma_buf *buf, unsigned long page,
-				   void *addr)
-{
-}
-
 static int tegra_gem_prime_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
 {
 	struct drm_gem_object *gem = buf->priv;
@@ -625,8 +615,6 @@ static const struct dma_buf_ops tegra_gem_prime_dmabuf_ops = {
 	.release = tegra_gem_prime_release,
 	.begin_cpu_access = tegra_gem_prime_begin_cpu_access,
 	.end_cpu_access = tegra_gem_prime_end_cpu_access,
-	.map = tegra_gem_prime_kmap,
-	.unmap = tegra_gem_prime_kunmap,
 	.mmap = tegra_gem_prime_mmap,
 	.vmap = tegra_gem_prime_vmap,
 	.vunmap = tegra_gem_prime_vunmap,
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/15] drm/tegra: Remove dma_buf->k(un)map

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 676 bytes --]

On Mon, Nov 18, 2019 at 11:35:29AM +0100, Daniel Vetter wrote:
> No in-tree users left.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Jonathan Hunter <jonathanh@nvidia.com>
> Cc: linux-tegra@vger.kernel.org
> ---
>  drivers/gpu/drm/tegra/gem.c | 12 ------------
>  1 file changed, 12 deletions(-)

Same as before, I don't see any regressions when running some of the
grate tests, and there's obviously no longer any reason to keep these
functions around given that they are no longer used, so:

Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 08/15] drm/tegra: Remove dma_buf->k(un)map

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 676 bytes --]

On Mon, Nov 18, 2019 at 11:35:29AM +0100, Daniel Vetter wrote:
> No in-tree users left.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Jonathan Hunter <jonathanh@nvidia.com>
> Cc: linux-tegra@vger.kernel.org
> ---
>  drivers/gpu/drm/tegra/gem.c | 12 ------------
>  1 file changed, 12 deletions(-)

Same as before, I don't see any regressions when running some of the
grate tests, and there's obviously no longer any reason to keep these
functions around given that they are no longer used, so:

Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 09/15] dma-buf: Drop dma_buf_k(un)map

[Daniel Vetter]

It's unused.

10 years ago, back when 32bit was still fairly common and trying to
not exhaust vmalloc space sounded like a worthwhile goal, adding these
to dma_buf made sense.

Reality is that they simply never caught on, and nowadays everyone who
needs plenty of buffers will run in 64bit mode anyway.

Also update the docs in this area to adjust them to reality.

The actual hooks in dma_buf_ops will be removed once all the
implementations are gone.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/dma-buf/dma-buf.c | 63 ++-------------------------------------
 include/linux/dma-buf.h   |  2 --
 2 files changed, 3 insertions(+), 62 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d377b4ca66bf..97988ce1d2dc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -880,29 +880,9 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
  *   with calls to dma_buf_begin_cpu_access() and dma_buf_end_cpu_access()
  *   access.
  *
- *   To support dma_buf objects residing in highmem cpu access is page-based
- *   using an api similar to kmap. Accessing a dma_buf is done in aligned chunks
- *   of PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which
- *   returns a pointer in kernel virtual address space. Afterwards the chunk
- *   needs to be unmapped again. There is no limit on how often a given chunk
- *   can be mapped and unmapped, i.e. the importer does not need to call
- *   begin_cpu_access again before mapping the same chunk again.
- *
- *   Interfaces::
- *      void \*dma_buf_kmap(struct dma_buf \*, unsigned long);
- *      void dma_buf_kunmap(struct dma_buf \*, unsigned long, void \*);
- *
- *   Implementing the functions is optional for exporters and for importers all
- *   the restrictions of using kmap apply.
- *
- *   dma_buf kmap calls outside of the range specified in begin_cpu_access are
- *   undefined. If the range is not PAGE_SIZE aligned, kmap needs to succeed on
- *   the partial chunks at the beginning and end but may return stale or bogus
- *   data outside of the range (in these partial chunks).
- *
- *   For some cases the overhead of kmap can be too high, a vmap interface
- *   is introduced. This interface should be used very carefully, as vmalloc
- *   space is a limited resources on many architectures.
+ *   Since for most kernel internal dma-buf accesses need the entire buffer, a
+ *   vmap interface is introduced. Note that on very old 32-bit architectures
+ *   vmalloc space might be limited and result in vmap calls failing.
  *
  *   Interfaces::
  *      void \*dma_buf_vmap(struct dma_buf \*dmabuf)
@@ -1052,43 +1032,6 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
 }
 EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
 
-/**
- * dma_buf_kmap - Map a page of the buffer object into kernel address space. The
- * same restrictions as for kmap and friends apply.
- * @dmabuf:	[in]	buffer to map page from.
- * @page_num:	[in]	page in PAGE_SIZE units to map.
- *
- * This call must always succeed, any necessary preparations that might fail
- * need to be done in begin_cpu_access.
- */
-void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num)
-{
-	WARN_ON(!dmabuf);
-
-	if (!dmabuf->ops->map)
-		return NULL;
-	return dmabuf->ops->map(dmabuf, page_num);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kmap);
-
-/**
- * dma_buf_kunmap - Unmap a page obtained by dma_buf_kmap.
- * @dmabuf:	[in]	buffer to unmap page from.
- * @page_num:	[in]	page in PAGE_SIZE units to unmap.
- * @vaddr:	[in]	kernel space pointer obtained from dma_buf_kmap.
- *
- * This call must always succeed.
- */
-void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num,
-		    void *vaddr)
-{
-	WARN_ON(!dmabuf);
-
-	if (dmabuf->ops->unmap)
-		dmabuf->ops->unmap(dmabuf, page_num, vaddr);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kunmap);
-
 
 /**
  * dma_buf_mmap - Setup up a userspace mmap with the given vma
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index af73f835c51c..7feb9c3805ae 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -464,8 +464,6 @@ int dma_buf_begin_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(struct dma_buf *, unsigned long);
-void dma_buf_kunmap(struct dma_buf *, unsigned long, void *);
 
 int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
 		 unsigned long);
-- 
2.24.0

[Intel-gfx] [PATCH 09/15] dma-buf: Drop dma_buf_k(un)map

[Daniel Vetter]

It's unused.

10 years ago, back when 32bit was still fairly common and trying to
not exhaust vmalloc space sounded like a worthwhile goal, adding these
to dma_buf made sense.

Reality is that they simply never caught on, and nowadays everyone who
needs plenty of buffers will run in 64bit mode anyway.

Also update the docs in this area to adjust them to reality.

The actual hooks in dma_buf_ops will be removed once all the
implementations are gone.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/dma-buf/dma-buf.c | 63 ++-------------------------------------
 include/linux/dma-buf.h   |  2 --
 2 files changed, 3 insertions(+), 62 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d377b4ca66bf..97988ce1d2dc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -880,29 +880,9 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
  *   with calls to dma_buf_begin_cpu_access() and dma_buf_end_cpu_access()
  *   access.
  *
- *   To support dma_buf objects residing in highmem cpu access is page-based
- *   using an api similar to kmap. Accessing a dma_buf is done in aligned chunks
- *   of PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which
- *   returns a pointer in kernel virtual address space. Afterwards the chunk
- *   needs to be unmapped again. There is no limit on how often a given chunk
- *   can be mapped and unmapped, i.e. the importer does not need to call
- *   begin_cpu_access again before mapping the same chunk again.
- *
- *   Interfaces::
- *      void \*dma_buf_kmap(struct dma_buf \*, unsigned long);
- *      void dma_buf_kunmap(struct dma_buf \*, unsigned long, void \*);
- *
- *   Implementing the functions is optional for exporters and for importers all
- *   the restrictions of using kmap apply.
- *
- *   dma_buf kmap calls outside of the range specified in begin_cpu_access are
- *   undefined. If the range is not PAGE_SIZE aligned, kmap needs to succeed on
- *   the partial chunks at the beginning and end but may return stale or bogus
- *   data outside of the range (in these partial chunks).
- *
- *   For some cases the overhead of kmap can be too high, a vmap interface
- *   is introduced. This interface should be used very carefully, as vmalloc
- *   space is a limited resources on many architectures.
+ *   Since for most kernel internal dma-buf accesses need the entire buffer, a
+ *   vmap interface is introduced. Note that on very old 32-bit architectures
+ *   vmalloc space might be limited and result in vmap calls failing.
  *
  *   Interfaces::
  *      void \*dma_buf_vmap(struct dma_buf \*dmabuf)
@@ -1052,43 +1032,6 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
 }
 EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
 
-/**
- * dma_buf_kmap - Map a page of the buffer object into kernel address space. The
- * same restrictions as for kmap and friends apply.
- * @dmabuf:	[in]	buffer to map page from.
- * @page_num:	[in]	page in PAGE_SIZE units to map.
- *
- * This call must always succeed, any necessary preparations that might fail
- * need to be done in begin_cpu_access.
- */
-void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num)
-{
-	WARN_ON(!dmabuf);
-
-	if (!dmabuf->ops->map)
-		return NULL;
-	return dmabuf->ops->map(dmabuf, page_num);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kmap);
-
-/**
- * dma_buf_kunmap - Unmap a page obtained by dma_buf_kmap.
- * @dmabuf:	[in]	buffer to unmap page from.
- * @page_num:	[in]	page in PAGE_SIZE units to unmap.
- * @vaddr:	[in]	kernel space pointer obtained from dma_buf_kmap.
- *
- * This call must always succeed.
- */
-void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num,
-		    void *vaddr)
-{
-	WARN_ON(!dmabuf);
-
-	if (dmabuf->ops->unmap)
-		dmabuf->ops->unmap(dmabuf, page_num, vaddr);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kunmap);
-
 
 /**
  * dma_buf_mmap - Setup up a userspace mmap with the given vma
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index af73f835c51c..7feb9c3805ae 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -464,8 +464,6 @@ int dma_buf_begin_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(struct dma_buf *, unsigned long);
-void dma_buf_kunmap(struct dma_buf *, unsigned long, void *);
 
 int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
 		 unsigned long);
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 09/15] dma-buf: Drop dma_buf_k(un)map

[Daniel Vetter]

It's unused.

10 years ago, back when 32bit was still fairly common and trying to
not exhaust vmalloc space sounded like a worthwhile goal, adding these
to dma_buf made sense.

Reality is that they simply never caught on, and nowadays everyone who
needs plenty of buffers will run in 64bit mode anyway.

Also update the docs in this area to adjust them to reality.

The actual hooks in dma_buf_ops will be removed once all the
implementations are gone.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/dma-buf/dma-buf.c | 63 ++-------------------------------------
 include/linux/dma-buf.h   |  2 --
 2 files changed, 3 insertions(+), 62 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d377b4ca66bf..97988ce1d2dc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -880,29 +880,9 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
  *   with calls to dma_buf_begin_cpu_access() and dma_buf_end_cpu_access()
  *   access.
  *
- *   To support dma_buf objects residing in highmem cpu access is page-based
- *   using an api similar to kmap. Accessing a dma_buf is done in aligned chunks
- *   of PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which
- *   returns a pointer in kernel virtual address space. Afterwards the chunk
- *   needs to be unmapped again. There is no limit on how often a given chunk
- *   can be mapped and unmapped, i.e. the importer does not need to call
- *   begin_cpu_access again before mapping the same chunk again.
- *
- *   Interfaces::
- *      void \*dma_buf_kmap(struct dma_buf \*, unsigned long);
- *      void dma_buf_kunmap(struct dma_buf \*, unsigned long, void \*);
- *
- *   Implementing the functions is optional for exporters and for importers all
- *   the restrictions of using kmap apply.
- *
- *   dma_buf kmap calls outside of the range specified in begin_cpu_access are
- *   undefined. If the range is not PAGE_SIZE aligned, kmap needs to succeed on
- *   the partial chunks at the beginning and end but may return stale or bogus
- *   data outside of the range (in these partial chunks).
- *
- *   For some cases the overhead of kmap can be too high, a vmap interface
- *   is introduced. This interface should be used very carefully, as vmalloc
- *   space is a limited resources on many architectures.
+ *   Since for most kernel internal dma-buf accesses need the entire buffer, a
+ *   vmap interface is introduced. Note that on very old 32-bit architectures
+ *   vmalloc space might be limited and result in vmap calls failing.
  *
  *   Interfaces::
  *      void \*dma_buf_vmap(struct dma_buf \*dmabuf)
@@ -1052,43 +1032,6 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
 }
 EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
 
-/**
- * dma_buf_kmap - Map a page of the buffer object into kernel address space. The
- * same restrictions as for kmap and friends apply.
- * @dmabuf:	[in]	buffer to map page from.
- * @page_num:	[in]	page in PAGE_SIZE units to map.
- *
- * This call must always succeed, any necessary preparations that might fail
- * need to be done in begin_cpu_access.
- */
-void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num)
-{
-	WARN_ON(!dmabuf);
-
-	if (!dmabuf->ops->map)
-		return NULL;
-	return dmabuf->ops->map(dmabuf, page_num);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kmap);
-
-/**
- * dma_buf_kunmap - Unmap a page obtained by dma_buf_kmap.
- * @dmabuf:	[in]	buffer to unmap page from.
- * @page_num:	[in]	page in PAGE_SIZE units to unmap.
- * @vaddr:	[in]	kernel space pointer obtained from dma_buf_kmap.
- *
- * This call must always succeed.
- */
-void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num,
-		    void *vaddr)
-{
-	WARN_ON(!dmabuf);
-
-	if (dmabuf->ops->unmap)
-		dmabuf->ops->unmap(dmabuf, page_num, vaddr);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kunmap);
-
 
 /**
  * dma_buf_mmap - Setup up a userspace mmap with the given vma
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index af73f835c51c..7feb9c3805ae 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -464,8 +464,6 @@ int dma_buf_begin_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(struct dma_buf *, unsigned long);
-void dma_buf_kunmap(struct dma_buf *, unsigned long, void *);
 
 int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
 		 unsigned long);
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/15] dma-buf: Drop dma_buf_k(un)map

[Daniel Vetter]

It's unused.

10 years ago, back when 32bit was still fairly common and trying to
not exhaust vmalloc space sounded like a worthwhile goal, adding these
to dma_buf made sense.

Reality is that they simply never caught on, and nowadays everyone who
needs plenty of buffers will run in 64bit mode anyway.

Also update the docs in this area to adjust them to reality.

The actual hooks in dma_buf_ops will be removed once all the
implementations are gone.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/dma-buf/dma-buf.c | 63 ++-------------------------------------
 include/linux/dma-buf.h   |  2 --
 2 files changed, 3 insertions(+), 62 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d377b4ca66bf..97988ce1d2dc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -880,29 +880,9 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
  *   with calls to dma_buf_begin_cpu_access() and dma_buf_end_cpu_access()
  *   access.
  *
- *   To support dma_buf objects residing in highmem cpu access is page-based
- *   using an api similar to kmap. Accessing a dma_buf is done in aligned chunks
- *   of PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which
- *   returns a pointer in kernel virtual address space. Afterwards the chunk
- *   needs to be unmapped again. There is no limit on how often a given chunk
- *   can be mapped and unmapped, i.e. the importer does not need to call
- *   begin_cpu_access again before mapping the same chunk again.
- *
- *   Interfaces::
- *      void \*dma_buf_kmap(struct dma_buf \*, unsigned long);
- *      void dma_buf_kunmap(struct dma_buf \*, unsigned long, void \*);
- *
- *   Implementing the functions is optional for exporters and for importers all
- *   the restrictions of using kmap apply.
- *
- *   dma_buf kmap calls outside of the range specified in begin_cpu_access are
- *   undefined. If the range is not PAGE_SIZE aligned, kmap needs to succeed on
- *   the partial chunks at the beginning and end but may return stale or bogus
- *   data outside of the range (in these partial chunks).
- *
- *   For some cases the overhead of kmap can be too high, a vmap interface
- *   is introduced. This interface should be used very carefully, as vmalloc
- *   space is a limited resources on many architectures.
+ *   Since for most kernel internal dma-buf accesses need the entire buffer, a
+ *   vmap interface is introduced. Note that on very old 32-bit architectures
+ *   vmalloc space might be limited and result in vmap calls failing.
  *
  *   Interfaces::
  *      void \*dma_buf_vmap(struct dma_buf \*dmabuf)
@@ -1052,43 +1032,6 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
 }
 EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
 
-/**
- * dma_buf_kmap - Map a page of the buffer object into kernel address space. The
- * same restrictions as for kmap and friends apply.
- * @dmabuf:	[in]	buffer to map page from.
- * @page_num:	[in]	page in PAGE_SIZE units to map.
- *
- * This call must always succeed, any necessary preparations that might fail
- * need to be done in begin_cpu_access.
- */
-void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num)
-{
-	WARN_ON(!dmabuf);
-
-	if (!dmabuf->ops->map)
-		return NULL;
-	return dmabuf->ops->map(dmabuf, page_num);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kmap);
-
-/**
- * dma_buf_kunmap - Unmap a page obtained by dma_buf_kmap.
- * @dmabuf:	[in]	buffer to unmap page from.
- * @page_num:	[in]	page in PAGE_SIZE units to unmap.
- * @vaddr:	[in]	kernel space pointer obtained from dma_buf_kmap.
- *
- * This call must always succeed.
- */
-void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num,
-		    void *vaddr)
-{
-	WARN_ON(!dmabuf);
-
-	if (dmabuf->ops->unmap)
-		dmabuf->ops->unmap(dmabuf, page_num, vaddr);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kunmap);
-
 
 /**
  * dma_buf_mmap - Setup up a userspace mmap with the given vma
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index af73f835c51c..7feb9c3805ae 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -464,8 +464,6 @@ int dma_buf_begin_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(struct dma_buf *, unsigned long);
-void dma_buf_kunmap(struct dma_buf *, unsigned long, void *);
 
 int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
 		 unsigned long);
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 10/15] drm/vmwgfx: Delete mmaping functions

[Daniel Vetter]

No need for stubs, dma-buf.c takes care of that.

Aside, not having a ->release callback smelled like refcounting leak
somewhere. It will also score you a WARN_ON backtrace in dma-buf.c on
every export. But then I found that ttm_device_object_init overwrites
it. Overwriting const memory is not going to go down well in recent
kernels.

One more aside: The (un)map_dma_buf can't ever be called because
->attach rejects everything. Might want to drop a BUG_ON(1) in there.
Same for ->detach.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
---
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 33 ---------------------------
 1 file changed, 33 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
index e420675e8db3..d9552a1efd13 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
@@ -62,45 +62,12 @@ static void vmw_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
 {
 }
 
-static void *vmw_prime_dmabuf_vmap(struct dma_buf *dma_buf)
-{
-	return NULL;
-}
-
-static void vmw_prime_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
-{
-}
-
-static void *vmw_prime_dmabuf_kmap(struct dma_buf *dma_buf,
-		unsigned long page_num)
-{
-	return NULL;
-}
-
-static void vmw_prime_dmabuf_kunmap(struct dma_buf *dma_buf,
-		unsigned long page_num, void *addr)
-{
-
-}
-
-static int vmw_prime_dmabuf_mmap(struct dma_buf *dma_buf,
-				 struct vm_area_struct *vma)
-{
-	WARN_ONCE(true, "Attempted use of dmabuf mmap. Bad.\n");
-	return -ENOSYS;
-}
-
 const struct dma_buf_ops vmw_prime_dmabuf_ops =  {
 	.attach = vmw_prime_map_attach,
 	.detach = vmw_prime_map_detach,
 	.map_dma_buf = vmw_prime_map_dma_buf,
 	.unmap_dma_buf = vmw_prime_unmap_dma_buf,
 	.release = NULL,
-	.map = vmw_prime_dmabuf_kmap,
-	.unmap = vmw_prime_dmabuf_kunmap,
-	.mmap = vmw_prime_dmabuf_mmap,
-	.vmap = vmw_prime_dmabuf_vmap,
-	.vunmap = vmw_prime_dmabuf_vunmap,
 };
 
 int vmw_prime_fd_to_handle(struct drm_device *dev,
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 10/15] drm/vmwgfx: Delete mmaping functions

[Daniel Vetter]

No need for stubs, dma-buf.c takes care of that.

Aside, not having a ->release callback smelled like refcounting leak
somewhere. It will also score you a WARN_ON backtrace in dma-buf.c on
every export. But then I found that ttm_device_object_init overwrites
it. Overwriting const memory is not going to go down well in recent
kernels.

One more aside: The (un)map_dma_buf can't ever be called because
->attach rejects everything. Might want to drop a BUG_ON(1) in there.
Same for ->detach.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
---
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 33 ---------------------------
 1 file changed, 33 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
index e420675e8db3..d9552a1efd13 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
@@ -62,45 +62,12 @@ static void vmw_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
 {
 }
 
-static void *vmw_prime_dmabuf_vmap(struct dma_buf *dma_buf)
-{
-	return NULL;
-}
-
-static void vmw_prime_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
-{
-}
-
-static void *vmw_prime_dmabuf_kmap(struct dma_buf *dma_buf,
-		unsigned long page_num)
-{
-	return NULL;
-}
-
-static void vmw_prime_dmabuf_kunmap(struct dma_buf *dma_buf,
-		unsigned long page_num, void *addr)
-{
-
-}
-
-static int vmw_prime_dmabuf_mmap(struct dma_buf *dma_buf,
-				 struct vm_area_struct *vma)
-{
-	WARN_ONCE(true, "Attempted use of dmabuf mmap. Bad.\n");
-	return -ENOSYS;
-}
-
 const struct dma_buf_ops vmw_prime_dmabuf_ops =  {
 	.attach = vmw_prime_map_attach,
 	.detach = vmw_prime_map_detach,
 	.map_dma_buf = vmw_prime_map_dma_buf,
 	.unmap_dma_buf = vmw_prime_unmap_dma_buf,
 	.release = NULL,
-	.map = vmw_prime_dmabuf_kmap,
-	.unmap = vmw_prime_dmabuf_kunmap,
-	.mmap = vmw_prime_dmabuf_mmap,
-	.vmap = vmw_prime_dmabuf_vmap,
-	.vunmap = vmw_prime_dmabuf_vunmap,
 };
 
 int vmw_prime_fd_to_handle(struct drm_device *dev,
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 10/15] drm/vmwgfx: Delete mmaping functions

[Daniel Vetter]

No need for stubs, dma-buf.c takes care of that.

Aside, not having a ->release callback smelled like refcounting leak
somewhere. It will also score you a WARN_ON backtrace in dma-buf.c on
every export. But then I found that ttm_device_object_init overwrites
it. Overwriting const memory is not going to go down well in recent
kernels.

One more aside: The (un)map_dma_buf can't ever be called because
->attach rejects everything. Might want to drop a BUG_ON(1) in there.
Same for ->detach.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
---
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 33 ---------------------------
 1 file changed, 33 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
index e420675e8db3..d9552a1efd13 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
@@ -62,45 +62,12 @@ static void vmw_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
 {
 }
 
-static void *vmw_prime_dmabuf_vmap(struct dma_buf *dma_buf)
-{
-	return NULL;
-}
-
-static void vmw_prime_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
-{
-}
-
-static void *vmw_prime_dmabuf_kmap(struct dma_buf *dma_buf,
-		unsigned long page_num)
-{
-	return NULL;
-}
-
-static void vmw_prime_dmabuf_kunmap(struct dma_buf *dma_buf,
-		unsigned long page_num, void *addr)
-{
-
-}
-
-static int vmw_prime_dmabuf_mmap(struct dma_buf *dma_buf,
-				 struct vm_area_struct *vma)
-{
-	WARN_ONCE(true, "Attempted use of dmabuf mmap. Bad.\n");
-	return -ENOSYS;
-}
-
 const struct dma_buf_ops vmw_prime_dmabuf_ops =  {
 	.attach = vmw_prime_map_attach,
 	.detach = vmw_prime_map_detach,
 	.map_dma_buf = vmw_prime_map_dma_buf,
 	.unmap_dma_buf = vmw_prime_unmap_dma_buf,
 	.release = NULL,
-	.map = vmw_prime_dmabuf_kmap,
-	.unmap = vmw_prime_dmabuf_kunmap,
-	.mmap = vmw_prime_dmabuf_mmap,
-	.vmap = vmw_prime_dmabuf_vmap,
-	.vunmap = vmw_prime_dmabuf_vunmap,
 };
 
 int vmw_prime_fd_to_handle(struct drm_device *dev,
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/15] drm/vmwgfx: Delete mmaping functions

[Thomas Hellstrom]

On Mon, 2019-11-18 at 11:35 +0100, Daniel Vetter wrote:
> No need for stubs, dma-buf.c takes care of that.
> 
> Aside, not having a ->release callback smelled like refcounting leak
> somewhere. It will also score you a WARN_ON backtrace in dma-buf.c on
> every export. But then I found that ttm_device_object_init overwrites
> it. Overwriting const memory is not going to go down well in recent
> kernels.

It's actually taking a non-const copy and updating it. Not that that's
much better, but at least it won't crash due to writing to wp memory.
I'll add a backlog item to revisit this.

> 
> One more aside: The (un)map_dma_buf can't ever be called because
> ->attach rejects everything. Might want to drop a BUG_ON(1) in there.
> Same for ->detach.

And this.

> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> ---
> 


Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

Will you be taking this through drm-misc?

Thanks,
Thomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/15] drm/vmwgfx: Delete mmaping functions

[Thomas Hellstrom]

On Mon, 2019-11-18 at 11:35 +0100, Daniel Vetter wrote:
> No need for stubs, dma-buf.c takes care of that.
> 
> Aside, not having a ->release callback smelled like refcounting leak
> somewhere. It will also score you a WARN_ON backtrace in dma-buf.c on
> every export. But then I found that ttm_device_object_init overwrites
> it. Overwriting const memory is not going to go down well in recent
> kernels.

It's actually taking a non-const copy and updating it. Not that that's
much better, but at least it won't crash due to writing to wp memory.
I'll add a backlog item to revisit this.

> 
> One more aside: The (un)map_dma_buf can't ever be called because
> ->attach rejects everything. Might want to drop a BUG_ON(1) in there.
> Same for ->detach.

And this.

> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> ---
> 


Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

Will you be taking this through drm-misc?

Thanks,
Thomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 10/15] drm/vmwgfx: Delete mmaping functions

[Thomas Hellstrom]

On Mon, 2019-11-18 at 11:35 +0100, Daniel Vetter wrote:
> No need for stubs, dma-buf.c takes care of that.
> 
> Aside, not having a ->release callback smelled like refcounting leak
> somewhere. It will also score you a WARN_ON backtrace in dma-buf.c on
> every export. But then I found that ttm_device_object_init overwrites
> it. Overwriting const memory is not going to go down well in recent
> kernels.

It's actually taking a non-const copy and updating it. Not that that's
much better, but at least it won't crash due to writing to wp memory.
I'll add a backlog item to revisit this.

> 
> One more aside: The (un)map_dma_buf can't ever be called because
> ->attach rejects everything. Might want to drop a BUG_ON(1) in there.
> Same for ->detach.

And this.

> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> ---
> 


Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

Will you be taking this through drm-misc?

Thanks,
Thomas

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/15] drm/vmwgfx: Delete mmaping functions

[Daniel Vetter]

On Mon, Nov 18, 2019 at 6:25 PM Thomas Hellstrom <thellstrom@vmware.com> wrote:
>
> On Mon, 2019-11-18 at 11:35 +0100, Daniel Vetter wrote:
> > No need for stubs, dma-buf.c takes care of that.
> >
> > Aside, not having a ->release callback smelled like refcounting leak
> > somewhere. It will also score you a WARN_ON backtrace in dma-buf.c on
> > every export. But then I found that ttm_device_object_init overwrites
> > it. Overwriting const memory is not going to go down well in recent
> > kernels.
>
> It's actually taking a non-const copy and updating it. Not that that's
> much better, but at least it won't crash due to writing to wp memory.
> I'll add a backlog item to revisit this.

Hm I was looking for that, but didn't spot where it does that. I'll
update the commit message when merging.

> > One more aside: The (un)map_dma_buf can't ever be called because
> > ->attach rejects everything. Might want to drop a BUG_ON(1) in there.
> > Same for ->detach.
>
> And this.
>
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
> > Cc: Thomas Hellstrom <thellstrom@vmware.com>
> > ---
> >
>
>
> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

Thanks for your review.

> Will you be taking this through drm-misc?

Yup, that's the plan.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 10/15] drm/vmwgfx: Delete mmaping functions

[Daniel Vetter]

On Mon, Nov 18, 2019 at 6:25 PM Thomas Hellstrom <thellstrom@vmware.com> wrote:
>
> On Mon, 2019-11-18 at 11:35 +0100, Daniel Vetter wrote:
> > No need for stubs, dma-buf.c takes care of that.
> >
> > Aside, not having a ->release callback smelled like refcounting leak
> > somewhere. It will also score you a WARN_ON backtrace in dma-buf.c on
> > every export. But then I found that ttm_device_object_init overwrites
> > it. Overwriting const memory is not going to go down well in recent
> > kernels.
>
> It's actually taking a non-const copy and updating it. Not that that's
> much better, but at least it won't crash due to writing to wp memory.
> I'll add a backlog item to revisit this.

Hm I was looking for that, but didn't spot where it does that. I'll
update the commit message when merging.

> > One more aside: The (un)map_dma_buf can't ever be called because
> > ->attach rejects everything. Might want to drop a BUG_ON(1) in there.
> > Same for ->detach.
>
> And this.
>
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
> > Cc: Thomas Hellstrom <thellstrom@vmware.com>
> > ---
> >
>
>
> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

Thanks for your review.

> Will you be taking this through drm-misc?

Yup, that's the plan.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

[Daniel Vetter]

No in-tree users left.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Pawel Osciak <pawel@osciak.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Tomasz Figa <tfiga@chromium.org>
Cc: linux-media@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 --------
 drivers/media/common/videobuf2/videobuf2-dma-sg.c     | 8 --------
 drivers/media/common/videobuf2/videobuf2-vmalloc.c    | 8 --------
 3 files changed, 24 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 44cd0e530bbd..d0c9dffe49e5 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
 	vb2_dc_put(dbuf->priv);
 }
 
-static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
-	struct vb2_dc_buf *buf = dbuf->priv;
-
-	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
 	struct vb2_dc_buf *buf = dbuf->priv;
@@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
 	.detach = vb2_dc_dmabuf_ops_detach,
 	.map_dma_buf = vb2_dc_dmabuf_ops_map,
 	.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
-	.map = vb2_dc_dmabuf_ops_kmap,
 	.vmap = vb2_dc_dmabuf_ops_vmap,
 	.mmap = vb2_dc_dmabuf_ops_mmap,
 	.release = vb2_dc_dmabuf_ops_release,
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index ed706b2a263c..6db60e9d5183 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf *dbuf)
 	vb2_dma_sg_put(dbuf->priv);
 }
 
-static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
-	struct vb2_dma_sg_buf *buf = dbuf->priv;
-
-	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
 	struct vb2_dma_sg_buf *buf = dbuf->priv;
@@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
 	.detach = vb2_dma_sg_dmabuf_ops_detach,
 	.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
 	.unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
-	.map = vb2_dma_sg_dmabuf_ops_kmap,
 	.vmap = vb2_dma_sg_dmabuf_ops_vmap,
 	.mmap = vb2_dma_sg_dmabuf_ops_mmap,
 	.release = vb2_dma_sg_dmabuf_ops_release,
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 04d51ca63223..4d5af352e249 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct dma_buf *dbuf)
 	vb2_vmalloc_put(dbuf->priv);
 }
 
-static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
-	struct vb2_vmalloc_buf *buf = dbuf->priv;
-
-	return buf->vaddr + pgnum * PAGE_SIZE;
-}
-
 static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
 	struct vb2_vmalloc_buf *buf = dbuf->priv;
@@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
 	.detach = vb2_vmalloc_dmabuf_ops_detach,
 	.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
 	.unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
-	.map = vb2_vmalloc_dmabuf_ops_kmap,
 	.vmap = vb2_vmalloc_dmabuf_ops_vmap,
 	.mmap = vb2_vmalloc_dmabuf_ops_mmap,
 	.release = vb2_vmalloc_dmabuf_ops_release,
-- 
2.24.0

[Intel-gfx] [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

[Daniel Vetter]

No in-tree users left.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Pawel Osciak <pawel@osciak.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Tomasz Figa <tfiga@chromium.org>
Cc: linux-media@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 --------
 drivers/media/common/videobuf2/videobuf2-dma-sg.c     | 8 --------
 drivers/media/common/videobuf2/videobuf2-vmalloc.c    | 8 --------
 3 files changed, 24 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 44cd0e530bbd..d0c9dffe49e5 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
 	vb2_dc_put(dbuf->priv);
 }
 
-static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
-	struct vb2_dc_buf *buf = dbuf->priv;
-
-	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
 	struct vb2_dc_buf *buf = dbuf->priv;
@@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
 	.detach = vb2_dc_dmabuf_ops_detach,
 	.map_dma_buf = vb2_dc_dmabuf_ops_map,
 	.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
-	.map = vb2_dc_dmabuf_ops_kmap,
 	.vmap = vb2_dc_dmabuf_ops_vmap,
 	.mmap = vb2_dc_dmabuf_ops_mmap,
 	.release = vb2_dc_dmabuf_ops_release,
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index ed706b2a263c..6db60e9d5183 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf *dbuf)
 	vb2_dma_sg_put(dbuf->priv);
 }
 
-static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
-	struct vb2_dma_sg_buf *buf = dbuf->priv;
-
-	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
 	struct vb2_dma_sg_buf *buf = dbuf->priv;
@@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
 	.detach = vb2_dma_sg_dmabuf_ops_detach,
 	.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
 	.unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
-	.map = vb2_dma_sg_dmabuf_ops_kmap,
 	.vmap = vb2_dma_sg_dmabuf_ops_vmap,
 	.mmap = vb2_dma_sg_dmabuf_ops_mmap,
 	.release = vb2_dma_sg_dmabuf_ops_release,
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 04d51ca63223..4d5af352e249 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct dma_buf *dbuf)
 	vb2_vmalloc_put(dbuf->priv);
 }
 
-static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
-	struct vb2_vmalloc_buf *buf = dbuf->priv;
-
-	return buf->vaddr + pgnum * PAGE_SIZE;
-}
-
 static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
 	struct vb2_vmalloc_buf *buf = dbuf->priv;
@@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
 	.detach = vb2_vmalloc_dmabuf_ops_detach,
 	.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
 	.unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
-	.map = vb2_vmalloc_dmabuf_ops_kmap,
 	.vmap = vb2_vmalloc_dmabuf_ops_vmap,
 	.mmap = vb2_vmalloc_dmabuf_ops_mmap,
 	.release = vb2_vmalloc_dmabuf_ops_release,
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

[Daniel Vetter]

No in-tree users left.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Pawel Osciak <pawel@osciak.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Tomasz Figa <tfiga@chromium.org>
Cc: linux-media@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 --------
 drivers/media/common/videobuf2/videobuf2-dma-sg.c     | 8 --------
 drivers/media/common/videobuf2/videobuf2-vmalloc.c    | 8 --------
 3 files changed, 24 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 44cd0e530bbd..d0c9dffe49e5 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
 	vb2_dc_put(dbuf->priv);
 }
 
-static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
-	struct vb2_dc_buf *buf = dbuf->priv;
-
-	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
 	struct vb2_dc_buf *buf = dbuf->priv;
@@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
 	.detach = vb2_dc_dmabuf_ops_detach,
 	.map_dma_buf = vb2_dc_dmabuf_ops_map,
 	.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
-	.map = vb2_dc_dmabuf_ops_kmap,
 	.vmap = vb2_dc_dmabuf_ops_vmap,
 	.mmap = vb2_dc_dmabuf_ops_mmap,
 	.release = vb2_dc_dmabuf_ops_release,
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index ed706b2a263c..6db60e9d5183 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf *dbuf)
 	vb2_dma_sg_put(dbuf->priv);
 }
 
-static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
-	struct vb2_dma_sg_buf *buf = dbuf->priv;
-
-	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
 	struct vb2_dma_sg_buf *buf = dbuf->priv;
@@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
 	.detach = vb2_dma_sg_dmabuf_ops_detach,
 	.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
 	.unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
-	.map = vb2_dma_sg_dmabuf_ops_kmap,
 	.vmap = vb2_dma_sg_dmabuf_ops_vmap,
 	.mmap = vb2_dma_sg_dmabuf_ops_mmap,
 	.release = vb2_dma_sg_dmabuf_ops_release,
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 04d51ca63223..4d5af352e249 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct dma_buf *dbuf)
 	vb2_vmalloc_put(dbuf->priv);
 }
 
-static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
-	struct vb2_vmalloc_buf *buf = dbuf->priv;
-
-	return buf->vaddr + pgnum * PAGE_SIZE;
-}
-
 static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
 	struct vb2_vmalloc_buf *buf = dbuf->priv;
@@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
 	.detach = vb2_vmalloc_dmabuf_ops_detach,
 	.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
 	.unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
-	.map = vb2_vmalloc_dmabuf_ops_kmap,
 	.vmap = vb2_vmalloc_dmabuf_ops_vmap,
 	.mmap = vb2_vmalloc_dmabuf_ops_mmap,
 	.release = vb2_vmalloc_dmabuf_ops_release,
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

[Daniel Vetter]

No in-tree users left.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Pawel Osciak <pawel@osciak.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Tomasz Figa <tfiga@chromium.org>
Cc: linux-media@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 --------
 drivers/media/common/videobuf2/videobuf2-dma-sg.c     | 8 --------
 drivers/media/common/videobuf2/videobuf2-vmalloc.c    | 8 --------
 3 files changed, 24 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 44cd0e530bbd..d0c9dffe49e5 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
 	vb2_dc_put(dbuf->priv);
 }
 
-static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
-	struct vb2_dc_buf *buf = dbuf->priv;
-
-	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
 	struct vb2_dc_buf *buf = dbuf->priv;
@@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
 	.detach = vb2_dc_dmabuf_ops_detach,
 	.map_dma_buf = vb2_dc_dmabuf_ops_map,
 	.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
-	.map = vb2_dc_dmabuf_ops_kmap,
 	.vmap = vb2_dc_dmabuf_ops_vmap,
 	.mmap = vb2_dc_dmabuf_ops_mmap,
 	.release = vb2_dc_dmabuf_ops_release,
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index ed706b2a263c..6db60e9d5183 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf *dbuf)
 	vb2_dma_sg_put(dbuf->priv);
 }
 
-static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
-	struct vb2_dma_sg_buf *buf = dbuf->priv;
-
-	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
 	struct vb2_dma_sg_buf *buf = dbuf->priv;
@@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
 	.detach = vb2_dma_sg_dmabuf_ops_detach,
 	.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
 	.unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
-	.map = vb2_dma_sg_dmabuf_ops_kmap,
 	.vmap = vb2_dma_sg_dmabuf_ops_vmap,
 	.mmap = vb2_dma_sg_dmabuf_ops_mmap,
 	.release = vb2_dma_sg_dmabuf_ops_release,
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 04d51ca63223..4d5af352e249 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct dma_buf *dbuf)
 	vb2_vmalloc_put(dbuf->priv);
 }
 
-static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
-	struct vb2_vmalloc_buf *buf = dbuf->priv;
-
-	return buf->vaddr + pgnum * PAGE_SIZE;
-}
-
 static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
 	struct vb2_vmalloc_buf *buf = dbuf->priv;
@@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
 	.detach = vb2_vmalloc_dmabuf_ops_detach,
 	.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
 	.unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
-	.map = vb2_vmalloc_dmabuf_ops_kmap,
 	.vmap = vb2_vmalloc_dmabuf_ops_vmap,
 	.mmap = vb2_vmalloc_dmabuf_ops_mmap,
 	.release = vb2_vmalloc_dmabuf_ops_release,
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

[Marek Szyprowski]

On 18.11.2019 11:35, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Pawel Osciak <pawel@osciak.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Tomasz Figa <tfiga@chromium.org>
> Cc: linux-media@vger.kernel.org

Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>

> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
>   drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 --------
>   drivers/media/common/videobuf2/videobuf2-dma-sg.c     | 8 --------
>   drivers/media/common/videobuf2/videobuf2-vmalloc.c    | 8 --------
>   3 files changed, 24 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 44cd0e530bbd..d0c9dffe49e5 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
>   	vb2_dc_put(dbuf->priv);
>   }
>   
> -static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>   static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   	struct vb2_dc_buf *buf = dbuf->priv;
> @@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
>   	.detach = vb2_dc_dmabuf_ops_detach,
>   	.map_dma_buf = vb2_dc_dmabuf_ops_map,
>   	.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> -	.map = vb2_dc_dmabuf_ops_kmap,
>   	.vmap = vb2_dc_dmabuf_ops_vmap,
>   	.mmap = vb2_dc_dmabuf_ops_mmap,
>   	.release = vb2_dc_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index ed706b2a263c..6db60e9d5183 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf *dbuf)
>   	vb2_dma_sg_put(dbuf->priv);
>   }
>   
> -static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dma_sg_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>   static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   	struct vb2_dma_sg_buf *buf = dbuf->priv;
> @@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
>   	.detach = vb2_dma_sg_dmabuf_ops_detach,
>   	.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
>   	.unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
> -	.map = vb2_dma_sg_dmabuf_ops_kmap,
>   	.vmap = vb2_dma_sg_dmabuf_ops_vmap,
>   	.mmap = vb2_dma_sg_dmabuf_ops_mmap,
>   	.release = vb2_dma_sg_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 04d51ca63223..4d5af352e249 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct dma_buf *dbuf)
>   	vb2_vmalloc_put(dbuf->priv);
>   }
>   
> -static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_vmalloc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr + pgnum * PAGE_SIZE;
> -}
> -
>   static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   	struct vb2_vmalloc_buf *buf = dbuf->priv;
> @@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
>   	.detach = vb2_vmalloc_dmabuf_ops_detach,
>   	.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
>   	.unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
> -	.map = vb2_vmalloc_dmabuf_ops_kmap,
>   	.vmap = vb2_vmalloc_dmabuf_ops_vmap,
>   	.mmap = vb2_vmalloc_dmabuf_ops_mmap,
>   	.release = vb2_vmalloc_dmabuf_ops_release,

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [Intel-gfx] [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

[Marek Szyprowski]

On 18.11.2019 11:35, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Pawel Osciak <pawel@osciak.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Tomasz Figa <tfiga@chromium.org>
> Cc: linux-media@vger.kernel.org

Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>

> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
>   drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 --------
>   drivers/media/common/videobuf2/videobuf2-dma-sg.c     | 8 --------
>   drivers/media/common/videobuf2/videobuf2-vmalloc.c    | 8 --------
>   3 files changed, 24 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 44cd0e530bbd..d0c9dffe49e5 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
>   	vb2_dc_put(dbuf->priv);
>   }
>   
> -static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>   static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   	struct vb2_dc_buf *buf = dbuf->priv;
> @@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
>   	.detach = vb2_dc_dmabuf_ops_detach,
>   	.map_dma_buf = vb2_dc_dmabuf_ops_map,
>   	.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> -	.map = vb2_dc_dmabuf_ops_kmap,
>   	.vmap = vb2_dc_dmabuf_ops_vmap,
>   	.mmap = vb2_dc_dmabuf_ops_mmap,
>   	.release = vb2_dc_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index ed706b2a263c..6db60e9d5183 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf *dbuf)
>   	vb2_dma_sg_put(dbuf->priv);
>   }
>   
> -static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dma_sg_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>   static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   	struct vb2_dma_sg_buf *buf = dbuf->priv;
> @@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
>   	.detach = vb2_dma_sg_dmabuf_ops_detach,
>   	.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
>   	.unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
> -	.map = vb2_dma_sg_dmabuf_ops_kmap,
>   	.vmap = vb2_dma_sg_dmabuf_ops_vmap,
>   	.mmap = vb2_dma_sg_dmabuf_ops_mmap,
>   	.release = vb2_dma_sg_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 04d51ca63223..4d5af352e249 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct dma_buf *dbuf)
>   	vb2_vmalloc_put(dbuf->priv);
>   }
>   
> -static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_vmalloc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr + pgnum * PAGE_SIZE;
> -}
> -
>   static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   	struct vb2_vmalloc_buf *buf = dbuf->priv;
> @@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
>   	.detach = vb2_vmalloc_dmabuf_ops_detach,
>   	.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
>   	.unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
> -	.map = vb2_vmalloc_dmabuf_ops_kmap,
>   	.vmap = vb2_vmalloc_dmabuf_ops_vmap,
>   	.mmap = vb2_vmalloc_dmabuf_ops_mmap,
>   	.release = vb2_vmalloc_dmabuf_ops_release,

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

[Marek Szyprowski]

On 18.11.2019 11:35, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Pawel Osciak <pawel@osciak.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Tomasz Figa <tfiga@chromium.org>
> Cc: linux-media@vger.kernel.org

Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>

> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
>   drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 --------
>   drivers/media/common/videobuf2/videobuf2-dma-sg.c     | 8 --------
>   drivers/media/common/videobuf2/videobuf2-vmalloc.c    | 8 --------
>   3 files changed, 24 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 44cd0e530bbd..d0c9dffe49e5 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
>   	vb2_dc_put(dbuf->priv);
>   }
>   
> -static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>   static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   	struct vb2_dc_buf *buf = dbuf->priv;
> @@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
>   	.detach = vb2_dc_dmabuf_ops_detach,
>   	.map_dma_buf = vb2_dc_dmabuf_ops_map,
>   	.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> -	.map = vb2_dc_dmabuf_ops_kmap,
>   	.vmap = vb2_dc_dmabuf_ops_vmap,
>   	.mmap = vb2_dc_dmabuf_ops_mmap,
>   	.release = vb2_dc_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index ed706b2a263c..6db60e9d5183 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf *dbuf)
>   	vb2_dma_sg_put(dbuf->priv);
>   }
>   
> -static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dma_sg_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>   static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   	struct vb2_dma_sg_buf *buf = dbuf->priv;
> @@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
>   	.detach = vb2_dma_sg_dmabuf_ops_detach,
>   	.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
>   	.unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
> -	.map = vb2_dma_sg_dmabuf_ops_kmap,
>   	.vmap = vb2_dma_sg_dmabuf_ops_vmap,
>   	.mmap = vb2_dma_sg_dmabuf_ops_mmap,
>   	.release = vb2_dma_sg_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 04d51ca63223..4d5af352e249 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct dma_buf *dbuf)
>   	vb2_vmalloc_put(dbuf->priv);
>   }
>   
> -static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_vmalloc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr + pgnum * PAGE_SIZE;
> -}
> -
>   static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   	struct vb2_vmalloc_buf *buf = dbuf->priv;
> @@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
>   	.detach = vb2_vmalloc_dmabuf_ops_detach,
>   	.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
>   	.unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
> -	.map = vb2_vmalloc_dmabuf_ops_kmap,
>   	.vmap = vb2_vmalloc_dmabuf_ops_vmap,
>   	.mmap = vb2_vmalloc_dmabuf_ops_mmap,
>   	.release = vb2_vmalloc_dmabuf_ops_release,

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

[Marek Szyprowski]

On 18.11.2019 11:35, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Pawel Osciak <pawel@osciak.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Tomasz Figa <tfiga@chromium.org>
> Cc: linux-media@vger.kernel.org

Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>

> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
>   drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 --------
>   drivers/media/common/videobuf2/videobuf2-dma-sg.c     | 8 --------
>   drivers/media/common/videobuf2/videobuf2-vmalloc.c    | 8 --------
>   3 files changed, 24 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 44cd0e530bbd..d0c9dffe49e5 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
>   	vb2_dc_put(dbuf->priv);
>   }
>   
> -static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>   static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   	struct vb2_dc_buf *buf = dbuf->priv;
> @@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
>   	.detach = vb2_dc_dmabuf_ops_detach,
>   	.map_dma_buf = vb2_dc_dmabuf_ops_map,
>   	.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> -	.map = vb2_dc_dmabuf_ops_kmap,
>   	.vmap = vb2_dc_dmabuf_ops_vmap,
>   	.mmap = vb2_dc_dmabuf_ops_mmap,
>   	.release = vb2_dc_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index ed706b2a263c..6db60e9d5183 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf *dbuf)
>   	vb2_dma_sg_put(dbuf->priv);
>   }
>   
> -static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dma_sg_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>   static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   	struct vb2_dma_sg_buf *buf = dbuf->priv;
> @@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
>   	.detach = vb2_dma_sg_dmabuf_ops_detach,
>   	.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
>   	.unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
> -	.map = vb2_dma_sg_dmabuf_ops_kmap,
>   	.vmap = vb2_dma_sg_dmabuf_ops_vmap,
>   	.mmap = vb2_dma_sg_dmabuf_ops_mmap,
>   	.release = vb2_dma_sg_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 04d51ca63223..4d5af352e249 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct dma_buf *dbuf)
>   	vb2_vmalloc_put(dbuf->priv);
>   }
>   
> -static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_vmalloc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr + pgnum * PAGE_SIZE;
> -}
> -
>   static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   	struct vb2_vmalloc_buf *buf = dbuf->priv;
> @@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
>   	.detach = vb2_vmalloc_dmabuf_ops_detach,
>   	.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
>   	.unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
> -	.map = vb2_vmalloc_dmabuf_ops_kmap,
>   	.vmap = vb2_vmalloc_dmabuf_ops_vmap,
>   	.mmap = vb2_vmalloc_dmabuf_ops_mmap,
>   	.release = vb2_vmalloc_dmabuf_ops_release,

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

[Hans Verkuil]

On 11/18/19 11:35 AM, Daniel Vetter wrote:
> No in-tree users left.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

Thanks!

	Hans

> Cc: Pawel Osciak <pawel@osciak.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Tomasz Figa <tfiga@chromium.org>
> Cc: linux-media@vger.kernel.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
>  drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 --------
>  drivers/media/common/videobuf2/videobuf2-dma-sg.c     | 8 --------
>  drivers/media/common/videobuf2/videobuf2-vmalloc.c    | 8 --------
>  3 files changed, 24 deletions(-)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 44cd0e530bbd..d0c9dffe49e5 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
>  	vb2_dc_put(dbuf->priv);
>  }
>  
> -static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>  static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>  {
>  	struct vb2_dc_buf *buf = dbuf->priv;
> @@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
>  	.detach = vb2_dc_dmabuf_ops_detach,
>  	.map_dma_buf = vb2_dc_dmabuf_ops_map,
>  	.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> -	.map = vb2_dc_dmabuf_ops_kmap,
>  	.vmap = vb2_dc_dmabuf_ops_vmap,
>  	.mmap = vb2_dc_dmabuf_ops_mmap,
>  	.release = vb2_dc_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index ed706b2a263c..6db60e9d5183 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf *dbuf)
>  	vb2_dma_sg_put(dbuf->priv);
>  }
>  
> -static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dma_sg_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>  static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
>  {
>  	struct vb2_dma_sg_buf *buf = dbuf->priv;
> @@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
>  	.detach = vb2_dma_sg_dmabuf_ops_detach,
>  	.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
>  	.unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
> -	.map = vb2_dma_sg_dmabuf_ops_kmap,
>  	.vmap = vb2_dma_sg_dmabuf_ops_vmap,
>  	.mmap = vb2_dma_sg_dmabuf_ops_mmap,
>  	.release = vb2_dma_sg_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 04d51ca63223..4d5af352e249 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct dma_buf *dbuf)
>  	vb2_vmalloc_put(dbuf->priv);
>  }
>  
> -static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_vmalloc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr + pgnum * PAGE_SIZE;
> -}
> -
>  static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>  {
>  	struct vb2_vmalloc_buf *buf = dbuf->priv;
> @@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
>  	.detach = vb2_vmalloc_dmabuf_ops_detach,
>  	.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
>  	.unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
> -	.map = vb2_vmalloc_dmabuf_ops_kmap,
>  	.vmap = vb2_vmalloc_dmabuf_ops_vmap,
>  	.mmap = vb2_vmalloc_dmabuf_ops_mmap,
>  	.release = vb2_vmalloc_dmabuf_ops_release,
> 

Re: [Intel-gfx] [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

[Hans Verkuil]

On 11/18/19 11:35 AM, Daniel Vetter wrote:
> No in-tree users left.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

Thanks!

	Hans

> Cc: Pawel Osciak <pawel@osciak.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Tomasz Figa <tfiga@chromium.org>
> Cc: linux-media@vger.kernel.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
>  drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 --------
>  drivers/media/common/videobuf2/videobuf2-dma-sg.c     | 8 --------
>  drivers/media/common/videobuf2/videobuf2-vmalloc.c    | 8 --------
>  3 files changed, 24 deletions(-)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 44cd0e530bbd..d0c9dffe49e5 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
>  	vb2_dc_put(dbuf->priv);
>  }
>  
> -static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>  static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>  {
>  	struct vb2_dc_buf *buf = dbuf->priv;
> @@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
>  	.detach = vb2_dc_dmabuf_ops_detach,
>  	.map_dma_buf = vb2_dc_dmabuf_ops_map,
>  	.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> -	.map = vb2_dc_dmabuf_ops_kmap,
>  	.vmap = vb2_dc_dmabuf_ops_vmap,
>  	.mmap = vb2_dc_dmabuf_ops_mmap,
>  	.release = vb2_dc_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index ed706b2a263c..6db60e9d5183 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf *dbuf)
>  	vb2_dma_sg_put(dbuf->priv);
>  }
>  
> -static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dma_sg_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>  static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
>  {
>  	struct vb2_dma_sg_buf *buf = dbuf->priv;
> @@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
>  	.detach = vb2_dma_sg_dmabuf_ops_detach,
>  	.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
>  	.unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
> -	.map = vb2_dma_sg_dmabuf_ops_kmap,
>  	.vmap = vb2_dma_sg_dmabuf_ops_vmap,
>  	.mmap = vb2_dma_sg_dmabuf_ops_mmap,
>  	.release = vb2_dma_sg_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 04d51ca63223..4d5af352e249 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct dma_buf *dbuf)
>  	vb2_vmalloc_put(dbuf->priv);
>  }
>  
> -static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_vmalloc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr + pgnum * PAGE_SIZE;
> -}
> -
>  static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>  {
>  	struct vb2_vmalloc_buf *buf = dbuf->priv;
> @@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
>  	.detach = vb2_vmalloc_dmabuf_ops_detach,
>  	.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
>  	.unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
> -	.map = vb2_vmalloc_dmabuf_ops_kmap,
>  	.vmap = vb2_vmalloc_dmabuf_ops_vmap,
>  	.mmap = vb2_vmalloc_dmabuf_ops_mmap,
>  	.release = vb2_vmalloc_dmabuf_ops_release,
> 

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

[Hans Verkuil]

On 11/18/19 11:35 AM, Daniel Vetter wrote:
> No in-tree users left.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

Thanks!

	Hans

> Cc: Pawel Osciak <pawel@osciak.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Tomasz Figa <tfiga@chromium.org>
> Cc: linux-media@vger.kernel.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
>  drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 --------
>  drivers/media/common/videobuf2/videobuf2-dma-sg.c     | 8 --------
>  drivers/media/common/videobuf2/videobuf2-vmalloc.c    | 8 --------
>  3 files changed, 24 deletions(-)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 44cd0e530bbd..d0c9dffe49e5 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
>  	vb2_dc_put(dbuf->priv);
>  }
>  
> -static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>  static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>  {
>  	struct vb2_dc_buf *buf = dbuf->priv;
> @@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
>  	.detach = vb2_dc_dmabuf_ops_detach,
>  	.map_dma_buf = vb2_dc_dmabuf_ops_map,
>  	.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> -	.map = vb2_dc_dmabuf_ops_kmap,
>  	.vmap = vb2_dc_dmabuf_ops_vmap,
>  	.mmap = vb2_dc_dmabuf_ops_mmap,
>  	.release = vb2_dc_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index ed706b2a263c..6db60e9d5183 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf *dbuf)
>  	vb2_dma_sg_put(dbuf->priv);
>  }
>  
> -static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_dma_sg_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>  static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
>  {
>  	struct vb2_dma_sg_buf *buf = dbuf->priv;
> @@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
>  	.detach = vb2_dma_sg_dmabuf_ops_detach,
>  	.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
>  	.unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
> -	.map = vb2_dma_sg_dmabuf_ops_kmap,
>  	.vmap = vb2_dma_sg_dmabuf_ops_vmap,
>  	.mmap = vb2_dma_sg_dmabuf_ops_mmap,
>  	.release = vb2_dma_sg_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 04d51ca63223..4d5af352e249 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct dma_buf *dbuf)
>  	vb2_vmalloc_put(dbuf->priv);
>  }
>  
> -static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
> -{
> -	struct vb2_vmalloc_buf *buf = dbuf->priv;
> -
> -	return buf->vaddr + pgnum * PAGE_SIZE;
> -}
> -
>  static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>  {
>  	struct vb2_vmalloc_buf *buf = dbuf->priv;
> @@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
>  	.detach = vb2_vmalloc_dmabuf_ops_detach,
>  	.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
>  	.unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
> -	.map = vb2_vmalloc_dmabuf_ops_kmap,
>  	.vmap = vb2_vmalloc_dmabuf_ops_vmap,
>  	.mmap = vb2_vmalloc_dmabuf_ops_mmap,
>  	.release = vb2_vmalloc_dmabuf_ops_release,
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support

[Daniel Vetter]

There's no in-tree users anymore.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: tee-dev@lists.linaro.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/misc/fastrpc.c | 8 --------
 drivers/tee/tee_shm.c  | 6 ------
 2 files changed, 14 deletions(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 1b1a794d639d..d0cbef9ec28a 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -555,13 +555,6 @@ static void fastrpc_dma_buf_detatch(struct dma_buf *dmabuf,
 	kfree(a);
 }
 
-static void *fastrpc_kmap(struct dma_buf *dmabuf, unsigned long pgnum)
-{
-	struct fastrpc_buf *buf = dmabuf->priv;
-
-	return buf->virt ? buf->virt + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *fastrpc_vmap(struct dma_buf *dmabuf)
 {
 	struct fastrpc_buf *buf = dmabuf->priv;
@@ -585,7 +578,6 @@ static const struct dma_buf_ops fastrpc_dma_buf_ops = {
 	.map_dma_buf = fastrpc_map_dma_buf,
 	.unmap_dma_buf = fastrpc_unmap_dma_buf,
 	.mmap = fastrpc_mmap,
-	.map = fastrpc_kmap,
 	.vmap = fastrpc_vmap,
 	.release = fastrpc_release,
 };
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index 09ddcd06c715..937ac5aaa6d8 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -71,11 +71,6 @@ static void tee_shm_op_release(struct dma_buf *dmabuf)
 	tee_shm_release(shm);
 }
 
-static void *tee_shm_op_map(struct dma_buf *dmabuf, unsigned long pgnum)
-{
-	return NULL;
-}
-
 static int tee_shm_op_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
 	struct tee_shm *shm = dmabuf->priv;
@@ -93,7 +88,6 @@ static const struct dma_buf_ops tee_shm_dma_buf_ops = {
 	.map_dma_buf = tee_shm_op_map_dma_buf,
 	.unmap_dma_buf = tee_shm_op_unmap_dma_buf,
 	.release = tee_shm_op_release,
-	.map = tee_shm_op_map,
 	.mmap = tee_shm_op_mmap,
 };
 
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support

[Daniel Vetter]

There's no in-tree users anymore.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: tee-dev@lists.linaro.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/misc/fastrpc.c | 8 --------
 drivers/tee/tee_shm.c  | 6 ------
 2 files changed, 14 deletions(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 1b1a794d639d..d0cbef9ec28a 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -555,13 +555,6 @@ static void fastrpc_dma_buf_detatch(struct dma_buf *dmabuf,
 	kfree(a);
 }
 
-static void *fastrpc_kmap(struct dma_buf *dmabuf, unsigned long pgnum)
-{
-	struct fastrpc_buf *buf = dmabuf->priv;
-
-	return buf->virt ? buf->virt + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *fastrpc_vmap(struct dma_buf *dmabuf)
 {
 	struct fastrpc_buf *buf = dmabuf->priv;
@@ -585,7 +578,6 @@ static const struct dma_buf_ops fastrpc_dma_buf_ops = {
 	.map_dma_buf = fastrpc_map_dma_buf,
 	.unmap_dma_buf = fastrpc_unmap_dma_buf,
 	.mmap = fastrpc_mmap,
-	.map = fastrpc_kmap,
 	.vmap = fastrpc_vmap,
 	.release = fastrpc_release,
 };
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index 09ddcd06c715..937ac5aaa6d8 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -71,11 +71,6 @@ static void tee_shm_op_release(struct dma_buf *dmabuf)
 	tee_shm_release(shm);
 }
 
-static void *tee_shm_op_map(struct dma_buf *dmabuf, unsigned long pgnum)
-{
-	return NULL;
-}
-
 static int tee_shm_op_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
 	struct tee_shm *shm = dmabuf->priv;
@@ -93,7 +88,6 @@ static const struct dma_buf_ops tee_shm_dma_buf_ops = {
 	.map_dma_buf = tee_shm_op_map_dma_buf,
 	.unmap_dma_buf = tee_shm_op_unmap_dma_buf,
 	.release = tee_shm_op_release,
-	.map = tee_shm_op_map,
 	.mmap = tee_shm_op_mmap,
 };
 
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support

[Daniel Vetter]

There's no in-tree users anymore.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: tee-dev@lists.linaro.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/misc/fastrpc.c | 8 --------
 drivers/tee/tee_shm.c  | 6 ------
 2 files changed, 14 deletions(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 1b1a794d639d..d0cbef9ec28a 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -555,13 +555,6 @@ static void fastrpc_dma_buf_detatch(struct dma_buf *dmabuf,
 	kfree(a);
 }
 
-static void *fastrpc_kmap(struct dma_buf *dmabuf, unsigned long pgnum)
-{
-	struct fastrpc_buf *buf = dmabuf->priv;
-
-	return buf->virt ? buf->virt + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *fastrpc_vmap(struct dma_buf *dmabuf)
 {
 	struct fastrpc_buf *buf = dmabuf->priv;
@@ -585,7 +578,6 @@ static const struct dma_buf_ops fastrpc_dma_buf_ops = {
 	.map_dma_buf = fastrpc_map_dma_buf,
 	.unmap_dma_buf = fastrpc_unmap_dma_buf,
 	.mmap = fastrpc_mmap,
-	.map = fastrpc_kmap,
 	.vmap = fastrpc_vmap,
 	.release = fastrpc_release,
 };
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index 09ddcd06c715..937ac5aaa6d8 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -71,11 +71,6 @@ static void tee_shm_op_release(struct dma_buf *dmabuf)
 	tee_shm_release(shm);
 }
 
-static void *tee_shm_op_map(struct dma_buf *dmabuf, unsigned long pgnum)
-{
-	return NULL;
-}
-
 static int tee_shm_op_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
 	struct tee_shm *shm = dmabuf->priv;
@@ -93,7 +88,6 @@ static const struct dma_buf_ops tee_shm_dma_buf_ops = {
 	.map_dma_buf = tee_shm_op_map_dma_buf,
 	.unmap_dma_buf = tee_shm_op_unmap_dma_buf,
 	.release = tee_shm_op_release,
-	.map = tee_shm_op_map,
 	.mmap = tee_shm_op_mmap,
 };
 
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support

[Greg Kroah-Hartman]

On Mon, Nov 18, 2019 at 11:35:33AM +0100, Daniel Vetter wrote:
> There's no in-tree users anymore.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jens Wiklander <jens.wiklander@linaro.org>
> Cc: tee-dev@lists.linaro.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support

[Greg Kroah-Hartman]

On Mon, Nov 18, 2019 at 11:35:33AM +0100, Daniel Vetter wrote:
> There's no in-tree users anymore.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jens Wiklander <jens.wiklander@linaro.org>
> Cc: tee-dev@lists.linaro.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support

[Jens Wiklander]

On Mon, Nov 18, 2019 at 11:35:33AM +0100, Daniel Vetter wrote:
> There's no in-tree users anymore.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jens Wiklander <jens.wiklander@linaro.org>
> Cc: tee-dev@lists.linaro.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel

Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

Cheers,
Jens
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support

[Jens Wiklander]

On Mon, Nov 18, 2019 at 11:35:33AM +0100, Daniel Vetter wrote:
> There's no in-tree users anymore.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jens Wiklander <jens.wiklander@linaro.org>
> Cc: tee-dev@lists.linaro.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel

Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

Cheers,
Jens
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support

[Jens Wiklander]

On Mon, Nov 18, 2019 at 11:35:33AM +0100, Daniel Vetter wrote:
> There's no in-tree users anymore.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jens Wiklander <jens.wiklander@linaro.org>
> Cc: tee-dev@lists.linaro.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel

Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

Cheers,
Jens
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

[Daniel Vetter]

There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/xen/gntdev-dmabuf.c | 23 -----------------------
 1 file changed, 23 deletions(-)

diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 2c4f324f8626..fe7bd69d6955 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -342,35 +342,12 @@ static void dmabuf_exp_ops_release(struct dma_buf *dma_buf)
 	mutex_unlock(&priv->lock);
 }
 
-static void *dmabuf_exp_ops_kmap(struct dma_buf *dma_buf,
-				 unsigned long page_num)
-{
-	/* Not implemented. */
-	return NULL;
-}
-
-static void dmabuf_exp_ops_kunmap(struct dma_buf *dma_buf,
-				  unsigned long page_num, void *addr)
-{
-	/* Not implemented. */
-}
-
-static int dmabuf_exp_ops_mmap(struct dma_buf *dma_buf,
-			       struct vm_area_struct *vma)
-{
-	/* Not implemented. */
-	return 0;
-}
-
 static const struct dma_buf_ops dmabuf_exp_ops =  {
 	.attach = dmabuf_exp_ops_attach,
 	.detach = dmabuf_exp_ops_detach,
 	.map_dma_buf = dmabuf_exp_ops_map_dma_buf,
 	.unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
 	.release = dmabuf_exp_ops_release,
-	.map = dmabuf_exp_ops_kmap,
-	.unmap = dmabuf_exp_ops_kunmap,
-	.mmap = dmabuf_exp_ops_mmap,
 };
 
 struct gntdev_dmabuf_export_args {
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Xen-devel] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

[Daniel Vetter]

There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/xen/gntdev-dmabuf.c | 23 -----------------------
 1 file changed, 23 deletions(-)

diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 2c4f324f8626..fe7bd69d6955 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -342,35 +342,12 @@ static void dmabuf_exp_ops_release(struct dma_buf *dma_buf)
 	mutex_unlock(&priv->lock);
 }
 
-static void *dmabuf_exp_ops_kmap(struct dma_buf *dma_buf,
-				 unsigned long page_num)
-{
-	/* Not implemented. */
-	return NULL;
-}
-
-static void dmabuf_exp_ops_kunmap(struct dma_buf *dma_buf,
-				  unsigned long page_num, void *addr)
-{
-	/* Not implemented. */
-}
-
-static int dmabuf_exp_ops_mmap(struct dma_buf *dma_buf,
-			       struct vm_area_struct *vma)
-{
-	/* Not implemented. */
-	return 0;
-}
-
 static const struct dma_buf_ops dmabuf_exp_ops =  {
 	.attach = dmabuf_exp_ops_attach,
 	.detach = dmabuf_exp_ops_detach,
 	.map_dma_buf = dmabuf_exp_ops_map_dma_buf,
 	.unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
 	.release = dmabuf_exp_ops_release,
-	.map = dmabuf_exp_ops_kmap,
-	.unmap = dmabuf_exp_ops_kunmap,
-	.mmap = dmabuf_exp_ops_mmap,
 };
 
 struct gntdev_dmabuf_export_args {
-- 
2.24.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Intel-gfx] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

[Daniel Vetter]

There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/xen/gntdev-dmabuf.c | 23 -----------------------
 1 file changed, 23 deletions(-)

diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 2c4f324f8626..fe7bd69d6955 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -342,35 +342,12 @@ static void dmabuf_exp_ops_release(struct dma_buf *dma_buf)
 	mutex_unlock(&priv->lock);
 }
 
-static void *dmabuf_exp_ops_kmap(struct dma_buf *dma_buf,
-				 unsigned long page_num)
-{
-	/* Not implemented. */
-	return NULL;
-}
-
-static void dmabuf_exp_ops_kunmap(struct dma_buf *dma_buf,
-				  unsigned long page_num, void *addr)
-{
-	/* Not implemented. */
-}
-
-static int dmabuf_exp_ops_mmap(struct dma_buf *dma_buf,
-			       struct vm_area_struct *vma)
-{
-	/* Not implemented. */
-	return 0;
-}
-
 static const struct dma_buf_ops dmabuf_exp_ops =  {
 	.attach = dmabuf_exp_ops_attach,
 	.detach = dmabuf_exp_ops_detach,
 	.map_dma_buf = dmabuf_exp_ops_map_dma_buf,
 	.unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
 	.release = dmabuf_exp_ops_release,
-	.map = dmabuf_exp_ops_kmap,
-	.unmap = dmabuf_exp_ops_kunmap,
-	.mmap = dmabuf_exp_ops_mmap,
 };
 
 struct gntdev_dmabuf_export_args {
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

[Daniel Vetter]

There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/xen/gntdev-dmabuf.c | 23 -----------------------
 1 file changed, 23 deletions(-)

diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 2c4f324f8626..fe7bd69d6955 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -342,35 +342,12 @@ static void dmabuf_exp_ops_release(struct dma_buf *dma_buf)
 	mutex_unlock(&priv->lock);
 }
 
-static void *dmabuf_exp_ops_kmap(struct dma_buf *dma_buf,
-				 unsigned long page_num)
-{
-	/* Not implemented. */
-	return NULL;
-}
-
-static void dmabuf_exp_ops_kunmap(struct dma_buf *dma_buf,
-				  unsigned long page_num, void *addr)
-{
-	/* Not implemented. */
-}
-
-static int dmabuf_exp_ops_mmap(struct dma_buf *dma_buf,
-			       struct vm_area_struct *vma)
-{
-	/* Not implemented. */
-	return 0;
-}
-
 static const struct dma_buf_ops dmabuf_exp_ops =  {
 	.attach = dmabuf_exp_ops_attach,
 	.detach = dmabuf_exp_ops_detach,
 	.map_dma_buf = dmabuf_exp_ops_map_dma_buf,
 	.unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
 	.release = dmabuf_exp_ops_release,
-	.map = dmabuf_exp_ops_kmap,
-	.unmap = dmabuf_exp_ops_kunmap,
-	.mmap = dmabuf_exp_ops_mmap,
 };
 
 struct gntdev_dmabuf_export_args {
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Xen-devel] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

[Oleksandr Andrushchenko]

On 11/18/19 12:35 PM, Daniel Vetter wrote:
> There's no in-kernel users for the k(un)map stuff. And the mmap one is
> actively harmful - return 0 and then _not_ actually mmaping can't end
> well.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: xen-devel@lists.xenproject.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
>   drivers/xen/gntdev-dmabuf.c | 23 -----------------------
>   1 file changed, 23 deletions(-)
>
> diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
> index 2c4f324f8626..fe7bd69d6955 100644
> --- a/drivers/xen/gntdev-dmabuf.c
> +++ b/drivers/xen/gntdev-dmabuf.c
> @@ -342,35 +342,12 @@ static void dmabuf_exp_ops_release(struct dma_buf *dma_buf)
>   	mutex_unlock(&priv->lock);
>   }
>   
> -static void *dmabuf_exp_ops_kmap(struct dma_buf *dma_buf,
> -				 unsigned long page_num)
> -{
> -	/* Not implemented. */
> -	return NULL;
> -}
> -
> -static void dmabuf_exp_ops_kunmap(struct dma_buf *dma_buf,
> -				  unsigned long page_num, void *addr)
> -{
> -	/* Not implemented. */
> -}
> -
> -static int dmabuf_exp_ops_mmap(struct dma_buf *dma_buf,
> -			       struct vm_area_struct *vma)
> -{
> -	/* Not implemented. */
> -	return 0;
> -}
> -
>   static const struct dma_buf_ops dmabuf_exp_ops =  {
>   	.attach = dmabuf_exp_ops_attach,
>   	.detach = dmabuf_exp_ops_detach,
>   	.map_dma_buf = dmabuf_exp_ops_map_dma_buf,
>   	.unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
>   	.release = dmabuf_exp_ops_release,
> -	.map = dmabuf_exp_ops_kmap,
> -	.unmap = dmabuf_exp_ops_kunmap,
> -	.mmap = dmabuf_exp_ops_mmap,
>   };
>   
>   struct gntdev_dmabuf_export_args {

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Xen-devel] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

[Oleksandr Andrushchenko]

On 11/18/19 12:35 PM, Daniel Vetter wrote:
> There's no in-kernel users for the k(un)map stuff. And the mmap one is
> actively harmful - return 0 and then _not_ actually mmaping can't end
> well.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: xen-devel@lists.xenproject.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
>   drivers/xen/gntdev-dmabuf.c | 23 -----------------------
>   1 file changed, 23 deletions(-)
>
> diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
> index 2c4f324f8626..fe7bd69d6955 100644
> --- a/drivers/xen/gntdev-dmabuf.c
> +++ b/drivers/xen/gntdev-dmabuf.c
> @@ -342,35 +342,12 @@ static void dmabuf_exp_ops_release(struct dma_buf *dma_buf)
>   	mutex_unlock(&priv->lock);
>   }
>   
> -static void *dmabuf_exp_ops_kmap(struct dma_buf *dma_buf,
> -				 unsigned long page_num)
> -{
> -	/* Not implemented. */
> -	return NULL;
> -}
> -
> -static void dmabuf_exp_ops_kunmap(struct dma_buf *dma_buf,
> -				  unsigned long page_num, void *addr)
> -{
> -	/* Not implemented. */
> -}
> -
> -static int dmabuf_exp_ops_mmap(struct dma_buf *dma_buf,
> -			       struct vm_area_struct *vma)
> -{
> -	/* Not implemented. */
> -	return 0;
> -}
> -
>   static const struct dma_buf_ops dmabuf_exp_ops =  {
>   	.attach = dmabuf_exp_ops_attach,
>   	.detach = dmabuf_exp_ops_detach,
>   	.map_dma_buf = dmabuf_exp_ops_map_dma_buf,
>   	.unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
>   	.release = dmabuf_exp_ops_release,
> -	.map = dmabuf_exp_ops_kmap,
> -	.unmap = dmabuf_exp_ops_kunmap,
> -	.mmap = dmabuf_exp_ops_mmap,
>   };
>   
>   struct gntdev_dmabuf_export_args {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Intel-gfx] [Xen-devel] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

[Oleksandr Andrushchenko]

On 11/18/19 12:35 PM, Daniel Vetter wrote:
> There's no in-kernel users for the k(un)map stuff. And the mmap one is
> actively harmful - return 0 and then _not_ actually mmaping can't end
> well.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: xen-devel@lists.xenproject.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
>   drivers/xen/gntdev-dmabuf.c | 23 -----------------------
>   1 file changed, 23 deletions(-)
>
> diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
> index 2c4f324f8626..fe7bd69d6955 100644
> --- a/drivers/xen/gntdev-dmabuf.c
> +++ b/drivers/xen/gntdev-dmabuf.c
> @@ -342,35 +342,12 @@ static void dmabuf_exp_ops_release(struct dma_buf *dma_buf)
>   	mutex_unlock(&priv->lock);
>   }
>   
> -static void *dmabuf_exp_ops_kmap(struct dma_buf *dma_buf,
> -				 unsigned long page_num)
> -{
> -	/* Not implemented. */
> -	return NULL;
> -}
> -
> -static void dmabuf_exp_ops_kunmap(struct dma_buf *dma_buf,
> -				  unsigned long page_num, void *addr)
> -{
> -	/* Not implemented. */
> -}
> -
> -static int dmabuf_exp_ops_mmap(struct dma_buf *dma_buf,
> -			       struct vm_area_struct *vma)
> -{
> -	/* Not implemented. */
> -	return 0;
> -}
> -
>   static const struct dma_buf_ops dmabuf_exp_ops =  {
>   	.attach = dmabuf_exp_ops_attach,
>   	.detach = dmabuf_exp_ops_detach,
>   	.map_dma_buf = dmabuf_exp_ops_map_dma_buf,
>   	.unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
>   	.release = dmabuf_exp_ops_release,
> -	.map = dmabuf_exp_ops_kmap,
> -	.unmap = dmabuf_exp_ops_kunmap,
> -	.mmap = dmabuf_exp_ops_mmap,
>   };
>   
>   struct gntdev_dmabuf_export_args {

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Xen-devel] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

[Oleksandr Andrushchenko]

On 11/18/19 12:35 PM, Daniel Vetter wrote:
> There's no in-kernel users for the k(un)map stuff. And the mmap one is
> actively harmful - return 0 and then _not_ actually mmaping can't end
> well.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: xen-devel@lists.xenproject.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
>   drivers/xen/gntdev-dmabuf.c | 23 -----------------------
>   1 file changed, 23 deletions(-)
>
> diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
> index 2c4f324f8626..fe7bd69d6955 100644
> --- a/drivers/xen/gntdev-dmabuf.c
> +++ b/drivers/xen/gntdev-dmabuf.c
> @@ -342,35 +342,12 @@ static void dmabuf_exp_ops_release(struct dma_buf *dma_buf)
>   	mutex_unlock(&priv->lock);
>   }
>   
> -static void *dmabuf_exp_ops_kmap(struct dma_buf *dma_buf,
> -				 unsigned long page_num)
> -{
> -	/* Not implemented. */
> -	return NULL;
> -}
> -
> -static void dmabuf_exp_ops_kunmap(struct dma_buf *dma_buf,
> -				  unsigned long page_num, void *addr)
> -{
> -	/* Not implemented. */
> -}
> -
> -static int dmabuf_exp_ops_mmap(struct dma_buf *dma_buf,
> -			       struct vm_area_struct *vma)
> -{
> -	/* Not implemented. */
> -	return 0;
> -}
> -
>   static const struct dma_buf_ops dmabuf_exp_ops =  {
>   	.attach = dmabuf_exp_ops_attach,
>   	.detach = dmabuf_exp_ops_detach,
>   	.map_dma_buf = dmabuf_exp_ops_map_dma_buf,
>   	.unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
>   	.release = dmabuf_exp_ops_release,
> -	.map = dmabuf_exp_ops_kmap,
> -	.unmap = dmabuf_exp_ops_kunmap,
> -	.mmap = dmabuf_exp_ops_mmap,
>   };
>   
>   struct gntdev_dmabuf_export_args {

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

[Jürgen Groß]

On 18.11.19 11:35, Daniel Vetter wrote:
> There's no in-kernel users for the k(un)map stuff. And the mmap one is
> actively harmful - return 0 and then _not_ actually mmaping can't end
> well.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: xen-devel@lists.xenproject.org

Reviewed-by: Juergen Gross <jgross@suse.com>

> --
> Ack for merging this through drm trees very much appreciated.

Yes, I'm fine with that.


Juergen
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Xen-devel] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

[Jürgen Groß]

On 18.11.19 11:35, Daniel Vetter wrote:
> There's no in-kernel users for the k(un)map stuff. And the mmap one is
> actively harmful - return 0 and then _not_ actually mmaping can't end
> well.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: xen-devel@lists.xenproject.org

Reviewed-by: Juergen Gross <jgross@suse.com>

> --
> Ack for merging this through drm trees very much appreciated.

Yes, I'm fine with that.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Intel-gfx] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

[Jürgen Groß]

On 18.11.19 11:35, Daniel Vetter wrote:
> There's no in-kernel users for the k(un)map stuff. And the mmap one is
> actively harmful - return 0 and then _not_ actually mmaping can't end
> well.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: xen-devel@lists.xenproject.org

Reviewed-by: Juergen Gross <jgross@suse.com>

> --
> Ack for merging this through drm trees very much appreciated.

Yes, I'm fine with that.


Juergen
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

[Jürgen Groß]

On 18.11.19 11:35, Daniel Vetter wrote:
> There's no in-kernel users for the k(un)map stuff. And the mmap one is
> actively harmful - return 0 and then _not_ actually mmaping can't end
> well.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: xen-devel@lists.xenproject.org

Reviewed-by: Juergen Gross <jgross@suse.com>

> --
> Ack for merging this through drm trees very much appreciated.

Yes, I'm fine with that.


Juergen
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 14/15] sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support

[Daniel Vetter]

No in-tree users left.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Kirti Wankhede <kwankhede@nvidia.com>
Cc: kvm@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 samples/vfio-mdev/mbochs.c | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index ac5c8c17b1ff..3cc5e5921682 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -891,26 +891,10 @@ static void mbochs_release_dmabuf(struct dma_buf *buf)
 	mutex_unlock(&mdev_state->ops_lock);
 }
 
-static void *mbochs_kmap_dmabuf(struct dma_buf *buf, unsigned long page_num)
-{
-	struct mbochs_dmabuf *dmabuf = buf->priv;
-	struct page *page = dmabuf->pages[page_num];
-
-	return kmap(page);
-}
-
-static void mbochs_kunmap_dmabuf(struct dma_buf *buf, unsigned long page_num,
-				 void *vaddr)
-{
-	kunmap(vaddr);
-}
-
 static struct dma_buf_ops mbochs_dmabuf_ops = {
 	.map_dma_buf	  = mbochs_map_dmabuf,
 	.unmap_dma_buf	  = mbochs_unmap_dmabuf,
 	.release	  = mbochs_release_dmabuf,
-	.map		  = mbochs_kmap_dmabuf,
-	.unmap		  = mbochs_kunmap_dmabuf,
 	.mmap		  = mbochs_mmap_dmabuf,
 };
 
-- 
2.24.0

[Intel-gfx] [PATCH 14/15] sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support

[Daniel Vetter]

No in-tree users left.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Kirti Wankhede <kwankhede@nvidia.com>
Cc: kvm@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 samples/vfio-mdev/mbochs.c | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index ac5c8c17b1ff..3cc5e5921682 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -891,26 +891,10 @@ static void mbochs_release_dmabuf(struct dma_buf *buf)
 	mutex_unlock(&mdev_state->ops_lock);
 }
 
-static void *mbochs_kmap_dmabuf(struct dma_buf *buf, unsigned long page_num)
-{
-	struct mbochs_dmabuf *dmabuf = buf->priv;
-	struct page *page = dmabuf->pages[page_num];
-
-	return kmap(page);
-}
-
-static void mbochs_kunmap_dmabuf(struct dma_buf *buf, unsigned long page_num,
-				 void *vaddr)
-{
-	kunmap(vaddr);
-}
-
 static struct dma_buf_ops mbochs_dmabuf_ops = {
 	.map_dma_buf	  = mbochs_map_dmabuf,
 	.unmap_dma_buf	  = mbochs_unmap_dmabuf,
 	.release	  = mbochs_release_dmabuf,
-	.map		  = mbochs_kmap_dmabuf,
-	.unmap		  = mbochs_kunmap_dmabuf,
 	.mmap		  = mbochs_mmap_dmabuf,
 };
 
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 14/15] sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support

[Daniel Vetter]

No in-tree users left.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Kirti Wankhede <kwankhede@nvidia.com>
Cc: kvm@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 samples/vfio-mdev/mbochs.c | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index ac5c8c17b1ff..3cc5e5921682 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -891,26 +891,10 @@ static void mbochs_release_dmabuf(struct dma_buf *buf)
 	mutex_unlock(&mdev_state->ops_lock);
 }
 
-static void *mbochs_kmap_dmabuf(struct dma_buf *buf, unsigned long page_num)
-{
-	struct mbochs_dmabuf *dmabuf = buf->priv;
-	struct page *page = dmabuf->pages[page_num];
-
-	return kmap(page);
-}
-
-static void mbochs_kunmap_dmabuf(struct dma_buf *buf, unsigned long page_num,
-				 void *vaddr)
-{
-	kunmap(vaddr);
-}
-
 static struct dma_buf_ops mbochs_dmabuf_ops = {
 	.map_dma_buf	  = mbochs_map_dmabuf,
 	.unmap_dma_buf	  = mbochs_unmap_dmabuf,
 	.release	  = mbochs_release_dmabuf,
-	.map		  = mbochs_kmap_dmabuf,
-	.unmap		  = mbochs_kunmap_dmabuf,
 	.mmap		  = mbochs_mmap_dmabuf,
 };
 
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 14/15] sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support

[Daniel Vetter]

No in-tree users left.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Kirti Wankhede <kwankhede@nvidia.com>
Cc: kvm@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 samples/vfio-mdev/mbochs.c | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index ac5c8c17b1ff..3cc5e5921682 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -891,26 +891,10 @@ static void mbochs_release_dmabuf(struct dma_buf *buf)
 	mutex_unlock(&mdev_state->ops_lock);
 }
 
-static void *mbochs_kmap_dmabuf(struct dma_buf *buf, unsigned long page_num)
-{
-	struct mbochs_dmabuf *dmabuf = buf->priv;
-	struct page *page = dmabuf->pages[page_num];
-
-	return kmap(page);
-}
-
-static void mbochs_kunmap_dmabuf(struct dma_buf *buf, unsigned long page_num,
-				 void *vaddr)
-{
-	kunmap(vaddr);
-}
-
 static struct dma_buf_ops mbochs_dmabuf_ops = {
 	.map_dma_buf	  = mbochs_map_dmabuf,
 	.unmap_dma_buf	  = mbochs_unmap_dmabuf,
 	.release	  = mbochs_release_dmabuf,
-	.map		  = mbochs_kmap_dmabuf,
-	.unmap		  = mbochs_kunmap_dmabuf,
 	.mmap		  = mbochs_mmap_dmabuf,
 };
 
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 14/15] sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support

[Gerd Hoffmann]

On Mon, Nov 18, 2019 at 11:35:35AM +0100, Daniel Vetter wrote:
> No in-tree users left.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Kirti Wankhede <kwankhede@nvidia.com>
> Cc: kvm@vger.kernel.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel

Acked-by: Gerd Hoffmann <kraxel@redhat.com>

cheers,
  Gerd

Re: [Intel-gfx] [PATCH 14/15] sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support

[Gerd Hoffmann]

On Mon, Nov 18, 2019 at 11:35:35AM +0100, Daniel Vetter wrote:
> No in-tree users left.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Kirti Wankhede <kwankhede@nvidia.com>
> Cc: kvm@vger.kernel.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel

Acked-by: Gerd Hoffmann <kraxel@redhat.com>

cheers,
  Gerd

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 14/15] sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support

[Gerd Hoffmann]

On Mon, Nov 18, 2019 at 11:35:35AM +0100, Daniel Vetter wrote:
> No in-tree users left.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Kirti Wankhede <kwankhede@nvidia.com>
> Cc: kvm@vger.kernel.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel

Acked-by: Gerd Hoffmann <kraxel@redhat.com>

cheers,
  Gerd

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 14/15] sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support

[Gerd Hoffmann]

On Mon, Nov 18, 2019 at 11:35:35AM +0100, Daniel Vetter wrote:
> No in-tree users left.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Kirti Wankhede <kwankhede@nvidia.com>
> Cc: kvm@vger.kernel.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel

Acked-by: Gerd Hoffmann <kraxel@redhat.com>

cheers,
  Gerd

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Daniel Vetter]

All implementations are gone now.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 include/linux/dma-buf.h | 25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 7feb9c3805ae..abf5459a5b9d 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -249,31 +249,6 @@ struct dma_buf_ops {
 	 */
 	int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
 
-	/**
-	 * @map:
-	 *
-	 * Maps a page from the buffer into kernel address space. The page is
-	 * specified by offset into the buffer in PAGE_SIZE units.
-	 *
-	 * This callback is optional.
-	 *
-	 * Returns:
-	 *
-	 * Virtual address pointer where requested page can be accessed. NULL
-	 * on error or when this function is unimplemented by the exporter.
-	 */
-	void *(*map)(struct dma_buf *, unsigned long);
-
-	/**
-	 * @unmap:
-	 *
-	 * Unmaps a page from the buffer. Page offset and address pointer should
-	 * be the same as the one passed to and returned by matching call to map.
-	 *
-	 * This callback is optional.
-	 */
-	void (*unmap)(struct dma_buf *, unsigned long, void *);
-
 	void *(*vmap)(struct dma_buf *);
 	void (*vunmap)(struct dma_buf *, void *vaddr);
 };
-- 
2.24.0

[Intel-gfx] [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Daniel Vetter]

All implementations are gone now.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 include/linux/dma-buf.h | 25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 7feb9c3805ae..abf5459a5b9d 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -249,31 +249,6 @@ struct dma_buf_ops {
 	 */
 	int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
 
-	/**
-	 * @map:
-	 *
-	 * Maps a page from the buffer into kernel address space. The page is
-	 * specified by offset into the buffer in PAGE_SIZE units.
-	 *
-	 * This callback is optional.
-	 *
-	 * Returns:
-	 *
-	 * Virtual address pointer where requested page can be accessed. NULL
-	 * on error or when this function is unimplemented by the exporter.
-	 */
-	void *(*map)(struct dma_buf *, unsigned long);
-
-	/**
-	 * @unmap:
-	 *
-	 * Unmaps a page from the buffer. Page offset and address pointer should
-	 * be the same as the one passed to and returned by matching call to map.
-	 *
-	 * This callback is optional.
-	 */
-	void (*unmap)(struct dma_buf *, unsigned long, void *);
-
 	void *(*vmap)(struct dma_buf *);
 	void (*vunmap)(struct dma_buf *, void *vaddr);
 };
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Daniel Vetter]

All implementations are gone now.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 include/linux/dma-buf.h | 25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 7feb9c3805ae..abf5459a5b9d 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -249,31 +249,6 @@ struct dma_buf_ops {
 	 */
 	int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
 
-	/**
-	 * @map:
-	 *
-	 * Maps a page from the buffer into kernel address space. The page is
-	 * specified by offset into the buffer in PAGE_SIZE units.
-	 *
-	 * This callback is optional.
-	 *
-	 * Returns:
-	 *
-	 * Virtual address pointer where requested page can be accessed. NULL
-	 * on error or when this function is unimplemented by the exporter.
-	 */
-	void *(*map)(struct dma_buf *, unsigned long);
-
-	/**
-	 * @unmap:
-	 *
-	 * Unmaps a page from the buffer. Page offset and address pointer should
-	 * be the same as the one passed to and returned by matching call to map.
-	 *
-	 * This callback is optional.
-	 */
-	void (*unmap)(struct dma_buf *, unsigned long, void *);
-
 	void *(*vmap)(struct dma_buf *);
 	void (*vunmap)(struct dma_buf *, void *vaddr);
 };
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Daniel Vetter]

All implementations are gone now.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 include/linux/dma-buf.h | 25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 7feb9c3805ae..abf5459a5b9d 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -249,31 +249,6 @@ struct dma_buf_ops {
 	 */
 	int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
 
-	/**
-	 * @map:
-	 *
-	 * Maps a page from the buffer into kernel address space. The page is
-	 * specified by offset into the buffer in PAGE_SIZE units.
-	 *
-	 * This callback is optional.
-	 *
-	 * Returns:
-	 *
-	 * Virtual address pointer where requested page can be accessed. NULL
-	 * on error or when this function is unimplemented by the exporter.
-	 */
-	void *(*map)(struct dma_buf *, unsigned long);
-
-	/**
-	 * @unmap:
-	 *
-	 * Unmaps a page from the buffer. Page offset and address pointer should
-	 * be the same as the one passed to and returned by matching call to map.
-	 *
-	 * This callback is optional.
-	 */
-	void (*unmap)(struct dma_buf *, unsigned long, void *);
-
 	void *(*vmap)(struct dma_buf *);
 	void (*vunmap)(struct dma_buf *, void *vaddr);
 };
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 4145 bytes --]

Hi Daniel,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.4-rc8 next-20191115]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=m68k 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
     .map    = kmap_udmabuf,
      ^~~
      mmap
>> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .map    = kmap_udmabuf,
               ^~~~~~~~~~~~
   drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 'udmabuf_ops.begin_cpu_access')
>> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
     .unmap    = kunmap_udmabuf,
      ^~~~~
      vunmap
   drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .unmap    = kunmap_udmabuf,
                 ^~~~~~~~~~~~~~
   drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 'udmabuf_ops.end_cpu_access')
   cc1: some warnings being treated as errors
--
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
     .map   = udl_dmabuf_kmap,
      ^~~
      mmap
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .map   = udl_dmabuf_kmap,
              ^~~~~~~~~~~~~~~
   drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 'udl_dmabuf_ops.release')
>> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
     .unmap   = udl_dmabuf_kunmap,
      ^~~~~
      vunmap
   drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .unmap   = udl_dmabuf_kunmap,
                ^~~~~~~~~~~~~~~~~
   drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 'udl_dmabuf_ops.begin_cpu_access')
   cc1: some warnings being treated as errors

vim +114 drivers/dma-buf/udmabuf.c

fbb0de79507819 Gerd Hoffmann 2018-08-27  109  
a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops udmabuf_ops = {
fbb0de79507819 Gerd Hoffmann 2018-08-27  111  	.map_dma_buf	  = map_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  112  	.unmap_dma_buf	  = unmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  113  	.release	  = release_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @114  	.map		  = kmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @115  	.unmap		  = kunmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  116  	.mmap		  = mmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
fbb0de79507819 Gerd Hoffmann 2018-08-27  118  

:::::: The code at line 114 was first introduced by commit
:::::: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device

:::::: TO: Gerd Hoffmann <kraxel@redhat.com>
:::::: CC: Gerd Hoffmann <kraxel@redhat.com>

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 51379 bytes --]

Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 4230 bytes --]

Hi Daniel,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.4-rc8 next-20191115]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=m68k 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
     .map    = kmap_udmabuf,
      ^~~
      mmap
>> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .map    = kmap_udmabuf,
               ^~~~~~~~~~~~
   drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 'udmabuf_ops.begin_cpu_access')
>> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
     .unmap    = kunmap_udmabuf,
      ^~~~~
      vunmap
   drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .unmap    = kunmap_udmabuf,
                 ^~~~~~~~~~~~~~
   drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 'udmabuf_ops.end_cpu_access')
   cc1: some warnings being treated as errors
--
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
     .map   = udl_dmabuf_kmap,
      ^~~
      mmap
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .map   = udl_dmabuf_kmap,
              ^~~~~~~~~~~~~~~
   drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 'udl_dmabuf_ops.release')
>> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
     .unmap   = udl_dmabuf_kunmap,
      ^~~~~
      vunmap
   drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .unmap   = udl_dmabuf_kunmap,
                ^~~~~~~~~~~~~~~~~
   drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 'udl_dmabuf_ops.begin_cpu_access')
   cc1: some warnings being treated as errors

vim +114 drivers/dma-buf/udmabuf.c

fbb0de79507819 Gerd Hoffmann 2018-08-27  109  
a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops udmabuf_ops = {
fbb0de79507819 Gerd Hoffmann 2018-08-27  111  	.map_dma_buf	  = map_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  112  	.unmap_dma_buf	  = unmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  113  	.release	  = release_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @114  	.map		  = kmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @115  	.unmap		  = kunmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  116  	.mmap		  = mmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
fbb0de79507819 Gerd Hoffmann 2018-08-27  118  

:::::: The code at line 114 was first introduced by commit
:::::: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device

:::::: TO: Gerd Hoffmann <kraxel@redhat.com>
:::::: CC: Gerd Hoffmann <kraxel@redhat.com>

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org Intel Corporation

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 51379 bytes --]

Re: [Intel-gfx] [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 4145 bytes --]

Hi Daniel,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.4-rc8 next-20191115]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=m68k 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
     .map    = kmap_udmabuf,
      ^~~
      mmap
>> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .map    = kmap_udmabuf,
               ^~~~~~~~~~~~
   drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 'udmabuf_ops.begin_cpu_access')
>> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
     .unmap    = kunmap_udmabuf,
      ^~~~~
      vunmap
   drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .unmap    = kunmap_udmabuf,
                 ^~~~~~~~~~~~~~
   drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 'udmabuf_ops.end_cpu_access')
   cc1: some warnings being treated as errors
--
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
     .map   = udl_dmabuf_kmap,
      ^~~
      mmap
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .map   = udl_dmabuf_kmap,
              ^~~~~~~~~~~~~~~
   drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 'udl_dmabuf_ops.release')
>> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
     .unmap   = udl_dmabuf_kunmap,
      ^~~~~
      vunmap
   drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .unmap   = udl_dmabuf_kunmap,
                ^~~~~~~~~~~~~~~~~
   drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 'udl_dmabuf_ops.begin_cpu_access')
   cc1: some warnings being treated as errors

vim +114 drivers/dma-buf/udmabuf.c

fbb0de79507819 Gerd Hoffmann 2018-08-27  109  
a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops udmabuf_ops = {
fbb0de79507819 Gerd Hoffmann 2018-08-27  111  	.map_dma_buf	  = map_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  112  	.unmap_dma_buf	  = unmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  113  	.release	  = release_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @114  	.map		  = kmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @115  	.unmap		  = kunmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  116  	.mmap		  = mmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
fbb0de79507819 Gerd Hoffmann 2018-08-27  118  

:::::: The code at line 114 was first introduced by commit
:::::: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device

:::::: TO: Gerd Hoffmann <kraxel@redhat.com>
:::::: CC: Gerd Hoffmann <kraxel@redhat.com>

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 51379 bytes --]

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 4145 bytes --]

Hi Daniel,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.4-rc8 next-20191115]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=m68k 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
     .map    = kmap_udmabuf,
      ^~~
      mmap
>> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .map    = kmap_udmabuf,
               ^~~~~~~~~~~~
   drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 'udmabuf_ops.begin_cpu_access')
>> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
     .unmap    = kunmap_udmabuf,
      ^~~~~
      vunmap
   drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .unmap    = kunmap_udmabuf,
                 ^~~~~~~~~~~~~~
   drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 'udmabuf_ops.end_cpu_access')
   cc1: some warnings being treated as errors
--
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
     .map   = udl_dmabuf_kmap,
      ^~~
      mmap
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .map   = udl_dmabuf_kmap,
              ^~~~~~~~~~~~~~~
   drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 'udl_dmabuf_ops.release')
>> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
     .unmap   = udl_dmabuf_kunmap,
      ^~~~~
      vunmap
   drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .unmap   = udl_dmabuf_kunmap,
                ^~~~~~~~~~~~~~~~~
   drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 'udl_dmabuf_ops.begin_cpu_access')
   cc1: some warnings being treated as errors

vim +114 drivers/dma-buf/udmabuf.c

fbb0de79507819 Gerd Hoffmann 2018-08-27  109  
a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops udmabuf_ops = {
fbb0de79507819 Gerd Hoffmann 2018-08-27  111  	.map_dma_buf	  = map_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  112  	.unmap_dma_buf	  = unmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  113  	.release	  = release_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @114  	.map		  = kmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @115  	.unmap		  = kunmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  116  	.mmap		  = mmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
fbb0de79507819 Gerd Hoffmann 2018-08-27  118  

:::::: The code at line 114 was first introduced by commit
:::::: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device

:::::: TO: Gerd Hoffmann <kraxel@redhat.com>
:::::: CC: Gerd Hoffmann <kraxel@redhat.com>

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 51379 bytes --]

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 4145 bytes --]

Hi Daniel,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.4-rc8 next-20191115]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=m68k 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
     .map    = kmap_udmabuf,
      ^~~
      mmap
>> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .map    = kmap_udmabuf,
               ^~~~~~~~~~~~
   drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 'udmabuf_ops.begin_cpu_access')
>> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
     .unmap    = kunmap_udmabuf,
      ^~~~~
      vunmap
   drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .unmap    = kunmap_udmabuf,
                 ^~~~~~~~~~~~~~
   drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 'udmabuf_ops.end_cpu_access')
   cc1: some warnings being treated as errors
--
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
     .map   = udl_dmabuf_kmap,
      ^~~
      mmap
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .map   = udl_dmabuf_kmap,
              ^~~~~~~~~~~~~~~
   drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 'udl_dmabuf_ops.release')
>> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
     .unmap   = udl_dmabuf_kunmap,
      ^~~~~
      vunmap
   drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     .unmap   = udl_dmabuf_kunmap,
                ^~~~~~~~~~~~~~~~~
   drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 'udl_dmabuf_ops.begin_cpu_access')
   cc1: some warnings being treated as errors

vim +114 drivers/dma-buf/udmabuf.c

fbb0de79507819 Gerd Hoffmann 2018-08-27  109  
a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops udmabuf_ops = {
fbb0de79507819 Gerd Hoffmann 2018-08-27  111  	.map_dma_buf	  = map_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  112  	.unmap_dma_buf	  = unmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  113  	.release	  = release_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @114  	.map		  = kmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @115  	.unmap		  = kunmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  116  	.mmap		  = mmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
fbb0de79507819 Gerd Hoffmann 2018-08-27  118  

:::::: The code at line 114 was first introduced by commit
:::::: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device

:::::: TO: Gerd Hoffmann <kraxel@redhat.com>
:::::: CC: Gerd Hoffmann <kraxel@redhat.com>

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 51379 bytes --]

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Daniel Vetter]

On Mon, Nov 18, 2019 at 4:23 PM kbuild test robot <lkp@intel.com> wrote:
>
> Hi Daniel,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on drm-intel/for-linux-next]
> [also build test ERROR on v5.4-rc8 next-20191115]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

Too old tree, on latest drm-tip this compiles since udl has lots its
own dma-buf implementation. Also, the patch set will start to compile
once linux-next is open for 5.6.

Cheers, Daniel

>
> url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
> base:   git://anongit.freedesktop.org/drm-intel for-linux-next
> config: m68k-allmodconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 7.4.0
> reproduce:
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         GCC_VERSION=7.4.0 make.cross ARCH=m68k
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> >> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>      .map    = kmap_udmabuf,
>       ^~~
>       mmap
> >> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .map    = kmap_udmabuf,
>                ^~~~~~~~~~~~
>    drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 'udmabuf_ops.begin_cpu_access')
> >> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>      .unmap    = kunmap_udmabuf,
>       ^~~~~
>       vunmap
>    drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .unmap    = kunmap_udmabuf,
>                  ^~~~~~~~~~~~~~
>    drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 'udmabuf_ops.end_cpu_access')
>    cc1: some warnings being treated as errors
> --
> >> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>      .map   = udl_dmabuf_kmap,
>       ^~~
>       mmap
> >> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .map   = udl_dmabuf_kmap,
>               ^~~~~~~~~~~~~~~
>    drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 'udl_dmabuf_ops.release')
> >> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>      .unmap   = udl_dmabuf_kunmap,
>       ^~~~~
>       vunmap
>    drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .unmap   = udl_dmabuf_kunmap,
>                 ^~~~~~~~~~~~~~~~~
>    drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 'udl_dmabuf_ops.begin_cpu_access')
>    cc1: some warnings being treated as errors
>
> vim +114 drivers/dma-buf/udmabuf.c
>
> fbb0de79507819 Gerd Hoffmann 2018-08-27  109
> a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops udmabuf_ops = {
> fbb0de79507819 Gerd Hoffmann 2018-08-27  111    .map_dma_buf      = map_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  112    .unmap_dma_buf    = unmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  113    .release          = release_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 @114    .map              = kmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 @115    .unmap            = kunmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  116    .mmap             = mmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
> fbb0de79507819 Gerd Hoffmann 2018-08-27  118
>
> :::::: The code at line 114 was first introduced by commit
> :::::: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device
>
> :::::: TO: Gerd Hoffmann <kraxel@redhat.com>
> :::::: CC: Gerd Hoffmann <kraxel@redhat.com>
>
> ---
> 0-DAY kernel test infrastructure                 Open Source Technology Center
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Daniel Vetter]

[-- Attachment #1: Type: text/plain, Size: 4805 bytes --]

On Mon, Nov 18, 2019 at 4:23 PM kbuild test robot <lkp@intel.com> wrote:
>
> Hi Daniel,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on drm-intel/for-linux-next]
> [also build test ERROR on v5.4-rc8 next-20191115]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

Too old tree, on latest drm-tip this compiles since udl has lots its
own dma-buf implementation. Also, the patch set will start to compile
once linux-next is open for 5.6.

Cheers, Daniel

>
> url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
> base:   git://anongit.freedesktop.org/drm-intel for-linux-next
> config: m68k-allmodconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 7.4.0
> reproduce:
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         GCC_VERSION=7.4.0 make.cross ARCH=m68k
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> >> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>      .map    = kmap_udmabuf,
>       ^~~
>       mmap
> >> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .map    = kmap_udmabuf,
>                ^~~~~~~~~~~~
>    drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 'udmabuf_ops.begin_cpu_access')
> >> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>      .unmap    = kunmap_udmabuf,
>       ^~~~~
>       vunmap
>    drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .unmap    = kunmap_udmabuf,
>                  ^~~~~~~~~~~~~~
>    drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 'udmabuf_ops.end_cpu_access')
>    cc1: some warnings being treated as errors
> --
> >> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>      .map   = udl_dmabuf_kmap,
>       ^~~
>       mmap
> >> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .map   = udl_dmabuf_kmap,
>               ^~~~~~~~~~~~~~~
>    drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 'udl_dmabuf_ops.release')
> >> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>      .unmap   = udl_dmabuf_kunmap,
>       ^~~~~
>       vunmap
>    drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .unmap   = udl_dmabuf_kunmap,
>                 ^~~~~~~~~~~~~~~~~
>    drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 'udl_dmabuf_ops.begin_cpu_access')
>    cc1: some warnings being treated as errors
>
> vim +114 drivers/dma-buf/udmabuf.c
>
> fbb0de79507819 Gerd Hoffmann 2018-08-27  109
> a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops udmabuf_ops = {
> fbb0de79507819 Gerd Hoffmann 2018-08-27  111    .map_dma_buf      = map_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  112    .unmap_dma_buf    = unmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  113    .release          = release_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 @114    .map              = kmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 @115    .unmap            = kunmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  116    .mmap             = mmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
> fbb0de79507819 Gerd Hoffmann 2018-08-27  118
>
> :::::: The code at line 114 was first introduced by commit
> :::::: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device
>
> :::::: TO: Gerd Hoffmann <kraxel@redhat.com>
> :::::: CC: Gerd Hoffmann <kraxel@redhat.com>
>
> ---
> 0-DAY kernel test infrastructure                 Open Source Technology Center
> https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org Intel Corporation



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Daniel Vetter]

On Mon, Nov 18, 2019 at 4:23 PM kbuild test robot <lkp@intel.com> wrote:
>
> Hi Daniel,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on drm-intel/for-linux-next]
> [also build test ERROR on v5.4-rc8 next-20191115]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

Too old tree, on latest drm-tip this compiles since udl has lots its
own dma-buf implementation. Also, the patch set will start to compile
once linux-next is open for 5.6.

Cheers, Daniel

>
> url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
> base:   git://anongit.freedesktop.org/drm-intel for-linux-next
> config: m68k-allmodconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 7.4.0
> reproduce:
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         GCC_VERSION=7.4.0 make.cross ARCH=m68k
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> >> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>      .map    = kmap_udmabuf,
>       ^~~
>       mmap
> >> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .map    = kmap_udmabuf,
>                ^~~~~~~~~~~~
>    drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 'udmabuf_ops.begin_cpu_access')
> >> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>      .unmap    = kunmap_udmabuf,
>       ^~~~~
>       vunmap
>    drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .unmap    = kunmap_udmabuf,
>                  ^~~~~~~~~~~~~~
>    drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 'udmabuf_ops.end_cpu_access')
>    cc1: some warnings being treated as errors
> --
> >> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>      .map   = udl_dmabuf_kmap,
>       ^~~
>       mmap
> >> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .map   = udl_dmabuf_kmap,
>               ^~~~~~~~~~~~~~~
>    drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 'udl_dmabuf_ops.release')
> >> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>      .unmap   = udl_dmabuf_kunmap,
>       ^~~~~
>       vunmap
>    drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .unmap   = udl_dmabuf_kunmap,
>                 ^~~~~~~~~~~~~~~~~
>    drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 'udl_dmabuf_ops.begin_cpu_access')
>    cc1: some warnings being treated as errors
>
> vim +114 drivers/dma-buf/udmabuf.c
>
> fbb0de79507819 Gerd Hoffmann 2018-08-27  109
> a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops udmabuf_ops = {
> fbb0de79507819 Gerd Hoffmann 2018-08-27  111    .map_dma_buf      = map_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  112    .unmap_dma_buf    = unmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  113    .release          = release_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 @114    .map              = kmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 @115    .unmap            = kunmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  116    .mmap             = mmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
> fbb0de79507819 Gerd Hoffmann 2018-08-27  118
>
> :::::: The code at line 114 was first introduced by commit
> :::::: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device
>
> :::::: TO: Gerd Hoffmann <kraxel@redhat.com>
> :::::: CC: Gerd Hoffmann <kraxel@redhat.com>
>
> ---
> 0-DAY kernel test infrastructure                 Open Source Technology Center
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Daniel Vetter]

On Mon, Nov 18, 2019 at 4:23 PM kbuild test robot <lkp@intel.com> wrote:
>
> Hi Daniel,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on drm-intel/for-linux-next]
> [also build test ERROR on v5.4-rc8 next-20191115]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

Too old tree, on latest drm-tip this compiles since udl has lots its
own dma-buf implementation. Also, the patch set will start to compile
once linux-next is open for 5.6.

Cheers, Daniel

>
> url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
> base:   git://anongit.freedesktop.org/drm-intel for-linux-next
> config: m68k-allmodconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 7.4.0
> reproduce:
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         GCC_VERSION=7.4.0 make.cross ARCH=m68k
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> >> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>      .map    = kmap_udmabuf,
>       ^~~
>       mmap
> >> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .map    = kmap_udmabuf,
>                ^~~~~~~~~~~~
>    drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 'udmabuf_ops.begin_cpu_access')
> >> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>      .unmap    = kunmap_udmabuf,
>       ^~~~~
>       vunmap
>    drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .unmap    = kunmap_udmabuf,
>                  ^~~~~~~~~~~~~~
>    drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 'udmabuf_ops.end_cpu_access')
>    cc1: some warnings being treated as errors
> --
> >> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>      .map   = udl_dmabuf_kmap,
>       ^~~
>       mmap
> >> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .map   = udl_dmabuf_kmap,
>               ^~~~~~~~~~~~~~~
>    drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 'udl_dmabuf_ops.release')
> >> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>      .unmap   = udl_dmabuf_kunmap,
>       ^~~~~
>       vunmap
>    drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>      .unmap   = udl_dmabuf_kunmap,
>                 ^~~~~~~~~~~~~~~~~
>    drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 'udl_dmabuf_ops.begin_cpu_access')
>    cc1: some warnings being treated as errors
>
> vim +114 drivers/dma-buf/udmabuf.c
>
> fbb0de79507819 Gerd Hoffmann 2018-08-27  109
> a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops udmabuf_ops = {
> fbb0de79507819 Gerd Hoffmann 2018-08-27  111    .map_dma_buf      = map_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  112    .unmap_dma_buf    = unmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  113    .release          = release_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 @114    .map              = kmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 @115    .unmap            = kunmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  116    .mmap             = mmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
> fbb0de79507819 Gerd Hoffmann 2018-08-27  118
>
> :::::: The code at line 114 was first introduced by commit
> :::::: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device
>
> :::::: TO: Gerd Hoffmann <kraxel@redhat.com>
> :::::: CC: Gerd Hoffmann <kraxel@redhat.com>
>
> ---
> 0-DAY kernel test infrastructure                 Open Source Technology Center
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [kbuild-all] Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Rong Chen]

On 11/19/19 12:43 AM, Daniel Vetter wrote:
> On Mon, Nov 18, 2019 at 4:23 PM kbuild test robot <lkp@intel.com> wrote:
>> Hi Daniel,
>>
>> I love your patch! Yet something to improve:
>>
>> [auto build test ERROR on drm-intel/for-linux-next]
>> [also build test ERROR on v5.4-rc8 next-20191115]
>> [if your patch is applied to the wrong git tree, please drop us a note to help
>> improve the system. BTW, we also suggest to use '--base' option to specify the
>> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
> Too old tree, on latest drm-tip this compiles since udl has lots its
> own dma-buf implementation. Also, the patch set will start to compile
> once linux-next is open for 5.6.
>
> Cheers, Daniel

Hi Daniel,

Thanks for clarifying, we'll take a look at the wrong base.

Best Regards,
Rong Chen

>
>> url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
>> base:   git://anongit.freedesktop.org/drm-intel for-linux-next
>> config: m68k-allmodconfig (attached as .config)
>> compiler: m68k-linux-gcc (GCC) 7.4.0
>> reproduce:
>>          wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>          chmod +x ~/bin/make.cross
>>          # save the attached .config to linux build tree
>>          GCC_VERSION=7.4.0 make.cross ARCH=m68k
>>
>> If you fix the issue, kindly add following tag
>> Reported-by: kbuild test robot <lkp@intel.com>
>>
>> All errors (new ones prefixed by >>):
>>
>>>> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>>       .map    = kmap_udmabuf,
>>        ^~~
>>        mmap
>>>> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .map    = kmap_udmabuf,
>>                 ^~~~~~~~~~~~
>>     drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 'udmabuf_ops.begin_cpu_access')
>>>> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>>       .unmap    = kunmap_udmabuf,
>>        ^~~~~
>>        vunmap
>>     drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .unmap    = kunmap_udmabuf,
>>                   ^~~~~~~~~~~~~~
>>     drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 'udmabuf_ops.end_cpu_access')
>>     cc1: some warnings being treated as errors
>> --
>>>> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>>       .map   = udl_dmabuf_kmap,
>>        ^~~
>>        mmap
>>>> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .map   = udl_dmabuf_kmap,
>>                ^~~~~~~~~~~~~~~
>>     drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 'udl_dmabuf_ops.release')
>>>> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>>       .unmap   = udl_dmabuf_kunmap,
>>        ^~~~~
>>        vunmap
>>     drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .unmap   = udl_dmabuf_kunmap,
>>                  ^~~~~~~~~~~~~~~~~
>>     drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 'udl_dmabuf_ops.begin_cpu_access')
>>     cc1: some warnings being treated as errors
>>
>> vim +114 drivers/dma-buf/udmabuf.c
>>
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  109
>> a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops udmabuf_ops = {
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  111    .map_dma_buf      = map_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  112    .unmap_dma_buf    = unmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  113    .release          = release_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27 @114    .map              = kmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27 @115    .unmap            = kunmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  116    .mmap             = mmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  118
>>
>> :::::: The code at line 114 was first introduced by commit
>> :::::: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device
>>
>> :::::: TO: Gerd Hoffmann <kraxel@redhat.com>
>> :::::: CC: Gerd Hoffmann <kraxel@redhat.com>
>>
>> ---
>> 0-DAY kernel test infrastructure                 Open Source Technology Center
>> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation
>
>

Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Rong Chen]

[-- Attachment #1: Type: text/plain, Size: 4971 bytes --]



On 11/19/19 12:43 AM, Daniel Vetter wrote:
> On Mon, Nov 18, 2019 at 4:23 PM kbuild test robot <lkp@intel.com> wrote:
>> Hi Daniel,
>>
>> I love your patch! Yet something to improve:
>>
>> [auto build test ERROR on drm-intel/for-linux-next]
>> [also build test ERROR on v5.4-rc8 next-20191115]
>> [if your patch is applied to the wrong git tree, please drop us a note to help
>> improve the system. BTW, we also suggest to use '--base' option to specify the
>> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
> Too old tree, on latest drm-tip this compiles since udl has lots its
> own dma-buf implementation. Also, the patch set will start to compile
> once linux-next is open for 5.6.
>
> Cheers, Daniel

Hi Daniel,

Thanks for clarifying, we'll take a look at the wrong base.

Best Regards,
Rong Chen

>
>> url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
>> base:   git://anongit.freedesktop.org/drm-intel for-linux-next
>> config: m68k-allmodconfig (attached as .config)
>> compiler: m68k-linux-gcc (GCC) 7.4.0
>> reproduce:
>>          wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>          chmod +x ~/bin/make.cross
>>          # save the attached .config to linux build tree
>>          GCC_VERSION=7.4.0 make.cross ARCH=m68k
>>
>> If you fix the issue, kindly add following tag
>> Reported-by: kbuild test robot <lkp@intel.com>
>>
>> All errors (new ones prefixed by >>):
>>
>>>> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>>       .map    = kmap_udmabuf,
>>        ^~~
>>        mmap
>>>> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .map    = kmap_udmabuf,
>>                 ^~~~~~~~~~~~
>>     drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 'udmabuf_ops.begin_cpu_access')
>>>> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>>       .unmap    = kunmap_udmabuf,
>>        ^~~~~
>>        vunmap
>>     drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .unmap    = kunmap_udmabuf,
>>                   ^~~~~~~~~~~~~~
>>     drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 'udmabuf_ops.end_cpu_access')
>>     cc1: some warnings being treated as errors
>> --
>>>> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>>       .map   = udl_dmabuf_kmap,
>>        ^~~
>>        mmap
>>>> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .map   = udl_dmabuf_kmap,
>>                ^~~~~~~~~~~~~~~
>>     drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 'udl_dmabuf_ops.release')
>>>> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>>       .unmap   = udl_dmabuf_kunmap,
>>        ^~~~~
>>        vunmap
>>     drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .unmap   = udl_dmabuf_kunmap,
>>                  ^~~~~~~~~~~~~~~~~
>>     drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 'udl_dmabuf_ops.begin_cpu_access')
>>     cc1: some warnings being treated as errors
>>
>> vim +114 drivers/dma-buf/udmabuf.c
>>
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  109
>> a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops udmabuf_ops = {
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  111    .map_dma_buf      = map_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  112    .unmap_dma_buf    = unmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  113    .release          = release_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27 @114    .map              = kmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27 @115    .unmap            = kunmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  116    .mmap             = mmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  118
>>
>> :::::: The code at line 114 was first introduced by commit
>> :::::: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device
>>
>> :::::: TO: Gerd Hoffmann <kraxel@redhat.com>
>> :::::: CC: Gerd Hoffmann <kraxel@redhat.com>
>>
>> ---
>> 0-DAY kernel test infrastructure                 Open Source Technology Center
>> https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org Intel Corporation
>
>

Re: [Intel-gfx] [kbuild-all] Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Rong Chen]

On 11/19/19 12:43 AM, Daniel Vetter wrote:
> On Mon, Nov 18, 2019 at 4:23 PM kbuild test robot <lkp@intel.com> wrote:
>> Hi Daniel,
>>
>> I love your patch! Yet something to improve:
>>
>> [auto build test ERROR on drm-intel/for-linux-next]
>> [also build test ERROR on v5.4-rc8 next-20191115]
>> [if your patch is applied to the wrong git tree, please drop us a note to help
>> improve the system. BTW, we also suggest to use '--base' option to specify the
>> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
> Too old tree, on latest drm-tip this compiles since udl has lots its
> own dma-buf implementation. Also, the patch set will start to compile
> once linux-next is open for 5.6.
>
> Cheers, Daniel

Hi Daniel,

Thanks for clarifying, we'll take a look at the wrong base.

Best Regards,
Rong Chen

>
>> url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
>> base:   git://anongit.freedesktop.org/drm-intel for-linux-next
>> config: m68k-allmodconfig (attached as .config)
>> compiler: m68k-linux-gcc (GCC) 7.4.0
>> reproduce:
>>          wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>          chmod +x ~/bin/make.cross
>>          # save the attached .config to linux build tree
>>          GCC_VERSION=7.4.0 make.cross ARCH=m68k
>>
>> If you fix the issue, kindly add following tag
>> Reported-by: kbuild test robot <lkp@intel.com>
>>
>> All errors (new ones prefixed by >>):
>>
>>>> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>>       .map    = kmap_udmabuf,
>>        ^~~
>>        mmap
>>>> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .map    = kmap_udmabuf,
>>                 ^~~~~~~~~~~~
>>     drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 'udmabuf_ops.begin_cpu_access')
>>>> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>>       .unmap    = kunmap_udmabuf,
>>        ^~~~~
>>        vunmap
>>     drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .unmap    = kunmap_udmabuf,
>>                   ^~~~~~~~~~~~~~
>>     drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 'udmabuf_ops.end_cpu_access')
>>     cc1: some warnings being treated as errors
>> --
>>>> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>>       .map   = udl_dmabuf_kmap,
>>        ^~~
>>        mmap
>>>> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .map   = udl_dmabuf_kmap,
>>                ^~~~~~~~~~~~~~~
>>     drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 'udl_dmabuf_ops.release')
>>>> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>>       .unmap   = udl_dmabuf_kunmap,
>>        ^~~~~
>>        vunmap
>>     drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .unmap   = udl_dmabuf_kunmap,
>>                  ^~~~~~~~~~~~~~~~~
>>     drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 'udl_dmabuf_ops.begin_cpu_access')
>>     cc1: some warnings being treated as errors
>>
>> vim +114 drivers/dma-buf/udmabuf.c
>>
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  109
>> a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops udmabuf_ops = {
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  111    .map_dma_buf      = map_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  112    .unmap_dma_buf    = unmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  113    .release          = release_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27 @114    .map              = kmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27 @115    .unmap            = kunmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  116    .mmap             = mmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  118
>>
>> :::::: The code at line 114 was first introduced by commit
>> :::::: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device
>>
>> :::::: TO: Gerd Hoffmann <kraxel@redhat.com>
>> :::::: CC: Gerd Hoffmann <kraxel@redhat.com>
>>
>> ---
>> 0-DAY kernel test infrastructure                 Open Source Technology Center
>> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation
>
>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [kbuild-all] Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Rong Chen]

On 11/19/19 12:43 AM, Daniel Vetter wrote:
> On Mon, Nov 18, 2019 at 4:23 PM kbuild test robot <lkp@intel.com> wrote:
>> Hi Daniel,
>>
>> I love your patch! Yet something to improve:
>>
>> [auto build test ERROR on drm-intel/for-linux-next]
>> [also build test ERROR on v5.4-rc8 next-20191115]
>> [if your patch is applied to the wrong git tree, please drop us a note to help
>> improve the system. BTW, we also suggest to use '--base' option to specify the
>> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
> Too old tree, on latest drm-tip this compiles since udl has lots its
> own dma-buf implementation. Also, the patch set will start to compile
> once linux-next is open for 5.6.
>
> Cheers, Daniel

Hi Daniel,

Thanks for clarifying, we'll take a look at the wrong base.

Best Regards,
Rong Chen

>
>> url:    https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
>> base:   git://anongit.freedesktop.org/drm-intel for-linux-next
>> config: m68k-allmodconfig (attached as .config)
>> compiler: m68k-linux-gcc (GCC) 7.4.0
>> reproduce:
>>          wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>          chmod +x ~/bin/make.cross
>>          # save the attached .config to linux build tree
>>          GCC_VERSION=7.4.0 make.cross ARCH=m68k
>>
>> If you fix the issue, kindly add following tag
>> Reported-by: kbuild test robot <lkp@intel.com>
>>
>> All errors (new ones prefixed by >>):
>>
>>>> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>>       .map    = kmap_udmabuf,
>>        ^~~
>>        mmap
>>>> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .map    = kmap_udmabuf,
>>                 ^~~~~~~~~~~~
>>     drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 'udmabuf_ops.begin_cpu_access')
>>>> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>>       .unmap    = kunmap_udmabuf,
>>        ^~~~~
>>        vunmap
>>     drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .unmap    = kunmap_udmabuf,
>>                   ^~~~~~~~~~~~~~
>>     drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 'udmabuf_ops.end_cpu_access')
>>     cc1: some warnings being treated as errors
>> --
>>>> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' has no member named 'map'; did you mean 'mmap'?
>>       .map   = udl_dmabuf_kmap,
>>        ^~~
>>        mmap
>>>> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .map   = udl_dmabuf_kmap,
>>                ^~~~~~~~~~~~~~~
>>     drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 'udl_dmabuf_ops.release')
>>>> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' has no member named 'unmap'; did you mean 'vunmap'?
>>       .unmap   = udl_dmabuf_kunmap,
>>        ^~~~~
>>        vunmap
>>     drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       .unmap   = udl_dmabuf_kunmap,
>>                  ^~~~~~~~~~~~~~~~~
>>     drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 'udl_dmabuf_ops.begin_cpu_access')
>>     cc1: some warnings being treated as errors
>>
>> vim +114 drivers/dma-buf/udmabuf.c
>>
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  109
>> a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops udmabuf_ops = {
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  111    .map_dma_buf      = map_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  112    .unmap_dma_buf    = unmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  113    .release          = release_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27 @114    .map              = kmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27 @115    .unmap            = kunmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  116    .mmap             = mmap_udmabuf,
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
>> fbb0de79507819 Gerd Hoffmann 2018-08-27  118
>>
>> :::::: The code at line 114 was first introduced by commit
>> :::::: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device
>>
>> :::::: TO: Gerd Hoffmann <kraxel@redhat.com>
>> :::::: CC: Gerd Hoffmann <kraxel@redhat.com>
>>
>> ---
>> 0-DAY kernel test infrastructure                 Open Source Technology Center
>> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation
>
>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Daniel Vetter]

On Mon, Nov 18, 2019 at 11:35:36AM +0100, Daniel Vetter wrote:
> All implementations are gone now.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: linux-media@vger.kernel.org
> Cc: linaro-mm-sig@lists.linaro.org

Applied the final two patches of this series now too.
-Daniel

> ---
>  include/linux/dma-buf.h | 25 -------------------------
>  1 file changed, 25 deletions(-)
> 
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 7feb9c3805ae..abf5459a5b9d 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -249,31 +249,6 @@ struct dma_buf_ops {
>  	 */
>  	int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
>  
> -	/**
> -	 * @map:
> -	 *
> -	 * Maps a page from the buffer into kernel address space. The page is
> -	 * specified by offset into the buffer in PAGE_SIZE units.
> -	 *
> -	 * This callback is optional.
> -	 *
> -	 * Returns:
> -	 *
> -	 * Virtual address pointer where requested page can be accessed. NULL
> -	 * on error or when this function is unimplemented by the exporter.
> -	 */
> -	void *(*map)(struct dma_buf *, unsigned long);
> -
> -	/**
> -	 * @unmap:
> -	 *
> -	 * Unmaps a page from the buffer. Page offset and address pointer should
> -	 * be the same as the one passed to and returned by matching call to map.
> -	 *
> -	 * This callback is optional.
> -	 */
> -	void (*unmap)(struct dma_buf *, unsigned long, void *);
> -
>  	void *(*vmap)(struct dma_buf *);
>  	void (*vunmap)(struct dma_buf *, void *vaddr);
>  };
> -- 
> 2.24.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Daniel Vetter]

On Mon, Nov 18, 2019 at 11:35:36AM +0100, Daniel Vetter wrote:
> All implementations are gone now.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: linux-media@vger.kernel.org
> Cc: linaro-mm-sig@lists.linaro.org

Applied the final two patches of this series now too.
-Daniel

> ---
>  include/linux/dma-buf.h | 25 -------------------------
>  1 file changed, 25 deletions(-)
> 
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 7feb9c3805ae..abf5459a5b9d 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -249,31 +249,6 @@ struct dma_buf_ops {
>  	 */
>  	int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
>  
> -	/**
> -	 * @map:
> -	 *
> -	 * Maps a page from the buffer into kernel address space. The page is
> -	 * specified by offset into the buffer in PAGE_SIZE units.
> -	 *
> -	 * This callback is optional.
> -	 *
> -	 * Returns:
> -	 *
> -	 * Virtual address pointer where requested page can be accessed. NULL
> -	 * on error or when this function is unimplemented by the exporter.
> -	 */
> -	void *(*map)(struct dma_buf *, unsigned long);
> -
> -	/**
> -	 * @unmap:
> -	 *
> -	 * Unmaps a page from the buffer. Page offset and address pointer should
> -	 * be the same as the one passed to and returned by matching call to map.
> -	 *
> -	 * This callback is optional.
> -	 */
> -	void (*unmap)(struct dma_buf *, unsigned long, void *);
> -
>  	void *(*vmap)(struct dma_buf *);
>  	void (*vunmap)(struct dma_buf *, void *vaddr);
>  };
> -- 
> 2.24.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

[Daniel Vetter]

On Mon, Nov 18, 2019 at 11:35:36AM +0100, Daniel Vetter wrote:
> All implementations are gone now.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: linux-media@vger.kernel.org
> Cc: linaro-mm-sig@lists.linaro.org

Applied the final two patches of this series now too.
-Daniel

> ---
>  include/linux/dma-buf.h | 25 -------------------------
>  1 file changed, 25 deletions(-)
> 
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 7feb9c3805ae..abf5459a5b9d 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -249,31 +249,6 @@ struct dma_buf_ops {
>  	 */
>  	int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
>  
> -	/**
> -	 * @map:
> -	 *
> -	 * Maps a page from the buffer into kernel address space. The page is
> -	 * specified by offset into the buffer in PAGE_SIZE units.
> -	 *
> -	 * This callback is optional.
> -	 *
> -	 * Returns:
> -	 *
> -	 * Virtual address pointer where requested page can be accessed. NULL
> -	 * on error or when this function is unimplemented by the exporter.
> -	 */
> -	void *(*map)(struct dma_buf *, unsigned long);
> -
> -	/**
> -	 * @unmap:
> -	 *
> -	 * Unmaps a page from the buffer. Page offset and address pointer should
> -	 * be the same as the one passed to and returned by matching call to map.
> -	 *
> -	 * This callback is optional.
> -	 */
> -	void (*unmap)(struct dma_buf *, unsigned long, void *);
> -
>  	void *(*vmap)(struct dma_buf *);
>  	void (*vunmap)(struct dma_buf *, void *vaddr);
>  };
> -- 
> 2.24.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

✗ Fi.CI.CHECKPATCH: warning for Retire dma_buf_k(un)map

[Patchwork]

== Series Details ==

Series: Retire dma_buf_k(un)map
URL   : https://patchwork.freedesktop.org/series/69616/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
4c6a4728b6b2 drm/tegra: Map cmdbuf once for reloc processing
-:73: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 43 lines checked
4e767396c955 drm/tegra: Delete host1x_bo_ops->k(un)map
-:95: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 65 lines checked
59215a0d0fd8 drm/i915: Remove dma_buf_kmap selftest
-:135: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 113 lines checked
03af633b49d7 staging/android/ion: delete dma_buf->kmap/unmap implemenation
-:4: WARNING:TYPO_SPELLING: 'implemenation' may be misspelled - perhaps 'implementation'?
#4: 
Subject: [PATCH] staging/android/ion: delete dma_buf->kmap/unmap implemenation

-:11: WARNING:TYPO_SPELLING: 'implemenation' may be misspelled - perhaps 'implementation'?
#11: 
implemenation.

-:51: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 3 warnings, 0 checks, 26 lines checked
985f778728c5 drm/armada: Delete dma_buf->k(un)map implemenation
-:4: WARNING:TYPO_SPELLING: 'implemenation' may be misspelled - perhaps 'implementation'?
#4: 
Subject: [PATCH] drm/armada: Delete dma_buf->k(un)map implemenation

-:40: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 2 warnings, 0 checks, 24 lines checked
039c203e8d68 drm/i915: Drop dma_buf->k(un)map
-:111: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 76 lines checked
08b98defec59 drm/omapdrm: Drop dma_buf->k(un)map
-:9: WARNING:TYPO_SPELLING: 'implemenation' may be misspelled - perhaps 'implementation'?
#9: 
that provided a kmap, but not a vmap implemenation. Given that the

-:55: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 2 warnings, 0 checks, 33 lines checked
92e11aa1752d drm/tegra: Remove dma_buf->k(un)map
-:42: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 24 lines checked
8329ea9797e4 dma-buf: Drop dma_buf_k(un)map
-:118: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 83 lines checked
91d8088a8fe6 drm/vmwgfx: Delete mmaping functions
-:71: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 45 lines checked
a0db1db5b4cc media/videobuf2: Drop dma_buf->k(un)map support
-:94: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 60 lines checked
973d8ca089b6 drm/tee_shm: Drop dma_buf_k(unmap) support
-:64: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 38 lines checked
6b42ade9bc8f xen/gntdev-dmabuf: Ditch dummy map functions
-:57: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 35 lines checked
a6d61e4e0454 sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support
-:43: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 26 lines checked
23be2279c0eb dma-buf: Remove kernel map/unmap hooks
-:48: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 31 lines checked

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Retire dma_buf_k(un)map

[Patchwork]

== Series Details ==

Series: Retire dma_buf_k(un)map
URL   : https://patchwork.freedesktop.org/series/69616/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
4c6a4728b6b2 drm/tegra: Map cmdbuf once for reloc processing
-:73: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 43 lines checked
4e767396c955 drm/tegra: Delete host1x_bo_ops->k(un)map
-:95: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 65 lines checked
59215a0d0fd8 drm/i915: Remove dma_buf_kmap selftest
-:135: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 113 lines checked
03af633b49d7 staging/android/ion: delete dma_buf->kmap/unmap implemenation
-:4: WARNING:TYPO_SPELLING: 'implemenation' may be misspelled - perhaps 'implementation'?
#4: 
Subject: [PATCH] staging/android/ion: delete dma_buf->kmap/unmap implemenation

-:11: WARNING:TYPO_SPELLING: 'implemenation' may be misspelled - perhaps 'implementation'?
#11: 
implemenation.

-:51: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 3 warnings, 0 checks, 26 lines checked
985f778728c5 drm/armada: Delete dma_buf->k(un)map implemenation
-:4: WARNING:TYPO_SPELLING: 'implemenation' may be misspelled - perhaps 'implementation'?
#4: 
Subject: [PATCH] drm/armada: Delete dma_buf->k(un)map implemenation

-:40: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 2 warnings, 0 checks, 24 lines checked
039c203e8d68 drm/i915: Drop dma_buf->k(un)map
-:111: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 76 lines checked
08b98defec59 drm/omapdrm: Drop dma_buf->k(un)map
-:9: WARNING:TYPO_SPELLING: 'implemenation' may be misspelled - perhaps 'implementation'?
#9: 
that provided a kmap, but not a vmap implemenation. Given that the

-:55: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 2 warnings, 0 checks, 33 lines checked
92e11aa1752d drm/tegra: Remove dma_buf->k(un)map
-:42: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 24 lines checked
8329ea9797e4 dma-buf: Drop dma_buf_k(un)map
-:118: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 83 lines checked
91d8088a8fe6 drm/vmwgfx: Delete mmaping functions
-:71: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 45 lines checked
a0db1db5b4cc media/videobuf2: Drop dma_buf->k(un)map support
-:94: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 60 lines checked
973d8ca089b6 drm/tee_shm: Drop dma_buf_k(unmap) support
-:64: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 38 lines checked
6b42ade9bc8f xen/gntdev-dmabuf: Ditch dummy map functions
-:57: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 35 lines checked
a6d61e4e0454 sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support
-:43: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 26 lines checked
23be2279c0eb dma-buf: Remove kernel map/unmap hooks
-:48: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 31 lines checked

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for Retire dma_buf_k(un)map

[Patchwork]

== Series Details ==

Series: Retire dma_buf_k(un)map
URL   : https://patchwork.freedesktop.org/series/69616/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7361 -> Patchwork_15311
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/index.html

Known issues
------------

  Here are the changes found in Patchwork_15311 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@kms_frontbuffer_tracking@basic:
    - fi-hsw-peppy:       [PASS][1] -> [DMESG-WARN][2] ([fdo#102614])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html

  
#### Possible fixes ####

  * igt@i915_module_load@reload-with-fault-injection:
    - {fi-kbl-7560u}:     [DMESG-WARN][3] ([fdo#112260]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-kbl-7560u/igt@i915_module_load@reload-with-fault-injection.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-kbl-7560u/igt@i915_module_load@reload-with-fault-injection.html

  * igt@i915_selftest@live_blt:
    - fi-hsw-4770r:       [DMESG-FAIL][5] -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-4770r/igt@i915_selftest@live_blt.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-hsw-4770r/igt@i915_selftest@live_blt.html
    - fi-hsw-peppy:       [DMESG-FAIL][7] ([fdo#112147]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [FAIL][9] ([fdo#111045] / [fdo#111096]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147
  [fdo#112260]: https://bugs.freedesktop.org/show_bug.cgi?id=112260


Participating hosts (50 -> 44)
------------------------------

  Additional (1): fi-icl-y 
  Missing    (7): fi-tgl-u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7361 -> Patchwork_15311

  CI-20190529: 20190529
  CI_DRM_7361: 9dff9fddfefbd9c185b84b30e24a78687dce62c8 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5292: ea9cd47fdb72c16d5ec84c04a85122c451c30025 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15311: 23be2279c0ebd531d05bc41cfbef57d2ffe879b7 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

23be2279c0eb dma-buf: Remove kernel map/unmap hooks
a6d61e4e0454 sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support
6b42ade9bc8f xen/gntdev-dmabuf: Ditch dummy map functions
973d8ca089b6 drm/tee_shm: Drop dma_buf_k(unmap) support
a0db1db5b4cc media/videobuf2: Drop dma_buf->k(un)map support
91d8088a8fe6 drm/vmwgfx: Delete mmaping functions
8329ea9797e4 dma-buf: Drop dma_buf_k(un)map
92e11aa1752d drm/tegra: Remove dma_buf->k(un)map
08b98defec59 drm/omapdrm: Drop dma_buf->k(un)map
039c203e8d68 drm/i915: Drop dma_buf->k(un)map
985f778728c5 drm/armada: Delete dma_buf->k(un)map implemenation
03af633b49d7 staging/android/ion: delete dma_buf->kmap/unmap implemenation
59215a0d0fd8 drm/i915: Remove dma_buf_kmap selftest
4e767396c955 drm/tegra: Delete host1x_bo_ops->k(un)map
4c6a4728b6b2 drm/tegra: Map cmdbuf once for reloc processing

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Retire dma_buf_k(un)map

[Patchwork]

== Series Details ==

Series: Retire dma_buf_k(un)map
URL   : https://patchwork.freedesktop.org/series/69616/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7361 -> Patchwork_15311
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/index.html

Known issues
------------

  Here are the changes found in Patchwork_15311 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@kms_frontbuffer_tracking@basic:
    - fi-hsw-peppy:       [PASS][1] -> [DMESG-WARN][2] ([fdo#102614])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html

  
#### Possible fixes ####

  * igt@i915_module_load@reload-with-fault-injection:
    - {fi-kbl-7560u}:     [DMESG-WARN][3] ([fdo#112260]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-kbl-7560u/igt@i915_module_load@reload-with-fault-injection.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-kbl-7560u/igt@i915_module_load@reload-with-fault-injection.html

  * igt@i915_selftest@live_blt:
    - fi-hsw-4770r:       [DMESG-FAIL][5] -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-4770r/igt@i915_selftest@live_blt.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-hsw-4770r/igt@i915_selftest@live_blt.html
    - fi-hsw-peppy:       [DMESG-FAIL][7] ([fdo#112147]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [FAIL][9] ([fdo#111045] / [fdo#111096]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147
  [fdo#112260]: https://bugs.freedesktop.org/show_bug.cgi?id=112260


Participating hosts (50 -> 44)
------------------------------

  Additional (1): fi-icl-y 
  Missing    (7): fi-tgl-u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7361 -> Patchwork_15311

  CI-20190529: 20190529
  CI_DRM_7361: 9dff9fddfefbd9c185b84b30e24a78687dce62c8 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5292: ea9cd47fdb72c16d5ec84c04a85122c451c30025 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15311: 23be2279c0ebd531d05bc41cfbef57d2ffe879b7 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

23be2279c0eb dma-buf: Remove kernel map/unmap hooks
a6d61e4e0454 sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support
6b42ade9bc8f xen/gntdev-dmabuf: Ditch dummy map functions
973d8ca089b6 drm/tee_shm: Drop dma_buf_k(unmap) support
a0db1db5b4cc media/videobuf2: Drop dma_buf->k(un)map support
91d8088a8fe6 drm/vmwgfx: Delete mmaping functions
8329ea9797e4 dma-buf: Drop dma_buf_k(un)map
92e11aa1752d drm/tegra: Remove dma_buf->k(un)map
08b98defec59 drm/omapdrm: Drop dma_buf->k(un)map
039c203e8d68 drm/i915: Drop dma_buf->k(un)map
985f778728c5 drm/armada: Delete dma_buf->k(un)map implemenation
03af633b49d7 staging/android/ion: delete dma_buf->kmap/unmap implemenation
59215a0d0fd8 drm/i915: Remove dma_buf_kmap selftest
4e767396c955 drm/tegra: Delete host1x_bo_ops->k(un)map
4c6a4728b6b2 drm/tegra: Map cmdbuf once for reloc processing

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 00/15] Retire dma_buf_k(un)map

[Sumit Semwal]

Hello Daniel,

On Mon, 18 Nov 2019 at 16:05, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> Hi all,
>
> Way back when we created the dma-buf spec it made sense to have kmap/unmap
> interfaces, since 32bit kernels with limited vmalloc space were still
> rather ubiquitous. But that idea (like many others) never caught on, was
> quickly replaced by vmaps covering the entire buffer for all real uses,
> and nowadays 64bit kernels rule the world. Currently merged upstream
> drivers (and we have a pile now) don't even bother to kmap for their
> private buffers, much less for anything shared.
>
> So since it was never used, and this idea's time is clearly over, let's
> remove it all.
As always, thanks for helping keep this code sane :)

Fwiw, for the series, please feel free to add my
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>

>
> Only real change I had to do (aside from deleting lots of dead code) was
> in the tegra driver. But even there I suspect the dma-buf kmap path has
> never been run in anger anywhere, it just doesn't make sense to put relocs
> into a dma-buf (as opposed to using a dma-buf for the target address of a
> reloc).
>
> Comments, reviews and testing very much appreciated.
>
> Cheers, Daniel
>
> Daniel Vetter (15):
>   drm/tegra: Map cmdbuf once for reloc processing
>   drm/tegra: Delete host1x_bo_ops->k(un)map
>   drm/i915: Remove dma_buf_kmap selftest
>   staging/android/ion: delete dma_buf->kmap/unmap implemenation
>   drm/armada: Delete dma_buf->k(un)map implemenation
>   drm/i915: Drop dma_buf->k(un)map
>   drm/omapdrm: Drop dma_buf->k(un)map
>   drm/tegra: Remove dma_buf->k(un)map
>   dma-buf: Drop dma_buf_k(un)map
>   drm/vmwgfx: Delete mmaping functions
>   media/videobuf2: Drop dma_buf->k(un)map support
>   drm/tee_shm: Drop dma_buf_k(unmap) support
>   xen/gntdev-dmabuf: Ditch dummy map functions
>   sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support
>   dma-buf: Remove kernel map/unmap hooks
>
>  drivers/dma-buf/dma-buf.c                     |  63 +----------
>  drivers/gpu/drm/armada/armada_gem.c           |  12 ---
>  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c    |  36 -------
>  .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 101 ------------------
>  .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  |  16 ---
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c     |  21 ----
>  drivers/gpu/drm/tegra/gem.c                   |  40 -------
>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c         |  33 ------
>  drivers/gpu/host1x/job.c                      |  21 ++--
>  .../common/videobuf2/videobuf2-dma-contig.c   |   8 --
>  .../media/common/videobuf2/videobuf2-dma-sg.c |   8 --
>  .../common/videobuf2/videobuf2-vmalloc.c      |   8 --
>  drivers/misc/fastrpc.c                        |   8 --
>  drivers/staging/android/ion/ion.c             |  14 ---
>  drivers/tee/tee_shm.c                         |   6 --
>  drivers/xen/gntdev-dmabuf.c                   |  23 ----
>  include/linux/dma-buf.h                       |  27 -----
>  include/linux/host1x.h                        |  13 ---
>  samples/vfio-mdev/mbochs.c                    |  16 ---
>  19 files changed, 10 insertions(+), 464 deletions(-)
>
> --
> 2.24.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Best,
Sumit.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/15] Retire dma_buf_k(un)map

[Sumit Semwal]

Hello Daniel,

On Mon, 18 Nov 2019 at 16:05, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> Hi all,
>
> Way back when we created the dma-buf spec it made sense to have kmap/unmap
> interfaces, since 32bit kernels with limited vmalloc space were still
> rather ubiquitous. But that idea (like many others) never caught on, was
> quickly replaced by vmaps covering the entire buffer for all real uses,
> and nowadays 64bit kernels rule the world. Currently merged upstream
> drivers (and we have a pile now) don't even bother to kmap for their
> private buffers, much less for anything shared.
>
> So since it was never used, and this idea's time is clearly over, let's
> remove it all.
As always, thanks for helping keep this code sane :)

Fwiw, for the series, please feel free to add my
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>

>
> Only real change I had to do (aside from deleting lots of dead code) was
> in the tegra driver. But even there I suspect the dma-buf kmap path has
> never been run in anger anywhere, it just doesn't make sense to put relocs
> into a dma-buf (as opposed to using a dma-buf for the target address of a
> reloc).
>
> Comments, reviews and testing very much appreciated.
>
> Cheers, Daniel
>
> Daniel Vetter (15):
>   drm/tegra: Map cmdbuf once for reloc processing
>   drm/tegra: Delete host1x_bo_ops->k(un)map
>   drm/i915: Remove dma_buf_kmap selftest
>   staging/android/ion: delete dma_buf->kmap/unmap implemenation
>   drm/armada: Delete dma_buf->k(un)map implemenation
>   drm/i915: Drop dma_buf->k(un)map
>   drm/omapdrm: Drop dma_buf->k(un)map
>   drm/tegra: Remove dma_buf->k(un)map
>   dma-buf: Drop dma_buf_k(un)map
>   drm/vmwgfx: Delete mmaping functions
>   media/videobuf2: Drop dma_buf->k(un)map support
>   drm/tee_shm: Drop dma_buf_k(unmap) support
>   xen/gntdev-dmabuf: Ditch dummy map functions
>   sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support
>   dma-buf: Remove kernel map/unmap hooks
>
>  drivers/dma-buf/dma-buf.c                     |  63 +----------
>  drivers/gpu/drm/armada/armada_gem.c           |  12 ---
>  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c    |  36 -------
>  .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 101 ------------------
>  .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  |  16 ---
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c     |  21 ----
>  drivers/gpu/drm/tegra/gem.c                   |  40 -------
>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c         |  33 ------
>  drivers/gpu/host1x/job.c                      |  21 ++--
>  .../common/videobuf2/videobuf2-dma-contig.c   |   8 --
>  .../media/common/videobuf2/videobuf2-dma-sg.c |   8 --
>  .../common/videobuf2/videobuf2-vmalloc.c      |   8 --
>  drivers/misc/fastrpc.c                        |   8 --
>  drivers/staging/android/ion/ion.c             |  14 ---
>  drivers/tee/tee_shm.c                         |   6 --
>  drivers/xen/gntdev-dmabuf.c                   |  23 ----
>  include/linux/dma-buf.h                       |  27 -----
>  include/linux/host1x.h                        |  13 ---
>  samples/vfio-mdev/mbochs.c                    |  16 ---
>  19 files changed, 10 insertions(+), 464 deletions(-)
>
> --
> 2.24.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Best,
Sumit.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 00/15] Retire dma_buf_k(un)map

[Sumit Semwal]

Hello Daniel,

On Mon, 18 Nov 2019 at 16:05, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> Hi all,
>
> Way back when we created the dma-buf spec it made sense to have kmap/unmap
> interfaces, since 32bit kernels with limited vmalloc space were still
> rather ubiquitous. But that idea (like many others) never caught on, was
> quickly replaced by vmaps covering the entire buffer for all real uses,
> and nowadays 64bit kernels rule the world. Currently merged upstream
> drivers (and we have a pile now) don't even bother to kmap for their
> private buffers, much less for anything shared.
>
> So since it was never used, and this idea's time is clearly over, let's
> remove it all.
As always, thanks for helping keep this code sane :)

Fwiw, for the series, please feel free to add my
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>

>
> Only real change I had to do (aside from deleting lots of dead code) was
> in the tegra driver. But even there I suspect the dma-buf kmap path has
> never been run in anger anywhere, it just doesn't make sense to put relocs
> into a dma-buf (as opposed to using a dma-buf for the target address of a
> reloc).
>
> Comments, reviews and testing very much appreciated.
>
> Cheers, Daniel
>
> Daniel Vetter (15):
>   drm/tegra: Map cmdbuf once for reloc processing
>   drm/tegra: Delete host1x_bo_ops->k(un)map
>   drm/i915: Remove dma_buf_kmap selftest
>   staging/android/ion: delete dma_buf->kmap/unmap implemenation
>   drm/armada: Delete dma_buf->k(un)map implemenation
>   drm/i915: Drop dma_buf->k(un)map
>   drm/omapdrm: Drop dma_buf->k(un)map
>   drm/tegra: Remove dma_buf->k(un)map
>   dma-buf: Drop dma_buf_k(un)map
>   drm/vmwgfx: Delete mmaping functions
>   media/videobuf2: Drop dma_buf->k(un)map support
>   drm/tee_shm: Drop dma_buf_k(unmap) support
>   xen/gntdev-dmabuf: Ditch dummy map functions
>   sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support
>   dma-buf: Remove kernel map/unmap hooks
>
>  drivers/dma-buf/dma-buf.c                     |  63 +----------
>  drivers/gpu/drm/armada/armada_gem.c           |  12 ---
>  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c    |  36 -------
>  .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 101 ------------------
>  .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  |  16 ---
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c     |  21 ----
>  drivers/gpu/drm/tegra/gem.c                   |  40 -------
>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c         |  33 ------
>  drivers/gpu/host1x/job.c                      |  21 ++--
>  .../common/videobuf2/videobuf2-dma-contig.c   |   8 --
>  .../media/common/videobuf2/videobuf2-dma-sg.c |   8 --
>  .../common/videobuf2/videobuf2-vmalloc.c      |   8 --
>  drivers/misc/fastrpc.c                        |   8 --
>  drivers/staging/android/ion/ion.c             |  14 ---
>  drivers/tee/tee_shm.c                         |   6 --
>  drivers/xen/gntdev-dmabuf.c                   |  23 ----
>  include/linux/dma-buf.h                       |  27 -----
>  include/linux/host1x.h                        |  13 ---
>  samples/vfio-mdev/mbochs.c                    |  16 ---
>  19 files changed, 10 insertions(+), 464 deletions(-)
>
> --
> 2.24.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Best,
Sumit.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

✓ Fi.CI.IGT: success for Retire dma_buf_k(un)map

[Patchwork]

== Series Details ==

Series: Retire dma_buf_k(un)map
URL   : https://patchwork.freedesktop.org/series/69616/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7361_full -> Patchwork_15311_full
====================================================

Summary
-------

  **WARNING**

  Minor unknown changes coming with Patchwork_15311_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15311_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_15311_full:

### IGT changes ###

#### Warnings ####

  * igt@kms_chamelium@hdmi-aspect-ratio:
    - shard-iclb:         [SKIP][1] ([fdo#109284]) -> [FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb3/igt@kms_chamelium@hdmi-aspect-ratio.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb7/igt@kms_chamelium@hdmi-aspect-ratio.html

  
Known issues
------------

  Here are the changes found in Patchwork_15311_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_busy@busy-vcs1:
    - shard-iclb:         [PASS][3] -> [SKIP][4] ([fdo#112080]) +11 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb4/igt@gem_busy@busy-vcs1.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb8/igt@gem_busy@busy-vcs1.html

  * igt@gem_ctx_isolation@vcs0-s3:
    - shard-skl:          [PASS][5] -> [INCOMPLETE][6] ([fdo#104108]) +1 similar issue
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-skl8/igt@gem_ctx_isolation@vcs0-s3.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-skl4/igt@gem_ctx_isolation@vcs0-s3.html

  * igt@gem_ctx_persistence@vcs1-persistence:
    - shard-iclb:         [PASS][7] -> [SKIP][8] ([fdo#109276] / [fdo#112080]) +1 similar issue
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb4/igt@gem_ctx_persistence@vcs1-persistence.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb8/igt@gem_ctx_persistence@vcs1-persistence.html

  * igt@gem_exec_parallel@contexts:
    - shard-tglb:         [PASS][9] -> [INCOMPLETE][10] ([fdo#111867])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb5/igt@gem_exec_parallel@contexts.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb6/igt@gem_exec_parallel@contexts.html

  * igt@gem_exec_reloc@basic-wc-gtt-noreloc:
    - shard-tglb:         [PASS][11] -> [TIMEOUT][12] ([fdo#112126])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb1/igt@gem_exec_reloc@basic-wc-gtt-noreloc.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb7/igt@gem_exec_reloc@basic-wc-gtt-noreloc.html

  * igt@gem_exec_schedule@preempt-queue-bsd1:
    - shard-iclb:         [PASS][13] -> [SKIP][14] ([fdo#109276]) +12 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb2/igt@gem_exec_schedule@preempt-queue-bsd1.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb5/igt@gem_exec_schedule@preempt-queue-bsd1.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
    - shard-iclb:         [PASS][15] -> [SKIP][16] ([fdo#112146]) +2 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb6/igt@gem_exec_schedule@reorder-wide-bsd.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb4/igt@gem_exec_schedule@reorder-wide-bsd.html

  * igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive:
    - shard-apl:          [PASS][17] -> [TIMEOUT][18] ([fdo#112113])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-apl7/igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-apl1/igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive.html

  * igt@gem_sync@basic-many-each:
    - shard-tglb:         [PASS][19] -> [INCOMPLETE][20] ([fdo#111880] / [fdo#111998])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb9/igt@gem_sync@basic-many-each.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb6/igt@gem_sync@basic-many-each.html

  * igt@gem_userptr_blits@sync-unmap:
    - shard-snb:          [PASS][21] -> [DMESG-WARN][22] ([fdo#111870])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-snb1/igt@gem_userptr_blits@sync-unmap.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-snb5/igt@gem_userptr_blits@sync-unmap.html

  * igt@gem_workarounds@suspend-resume-context:
    - shard-apl:          [PASS][23] -> [DMESG-WARN][24] ([fdo#108566]) +1 similar issue
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-apl8/igt@gem_workarounds@suspend-resume-context.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-apl6/igt@gem_workarounds@suspend-resume-context.html

  * igt@i915_pm_dc@dc6-dpms:
    - shard-iclb:         [PASS][25] -> [FAIL][26] ([fdo#111830 ])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb4/igt@i915_pm_dc@dc6-dpms.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb3/igt@i915_pm_dc@dc6-dpms.html

  * igt@i915_pm_rpm@system-suspend-devices:
    - shard-tglb:         [PASS][27] -> [INCOMPLETE][28] ([fdo#111832] / [fdo#111850])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb8/igt@i915_pm_rpm@system-suspend-devices.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb5/igt@i915_pm_rpm@system-suspend-devices.html

  * igt@i915_selftest@live_hangcheck:
    - shard-snb:          [PASS][29] -> [INCOMPLETE][30] ([fdo#105411])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-snb4/igt@i915_selftest@live_hangcheck.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-snb4/igt@i915_selftest@live_hangcheck.html

  * igt@i915_selftest@live_perf:
    - shard-hsw:          [PASS][31] -> [INCOMPLETE][32] ([fdo#103540])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-hsw2/igt@i915_selftest@live_perf.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-hsw5/igt@i915_selftest@live_perf.html

  * igt@kms_flip@dpms-off-confusion-interruptible:
    - shard-tglb:         [PASS][33] -> [TIMEOUT][34] ([fdo#112168]) +1 similar issue
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb1/igt@kms_flip@dpms-off-confusion-interruptible.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb7/igt@kms_flip@dpms-off-confusion-interruptible.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw:
    - shard-tglb:         [PASS][35] -> [FAIL][36] ([fdo#103167]) +2 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb6/igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb8/igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt:
    - shard-iclb:         [PASS][37] -> [FAIL][38] ([fdo#103167]) +7 similar issues
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb3/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html

  * igt@kms_plane_lowres@pipe-a-tiling-y:
    - shard-iclb:         [PASS][39] -> [FAIL][40] ([fdo#103166])
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb5/igt@kms_plane_lowres@pipe-a-tiling-y.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-y.html

  * igt@kms_psr@psr2_no_drrs:
    - shard-iclb:         [PASS][41] -> [SKIP][42] ([fdo#109441]) +1 similar issue
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb2/igt@kms_psr@psr2_no_drrs.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb1/igt@kms_psr@psr2_no_drrs.html

  * igt@kms_psr@suspend:
    - shard-skl:          [PASS][43] -> [INCOMPLETE][44] ([fdo#108972])
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-skl1/igt@kms_psr@suspend.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-skl9/igt@kms_psr@suspend.html

  * igt@kms_setmode@basic:
    - shard-apl:          [PASS][45] -> [FAIL][46] ([fdo#99912])
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-apl1/igt@kms_setmode@basic.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-apl8/igt@kms_setmode@basic.html

  * igt@kms_vblank@pipe-b-ts-continuation-suspend:
    - shard-kbl:          [PASS][47] -> [DMESG-WARN][48] ([fdo#108566])
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-kbl7/igt@kms_vblank@pipe-b-ts-continuation-suspend.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-kbl2/igt@kms_vblank@pipe-b-ts-continuation-suspend.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@rcs0-s3:
    - shard-kbl:          [DMESG-WARN][49] ([fdo#108566]) -> [PASS][50] +4 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-kbl4/igt@gem_ctx_isolation@rcs0-s3.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-kbl3/igt@gem_ctx_isolation@rcs0-s3.html

  * igt@gem_ctx_persistence@vcs1-queued:
    - shard-iclb:         [SKIP][51] ([fdo#109276] / [fdo#112080]) -> [PASS][52] +5 similar issues
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb7/igt@gem_ctx_persistence@vcs1-queued.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb4/igt@gem_ctx_persistence@vcs1-queued.html

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
    - shard-iclb:         [SKIP][53] ([fdo#110841]) -> [PASS][54]
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb4/igt@gem_ctx_shared@exec-single-timeline-bsd.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb8/igt@gem_ctx_shared@exec-single-timeline-bsd.html

  * igt@gem_ctx_shared@q-smoketest-all:
    - shard-tglb:         [INCOMPLETE][55] ([fdo#111735]) -> [PASS][56]
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb6/igt@gem_ctx_shared@q-smoketest-all.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb8/igt@gem_ctx_shared@q-smoketest-all.html

  * igt@gem_ctx_switch@vcs1-heavy-queue:
    - shard-iclb:         [SKIP][57] ([fdo#112080]) -> [PASS][58] +6 similar issues
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb6/igt@gem_ctx_switch@vcs1-heavy-queue.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb4/igt@gem_ctx_switch@vcs1-heavy-queue.html

  * {igt@gem_exec_parse_blt@bb-start-far}:
    - shard-glk:          [TIMEOUT][59] ([fdo#112271]) -> [PASS][60]
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-glk3/igt@gem_exec_parse_blt@bb-start-far.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-glk2/igt@gem_exec_parse_blt@bb-start-far.html

  * igt@gem_exec_schedule@pi-ringfull-bsd2:
    - shard-iclb:         [SKIP][61] ([fdo#109276]) -> [PASS][62] +12 similar issues
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb6/igt@gem_exec_schedule@pi-ringfull-bsd2.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb4/igt@gem_exec_schedule@pi-ringfull-bsd2.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
    - shard-iclb:         [SKIP][63] ([fdo#112146]) -> [PASS][64] +5 similar issues
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb4/igt@gem_exec_schedule@preempt-other-chain-bsd.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb8/igt@gem_exec_schedule@preempt-other-chain-bsd.html

  * igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive:
    - shard-tglb:         [TIMEOUT][65] ([fdo#112068 ]) -> [PASS][66]
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb3/igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb3/igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive.html

  * igt@gem_softpin@noreloc-s3:
    - shard-apl:          [DMESG-WARN][67] ([fdo#108566]) -> [PASS][68] +1 similar issue
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-apl4/igt@gem_softpin@noreloc-s3.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-apl7/igt@gem_softpin@noreloc-s3.html

  * igt@gem_userptr_blits@dmabuf-sync:
    - shard-snb:          [DMESG-WARN][69] ([fdo#111870]) -> [PASS][70]
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-snb5/igt@gem_userptr_blits@dmabuf-sync.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-snb6/igt@gem_userptr_blits@dmabuf-sync.html

  * igt@gem_userptr_blits@sync-unmap:
    - shard-hsw:          [DMESG-WARN][71] ([fdo#111870]) -> [PASS][72]
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-hsw6/igt@gem_userptr_blits@sync-unmap.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-hsw2/igt@gem_userptr_blits@sync-unmap.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
    - shard-snb:          [DMESG-WARN][73] ([fdo#102365]) -> [PASS][74]
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-snb4/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-snb5/igt@kms_cursor_crc@pipe-b-cursor-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
    - shard-iclb:         [FAIL][75] ([fdo#103167]) -> [PASS][76] +4 similar issues
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb4/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb7/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt:
    - shard-tglb:         [FAIL][77] ([fdo#103167]) -> [PASS][78] +4 similar issues
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb4/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb2/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [FAIL][79] ([fdo#108145] / [fdo#110403]) -> [PASS][80] +1 similar issue
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-skl1/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-skl1/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_blt:
    - shard-iclb:         [SKIP][81] ([fdo#109441]) -> [PASS][82] +2 similar issues
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb1/igt@kms_psr@psr2_cursor_blt.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html

  * igt@kms_setmode@basic:
    - shard-skl:          [FAIL][83] ([fdo#99912]) -> [PASS][84]
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-skl4/igt@kms_setmode@basic.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-skl1/igt@kms_setmode@basic.html

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
    - shard-tglb:         [INCOMPLETE][85] ([fdo#111832] / [fdo#111850]) -> [PASS][86] +1 similar issue
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb1/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb9/igt@kms_vblank@pipe-a-ts-continuation-suspend.html

  
#### Warnings ####

  * igt@gem_ctx_isolation@vcs2-reset:
    - shard-tglb:         [SKIP][87] ([fdo#112080]) -> [SKIP][88] ([fdo#111912] / [fdo#112080]) +2 similar issues
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb9/igt@gem_ctx_isolation@vcs2-reset.html
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb6/igt@gem_ctx_isolation@vcs2-reset.html

  * igt@gem_exec_schedule@deep-blt:
    - shard-tglb:         [INCOMPLETE][89] ([fdo#111671]) -> [FAIL][90] ([fdo#111646])
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb6/igt@gem_exec_schedule@deep-blt.html
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb5/igt@gem_exec_schedule@deep-blt.html

  * igt@kms_atomic_transition@6x-modeset-transitions-fencing:
    - shard-tglb:         [SKIP][91] ([fdo#112016 ] / [fdo#112021 ]) -> [SKIP][92] ([fdo#112021 ])
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb2/igt@kms_atomic_transition@6x-modeset-transitions-fencing.html
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb9/igt@kms_atomic_transition@6x-modeset-transitions-fencing.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#102365]: https://bugs.freedesktop.org/show_bug.cgi?id=102365
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108972]: https://bugs.freedesktop.org/show_bug.cgi?id=108972
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#110403]: https://bugs.freedesktop.org/show_bug.cgi?id=110403
  [fdo#110841]: https://bugs.freedesktop.org/show_bug.cgi?id=110841
  [fdo#111646]: https://bugs.freedesktop.org/show_bug.cgi?id=111646
  [fdo#111671]: https://bugs.freedesktop.org/show_bug.cgi?id=111671
  [fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
  [fdo#111830 ]: https://bugs.freedesktop.org/show_bug.cgi?id=111830 
  [fdo#111832]: https://bugs.freedesktop.org/show_bug.cgi?id=111832
  [fdo#111850]: https://bugs.freedesktop.org/show_bug.cgi?id=111850
  [fdo#111867]: https://bugs.freedesktop.org/show_bug.cgi?id=111867
  [fdo#111870]: https://bugs.freedesktop.org/show_bug.cgi?id=111870
  [fdo#111880]: https://bugs.freedesktop.org/show_bug.cgi?id=111880
  [fdo#111912]: https://bugs.freedesktop.org/show_bug.cgi?id=111912
  [fdo#111998]: https://bugs.freedesktop.org/show_bug.cgi?id=111998
  [fdo#112016 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112016 
  [fdo#112021 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112021 
  [fdo#112068 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112068 
  [fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
  [fdo#112113]: https://bugs.freedesktop.org/show_bug.cgi?id=112113
  [fdo#112126]: https://bugs.freedesktop.org/show_bug.cgi?id=112126
  [fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
  [fdo#112168]: https://bugs.freedesktop.org/show_bug.cgi?

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for Retire dma_buf_k(un)map

[Patchwork]

== Series Details ==

Series: Retire dma_buf_k(un)map
URL   : https://patchwork.freedesktop.org/series/69616/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7361_full -> Patchwork_15311_full
====================================================

Summary
-------

  **WARNING**

  Minor unknown changes coming with Patchwork_15311_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15311_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_15311_full:

### IGT changes ###

#### Warnings ####

  * igt@kms_chamelium@hdmi-aspect-ratio:
    - shard-iclb:         [SKIP][1] ([fdo#109284]) -> [FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb3/igt@kms_chamelium@hdmi-aspect-ratio.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb7/igt@kms_chamelium@hdmi-aspect-ratio.html

  
Known issues
------------

  Here are the changes found in Patchwork_15311_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_busy@busy-vcs1:
    - shard-iclb:         [PASS][3] -> [SKIP][4] ([fdo#112080]) +11 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb4/igt@gem_busy@busy-vcs1.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb8/igt@gem_busy@busy-vcs1.html

  * igt@gem_ctx_isolation@vcs0-s3:
    - shard-skl:          [PASS][5] -> [INCOMPLETE][6] ([fdo#104108]) +1 similar issue
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-skl8/igt@gem_ctx_isolation@vcs0-s3.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-skl4/igt@gem_ctx_isolation@vcs0-s3.html

  * igt@gem_ctx_persistence@vcs1-persistence:
    - shard-iclb:         [PASS][7] -> [SKIP][8] ([fdo#109276] / [fdo#112080]) +1 similar issue
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb4/igt@gem_ctx_persistence@vcs1-persistence.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb8/igt@gem_ctx_persistence@vcs1-persistence.html

  * igt@gem_exec_parallel@contexts:
    - shard-tglb:         [PASS][9] -> [INCOMPLETE][10] ([fdo#111867])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb5/igt@gem_exec_parallel@contexts.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb6/igt@gem_exec_parallel@contexts.html

  * igt@gem_exec_reloc@basic-wc-gtt-noreloc:
    - shard-tglb:         [PASS][11] -> [TIMEOUT][12] ([fdo#112126])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb1/igt@gem_exec_reloc@basic-wc-gtt-noreloc.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb7/igt@gem_exec_reloc@basic-wc-gtt-noreloc.html

  * igt@gem_exec_schedule@preempt-queue-bsd1:
    - shard-iclb:         [PASS][13] -> [SKIP][14] ([fdo#109276]) +12 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb2/igt@gem_exec_schedule@preempt-queue-bsd1.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb5/igt@gem_exec_schedule@preempt-queue-bsd1.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
    - shard-iclb:         [PASS][15] -> [SKIP][16] ([fdo#112146]) +2 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb6/igt@gem_exec_schedule@reorder-wide-bsd.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb4/igt@gem_exec_schedule@reorder-wide-bsd.html

  * igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive:
    - shard-apl:          [PASS][17] -> [TIMEOUT][18] ([fdo#112113])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-apl7/igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-apl1/igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive.html

  * igt@gem_sync@basic-many-each:
    - shard-tglb:         [PASS][19] -> [INCOMPLETE][20] ([fdo#111880] / [fdo#111998])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb9/igt@gem_sync@basic-many-each.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb6/igt@gem_sync@basic-many-each.html

  * igt@gem_userptr_blits@sync-unmap:
    - shard-snb:          [PASS][21] -> [DMESG-WARN][22] ([fdo#111870])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-snb1/igt@gem_userptr_blits@sync-unmap.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-snb5/igt@gem_userptr_blits@sync-unmap.html

  * igt@gem_workarounds@suspend-resume-context:
    - shard-apl:          [PASS][23] -> [DMESG-WARN][24] ([fdo#108566]) +1 similar issue
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-apl8/igt@gem_workarounds@suspend-resume-context.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-apl6/igt@gem_workarounds@suspend-resume-context.html

  * igt@i915_pm_dc@dc6-dpms:
    - shard-iclb:         [PASS][25] -> [FAIL][26] ([fdo#111830 ])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb4/igt@i915_pm_dc@dc6-dpms.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb3/igt@i915_pm_dc@dc6-dpms.html

  * igt@i915_pm_rpm@system-suspend-devices:
    - shard-tglb:         [PASS][27] -> [INCOMPLETE][28] ([fdo#111832] / [fdo#111850])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb8/igt@i915_pm_rpm@system-suspend-devices.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb5/igt@i915_pm_rpm@system-suspend-devices.html

  * igt@i915_selftest@live_hangcheck:
    - shard-snb:          [PASS][29] -> [INCOMPLETE][30] ([fdo#105411])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-snb4/igt@i915_selftest@live_hangcheck.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-snb4/igt@i915_selftest@live_hangcheck.html

  * igt@i915_selftest@live_perf:
    - shard-hsw:          [PASS][31] -> [INCOMPLETE][32] ([fdo#103540])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-hsw2/igt@i915_selftest@live_perf.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-hsw5/igt@i915_selftest@live_perf.html

  * igt@kms_flip@dpms-off-confusion-interruptible:
    - shard-tglb:         [PASS][33] -> [TIMEOUT][34] ([fdo#112168]) +1 similar issue
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb1/igt@kms_flip@dpms-off-confusion-interruptible.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb7/igt@kms_flip@dpms-off-confusion-interruptible.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw:
    - shard-tglb:         [PASS][35] -> [FAIL][36] ([fdo#103167]) +2 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb6/igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb8/igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt:
    - shard-iclb:         [PASS][37] -> [FAIL][38] ([fdo#103167]) +7 similar issues
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb3/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html

  * igt@kms_plane_lowres@pipe-a-tiling-y:
    - shard-iclb:         [PASS][39] -> [FAIL][40] ([fdo#103166])
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb5/igt@kms_plane_lowres@pipe-a-tiling-y.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-y.html

  * igt@kms_psr@psr2_no_drrs:
    - shard-iclb:         [PASS][41] -> [SKIP][42] ([fdo#109441]) +1 similar issue
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb2/igt@kms_psr@psr2_no_drrs.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb1/igt@kms_psr@psr2_no_drrs.html

  * igt@kms_psr@suspend:
    - shard-skl:          [PASS][43] -> [INCOMPLETE][44] ([fdo#108972])
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-skl1/igt@kms_psr@suspend.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-skl9/igt@kms_psr@suspend.html

  * igt@kms_setmode@basic:
    - shard-apl:          [PASS][45] -> [FAIL][46] ([fdo#99912])
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-apl1/igt@kms_setmode@basic.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-apl8/igt@kms_setmode@basic.html

  * igt@kms_vblank@pipe-b-ts-continuation-suspend:
    - shard-kbl:          [PASS][47] -> [DMESG-WARN][48] ([fdo#108566])
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-kbl7/igt@kms_vblank@pipe-b-ts-continuation-suspend.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-kbl2/igt@kms_vblank@pipe-b-ts-continuation-suspend.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@rcs0-s3:
    - shard-kbl:          [DMESG-WARN][49] ([fdo#108566]) -> [PASS][50] +4 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-kbl4/igt@gem_ctx_isolation@rcs0-s3.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-kbl3/igt@gem_ctx_isolation@rcs0-s3.html

  * igt@gem_ctx_persistence@vcs1-queued:
    - shard-iclb:         [SKIP][51] ([fdo#109276] / [fdo#112080]) -> [PASS][52] +5 similar issues
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb7/igt@gem_ctx_persistence@vcs1-queued.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb4/igt@gem_ctx_persistence@vcs1-queued.html

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
    - shard-iclb:         [SKIP][53] ([fdo#110841]) -> [PASS][54]
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb4/igt@gem_ctx_shared@exec-single-timeline-bsd.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb8/igt@gem_ctx_shared@exec-single-timeline-bsd.html

  * igt@gem_ctx_shared@q-smoketest-all:
    - shard-tglb:         [INCOMPLETE][55] ([fdo#111735]) -> [PASS][56]
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb6/igt@gem_ctx_shared@q-smoketest-all.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb8/igt@gem_ctx_shared@q-smoketest-all.html

  * igt@gem_ctx_switch@vcs1-heavy-queue:
    - shard-iclb:         [SKIP][57] ([fdo#112080]) -> [PASS][58] +6 similar issues
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb6/igt@gem_ctx_switch@vcs1-heavy-queue.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb4/igt@gem_ctx_switch@vcs1-heavy-queue.html

  * {igt@gem_exec_parse_blt@bb-start-far}:
    - shard-glk:          [TIMEOUT][59] ([fdo#112271]) -> [PASS][60]
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-glk3/igt@gem_exec_parse_blt@bb-start-far.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-glk2/igt@gem_exec_parse_blt@bb-start-far.html

  * igt@gem_exec_schedule@pi-ringfull-bsd2:
    - shard-iclb:         [SKIP][61] ([fdo#109276]) -> [PASS][62] +12 similar issues
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb6/igt@gem_exec_schedule@pi-ringfull-bsd2.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb4/igt@gem_exec_schedule@pi-ringfull-bsd2.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
    - shard-iclb:         [SKIP][63] ([fdo#112146]) -> [PASS][64] +5 similar issues
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb4/igt@gem_exec_schedule@preempt-other-chain-bsd.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb8/igt@gem_exec_schedule@preempt-other-chain-bsd.html

  * igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive:
    - shard-tglb:         [TIMEOUT][65] ([fdo#112068 ]) -> [PASS][66]
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb3/igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb3/igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive.html

  * igt@gem_softpin@noreloc-s3:
    - shard-apl:          [DMESG-WARN][67] ([fdo#108566]) -> [PASS][68] +1 similar issue
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-apl4/igt@gem_softpin@noreloc-s3.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-apl7/igt@gem_softpin@noreloc-s3.html

  * igt@gem_userptr_blits@dmabuf-sync:
    - shard-snb:          [DMESG-WARN][69] ([fdo#111870]) -> [PASS][70]
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-snb5/igt@gem_userptr_blits@dmabuf-sync.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-snb6/igt@gem_userptr_blits@dmabuf-sync.html

  * igt@gem_userptr_blits@sync-unmap:
    - shard-hsw:          [DMESG-WARN][71] ([fdo#111870]) -> [PASS][72]
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-hsw6/igt@gem_userptr_blits@sync-unmap.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-hsw2/igt@gem_userptr_blits@sync-unmap.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
    - shard-snb:          [DMESG-WARN][73] ([fdo#102365]) -> [PASS][74]
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-snb4/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-snb5/igt@kms_cursor_crc@pipe-b-cursor-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
    - shard-iclb:         [FAIL][75] ([fdo#103167]) -> [PASS][76] +4 similar issues
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb4/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb7/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt:
    - shard-tglb:         [FAIL][77] ([fdo#103167]) -> [PASS][78] +4 similar issues
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb4/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb2/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [FAIL][79] ([fdo#108145] / [fdo#110403]) -> [PASS][80] +1 similar issue
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-skl1/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-skl1/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_blt:
    - shard-iclb:         [SKIP][81] ([fdo#109441]) -> [PASS][82] +2 similar issues
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-iclb1/igt@kms_psr@psr2_cursor_blt.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html

  * igt@kms_setmode@basic:
    - shard-skl:          [FAIL][83] ([fdo#99912]) -> [PASS][84]
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-skl4/igt@kms_setmode@basic.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-skl1/igt@kms_setmode@basic.html

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
    - shard-tglb:         [INCOMPLETE][85] ([fdo#111832] / [fdo#111850]) -> [PASS][86] +1 similar issue
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb1/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb9/igt@kms_vblank@pipe-a-ts-continuation-suspend.html

  
#### Warnings ####

  * igt@gem_ctx_isolation@vcs2-reset:
    - shard-tglb:         [SKIP][87] ([fdo#112080]) -> [SKIP][88] ([fdo#111912] / [fdo#112080]) +2 similar issues
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb9/igt@gem_ctx_isolation@vcs2-reset.html
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb6/igt@gem_ctx_isolation@vcs2-reset.html

  * igt@gem_exec_schedule@deep-blt:
    - shard-tglb:         [INCOMPLETE][89] ([fdo#111671]) -> [FAIL][90] ([fdo#111646])
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb6/igt@gem_exec_schedule@deep-blt.html
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb5/igt@gem_exec_schedule@deep-blt.html

  * igt@kms_atomic_transition@6x-modeset-transitions-fencing:
    - shard-tglb:         [SKIP][91] ([fdo#112016 ] / [fdo#112021 ]) -> [SKIP][92] ([fdo#112021 ])
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/shard-tglb2/igt@kms_atomic_transition@6x-modeset-transitions-fencing.html
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/shard-tglb9/igt@kms_atomic_transition@6x-modeset-transitions-fencing.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#102365]: https://bugs.freedesktop.org/show_bug.cgi?id=102365
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108972]: https://bugs.freedesktop.org/show_bug.cgi?id=108972
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#110403]: https://bugs.freedesktop.org/show_bug.cgi?id=110403
  [fdo#110841]: https://bugs.freedesktop.org/show_bug.cgi?id=110841
  [fdo#111646]: https://bugs.freedesktop.org/show_bug.cgi?id=111646
  [fdo#111671]: https://bugs.freedesktop.org/show_bug.cgi?id=111671
  [fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
  [fdo#111830 ]: https://bugs.freedesktop.org/show_bug.cgi?id=111830 
  [fdo#111832]: https://bugs.freedesktop.org/show_bug.cgi?id=111832
  [fdo#111850]: https://bugs.freedesktop.org/show_bug.cgi?id=111850
  [fdo#111867]: https://bugs.freedesktop.org/show_bug.cgi?id=111867
  [fdo#111870]: https://bugs.freedesktop.org/show_bug.cgi?id=111870
  [fdo#111880]: https://bugs.freedesktop.org/show_bug.cgi?id=111880
  [fdo#111912]: https://bugs.freedesktop.org/show_bug.cgi?id=111912
  [fdo#111998]: https://bugs.freedesktop.org/show_bug.cgi?id=111998
  [fdo#112016 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112016 
  [fdo#112021 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112021 
  [fdo#112068 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112068 
  [fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
  [fdo#112113]: https://bugs.freedesktop.org/show_bug.cgi?id=112113
  [fdo#112126]: https://bugs.freedesktop.org/show_bug.cgi?id=112126
  [fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
  [fdo#112168]: https://bugs.freedesktop.org/show_bug.cgi?

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx