[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1bddb721-d4d9-f113-bacc-0a0ca2d57753@ti.com>
Date: Wed, 6 May 2020 12:04:12 -0400
From: "Andrew F. Davis" <afd@...com>
To: Brian Starkey <brian.starkey@....com>,
John Stultz <john.stultz@...aro.org>
CC: lkml <linux-kernel@...r.kernel.org>,
Rob Herring <robh+dt@...nel.org>,
Sumit Semwal <sumit.semwal@...aro.org>,
Benjamin Gaignard <benjamin.gaignard@...aro.org>,
Liam Mark <lmark@...eaurora.org>,
Pratik Patel <pratikp@...eaurora.org>,
Laura Abbott <labbott@...hat.com>,
Chenbo Feng <fengc@...gle.com>,
Alistair Strachan <astrachan@...gle.com>,
Sandeep Patil <sspatil@...gle.com>,
Hridya Valsaraju <hridya@...gle.com>,
Christoph Hellwig <hch@....de>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Robin Murphy <robin.murphy@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
linux-mm <linux-mm@...ck.org>, nd <nd@....com>
Subject: Re: [RFC][PATCH 1/4] devicetree: bindings: Add linux,cma-heap tag for
reserved memory
On 5/4/20 4:50 AM, Brian Starkey wrote:
> On Fri, May 01, 2020 at 11:40:16AM -0700, John Stultz wrote:
>> On Fri, May 1, 2020 at 3:42 AM Brian Starkey <brian.starkey@....com> wrote:
>>>
>>> Hi,
>>>
>>> On Fri, May 01, 2020 at 07:39:46AM +0000, John Stultz wrote:
>>>> This patch adds a linux,cma-heap property for CMA reserved memory
>>>> regions, which will be used to allow the region to be exposed via
>>>> the DMA-BUF Heaps interface
>>>>
>>>> Cc: Rob Herring <robh+dt@...nel.org>
>>>> Cc: Sumit Semwal <sumit.semwal@...aro.org>
>>>> Cc: "Andrew F. Davis" <afd@...com>
>>>> Cc: Benjamin Gaignard <benjamin.gaignard@...aro.org>
>>>> Cc: Liam Mark <lmark@...eaurora.org>
>>>> Cc: Pratik Patel <pratikp@...eaurora.org>
>>>> Cc: Laura Abbott <labbott@...hat.com>
>>>> Cc: Brian Starkey <Brian.Starkey@....com>
>>>> Cc: Chenbo Feng <fengc@...gle.com>
>>>> Cc: Alistair Strachan <astrachan@...gle.com>
>>>> Cc: Sandeep Patil <sspatil@...gle.com>
>>>> Cc: Hridya Valsaraju <hridya@...gle.com>
>>>> Cc: Christoph Hellwig <hch@....de>
>>>> Cc: Marek Szyprowski <m.szyprowski@...sung.com>
>>>> Cc: Robin Murphy <robin.murphy@....com>
>>>> Cc: Andrew Morton <akpm@...ux-foundation.org>
>>>> Cc: devicetree@...r.kernel.org
>>>> Cc: dri-devel@...ts.freedesktop.org
>>>> Cc: linux-mm@...ck.org
>>>> Signed-off-by: John Stultz <john.stultz@...aro.org>
>>>> ---
>>>> .../devicetree/bindings/reserved-memory/reserved-memory.txt | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>>>> index bac4afa3b197..e97b6a4c3bc0 100644
>>>> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>>>> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>>>> @@ -68,6 +68,9 @@ Linux implementation note:
>>>> - If a "linux,cma-default" property is present, then Linux will use the
>>>> region for the default pool of the contiguous memory allocator.
>>>>
>>>> +- If a "linux,cma-heap" property is present, then Linux will expose the
>>>> + the CMA region via the DMA-BUF Heaps interface.
>>>> +
>>>
>>> Would it be useful or even possible to give some indication of what
>>> the heap will end up being called? I'm afraid I don't remember what if
>>> any conclusions came out of previous discussions on UAPI for heap
>>> enumeration.
>>
>> So the name we expose is the CMA name itself. So with dt it will be
>> the name of the reserved memory node that the flag property is added
>> to.
>>
>
> Yeah I'm just wondering if that's "stable" so we can say "the heap
> will use the node name", or if saying that would cause us a headache
> in the future.
The issue is going to be this causes the node name in DT to become a
kind of ABI. Right now until we have some userspace lib that enumerates
the heaps in a stable way programs will hard-code the full heap name,
which right now would look like:
char *heap = "/dev/dma_heap/dma_heap_mem@...00000";
Yuk.. we might want to look into exporting heap properties to make them
searchable based on something other than name here soon. Or this will be
a mess to cleanup in the future.
Andrew
>
>>> I suppose CMA names haven't been relevant to userspace before, but
>>> they perhaps would be with this change.
>>>
>>> Alternatively, leaving it effectively undefined doesn't tie us down,
>>> and something like links in sysfs can be added as a richer API in the
>>> future.
>>
>> Hrm. Mind expanding on what you're thinking here?
>
> Super hand-wavy, something like:
>
> /sys/devices/blah/display@...00000/cma_region is a symlink to
> /sys/class/dma_heaps/heap_display
>
> I think danvet had some thoughts in this vein.
>
> Cheers,
> -Brian
>
>>
>> thanks
>> -john
Powered by blists - more mailing lists