Thread (74 messages) 74 messages, 16 authors, 2017-03-17

[RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

flat view

From: Laura Abbott <hidden>
Date: 2017-03-03 18:48:02
Also in: dri-devel, linux-media, linux-mm, lkml

On 03/03/2017 08:39 AM, Laurent Pinchart wrote:
Hi Daniel,

On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
quoted
On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
quoted
Now that we call dma_map in the dma_buf API callbacks there is no need
to use the existing cache APIs. Remove the sync ioctl and the existing
bad dma_sync calls. Explicit caching can be handled with the dma_buf
sync API.

Signed-off-by: Laura Abbott <redacted>
---

 drivers/staging/android/ion/ion-ioctl.c         |  5 ----
 drivers/staging/android/ion/ion.c               | 40 --------------------
 drivers/staging/android/ion/ion_carveout_heap.c |  6 ----
 drivers/staging/android/ion/ion_chunk_heap.c    |  6 ----
 drivers/staging/android/ion/ion_page_pool.c     |  3 --
 drivers/staging/android/ion/ion_system_heap.c   |  5 ----
 6 files changed, 65 deletions(-)
diff --git a/drivers/staging/android/ion/ion-ioctl.c
b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)> 
 			data.handle.handle = handle->id;
 		
 		break;
 	
 	}

-	case ION_IOC_SYNC:
-	{
-		ret = ion_sync_for_device(client, data.fd.fd);
-		break;
-	}
You missed the case ION_IOC_SYNC: in compat_ion.c.

While at it: Should we also remove the entire custom_ioctl infrastructure?
It's entirely unused afaict, and for a pure buffer allocator I don't see
any need to have custom ioctl.
I second that, if you want to make ion a standard API, then we certainly don't 
want any custom ioctl.
quoted
More code to remove potentially:
- The entire compat ioctl stuff - would be an abi break, but I guess if we
  pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
  would allow us to remove compat_ion.c entirely.

- ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
  still need to be able to import anything. All the cache flushing/mapping
  is done through dma-buf ops/ioctls.
Good point to all of the above. I was considering keeping the import around
for backwards compatibility reasons but given how much other stuff is being
potentially broken, everything should just get ripped out.

Thanks,
Laura
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help