From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752179AbdCCRpm (ORCPT ); Fri, 3 Mar 2017 12:45:42 -0500 Received: from mail-qk0-f178.google.com ([209.85.220.178]:33647 "EHLO mail-qk0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751797AbdCCRpi (ORCPT ); Fri, 3 Mar 2017 12:45:38 -0500 Subject: Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging To: Michal Hocko References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <20170303132949.GC31582@dhcp22.suse.cz> Cc: Sumit Semwal , Riley Andrews , arve@android.com, romlem@google.com, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, linaro-mm-sig@lists.linaro.org, Greg Kroah-Hartman , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, Brian Starkey , Daniel Vetter , Mark Brown , Benjamin Gaignard , linux-mm@kvack.org From: Laura Abbott Message-ID: Date: Fri, 3 Mar 2017 09:37:55 -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: <20170303132949.GC31582@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/03/2017 05:29 AM, Michal Hocko wrote: > On Thu 02-03-17 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. >> - CMA allocations now happen without the need of a dummy device structure. >> This fixes a bunch of the reasons why I attempted to add devicetree >> support before. >> >> I've had problems getting feedback in the past so if I don't hear any major >> objections I'm going to send out with the RFC dropped to be picked up. >> The only reason there isn't a patch to come out of staging is to discuss any >> other changes to the ABI people might want. Once this comes out of staging, >> I really don't want to mess with the ABI. > > Could you recapitulate concerns preventing the code being merged > normally rather than through the staging tree and how they were > addressed? > Sorry, I'm really not understanding your question here, can you clarify? Thanks, Laura From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f198.google.com (mail-qk0-f198.google.com [209.85.220.198]) by kanga.kvack.org (Postfix) with ESMTP id D61D96B0038 for ; Fri, 3 Mar 2017 12:38:00 -0500 (EST) Received: by mail-qk0-f198.google.com with SMTP id c85so148705326qkg.0 for ; Fri, 03 Mar 2017 09:38:00 -0800 (PST) Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com. [209.85.220.169]) by mx.google.com with ESMTPS id p186si852081qkc.250.2017.03.03.09.37.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 09:37:59 -0800 (PST) Received: by mail-qk0-f169.google.com with SMTP id n127so187369102qkf.0 for ; Fri, 03 Mar 2017 09:37:59 -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> <20170303132949.GC31582@dhcp22.suse.cz> From: Laura Abbott Message-ID: Date: Fri, 3 Mar 2017 09:37:55 -0800 MIME-Version: 1.0 In-Reply-To: <20170303132949.GC31582@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Sumit Semwal , Riley Andrews , arve@android.com, romlem@google.com, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, linaro-mm-sig@lists.linaro.org, Greg Kroah-Hartman , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, Brian Starkey , Daniel Vetter , Mark Brown , Benjamin Gaignard , linux-mm@kvack.org On 03/03/2017 05:29 AM, Michal Hocko wrote: > On Thu 02-03-17 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. >> - CMA allocations now happen without the need of a dummy device structure. >> This fixes a bunch of the reasons why I attempted to add devicetree >> support before. >> >> I've had problems getting feedback in the past so if I don't hear any major >> objections I'm going to send out with the RFC dropped to be picked up. >> The only reason there isn't a patch to come out of staging is to discuss any >> other changes to the ABI people might want. Once this comes out of staging, >> I really don't want to mess with the ABI. > > Could you recapitulate concerns preventing the code being merged > normally rather than through the staging tree and how they were > addressed? > Sorry, I'm really not understanding your question here, can you clarify? 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 09:37:55 -0800 Subject: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging In-Reply-To: <20170303132949.GC31582@dhcp22.suse.cz> References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <20170303132949.GC31582@dhcp22.suse.cz> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 03/03/2017 05:29 AM, Michal Hocko wrote: > On Thu 02-03-17 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. >> - CMA allocations now happen without the need of a dummy device structure. >> This fixes a bunch of the reasons why I attempted to add devicetree >> support before. >> >> I've had problems getting feedback in the past so if I don't hear any major >> objections I'm going to send out with the RFC dropped to be picked up. >> The only reason there isn't a patch to come out of staging is to discuss any >> other changes to the ABI people might want. Once this comes out of staging, >> I really don't want to mess with the ABI. > > Could you recapitulate concerns preventing the code being merged > normally rather than through the staging tree and how they were > addressed? > Sorry, I'm really not understanding your question here, can you clarify? 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 09:37:55 -0800 Message-ID: References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <20170303132949.GC31582@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) by gabe.freedesktop.org (Postfix) with ESMTPS id E65D66EDB8 for ; Fri, 3 Mar 2017 17:37:59 +0000 (UTC) Received: by mail-qk0-f181.google.com with SMTP id g129so3676392qkd.1 for ; Fri, 03 Mar 2017 09:37:59 -0800 (PST) In-Reply-To: <20170303132949.GC31582@dhcp22.suse.cz> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Michal Hocko Cc: devel@driverdev.osuosl.org, romlem@google.com, Greg Kroah-Hartman , arve@android.com, dri-devel@lists.freedesktop.org, 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 T24gMDMvMDMvMjAxNyAwNToyOSBBTSwgTWljaGFsIEhvY2tvIHdyb3RlOgo+IE9uIFRodSAwMi0w My0xNyAxMzo0NDozMiwgTGF1cmEgQWJib3R0IHdyb3RlOgo+PiBIaSwKPj4KPj4gVGhlcmUncyBi ZWVuIHNvbWUgcmVjZW50IGRpc2N1c3Npb25zWzFdIGFib3V0IElvbi1saWtlIGZyYW1ld29ya3Mu IFRoZXJlJ3MKPj4gYXBwYXJlbnRseSBpbnRlcmVzdCBpbiBqdXN0IGtlZXBpbmcgSW9uIHNpbmNl IGl0IHdvcmtzIHJlYXNvbmFibGx5IHdlbGwuCj4+IFRoaXMgc2VyaWVzIGRvZXMgd2hhdCBzaG91 bGQgYmUgdGhlIGZpbmFsIGNsZWFuIHVwcyBmb3IgaXQgdG8gcG9zc2libHkgYmUKPj4gbW92ZWQg b3V0IG9mIHN0YWdpbmcuCj4+Cj4+IFRoaXMgaW5jbHVkZXMgdGhlIGZvbGxvd2luZzoKPj4gLSBT b21lIGdlbmVyYWwgY2xlYW4gdXAgYW5kIHJlbW92YWwgb2YgZmVhdHVyZXMgdGhhdCBuZXZlciBn b3QgYSBsb3Qgb2YgdXNlCj4+ICAgYXMgZmFyIGFzIEkgY2FuIHRlbGwuCj4+IC0gRml4aW5nIHVw IHRoZSBjYWNoaW5nLiBUaGlzIGlzIHRoZSBzZXJpZXMgSSBwcm9wb3NlZCBiYWNrIGluIERlY2Vt YmVyWzJdCj4+ICAgYnV0IG5ldmVyIGhlYXJkIGFueSBmZWVkYmFjayBvbi4gSXQgd2lsbCBjZXJ0 YWlubHkgYnJlYWsgZXhpc3RpbmcKPj4gICBhcHBsaWNhdGlvbnMgdGhhdCByZWx5IG9uIHRoZSBp bXBsaWNpdCBjYWNoaW5nLiBJJ2QgcmF0aGVyIG1ha2UgYW4gZWZmb3J0Cj4+ICAgdG8gbW92ZSB0 byBhIG1vZGVsIHRoYXQgaXNuJ3QgZ29pbmcgZGlyZWN0bHkgYWdhaW5zdCB0aGUgZXN0YWJsaXNo ZW1lbnQKPj4gICB0aG91Z2guCj4+IC0gRml4aW5nIHVwIHRoZSBwbGF0Zm9ybSBzdXBwb3J0LiBU aGUgZGV2aWNldHJlZSBhcHByb2FjaCB3YXMgbmV2ZXIgd2VsbAo+PiAgIHJlY2lldmVkIGJ5IERU IG1haW50YWluZXJzLiBUaGUgcHJvcG9zYWwgaGVyZSBpcyB0byB0aGluayBvZiBJb24gbGVzcyBh cwo+PiAgIHNwZWNpZnlpbmcgcmVxdWlyZW1lbnRzIGFuZCBtb3JlIG9mIGEgZnJhbWV3b3JrIGZv ciBleHBvc2luZyBtZW1vcnkgdG8KPj4gICB1c2Vyc3BhY2UuCj4+IC0gQ01BIGFsbG9jYXRpb25z IG5vdyBoYXBwZW4gd2l0aG91dCB0aGUgbmVlZCBvZiBhIGR1bW15IGRldmljZSBzdHJ1Y3R1cmUu Cj4+ICAgVGhpcyBmaXhlcyBhIGJ1bmNoIG9mIHRoZSByZWFzb25zIHdoeSBJIGF0dGVtcHRlZCB0 byBhZGQgZGV2aWNldHJlZQo+PiAgIHN1cHBvcnQgYmVmb3JlLgo+Pgo+PiBJJ3ZlIGhhZCBwcm9i bGVtcyBnZXR0aW5nIGZlZWRiYWNrIGluIHRoZSBwYXN0IHNvIGlmIEkgZG9uJ3QgaGVhciBhbnkg bWFqb3IKPj4gb2JqZWN0aW9ucyBJJ20gZ29pbmcgdG8gc2VuZCBvdXQgd2l0aCB0aGUgUkZDIGRy b3BwZWQgdG8gYmUgcGlja2VkIHVwLgo+PiBUaGUgb25seSByZWFzb24gdGhlcmUgaXNuJ3QgYSBw YXRjaCB0byBjb21lIG91dCBvZiBzdGFnaW5nIGlzIHRvIGRpc2N1c3MgYW55Cj4+IG90aGVyIGNo YW5nZXMgdG8gdGhlIEFCSSBwZW9wbGUgbWlnaHQgd2FudC4gT25jZSB0aGlzIGNvbWVzIG91dCBv ZiBzdGFnaW5nLAo+PiBJIHJlYWxseSBkb24ndCB3YW50IHRvIG1lc3Mgd2l0aCB0aGUgQUJJLgo+ IAo+IENvdWxkIHlvdSByZWNhcGl0dWxhdGUgY29uY2VybnMgcHJldmVudGluZyB0aGUgY29kZSBi ZWluZyBtZXJnZWQKPiBub3JtYWxseSByYXRoZXIgdGhhbiB0aHJvdWdoIHRoZSBzdGFnaW5nIHRy ZWUgYW5kIGhvdyB0aGV5IHdlcmUKPiBhZGRyZXNzZWQ/Cj4gCgpTb3JyeSwgSSdtIHJlYWxseSBu b3QgdW5kZXJzdGFuZGluZyB5b3VyIHF1ZXN0aW9uIGhlcmUsIGNhbiB5b3UKY2xhcmlmeT8KClRo YW5rcywKTGF1cmEKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3Jn Cmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs Cg==