linux-kernel - Re: [PATCH] staging/android: Update ION TODO per LPC discussion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <55D793D4.4050500@intel.com>
Date:	Fri, 21 Aug 2015 18:10:44 -0300
From:	Tiago Vignatti <tiago.vignatti@...el.com>
To:	Daniel Vetter <daniel.vetter@...ll.ch>,
	LKML <linux-kernel@...r.kernel.org>
Cc:	DRI Development <dri-devel@...ts.freedesktop.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Laura Abbott <labbott@...hat.com>, sumit.semwal@...aro.org,
	laurent.pinchart@...asonboard.com, ghackmann@...gle.com,
	robdclark@...il.com, david.brown@....com, romlem@...gle.com,
	Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [PATCH] staging/android: Update ION TODO per LPC discussion

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@...hat.com>
> Cc: sumit.semwal@...aro.org
> Cc: laurent.pinchart@...asonboard.com
> Cc: ghackmann@...gle.com
> Cc: robdclark@...il.com
> Cc: david.brown@....com
> Cc: romlem@...gle.com
> Cc: Tiago Vignatti <tiago.vignatti@...el.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@...el.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@...ah.com> and Cc:
>   Brian Swetland <swetland@...gle.com>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/