From mboxrd@z Thu Jan 1 00:00:00 1970 From: laura@labbott.name (Laura Abbott) Date: Thu, 22 Oct 2015 10:23:15 -0700 Subject: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion In-Reply-To: <93351858f57ca6e1220a0007f98baa25@cloud.ncrmnt.org> References: <1444164433-9107-1-git-send-email-labbott@fedoraproject.org> <1444164433-9107-2-git-send-email-labbott@fedoraproject.org> <1c6ea0362f5336d9bc8acbfbd7ceae06@mail.ncrmnt.org> <93351858f57ca6e1220a0007f98baa25@cloud.ncrmnt.org> Message-ID: <56291B83.6060208@labbott.name> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 10/22/15 3:36 AM, andrew at ncrmnt.org wrote: > 20 ??????? 2015 ?., 19:34, "Mitchel Humpherys" ???????: >> On Tue, Oct 13 2015 at 11:14:23 AM, Andrew wrote: >> >>> On 2015-10-12 21:39, Mitchel Humpherys wrote: >>>> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring >>>> wrote: >>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott >>>>> wrote: >>>> >>>> [...] >>>> >>>>>> +Example: >>>>>> + >>>>>> + ion { >>>>>> + compatbile = "linux,ion"; >>>>>> + #address-cells = <1>; >>>>>> + #size-cells = <0>; >>>>>> + >>>>>> + ion-system-heap { >>>>>> + linux,ion-heap-id = <0>; >>>>>> + linux,ion-heap-type = ; >>>>>> + linux,ion-heap-name = "system"; >>>>> >>>>> How does this vary across platforms? Is all of this being pushed down >>>>> to DT, because there is no coordination of this at the kernel ABI >>>>> level across platforms. In other words, why can't heap 0 be hardcoded >>>>> as system heap in the driver. It seems to me any 1 of these 3 >>>>> properties could be used to derive the other 2. >>>> >>>> The heap-id<->heap-type mapping isn't necessarily 1:1. As Laura >>>> indicated elsewhere on this thread, a given heap might need to be >>>> contiguous on one platform but not on another. In that case you just >>>> swap out the heap-type here and there's no need for userspace to change. >>>> >>>> The heap-name, OTOH, could be derived from the heap-id, which is what we >>>> hackishly do here [1] and here[2]. >>> >>> By the way, since we agreed that heap id and heap type mappings >>> are not 1:1 - we have a problem with the current API. >>> >>> In userspace we currently have this: >>> >>> int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask, >>> unsigned int flags, ion_user_handle_t *handle); >>> >>> We do not specify here what TYPE of heap we want the allocation to come >>> from. >>> This may lead to very unpleasant stuff when porting from one platfrom to >>> another. > > Okay, I may be totally missing some point here then. > >> What "unpleasant stuff" are you referring to, exactly? > > It's not really clear for me how (and at where - kernel or userspace) > we should properly sort out cases when the next device the pipeline > introduces some constraints on the buffer it can use. > > For instance: camera can save data into a non-contiguous buffer, but the > image processing hardware (that may or may not be involved) expects the > buffer to be contiguous. > You've just hit on one of the open problems. There isn't a good answer right now for how that is supposed to work. Sumit was working on cenalloc as an answer to some of that. I think we've decided that may become more of a long term theoretical problem to solve rather than a pressing practical problem. These days IOMMUs and the like are much more common across the entire system so it's becoming rarer to have a case where some hardware can have discontiguous buffers but some cannot. This isn't to say it's not a problem that needs to be solved, but we're focusing on other efforts of Ion right now. In general though we're working off the assumption that the kernel knows the constraints and if userspace is requesting memory from a particular heap the kernel will allocate the correct memory. This means that it's up to the kernel to set up the heaps correctly for a particular platform (once again, an open problem). Thanks, Laura From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laura Abbott Subject: Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion Date: Thu, 22 Oct 2015 10:23:15 -0700 Message-ID: <56291B83.6060208@labbott.name> References: <1444164433-9107-1-git-send-email-labbott@fedoraproject.org> <1444164433-9107-2-git-send-email-labbott@fedoraproject.org> <1c6ea0362f5336d9bc8acbfbd7ceae06@mail.ncrmnt.org> <93351858f57ca6e1220a0007f98baa25@cloud.ncrmnt.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <93351858f57ca6e1220a0007f98baa25@cloud.ncrmnt.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: andrew@ncrmnt.org, Mitchel Humpherys Cc: devel@driverdev.osuosl.org, devicetree@vger.kernel.org, Feng Tang , Tom Gall , romlem@google.com, Greg Kroah-Hartman , a.makarov@module.ru, Riley Andrews , Colin Cross , linux-kernel@vger.kernel.org, a.bogdanova@module.ru, arve@android.com, Rob Herring , Rob Herring , Grant Likely , John Stultz , Marek Szyprowski , Frank Rowand , Sumit Semwal , linux-arm-kernel@lists.infradead.org, Laura Abbott List-Id: devicetree@vger.kernel.org T24gMTAvMjIvMTUgMzozNiBBTSwgYW5kcmV3QG5jcm1udC5vcmcgd3JvdGU6Cj4gMjAg0L7QutGC 0Y/QsdGA0Y8gMjAxNSDQsy4sIDE5OjM0LCAiTWl0Y2hlbCBIdW1waGVyeXMiIDxtaXRjaGVsaEBj b2RlYXVyb3JhLm9yZz4g0L3QsNC/0LjRgdCw0Ls6Cj4+IE9uIFR1ZSwgT2N0IDEzIDIwMTUgYXQg MTE6MTQ6MjMgQU0sIEFuZHJldyA8YW5kcmV3QG5jcm1udC5vcmc+IHdyb3RlOgo+Pgo+Pj4gT24g MjAxNS0xMC0xMiAyMTozOSwgTWl0Y2hlbCBIdW1waGVyeXMgd3JvdGU6Cj4+Pj4gT24gVHVlLCBP Y3QgMDYgMjAxNSBhdCAwNTozNTo0MSBQTSwgUm9iIEhlcnJpbmcgPHJvYmhlcnJpbmcyQGdtYWls LmNvbT4KPj4+PiB3cm90ZToKPj4+Pj4gT24gVHVlLCBPY3QgNiwgMjAxNSBhdCAzOjQ3IFBNLCBM YXVyYSBBYmJvdHQgPGxhYmJvdHRAZmVkb3JhcHJvamVjdC5vcmc+Cj4+Pj4+IHdyb3RlOgo+Pj4+ Cj4+Pj4gWy4uLl0KPj4+Pgo+Pj4+Pj4gK0V4YW1wbGU6Cj4+Pj4+PiArCj4+Pj4+PiArIGlvbiB7 Cj4+Pj4+PiArIGNvbXBhdGJpbGUgPSAibGludXgsaW9uIjsKPj4+Pj4+ICsgI2FkZHJlc3MtY2Vs bHMgPSA8MT47Cj4+Pj4+PiArICNzaXplLWNlbGxzID0gPDA+Owo+Pj4+Pj4gKwo+Pj4+Pj4gKyBp b24tc3lzdGVtLWhlYXAgewo+Pj4+Pj4gKyBsaW51eCxpb24taGVhcC1pZCA9IDwwPjsKPj4+Pj4+ ICsgbGludXgsaW9uLWhlYXAtdHlwZSA9IDxJT05fU1lTVEVNX0hFQVBfVFlQRT47Cj4+Pj4+PiAr IGxpbnV4LGlvbi1oZWFwLW5hbWUgPSAic3lzdGVtIjsKPj4+Pj4KPj4+Pj4gSG93IGRvZXMgdGhp cyB2YXJ5IGFjcm9zcyBwbGF0Zm9ybXM/IElzIGFsbCBvZiB0aGlzIGJlaW5nIHB1c2hlZCBkb3du Cj4+Pj4+IHRvIERULCBiZWNhdXNlIHRoZXJlIGlzIG5vIGNvb3JkaW5hdGlvbiBvZiB0aGlzIGF0 IHRoZSBrZXJuZWwgQUJJCj4+Pj4+IGxldmVsIGFjcm9zcyBwbGF0Zm9ybXMuIEluIG90aGVyIHdv cmRzLCB3aHkgY2FuJ3QgaGVhcCAwIGJlIGhhcmRjb2RlZAo+Pj4+PiBhcyBzeXN0ZW0gaGVhcCBp biB0aGUgZHJpdmVyLiBJdCBzZWVtcyB0byBtZSBhbnkgMSBvZiB0aGVzZSAzCj4+Pj4+IHByb3Bl cnRpZXMgY291bGQgYmUgdXNlZCB0byBkZXJpdmUgdGhlIG90aGVyIDIuCj4+Pj4KPj4+PiBUaGUg aGVhcC1pZDwtPmhlYXAtdHlwZSBtYXBwaW5nIGlzbid0IG5lY2Vzc2FyaWx5IDE6MS4gQXMgTGF1 cmEKPj4+PiBpbmRpY2F0ZWQgZWxzZXdoZXJlIG9uIHRoaXMgdGhyZWFkLCBhIGdpdmVuIGhlYXAg bWlnaHQgbmVlZCB0byBiZQo+Pj4+IGNvbnRpZ3VvdXMgb24gb25lIHBsYXRmb3JtIGJ1dCBub3Qg b24gYW5vdGhlci4gSW4gdGhhdCBjYXNlIHlvdSBqdXN0Cj4+Pj4gc3dhcCBvdXQgdGhlIGhlYXAt dHlwZSBoZXJlIGFuZCB0aGVyZSdzIG5vIG5lZWQgZm9yIHVzZXJzcGFjZSB0byBjaGFuZ2UuCj4+ Pj4KPj4+PiBUaGUgaGVhcC1uYW1lLCBPVE9ILCBjb3VsZCBiZSBkZXJpdmVkIGZyb20gdGhlIGhl YXAtaWQsIHdoaWNoIGlzIHdoYXQgd2UKPj4+PiBoYWNraXNobHkgZG8gaGVyZSBbMV0gYW5kIGhl cmVbMl0uCj4+Pgo+Pj4gQnkgdGhlIHdheSwgc2luY2Ugd2UgYWdyZWVkIHRoYXQgaGVhcCBpZCBh bmQgaGVhcCB0eXBlIG1hcHBpbmdzCj4+PiBhcmUgbm90IDE6MSAtIHdlIGhhdmUgYSBwcm9ibGVt IHdpdGggdGhlIGN1cnJlbnQgQVBJLgo+Pj4KPj4+IEluIHVzZXJzcGFjZSB3ZSBjdXJyZW50bHkg aGF2ZSB0aGlzOgo+Pj4KPj4+IGludCBpb25fYWxsb2MoaW50IGZkLCBzaXplX3QgbGVuLCBzaXpl X3QgYWxpZ24sIHVuc2lnbmVkIGludCBoZWFwX21hc2ssCj4+PiB1bnNpZ25lZCBpbnQgZmxhZ3Ms IGlvbl91c2VyX2hhbmRsZV90ICpoYW5kbGUpOwo+Pj4KPj4+IFdlIGRvIG5vdCBzcGVjaWZ5IGhl cmUgd2hhdCBUWVBFIG9mIGhlYXAgd2Ugd2FudCB0aGUgYWxsb2NhdGlvbiB0byBjb21lCj4+PiBm cm9tLgo+Pj4gVGhpcyBtYXkgbGVhZCB0byB2ZXJ5IHVucGxlYXNhbnQgc3R1ZmYgd2hlbiBwb3J0 aW5nIGZyb20gb25lIHBsYXRmcm9tIHRvCj4+PiBhbm90aGVyLgo+Cj4gT2theSwgSSBtYXkgYmUg dG90YWxseSBtaXNzaW5nIHNvbWUgcG9pbnQgaGVyZSB0aGVuLgo+Cj4+IFdoYXQgInVucGxlYXNh bnQgc3R1ZmYiIGFyZSB5b3UgcmVmZXJyaW5nIHRvLCBleGFjdGx5Pwo+Cj4gSXQncyBub3QgcmVh bGx5IGNsZWFyIGZvciBtZSBob3cgKGFuZCBhdCB3aGVyZSAtIGtlcm5lbCBvciB1c2Vyc3BhY2Up Cj4gd2Ugc2hvdWxkIHByb3Blcmx5IHNvcnQgb3V0IGNhc2VzIHdoZW4gdGhlIG5leHQgZGV2aWNl IHRoZSBwaXBlbGluZQo+IGludHJvZHVjZXMgc29tZSBjb25zdHJhaW50cyBvbiB0aGUgYnVmZmVy IGl0IGNhbiB1c2UuCj4KPiBGb3IgaW5zdGFuY2U6IGNhbWVyYSBjYW4gc2F2ZSBkYXRhIGludG8g YSBub24tY29udGlndW91cyBidWZmZXIsIGJ1dCB0aGUKPiBpbWFnZSBwcm9jZXNzaW5nIGhhcmR3 YXJlICh0aGF0IG1heSBvciBtYXkgbm90IGJlIGludm9sdmVkKSBleHBlY3RzIHRoZQo+IGJ1ZmZl ciB0byBiZSBjb250aWd1b3VzLgo+CgpZb3UndmUganVzdCBoaXQgb24gb25lIG9mIHRoZSBvcGVu IHByb2JsZW1zLiBUaGVyZSBpc24ndCBhIGdvb2QgYW5zd2VyCnJpZ2h0IG5vdyBmb3IgaG93IHRo YXQgaXMgc3VwcG9zZWQgdG8gd29yay4gU3VtaXQgd2FzIHdvcmtpbmcgb24KY2VuYWxsb2MgYXMg YW4gYW5zd2VyIHRvIHNvbWUgb2YgdGhhdC4gSSB0aGluayB3ZSd2ZSBkZWNpZGVkIHRoYXQKbWF5 IGJlY29tZSBtb3JlIG9mIGEgbG9uZyB0ZXJtIHRoZW9yZXRpY2FsIHByb2JsZW0gdG8gc29sdmUg cmF0aGVyCnRoYW4gYSBwcmVzc2luZyBwcmFjdGljYWwgcHJvYmxlbS4gVGhlc2UgZGF5cyBJT01N VXMgYW5kIHRoZSBsaWtlIGFyZQptdWNoIG1vcmUgY29tbW9uIGFjcm9zcyB0aGUgZW50aXJlIHN5 c3RlbSBzbyBpdCdzIGJlY29taW5nIHJhcmVyIHRvCmhhdmUgYSBjYXNlIHdoZXJlIHNvbWUgaGFy ZHdhcmUgY2FuIGhhdmUgZGlzY29udGlndW91cyBidWZmZXJzIGJ1dApzb21lIGNhbm5vdC4gVGhp cyBpc24ndCB0byBzYXkgaXQncyBub3QgYSBwcm9ibGVtIHRoYXQgbmVlZHMgdG8gYmUKc29sdmVk LCBidXQgd2UncmUgZm9jdXNpbmcgb24gb3RoZXIgZWZmb3J0cyBvZiBJb24gcmlnaHQgbm93LgoK SW4gZ2VuZXJhbCB0aG91Z2ggd2UncmUgd29ya2luZyBvZmYgdGhlIGFzc3VtcHRpb24gdGhhdCB0 aGUKa2VybmVsIGtub3dzIHRoZSBjb25zdHJhaW50cyBhbmQgaWYgdXNlcnNwYWNlIGlzIHJlcXVl c3RpbmcgbWVtb3J5IGZyb20KYSBwYXJ0aWN1bGFyIGhlYXAgdGhlIGtlcm5lbCB3aWxsIGFsbG9j YXRlIHRoZSBjb3JyZWN0IG1lbW9yeS4gVGhpcwptZWFucyB0aGF0IGl0J3MgdXAgdG8gdGhlIGtl cm5lbCB0byBzZXQgdXAgdGhlIGhlYXBzIGNvcnJlY3RseSBmb3IKYSBwYXJ0aWN1bGFyIHBsYXRm b3JtIChvbmNlIGFnYWluLCBhbiBvcGVuIHByb2JsZW0pLgoKVGhhbmtzLApMYXVyYQoKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRldmVsIG1haWxpbmcg bGlzdApkZXZlbEBsaW51eGRyaXZlcnByb2plY3Qub3JnCmh0dHA6Ly9kcml2ZXJkZXYubGludXhk cml2ZXJwcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaXZlcmRldi1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757532AbbJVRXU (ORCPT ); Thu, 22 Oct 2015 13:23:20 -0400 Received: from mail-pa0-f48.google.com ([209.85.220.48]:36599 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756191AbbJVRXS (ORCPT ); Thu, 22 Oct 2015 13:23:18 -0400 Subject: Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion To: andrew@ncrmnt.org, Mitchel Humpherys References: <1444164433-9107-1-git-send-email-labbott@fedoraproject.org> <1444164433-9107-2-git-send-email-labbott@fedoraproject.org> <1c6ea0362f5336d9bc8acbfbd7ceae06@mail.ncrmnt.org> <93351858f57ca6e1220a0007f98baa25@cloud.ncrmnt.org> Cc: Rob Herring , Laura Abbott , Rob Herring , Frank Rowand , Sumit Semwal , arve@android.com, Riley Andrews , John Stultz , Grant Likely , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Tom Gall , Colin Cross , devel@driverdev.osuosl.org, Greg Kroah-Hartman , romlem@google.com, linux-arm-kernel@lists.infradead.org, Feng Tang , Marek Szyprowski , a.makarov@module.ru, a.bogdanova@module.ru From: Laura Abbott Message-ID: <56291B83.6060208@labbott.name> Date: Thu, 22 Oct 2015 10:23:15 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <93351858f57ca6e1220a0007f98baa25@cloud.ncrmnt.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/22/15 3:36 AM, andrew@ncrmnt.org wrote: > 20 октября 2015 г., 19:34, "Mitchel Humpherys" написал: >> On Tue, Oct 13 2015 at 11:14:23 AM, Andrew wrote: >> >>> On 2015-10-12 21:39, Mitchel Humpherys wrote: >>>> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring >>>> wrote: >>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott >>>>> wrote: >>>> >>>> [...] >>>> >>>>>> +Example: >>>>>> + >>>>>> + ion { >>>>>> + compatbile = "linux,ion"; >>>>>> + #address-cells = <1>; >>>>>> + #size-cells = <0>; >>>>>> + >>>>>> + ion-system-heap { >>>>>> + linux,ion-heap-id = <0>; >>>>>> + linux,ion-heap-type = ; >>>>>> + linux,ion-heap-name = "system"; >>>>> >>>>> How does this vary across platforms? Is all of this being pushed down >>>>> to DT, because there is no coordination of this at the kernel ABI >>>>> level across platforms. In other words, why can't heap 0 be hardcoded >>>>> as system heap in the driver. It seems to me any 1 of these 3 >>>>> properties could be used to derive the other 2. >>>> >>>> The heap-id<->heap-type mapping isn't necessarily 1:1. As Laura >>>> indicated elsewhere on this thread, a given heap might need to be >>>> contiguous on one platform but not on another. In that case you just >>>> swap out the heap-type here and there's no need for userspace to change. >>>> >>>> The heap-name, OTOH, could be derived from the heap-id, which is what we >>>> hackishly do here [1] and here[2]. >>> >>> By the way, since we agreed that heap id and heap type mappings >>> are not 1:1 - we have a problem with the current API. >>> >>> In userspace we currently have this: >>> >>> int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask, >>> unsigned int flags, ion_user_handle_t *handle); >>> >>> We do not specify here what TYPE of heap we want the allocation to come >>> from. >>> This may lead to very unpleasant stuff when porting from one platfrom to >>> another. > > Okay, I may be totally missing some point here then. > >> What "unpleasant stuff" are you referring to, exactly? > > It's not really clear for me how (and at where - kernel or userspace) > we should properly sort out cases when the next device the pipeline > introduces some constraints on the buffer it can use. > > For instance: camera can save data into a non-contiguous buffer, but the > image processing hardware (that may or may not be involved) expects the > buffer to be contiguous. > You've just hit on one of the open problems. There isn't a good answer right now for how that is supposed to work. Sumit was working on cenalloc as an answer to some of that. I think we've decided that may become more of a long term theoretical problem to solve rather than a pressing practical problem. These days IOMMUs and the like are much more common across the entire system so it's becoming rarer to have a case where some hardware can have discontiguous buffers but some cannot. This isn't to say it's not a problem that needs to be solved, but we're focusing on other efforts of Ion right now. In general though we're working off the assumption that the kernel knows the constraints and if userspace is requesting memory from a particular heap the kernel will allocate the correct memory. This means that it's up to the kernel to set up the heaps correctly for a particular platform (once again, an open problem). Thanks, Laura