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>
>
