Messages in this thread | | | Subject | Re: [RFC][PATCH 1/4] devicetree: bindings: Add linux,cma-heap tag for reserved memory | From | "Andrew F. Davis" <> | Date | Wed, 6 May 2020 12:04:12 -0400 |
| |
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@arm.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@kernel.org> >>>> Cc: Sumit Semwal <sumit.semwal@linaro.org> >>>> Cc: "Andrew F. Davis" <afd@ti.com> >>>> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> >>>> Cc: Liam Mark <lmark@codeaurora.org> >>>> Cc: Pratik Patel <pratikp@codeaurora.org> >>>> Cc: Laura Abbott <labbott@redhat.com> >>>> Cc: Brian Starkey <Brian.Starkey@arm.com> >>>> Cc: Chenbo Feng <fengc@google.com> >>>> Cc: Alistair Strachan <astrachan@google.com> >>>> Cc: Sandeep Patil <sspatil@google.com> >>>> Cc: Hridya Valsaraju <hridya@google.com> >>>> Cc: Christoph Hellwig <hch@lst.de> >>>> Cc: Marek Szyprowski <m.szyprowski@samsung.com> >>>> Cc: Robin Murphy <robin.murphy@arm.com> >>>> Cc: Andrew Morton <akpm@linux-foundation.org> >>>> Cc: devicetree@vger.kernel.org >>>> Cc: dri-devel@lists.freedesktop.org >>>> Cc: linux-mm@kvack.org >>>> Signed-off-by: John Stultz <john.stultz@linaro.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@89000000";
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@2f000000/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
| |