From: mitchelh@codeaurora•org (Mitchel Humpherys)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion
Date: Mon, 12 Oct 2015 11:39:43 -0700 [thread overview]
Message-ID: <vnkwh9lwlymo.fsf@codeaurora.org> (raw)
In-Reply-To: <CAL_JsqJ+i3zC7UJ3BcdtOhdmQd8YnRC7bs3D2Ei5JD-4-C+A0g@mail.gmail.com> (Rob Herring's message of "Tue, 6 Oct 2015 17:35:41 -0500")
On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail•com> wrote:
> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject•org> wrote:
[...]
>> +Example:
>> +
>> + ion {
>> + compatbile = "linux,ion";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + ion-system-heap {
>> + linux,ion-heap-id = <0>;
>> + linux,ion-heap-type = <ION_SYSTEM_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].
[1] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n53
[2] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n398
-Mitch
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-10-12 18:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-06 20:47 [RFC][PATCH 0/2] Devicetree bindings for Ion Laura Abbott
2015-10-06 20:47 ` [RFC][PATCH 1/2] WIP: " Laura Abbott
2015-10-06 22:35 ` Rob Herring
2015-10-06 23:01 ` Laura Abbott
2015-10-07 10:36 ` Andrew
2015-10-07 18:36 ` Rob Herring
2015-10-07 19:23 ` Andrew
2015-10-08 1:43 ` Laura Abbott
2015-10-12 18:39 ` Mitchel Humpherys [this message]
2015-10-13 8:14 ` Andrew
2015-10-20 16:34 ` Mitchel Humpherys
2015-10-22 10:36 ` andrew at ncrmnt.org
2015-10-22 17:23 ` Laura Abbott
2015-10-06 20:47 ` [RFC][PATCH 2/2] staging: ion: Add files for parsing the devicetree (WIP) Laura Abbott
2015-10-06 21:29 ` kbuild test robot
2015-10-06 21:29 ` [RFC PATCH] staging: ion: ion_parse_dt_heap_common() can be static kbuild test robot
2015-10-06 21:30 ` [RFC][PATCH 2/2] staging: ion: Add files for parsing the devicetree (WIP) Andrew
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vnkwh9lwlymo.fsf@codeaurora.org \
--to=mitchelh@codeaurora$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox