From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752438AbdCCTOy (ORCPT ); Fri, 3 Mar 2017 14:14:54 -0500 Received: from mail-qk0-f182.google.com ([209.85.220.182]:33319 "EHLO mail-qk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752411AbdCCTOw (ORCPT ); Fri, 3 Mar 2017 14:14:52 -0500 Subject: Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging To: Laurent Pinchart , dri-devel@lists.freedesktop.org References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <1836110.VXJcCJDUAn@avalon> Cc: Sumit Semwal , Riley Andrews , arve@android.com, devel@driverdev.osuosl.org, romlem@google.com, Greg Kroah-Hartman , linux-kernel@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, Mark Brown , Daniel Vetter , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org From: Laura Abbott Message-ID: Date: Fri, 3 Mar 2017 11:14:47 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <1836110.VXJcCJDUAn@avalon> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/03/2017 08:25 AM, Laurent Pinchart wrote: > Hi Laura, > > Thank you for the patches. > > On Thursday 02 Mar 2017 13:44:32 Laura Abbott wrote: >> Hi, >> >> There's been some recent discussions[1] about Ion-like frameworks. There's >> apparently interest in just keeping Ion since it works reasonablly well. >> This series does what should be the final clean ups for it to possibly be >> moved out of staging. >> >> This includes the following: >> - Some general clean up and removal of features that never got a lot of use >> as far as I can tell. >> - Fixing up the caching. This is the series I proposed back in December[2] >> but never heard any feedback on. It will certainly break existing >> applications that rely on the implicit caching. I'd rather make an effort >> to move to a model that isn't going directly against the establishement >> though. >> - Fixing up the platform support. The devicetree approach was never well >> recieved by DT maintainers. The proposal here is to think of Ion less as >> specifying requirements and more of a framework for exposing memory to >> userspace. > > That's where most of my concerns with ion are. I still strongly believe that > the heap-based approach is inherently flawed, as it would need to be > configured for each device according to product-specific use cases. That's not > something that could be easily shipped with a generic distribution. We should > replace that with a constraint-based system. > I don't think of constraints and heaps as being mutually exclusive. Some general heaps (e.g. system heaps) can be available always. Others might just be exposed if there is a particular memory region available. The constraint solving is responsible for querying and figuring out what's the best choice. Thanks, Laura From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f199.google.com (mail-qk0-f199.google.com [209.85.220.199]) by kanga.kvack.org (Postfix) with ESMTP id 4152A6B038C for ; Fri, 3 Mar 2017 14:14:52 -0500 (EST) Received: by mail-qk0-f199.google.com with SMTP id a189so150899510qkc.4 for ; Fri, 03 Mar 2017 11:14:52 -0800 (PST) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com. [209.85.220.171]) by mx.google.com with ESMTPS id 124si9990712qkh.292.2017.03.03.11.14.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 11:14:51 -0800 (PST) Received: by mail-qk0-f171.google.com with SMTP id n127so192007891qkf.0 for ; Fri, 03 Mar 2017 11:14:51 -0800 (PST) Subject: Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <1836110.VXJcCJDUAn@avalon> From: Laura Abbott Message-ID: Date: Fri, 3 Mar 2017 11:14:47 -0800 MIME-Version: 1.0 In-Reply-To: <1836110.VXJcCJDUAn@avalon> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Laurent Pinchart , dri-devel@lists.freedesktop.org Cc: Sumit Semwal , Riley Andrews , arve@android.com, devel@driverdev.osuosl.org, romlem@google.com, Greg Kroah-Hartman , linux-kernel@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, Mark Brown , Daniel Vetter , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org On 03/03/2017 08:25 AM, Laurent Pinchart wrote: > Hi Laura, > > Thank you for the patches. > > On Thursday 02 Mar 2017 13:44:32 Laura Abbott wrote: >> Hi, >> >> There's been some recent discussions[1] about Ion-like frameworks. There's >> apparently interest in just keeping Ion since it works reasonablly well. >> This series does what should be the final clean ups for it to possibly be >> moved out of staging. >> >> This includes the following: >> - Some general clean up and removal of features that never got a lot of use >> as far as I can tell. >> - Fixing up the caching. This is the series I proposed back in December[2] >> but never heard any feedback on. It will certainly break existing >> applications that rely on the implicit caching. I'd rather make an effort >> to move to a model that isn't going directly against the establishement >> though. >> - Fixing up the platform support. The devicetree approach was never well >> recieved by DT maintainers. The proposal here is to think of Ion less as >> specifying requirements and more of a framework for exposing memory to >> userspace. > > That's where most of my concerns with ion are. I still strongly believe that > the heap-based approach is inherently flawed, as it would need to be > configured for each device according to product-specific use cases. That's not > something that could be easily shipped with a generic distribution. We should > replace that with a constraint-based system. > I don't think of constraints and heaps as being mutually exclusive. Some general heaps (e.g. system heaps) can be available always. Others might just be exposed if there is a particular memory region available. The constraint solving is responsible for querying and figuring out what's the best choice. Thanks, Laura -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: labbott@redhat.com (Laura Abbott) Date: Fri, 3 Mar 2017 11:14:47 -0800 Subject: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging In-Reply-To: <1836110.VXJcCJDUAn@avalon> References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <1836110.VXJcCJDUAn@avalon> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 03/03/2017 08:25 AM, Laurent Pinchart wrote: > Hi Laura, > > Thank you for the patches. > > On Thursday 02 Mar 2017 13:44:32 Laura Abbott wrote: >> Hi, >> >> There's been some recent discussions[1] about Ion-like frameworks. There's >> apparently interest in just keeping Ion since it works reasonablly well. >> This series does what should be the final clean ups for it to possibly be >> moved out of staging. >> >> This includes the following: >> - Some general clean up and removal of features that never got a lot of use >> as far as I can tell. >> - Fixing up the caching. This is the series I proposed back in December[2] >> but never heard any feedback on. It will certainly break existing >> applications that rely on the implicit caching. I'd rather make an effort >> to move to a model that isn't going directly against the establishement >> though. >> - Fixing up the platform support. The devicetree approach was never well >> recieved by DT maintainers. The proposal here is to think of Ion less as >> specifying requirements and more of a framework for exposing memory to >> userspace. > > That's where most of my concerns with ion are. I still strongly believe that > the heap-based approach is inherently flawed, as it would need to be > configured for each device according to product-specific use cases. That's not > something that could be easily shipped with a generic distribution. We should > replace that with a constraint-based system. > I don't think of constraints and heaps as being mutually exclusive. Some general heaps (e.g. system heaps) can be available always. Others might just be exposed if there is a particular memory region available. The constraint solving is responsible for querying and figuring out what's the best choice. Thanks, Laura From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laura Abbott Subject: Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Date: Fri, 3 Mar 2017 11:14:47 -0800 Message-ID: References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <1836110.VXJcCJDUAn@avalon> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) by gabe.freedesktop.org (Postfix) with ESMTPS id C81906EDEA for ; Fri, 3 Mar 2017 19:14:51 +0000 (UTC) Received: by mail-qk0-f176.google.com with SMTP id g129so8312124qkd.1 for ; Fri, 03 Mar 2017 11:14:51 -0800 (PST) In-Reply-To: <1836110.VXJcCJDUAn@avalon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Laurent Pinchart , dri-devel@lists.freedesktop.org Cc: devel@driverdev.osuosl.org, romlem@google.com, Greg Kroah-Hartman , arve@android.com, linux-kernel@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, Riley Andrews , Mark Brown , Daniel Vetter , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org T24gMDMvMDMvMjAxNyAwODoyNSBBTSwgTGF1cmVudCBQaW5jaGFydCB3cm90ZToKPiBIaSBMYXVy YSwKPiAKPiBUaGFuayB5b3UgZm9yIHRoZSBwYXRjaGVzLgo+IAo+IE9uIFRodXJzZGF5IDAyIE1h ciAyMDE3IDEzOjQ0OjMyIExhdXJhIEFiYm90dCB3cm90ZToKPj4gSGksCj4+Cj4+IFRoZXJlJ3Mg YmVlbiBzb21lIHJlY2VudCBkaXNjdXNzaW9uc1sxXSBhYm91dCBJb24tbGlrZSBmcmFtZXdvcmtz LiBUaGVyZSdzCj4+IGFwcGFyZW50bHkgaW50ZXJlc3QgaW4ganVzdCBrZWVwaW5nIElvbiBzaW5j ZSBpdCB3b3JrcyByZWFzb25hYmxseSB3ZWxsLgo+PiBUaGlzIHNlcmllcyBkb2VzIHdoYXQgc2hv dWxkIGJlIHRoZSBmaW5hbCBjbGVhbiB1cHMgZm9yIGl0IHRvIHBvc3NpYmx5IGJlCj4+IG1vdmVk IG91dCBvZiBzdGFnaW5nLgo+Pgo+PiBUaGlzIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmc6Cj4+IC0g U29tZSBnZW5lcmFsIGNsZWFuIHVwIGFuZCByZW1vdmFsIG9mIGZlYXR1cmVzIHRoYXQgbmV2ZXIg Z290IGEgbG90IG9mIHVzZQo+PiAgIGFzIGZhciBhcyBJIGNhbiB0ZWxsLgo+PiAtIEZpeGluZyB1 cCB0aGUgY2FjaGluZy4gVGhpcyBpcyB0aGUgc2VyaWVzIEkgcHJvcG9zZWQgYmFjayBpbiBEZWNl bWJlclsyXQo+PiAgIGJ1dCBuZXZlciBoZWFyZCBhbnkgZmVlZGJhY2sgb24uIEl0IHdpbGwgY2Vy dGFpbmx5IGJyZWFrIGV4aXN0aW5nCj4+ICAgYXBwbGljYXRpb25zIHRoYXQgcmVseSBvbiB0aGUg aW1wbGljaXQgY2FjaGluZy4gSSdkIHJhdGhlciBtYWtlIGFuIGVmZm9ydAo+PiAgIHRvIG1vdmUg dG8gYSBtb2RlbCB0aGF0IGlzbid0IGdvaW5nIGRpcmVjdGx5IGFnYWluc3QgdGhlIGVzdGFibGlz aGVtZW50Cj4+ICAgdGhvdWdoLgo+PiAtIEZpeGluZyB1cCB0aGUgcGxhdGZvcm0gc3VwcG9ydC4g VGhlIGRldmljZXRyZWUgYXBwcm9hY2ggd2FzIG5ldmVyIHdlbGwKPj4gICByZWNpZXZlZCBieSBE VCBtYWludGFpbmVycy4gVGhlIHByb3Bvc2FsIGhlcmUgaXMgdG8gdGhpbmsgb2YgSW9uIGxlc3Mg YXMKPj4gICBzcGVjaWZ5aW5nIHJlcXVpcmVtZW50cyBhbmQgbW9yZSBvZiBhIGZyYW1ld29yayBm b3IgZXhwb3NpbmcgbWVtb3J5IHRvCj4+ICAgdXNlcnNwYWNlLgo+IAo+IFRoYXQncyB3aGVyZSBt b3N0IG9mIG15IGNvbmNlcm5zIHdpdGggaW9uIGFyZS4gSSBzdGlsbCBzdHJvbmdseSBiZWxpZXZl IHRoYXQgCj4gdGhlIGhlYXAtYmFzZWQgYXBwcm9hY2ggaXMgaW5oZXJlbnRseSBmbGF3ZWQsIGFz IGl0IHdvdWxkIG5lZWQgdG8gYmUgCj4gY29uZmlndXJlZCBmb3IgZWFjaCBkZXZpY2UgYWNjb3Jk aW5nIHRvIHByb2R1Y3Qtc3BlY2lmaWMgdXNlIGNhc2VzLiBUaGF0J3Mgbm90IAo+IHNvbWV0aGlu ZyB0aGF0IGNvdWxkIGJlIGVhc2lseSBzaGlwcGVkIHdpdGggYSBnZW5lcmljIGRpc3RyaWJ1dGlv bi4gV2Ugc2hvdWxkIAo+IHJlcGxhY2UgdGhhdCB3aXRoIGEgY29uc3RyYWludC1iYXNlZCBzeXN0 ZW0uCj4gCgpJIGRvbid0IHRoaW5rIG9mIGNvbnN0cmFpbnRzIGFuZCBoZWFwcyBhcyBiZWluZyBt dXR1YWxseSBleGNsdXNpdmUuIFNvbWUgZ2VuZXJhbApoZWFwcyAoZS5nLiBzeXN0ZW0gaGVhcHMp IGNhbiBiZSBhdmFpbGFibGUgYWx3YXlzLiBPdGhlcnMgbWlnaHQganVzdCBiZQpleHBvc2VkIGlm IHRoZXJlIGlzIGEgcGFydGljdWxhciBtZW1vcnkgcmVnaW9uIGF2YWlsYWJsZS4gVGhlIGNvbnN0 cmFpbnQgc29sdmluZwppcyByZXNwb25zaWJsZSBmb3IgcXVlcnlpbmcgYW5kIGZpZ3VyaW5nIG91 dCB3aGF0J3MgdGhlIGJlc3QgY2hvaWNlLgoKVGhhbmtzLApMYXVyYQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRy aS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5v cmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK