From: Laura Abbott <laura@labbott.name>
To: Rob Herring <robh+dt@kernel.org>
Cc: devel@driverdev.osuosl.org,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Andrew Andrianov <andrew@ncrmnt.org>,
Tom Gall <tom.gall@linaro.org>,
Rom Lemarchand <romlem@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
arve@android.com, Colin Cross <ccross@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Riley Andrews <riandrews@android.com>,
John Stultz <john.stultz@linaro.org>,
Feng Tang <feng.tang@intel.com>,
Grant Likely <grant.likely@linaro.org>,
Mark Rutland <mark.rutland@arm.com>,
Frank Rowand <frowand.list@gmail.com>,
Sumit Semwal <sumit.semwal@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [RESEND][PATCHv2 1/3] ion: Devicetree bindings for Ion
Date: Mon, 11 Jan 2016 16:26:28 -0800 [thread overview]
Message-ID: <56944834.4040108@labbott.name> (raw)
In-Reply-To: <CAL_JsqLBk1TAa2bKnA6TpEfrXxVZ7JYojOgmszEKoWC0+Huuug@mail.gmail.com>
On 1/11/16 3:28 PM, Rob Herring wrote:
> On Mon, Jan 11, 2016 at 3:39 PM, Laura Abbott <laura@labbott.name> wrote:
>>
>> This adds a base set of devicetree bindings for the Ion memory
>> manager. This supports setting up the generic set of heaps and
>> their properties.
>>
>> Signed-off-by: Laura Abbott <laura@labbott.name>
>> ---
>> drivers/staging/android/ion/devicetree.txt | 50 ++++++++++++++++++++++++++++++
>> 1 file changed, 50 insertions(+)
>> create mode 100644 drivers/staging/android/ion/devicetree.txt
>>
>> diff --git a/drivers/staging/android/ion/devicetree.txt b/drivers/staging/android/ion/devicetree.txt
>> new file mode 100644
>> index 0000000..e1ea537
>> --- /dev/null
>> +++ b/drivers/staging/android/ion/devicetree.txt
>> @@ -0,0 +1,50 @@
>> +Ion Memory Manager
>> +
>> +Ion is a memory manager that allows for sharing of buffers via dma-buf.
>> +Ion allows for different types of allocation via an abstraction called
>> +a 'heap'. A heap represents a specific type of memory. Each heap has
>> +a different type. There can be multiple instances of the same heap
>> +type.
>> +
>> +Required properties for Ion
>> +
>> +- compatible: "linux,ion" PLUS a compatible property for the device
>> +
>> +All child nodes of a linux,ion node are interpreted as heaps
>> +
>> +required properties for heaps
>> +
>> +- compatible: compatible string for a heap type PLUS a compatible property
>> +for the specific instance of the heap. Current heap types
>> +-- linux,ion-heap-system
>> +-- linux,ion-heap-system-contig
>> +-- linux,ion-heap-carveout
>> +-- linux,ion-heap-chunk
>> +-- linux,ion-heap-dma
>> +-- linux,ion-heap-custom
>> +
>> +Optional properties
>> +- memory-region: A phandle to a memory region. Required for DMA heap type
>> +(see reserved-memory.txt for details on the reservation)
>
> Why would all of them not require a memory region other than system heap?
>
>> +
>> +Example:
>> +
>> + ion {
>> + compatbile = "qcom,msm8916-ion", "linux,ion";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + ion-system-heap {
>> + compatbile = "qcom,system-heap", "linux,ion-heap-system"
>> + };
>
> What is the purpose of this in DT? Don't we always want/need a system
> heap? How does it vary by platform?
>
>> + ion-camera-region {
>> + compatible = "qcom,camera-heap", "linux,ion-heap-dma"
>> + memory-region = <&camera_region>;
>
> Why not just add a property (or properties) to the camera_region node
> that ION drivers can search for?
>
> Rob
>
Thinking about all of this put together with the general comments, would the
following be more acceptable:
- Keep the approach of this patch series with having the heaps specified
in an array in a file
- For each array of heaps, have a list of machine compatible strings that
work with the heaps.
- Call of_machine_is_compatible on all the heaps until one is found
- When setting up the heaps, check for a property like Rob suggested
to get the appropriate memory node
- Add appropriate documentation in the devicetree directory explaining
the entire approach
The only Ion data in the DT with this approach would be the property in the
appropriate memory node. There is no ABI except the memory property so as
Ion changes there would be no breakage. This approach does go a little
bit out outside of the traditional way devicetree works. A more
traditional approach would be to just have an ion node with a compatible
string and then just find the memory node via a property (although this
does taint the DT more with Ion even if the ABI may be relatively stable)
Thanks,
Laura
next prev parent reply other threads:[~2016-01-12 0:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-11 21:39 [RESEND][PATCHv2 0/3] Devicetree bindings for Ion Laura Abbott
2016-01-11 21:39 ` [RESEND][PATCHv2 2/3] staging: ion: Add files for parsing the devicetree Laura Abbott
[not found] ` <1452548364-9522-3-git-send-email-laura-0PSzFVTn/CLa5EbDDlwbIw@public.gmane.org>
2016-01-11 23:24 ` kbuild test robot
[not found] ` <1452548364-9522-1-git-send-email-laura-0PSzFVTn/CLa5EbDDlwbIw@public.gmane.org>
2016-01-11 21:39 ` [RESEND][PATCHv2 1/3] ion: Devicetree bindings for Ion Laura Abbott
2016-01-11 23:28 ` Rob Herring
2016-01-12 0:26 ` Laura Abbott [this message]
2016-01-11 21:39 ` [RESEND][PATCHv2 3/3] NOMERGE: Sample driver Laura Abbott
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=56944834.4040108@labbott.name \
--to=laura@labbott.name \
--cc=andrew@ncrmnt.org \
--cc=arve@android.com \
--cc=ccross@google.com \
--cc=devel@driverdev.osuosl.org \
--cc=devicetree@vger.kernel.org \
--cc=feng.tang@intel.com \
--cc=frowand.list@gmail.com \
--cc=grant.likely@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=john.stultz@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mark.rutland@arm.com \
--cc=riandrews@android.com \
--cc=robh+dt@kernel.org \
--cc=romlem@google.com \
--cc=sumit.semwal@linaro.org \
--cc=tom.gall@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).