staging/android: Update ION TODO per LPC discussion
diff mbox

Message ID 1440190977-10050-1-git-send-email-daniel.vetter@ffwll.ch
State New
Headers show

Commit Message

Daniel Vetter Aug. 21, 2015, 9:02 p.m. UTC
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@redhat.com>
Cc: sumit.semwal@linaro.org
Cc: laurent.pinchart@ideasonboard.com
Cc: ghackmann@google.com
Cc: robdclark@gmail.com
Cc: david.brown@arm.com
Cc: romlem@google.com
Cc: Tiago Vignatti <tiago.vignatti@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/staging/android/TODO | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

Comments

Tiago Vignatti Aug. 21, 2015, 9:10 p.m. UTC | #1
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@redhat.com>
> Cc: sumit.semwal@linaro.org
> Cc: laurent.pinchart@ideasonboard.com
> Cc: ghackmann@google.com
> Cc: robdclark@gmail.com
> Cc: david.brown@arm.com
> Cc: romlem@google.com
> Cc: Tiago Vignatti <tiago.vignatti@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@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@kroah.com> and Cc:
>   Brian Swetland <swetland@google.com>
>

Patch
diff mbox

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@kroah.com> and Cc:
 Brian Swetland <swetland@google.com>