All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org
Subject: [PATCH 09/15] dma-buf: Drop dma_buf_k(un)map
Date: Mon, 18 Nov 2019 11:35:30 +0100	[thread overview]
Message-ID: <20191118103536.17675-10-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <20191118103536.17675-1-daniel.vetter@ffwll.ch>

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


WARNING: multiple messages have this Message-ID
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	linaro-mm-sig@lists.linaro.org,
	Daniel Vetter <daniel.vetter@intel.com>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	linux-media@vger.kernel.org
Subject: [PATCH 09/15] dma-buf: Drop dma_buf_k(un)map
Date: Mon, 18 Nov 2019 11:35:30 +0100	[thread overview]
Message-ID: <20191118103536.17675-10-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <20191118103536.17675-1-daniel.vetter@ffwll.ch>

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

WARNING: multiple messages have this Message-ID
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	linaro-mm-sig@lists.linaro.org,
	Daniel Vetter <daniel.vetter@intel.com>,
	linux-media@vger.kernel.org
Subject: [PATCH 09/15] dma-buf: Drop dma_buf_k(un)map
Date: Mon, 18 Nov 2019 11:35:30 +0100	[thread overview]
Message-ID: <20191118103536.17675-10-daniel.vetter@ffwll.ch> (raw)
Message-ID: <20191118103530.rp6SkBW2L8pvc-GzjK61rA20qzsmeovtHipP82trAPc@z> (raw)
In-Reply-To: <20191118103536.17675-1-daniel.vetter@ffwll.ch>

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

WARNING: multiple messages have this Message-ID
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	linaro-mm-sig@lists.linaro.org,
	Daniel Vetter <daniel.vetter@intel.com>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	linux-media@vger.kernel.org
Subject: [Intel-gfx] [PATCH 09/15] dma-buf: Drop dma_buf_k(un)map
Date: Mon, 18 Nov 2019 11:35:30 +0100	[thread overview]
Message-ID: <20191118103536.17675-10-daniel.vetter@ffwll.ch> (raw)
Message-ID: <20191118103530.4r6VvAiywOb_S-niztvWz4vU7z8tDPJKzfNnCq25WME@z> (raw)
In-Reply-To: <20191118103536.17675-1-daniel.vetter@ffwll.ch>

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

  parent reply	other threads:[~2019-11-18 10:35 UTC|newest]

Thread overview: 142+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-18 10:35 [PATCH 00/15] Retire dma_buf_k(un)map Daniel Vetter
2019-11-18 10:35 ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35 ` [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-25  9:58   ` Daniel Vetter
2019-11-25  9:58     ` [Intel-gfx] " Daniel Vetter
2019-11-25  9:58     ` Daniel Vetter
2019-11-25 10:47     ` Thierry Reding
2019-11-25 10:47       ` [Intel-gfx] " Thierry Reding
2019-11-25 10:47       ` Thierry Reding
2019-11-25 11:02   ` Thierry Reding
2019-11-25 11:02     ` [Intel-gfx] " Thierry Reding
2019-11-25 11:02     ` Thierry Reding
2019-11-18 10:35 ` [PATCH 02/15] drm/tegra: Delete host1x_bo_ops->k(un)map Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-25 11:04   ` Thierry Reding
2019-11-25 11:04     ` [Intel-gfx] " Thierry Reding
2019-11-25 11:04     ` Thierry Reding
2019-11-18 10:35 ` [PATCH 03/15] drm/i915: Remove dma_buf_kmap selftest Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 12:58   ` Chris Wilson
2019-11-18 12:58     ` [Intel-gfx] " Chris Wilson
2019-11-18 12:58     ` Chris Wilson
2019-11-18 10:35 ` [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 11:26   ` Greg KH
2019-11-18 11:26     ` [Intel-gfx] " Greg KH
2019-11-18 11:26     ` Greg KH
2019-11-18 11:26     ` Greg KH
2019-11-18 14:55   ` Laura Abbott
2019-11-18 14:55     ` [Intel-gfx] " Laura Abbott
2019-11-18 14:55     ` Laura Abbott
2019-11-18 10:35 ` [PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-25 21:44   ` Daniel Vetter
2019-11-25 21:44     ` [Intel-gfx] " Daniel Vetter
2019-11-26  0:35     ` Russell King - ARM Linux admin
2019-11-26  0:35       ` [Intel-gfx] " Russell King - ARM Linux admin
2019-11-26  8:33       ` Daniel Vetter
2019-11-26  8:33         ` [Intel-gfx] " Daniel Vetter
2019-11-26  8:33         ` Daniel Vetter
2019-11-18 10:35 ` [PATCH 06/15] drm/i915: Drop dma_buf->k(un)map Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 11:38   ` Christian König
2019-11-18 11:38     ` [Intel-gfx] " Christian König
2019-11-18 11:38     ` Christian König
2019-11-18 12:53   ` Chris Wilson
2019-11-18 12:53     ` [Intel-gfx] " Chris Wilson
2019-11-18 12:53     ` Chris Wilson
2019-11-18 10:35 ` [PATCH 07/15] drm/omapdrm: " Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 12:44   ` Tomi Valkeinen
2019-11-18 12:44     ` [Intel-gfx] " Tomi Valkeinen
2019-11-18 12:44     ` Tomi Valkeinen
2019-11-18 10:35 ` [PATCH 08/15] drm/tegra: Remove dma_buf->k(un)map Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-25 11:06   ` Thierry Reding
2019-11-25 11:06     ` [Intel-gfx] " Thierry Reding
2019-11-18 10:35 ` Daniel Vetter [this message]
2019-11-18 10:35   ` [Intel-gfx] [PATCH 09/15] dma-buf: Drop dma_buf_k(un)map Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 10:35 ` [PATCH 10/15] drm/vmwgfx: Delete mmaping functions Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 17:25   ` Thomas Hellstrom
2019-11-18 17:25     ` [Intel-gfx] " Thomas Hellstrom
2019-11-18 17:25     ` Thomas Hellstrom
2019-11-18 17:42     ` Daniel Vetter
2019-11-18 17:42       ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35 ` [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 10:58   ` Marek Szyprowski
2019-11-18 10:58     ` [Intel-gfx] " Marek Szyprowski
2019-11-18 10:58     ` Marek Szyprowski
2019-11-18 10:58     ` Marek Szyprowski
2019-11-18 11:02   ` Hans Verkuil
2019-11-18 11:02     ` [Intel-gfx] " Hans Verkuil
2019-11-18 11:02     ` Hans Verkuil
2019-11-18 10:35 ` [PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 11:26   ` Greg Kroah-Hartman
2019-11-18 11:26     ` [Intel-gfx] " Greg Kroah-Hartman
2019-11-18 12:02   ` Jens Wiklander
2019-11-18 12:02     ` [Intel-gfx] " Jens Wiklander
2019-11-18 12:02     ` Jens Wiklander
2019-11-18 10:35 ` [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions Daniel Vetter
2019-11-18 10:35   ` [Xen-devel] " Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 10:50   ` [Xen-devel] " Oleksandr Andrushchenko
2019-11-18 10:50     ` Oleksandr Andrushchenko
2019-11-18 10:50     ` [Intel-gfx] " Oleksandr Andrushchenko
2019-11-18 10:50     ` Oleksandr Andrushchenko
2019-11-18 10:53   ` Jürgen Groß
2019-11-18 10:53     ` [Xen-devel] " Jürgen Groß
2019-11-18 10:53     ` [Intel-gfx] " Jürgen Groß
2019-11-18 10:53     ` Jürgen Groß
2019-11-18 10:35 ` [PATCH 14/15] sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 11:41   ` Gerd Hoffmann
2019-11-18 11:41     ` [Intel-gfx] " Gerd Hoffmann
2019-11-18 11:41     ` Gerd Hoffmann
2019-11-18 11:41     ` Gerd Hoffmann
2019-11-18 10:35 ` [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks Daniel Vetter
2019-11-18 10:35   ` [Intel-gfx] " Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 10:35   ` Daniel Vetter
2019-11-18 15:22   ` kbuild test robot
2019-11-18 15:22     ` [Intel-gfx] " kbuild test robot
2019-11-18 15:22     ` kbuild test robot
2019-11-18 15:22     ` kbuild test robot
2019-11-18 16:43     ` Daniel Vetter
2019-11-18 16:43       ` [Intel-gfx] " Daniel Vetter
2019-11-18 16:43       ` Daniel Vetter
2019-11-25  0:46       ` [kbuild-all] " Rong Chen
2019-11-25  0:46         ` [Intel-gfx] " Rong Chen
2019-11-25  0:46         ` Rong Chen
2019-11-26 10:54   ` Daniel Vetter
2019-11-26 10:54     ` [Intel-gfx] " Daniel Vetter
2019-11-26 10:54     ` Daniel Vetter
2019-11-18 12:36 ` ✗ Fi.CI.CHECKPATCH: warning for Retire dma_buf_k(un)map Patchwork
2019-11-18 12:36   ` [Intel-gfx] " Patchwork
2019-11-18 13:01 ` ✓ Fi.CI.BAT: success " Patchwork
2019-11-18 13:01   ` [Intel-gfx] " Patchwork
2019-11-18 15:58 ` [PATCH 00/15] " Sumit Semwal
2019-11-18 15:58   ` [Intel-gfx] " Sumit Semwal
2019-11-18 15:58   ` Sumit Semwal
2019-11-18 18:45 ` ✓ Fi.CI.IGT: success for " Patchwork
2019-11-18 18:45   ` [Intel-gfx] " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191118103536.17675-10-daniel.vetter@ffwll.ch \
    --to=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=sumit.semwal@linaro.org \
    --subject='Re: [PATCH 09/15] dma-buf: Drop dma_buf_k(un)map' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.