From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753558AbdCFNnb (ORCPT ); Mon, 6 Mar 2017 08:43:31 -0500 Received: from galahad.ideasonboard.com ([185.26.127.97]:34493 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752789AbdCFNnT (ORCPT ); Mon, 6 Mar 2017 08:43:19 -0500 From: Laurent Pinchart To: Daniel Vetter Cc: Laura Abbott , dri-devel@lists.freedesktop.org, 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 Subject: Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Date: Mon, 06 Mar 2017 15:43:53 +0200 Message-ID: <6709093.jyTQHIiK7d@avalon> User-Agent: KMail/4.14.10 (Linux/4.9.6-gentoo-r1; KDE/4.14.29; x86_64; ; ) In-Reply-To: <20170306103204.d3yf6woxpsqvdakp@phenom.ffwll.local> References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <0541f57b-4060-ea10-7173-26ae77777518@redhat.com> <20170306103204.d3yf6woxpsqvdakp@phenom.ffwll.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote: > On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote: > > On 03/03/2017 08:41 AM, Laurent Pinchart wrote: > >> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote: > >>> When CMA was first introduced, its primary use was for DMA allocation > >>> and the only way to get CMA memory was to call dma_alloc_coherent. This > >>> put Ion in an awkward position since there was no device structure > >>> readily available and setting one up messed up the coherency model. > >>> These days, CMA can be allocated directly from the APIs. Switch to > >>> using this model to avoid needing a dummy device. This also avoids > >>> awkward caching questions. > >> > >> If the DMA mapping API isn't suitable for today's requirements anymore, > >> I believe that's what needs to be fixed, instead of working around the > >> problem by introducing another use-case-specific API. > > > > I don't think this is a usecase specific API. CMA has been decoupled from > > DMA already because it's used in other places. The trying to go through > > DMA was just another layer of abstraction, especially since there isn't > > a device available for allocation. > > Also, we've had separation of allocation and dma-mapping since forever, > that's how it works almost everywhere. Not exactly sure why/how arm-soc > ecosystem ended up focused so much on dma_alloc_coherent. I believe because that was the easy way to specify memory constraints. The API receives a device pointer and will allocate memory suitable for DMA for that device. The fact that it maps it to the device is a side-effect in my opinion. > I think separating allocation from dma mapping/coherency is perfectly > fine, and the way to go. Especially given that in many cases we'll want to share buffers between multiple devices, so we'll need to map them multiple times. My point still stands though, if we want to move towards a model where allocation and mapping are decoupled, we need an allocation function that takes constraints (possibly implemented with two layers, a constraint resolution layer on top of a pool/heap/type/foo-based allocator), and a mapping API. IOMMU handling being integrated in the DMA mapping API we're currently stuck with it, which might call for brushing up that API. -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f197.google.com (mail-wr0-f197.google.com [209.85.128.197]) by kanga.kvack.org (Postfix) with ESMTP id 9E1466B0038 for ; Mon, 6 Mar 2017 08:43:18 -0500 (EST) Received: by mail-wr0-f197.google.com with SMTP id u108so53121426wrb.3 for ; Mon, 06 Mar 2017 05:43:18 -0800 (PST) Received: from galahad.ideasonboard.com (galahad.ideasonboard.com. [185.26.127.97]) by mx.google.com with ESMTPS id i79si14686822wme.61.2017.03.06.05.43.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 05:43:17 -0800 (PST) From: Laurent Pinchart Subject: Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Date: Mon, 06 Mar 2017 15:43:53 +0200 Message-ID: <6709093.jyTQHIiK7d@avalon> In-Reply-To: <20170306103204.d3yf6woxpsqvdakp@phenom.ffwll.local> References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <0541f57b-4060-ea10-7173-26ae77777518@redhat.com> <20170306103204.d3yf6woxpsqvdakp@phenom.ffwll.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: owner-linux-mm@kvack.org List-ID: To: Daniel Vetter Cc: Laura Abbott , dri-devel@lists.freedesktop.org, 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 Hi Daniel, On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote: > On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote: > > On 03/03/2017 08:41 AM, Laurent Pinchart wrote: > >> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote: > >>> When CMA was first introduced, its primary use was for DMA allocation > >>> and the only way to get CMA memory was to call dma_alloc_coherent. This > >>> put Ion in an awkward position since there was no device structure > >>> readily available and setting one up messed up the coherency model. > >>> These days, CMA can be allocated directly from the APIs. Switch to > >>> using this model to avoid needing a dummy device. This also avoids > >>> awkward caching questions. > >> > >> If the DMA mapping API isn't suitable for today's requirements anymore, > >> I believe that's what needs to be fixed, instead of working around the > >> problem by introducing another use-case-specific API. > > > > I don't think this is a usecase specific API. CMA has been decoupled from > > DMA already because it's used in other places. The trying to go through > > DMA was just another layer of abstraction, especially since there isn't > > a device available for allocation. > > Also, we've had separation of allocation and dma-mapping since forever, > that's how it works almost everywhere. Not exactly sure why/how arm-soc > ecosystem ended up focused so much on dma_alloc_coherent. I believe because that was the easy way to specify memory constraints. The API receives a device pointer and will allocate memory suitable for DMA for that device. The fact that it maps it to the device is a side-effect in my opinion. > I think separating allocation from dma mapping/coherency is perfectly > fine, and the way to go. Especially given that in many cases we'll want to share buffers between multiple devices, so we'll need to map them multiple times. My point still stands though, if we want to move towards a model where allocation and mapping are decoupled, we need an allocation function that takes constraints (possibly implemented with two layers, a constraint resolution layer on top of a pool/heap/type/foo-based allocator), and a mapping API. IOMMU handling being integrated in the DMA mapping API we're currently stuck with it, which might call for brushing up that API. -- Regards, Laurent Pinchart -- 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: laurent.pinchart@ideasonboard.com (Laurent Pinchart) Date: Mon, 06 Mar 2017 15:43:53 +0200 Subject: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly In-Reply-To: <20170306103204.d3yf6woxpsqvdakp@phenom.ffwll.local> References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <0541f57b-4060-ea10-7173-26ae77777518@redhat.com> <20170306103204.d3yf6woxpsqvdakp@phenom.ffwll.local> Message-ID: <6709093.jyTQHIiK7d@avalon> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Daniel, On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote: > On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote: > > On 03/03/2017 08:41 AM, Laurent Pinchart wrote: > >> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote: > >>> When CMA was first introduced, its primary use was for DMA allocation > >>> and the only way to get CMA memory was to call dma_alloc_coherent. This > >>> put Ion in an awkward position since there was no device structure > >>> readily available and setting one up messed up the coherency model. > >>> These days, CMA can be allocated directly from the APIs. Switch to > >>> using this model to avoid needing a dummy device. This also avoids > >>> awkward caching questions. > >> > >> If the DMA mapping API isn't suitable for today's requirements anymore, > >> I believe that's what needs to be fixed, instead of working around the > >> problem by introducing another use-case-specific API. > > > > I don't think this is a usecase specific API. CMA has been decoupled from > > DMA already because it's used in other places. The trying to go through > > DMA was just another layer of abstraction, especially since there isn't > > a device available for allocation. > > Also, we've had separation of allocation and dma-mapping since forever, > that's how it works almost everywhere. Not exactly sure why/how arm-soc > ecosystem ended up focused so much on dma_alloc_coherent. I believe because that was the easy way to specify memory constraints. The API receives a device pointer and will allocate memory suitable for DMA for that device. The fact that it maps it to the device is a side-effect in my opinion. > I think separating allocation from dma mapping/coherency is perfectly > fine, and the way to go. Especially given that in many cases we'll want to share buffers between multiple devices, so we'll need to map them multiple times. My point still stands though, if we want to move towards a model where allocation and mapping are decoupled, we need an allocation function that takes constraints (possibly implemented with two layers, a constraint resolution layer on top of a pool/heap/type/foo-based allocator), and a mapping API. IOMMU handling being integrated in the DMA mapping API we're currently stuck with it, which might call for brushing up that API. -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Date: Mon, 06 Mar 2017 15:43:53 +0200 Message-ID: <6709093.jyTQHIiK7d@avalon> References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <0541f57b-4060-ea10-7173-26ae77777518@redhat.com> <20170306103204.d3yf6woxpsqvdakp@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from galahad.ideasonboard.com (galahad.ideasonboard.com [185.26.127.97]) by gabe.freedesktop.org (Postfix) with ESMTPS id 239246E42D for ; Mon, 6 Mar 2017 13:43:18 +0000 (UTC) In-Reply-To: <20170306103204.d3yf6woxpsqvdakp@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: devel@driverdev.osuosl.org, romlem@google.com, Greg Kroah-Hartman , Riley Andrews , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, arve@android.com, Mark Brown , Daniel Vetter , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org SGkgRGFuaWVsLAoKT24gTW9uZGF5IDA2IE1hciAyMDE3IDExOjMyOjA0IERhbmllbCBWZXR0ZXIg d3JvdGU6Cj4gT24gRnJpLCBNYXIgMDMsIDIwMTcgYXQgMTA6NTA6MjBBTSAtMDgwMCwgTGF1cmEg QWJib3R0IHdyb3RlOgo+ID4gT24gMDMvMDMvMjAxNyAwODo0MSBBTSwgTGF1cmVudCBQaW5jaGFy dCB3cm90ZToKPiA+PiBPbiBUaHVyc2RheSAwMiBNYXIgMjAxNyAxMzo0NDo0MiBMYXVyYSBBYmJv dHQgd3JvdGU6Cj4gPj4+IFdoZW4gQ01BIHdhcyBmaXJzdCBpbnRyb2R1Y2VkLCBpdHMgcHJpbWFy eSB1c2Ugd2FzIGZvciBETUEgYWxsb2NhdGlvbgo+ID4+PiBhbmQgdGhlIG9ubHkgd2F5IHRvIGdl dCBDTUEgbWVtb3J5IHdhcyB0byBjYWxsIGRtYV9hbGxvY19jb2hlcmVudC4gVGhpcwo+ID4+PiBw dXQgSW9uIGluIGFuIGF3a3dhcmQgcG9zaXRpb24gc2luY2UgdGhlcmUgd2FzIG5vIGRldmljZSBz dHJ1Y3R1cmUKPiA+Pj4gcmVhZGlseSBhdmFpbGFibGUgYW5kIHNldHRpbmcgb25lIHVwIG1lc3Nl ZCB1cCB0aGUgY29oZXJlbmN5IG1vZGVsLgo+ID4+PiBUaGVzZSBkYXlzLCBDTUEgY2FuIGJlIGFs bG9jYXRlZCBkaXJlY3RseSBmcm9tIHRoZSBBUElzLiBTd2l0Y2ggdG8KPiA+Pj4gdXNpbmcgdGhp cyBtb2RlbCB0byBhdm9pZCBuZWVkaW5nIGEgZHVtbXkgZGV2aWNlLiBUaGlzIGFsc28gYXZvaWRz Cj4gPj4+IGF3a3dhcmQgY2FjaGluZyBxdWVzdGlvbnMuCj4gPj4gCj4gPj4gSWYgdGhlIERNQSBt YXBwaW5nIEFQSSBpc24ndCBzdWl0YWJsZSBmb3IgdG9kYXkncyByZXF1aXJlbWVudHMgYW55bW9y ZSwKPiA+PiBJIGJlbGlldmUgdGhhdCdzIHdoYXQgbmVlZHMgdG8gYmUgZml4ZWQsIGluc3RlYWQg b2Ygd29ya2luZyBhcm91bmQgdGhlCj4gPj4gcHJvYmxlbSBieSBpbnRyb2R1Y2luZyBhbm90aGVy IHVzZS1jYXNlLXNwZWNpZmljIEFQSS4KPiA+IAo+ID4gSSBkb24ndCB0aGluayB0aGlzIGlzIGEg dXNlY2FzZSBzcGVjaWZpYyBBUEkuIENNQSBoYXMgYmVlbiBkZWNvdXBsZWQgZnJvbQo+ID4gRE1B IGFscmVhZHkgYmVjYXVzZSBpdCdzIHVzZWQgaW4gb3RoZXIgcGxhY2VzLiBUaGUgdHJ5aW5nIHRv IGdvIHRocm91Z2gKPiA+IERNQSB3YXMganVzdCBhbm90aGVyIGxheWVyIG9mIGFic3RyYWN0aW9u LCBlc3BlY2lhbGx5IHNpbmNlIHRoZXJlIGlzbid0Cj4gPiBhIGRldmljZSBhdmFpbGFibGUgZm9y IGFsbG9jYXRpb24uCj4gCj4gQWxzbywgd2UndmUgaGFkIHNlcGFyYXRpb24gb2YgYWxsb2NhdGlv biBhbmQgZG1hLW1hcHBpbmcgc2luY2UgZm9yZXZlciwKPiB0aGF0J3MgaG93IGl0IHdvcmtzIGFs bW9zdCBldmVyeXdoZXJlLiBOb3QgZXhhY3RseSBzdXJlIHdoeS9ob3cgYXJtLXNvYwo+IGVjb3N5 c3RlbSBlbmRlZCB1cCBmb2N1c2VkIHNvIG11Y2ggb24gZG1hX2FsbG9jX2NvaGVyZW50LgoKSSBi ZWxpZXZlIGJlY2F1c2UgdGhhdCB3YXMgdGhlIGVhc3kgd2F5IHRvIHNwZWNpZnkgbWVtb3J5IGNv bnN0cmFpbnRzLiBUaGUgQVBJIApyZWNlaXZlcyBhIGRldmljZSBwb2ludGVyIGFuZCB3aWxsIGFs bG9jYXRlIG1lbW9yeSBzdWl0YWJsZSBmb3IgRE1BIGZvciB0aGF0IApkZXZpY2UuIFRoZSBmYWN0 IHRoYXQgaXQgbWFwcyBpdCB0byB0aGUgZGV2aWNlIGlzIGEgc2lkZS1lZmZlY3QgaW4gbXkgb3Bp bmlvbi4KCj4gSSB0aGluayBzZXBhcmF0aW5nIGFsbG9jYXRpb24gZnJvbSBkbWEgbWFwcGluZy9j b2hlcmVuY3kgaXMgcGVyZmVjdGx5Cj4gZmluZSwgYW5kIHRoZSB3YXkgdG8gZ28uCgpFc3BlY2lh bGx5IGdpdmVuIHRoYXQgaW4gbWFueSBjYXNlcyB3ZSdsbCB3YW50IHRvIHNoYXJlIGJ1ZmZlcnMg YmV0d2VlbiAKbXVsdGlwbGUgZGV2aWNlcywgc28gd2UnbGwgbmVlZCB0byBtYXAgdGhlbSBtdWx0 aXBsZSB0aW1lcy4KCk15IHBvaW50IHN0aWxsIHN0YW5kcyB0aG91Z2gsIGlmIHdlIHdhbnQgdG8g bW92ZSB0b3dhcmRzIGEgbW9kZWwgd2hlcmUgCmFsbG9jYXRpb24gYW5kIG1hcHBpbmcgYXJlIGRl Y291cGxlZCwgd2UgbmVlZCBhbiBhbGxvY2F0aW9uIGZ1bmN0aW9uIHRoYXQgCnRha2VzIGNvbnN0 cmFpbnRzIChwb3NzaWJseSBpbXBsZW1lbnRlZCB3aXRoIHR3byBsYXllcnMsIGEgY29uc3RyYWlu dCAKcmVzb2x1dGlvbiBsYXllciBvbiB0b3Agb2YgYSBwb29sL2hlYXAvdHlwZS9mb28tYmFzZWQg YWxsb2NhdG9yKSwgYW5kIGEgCm1hcHBpbmcgQVBJLiBJT01NVSBoYW5kbGluZyBiZWluZyBpbnRl Z3JhdGVkIGluIHRoZSBETUEgbWFwcGluZyBBUEkgd2UncmUgCmN1cnJlbnRseSBzdHVjayB3aXRo IGl0LCB3aGljaCBtaWdodCBjYWxsIGZvciBicnVzaGluZyB1cCB0aGF0IEFQSS4KCi0tIApSZWdh cmRzLAoKTGF1cmVudCBQaW5jaGFydAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJl ZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGlu Zm8vZHJpLWRldmVsCg==