| Message ID | 20191118103536.17675-8-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Retire dma_buf_k(un)map | expand |
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
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, };
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(-)