* Re: [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation
2019-11-18 10:35 ` [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation Daniel Vetter
@ 2019-11-18 11:26 ` Greg KH
2019-11-18 14:55 ` Laura Abbott
1 sibling, 0 replies; 3+ messages in thread
From: Greg KH @ 2019-11-18 11:26 UTC (permalink / raw)
To: Daniel Vetter
Cc: devel, Intel Graphics Development, DRI Development,
linaro-mm-sig, Daniel Vetter, Sumit Semwal
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation
2019-11-18 10:35 ` [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation Daniel Vetter
2019-11-18 11:26 ` Greg KH
@ 2019-11-18 14:55 ` Laura Abbott
1 sibling, 0 replies; 3+ messages in thread
From: Laura Abbott @ 2019-11-18 14:55 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: devel, Daniel Vetter, Intel Graphics Development, linaro-mm-sig,
Sumit Semwal
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
^ permalink raw reply [flat|nested] 3+ messages in thread