[PATCH] staging/android: Update ION TODO per LPC discussion

[Tiago Vignatti]

sgtm. Thanks for keeping me in the loop.

Tiago

On 08/21/2015 06:02 PM, Daniel Vetter wrote:
> We discussed a bit with the folks on the Cc: list below what to do
> with ION. Two big take-aways:
>
> - High-performance drivers (like gpus) always want to play tricks with
>    coherency and will lie to the dma api (radeon, nouveau, i915 gpu
>    drivers all do so in upstream). What needs to be done here is fill
>    gaps in dma-buf so that we can do this without breaking the dma-api
>    expections of other clients like v4l. The consesus is that hw won't
>    stop needing these tricks anytime soon.
>
> - Placement constraints for shared buffers won't be solved any other
>    way than through something platform-specific like ion with
>    platform-specific knowledge in userspace in something like gralloc.
>    For general-purpose devices where this assumption would be painful
>    for userspace (like servers) the consensus is that such devices will
>    have proper MMUs where placement constraint handling is fairly
>    irrelevant.
>
> Hence it is reasonable to destage ion as-is without changing the
> overall design to enable these use-cases and just fixing up a these
> few fairly minor things. Since there won't relly be an open-source
> userspace for ion (and hence drm maintainers won't take it) the
> proposal is to eventually move it to drivers/android/ion.[hc]. Laura
> would be ok with being maintainer once this is all done and ion is
> destaged.
>
> Note that Thiago is working on exposing the cpu cache flushing for
> cpu access from userspace through mmaps so this is alread in progress.
> Also adding him to the Cc: list.
>
> v2: Add ION_IOC_IMPORT to the list of ioctl that probably should go.
>
> Cc: Laura Abbott <labbott at redhat.com>
> Cc: sumit.semwal at linaro.org
> Cc: laurent.pinchart at ideasonboard.com
> Cc: ghackmann at google.com
> Cc: robdclark at gmail.com
> Cc: david.brown at arm.com
> Cc: romlem at google.com
> Cc: Tiago Vignatti <tiago.vignatti at intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> ---
>   drivers/staging/android/TODO | 20 ++++++++++++++++++++
>   1 file changed, 20 insertions(+)
>
> diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> index 06954cdf3dba..bc84a72af32d 100644
> --- a/drivers/staging/android/TODO
> +++ b/drivers/staging/android/TODO
> @@ -13,5 +13,25 @@ TODO:
>   	- This bug is introduced by Xiong Zhou in the patch bd471258f2e09
>   	- ("staging: android: logger: use kuid_t instead of uid_t")
>
> +
> +ion/
> + - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel internal
> +   interface on top of dma-buf. flush_for_device needs to be added to dma-buf
> +   first.
> + - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in some
> +   vendor trees. Should be replaced with an ioctl on the dma-buf to expose the
> +   begin/end_cpu_access hooks to userspace.
> + - Clarify the tricks ion plays with explicitly managing coherency behind the
> +   dma api's back (this is absolutely needed for high-perf gpu drivers): Add an
> +   explicit coherency management mode to flush_for_device to be used by drivers
> +   which want to manage caches themselves and which indicates whether cpu caches
> +   need flushing.
> + - With those removed there's probably no use for ION_IOC_IMPORT anymore either
> +   since ion would just be the central allocator for shared buffers.
> + - Add dt-binding to expose cma regions as ion heaps, with the rule that any
> +   such cma regions must already be used by some device for dma. I.e. ion only
> +   exposes existing cma regions and doesn't reserve unecessarily memory when
> +   booting a system which doesn't use ion.
> +
>   Please send patches to Greg Kroah-Hartman <greg at kroah.com> and Cc:
>   Brian Swetland <swetland at google.com>
>