Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752901AbbHUVKu (ORCPT ); Fri, 21 Aug 2015 17:10:50 -0400 Received: from mga09.intel.com ([134.134.136.24]:33530 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752246AbbHUVKs (ORCPT ); Fri, 21 Aug 2015 17:10:48 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,723,1432623600"; d="scan'208";a="629953031" Subject: Re: [PATCH] staging/android: Update ION TODO per LPC discussion To: Daniel Vetter , LKML References: <1440190977-10050-1-git-send-email-daniel.vetter@ffwll.ch> Cc: DRI Development , Greg KH , Laura Abbott , sumit.semwal@linaro.org, laurent.pinchart@ideasonboard.com, ghackmann@google.com, robdclark@gmail.com, david.brown@arm.com, romlem@google.com, Daniel Vetter From: Tiago Vignatti Message-ID: <55D793D4.4050500@intel.com> Date: Fri, 21 Aug 2015 18:10:44 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <1440190977-10050-1-git-send-email-daniel.vetter@ffwll.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4059 Lines: 87 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 > 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 > Signed-off-by: Daniel Vetter > --- > 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 and Cc: > Brian Swetland > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/