| Message ID | 20200501073949.120396-2-john.stultz@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Support non-default CMA regions to the dmabuf heaps interface | expand |
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. 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. Cheers, -Brian > - If a "linux,dma-default" property is present, then Linux will use the > region for the default pool of the consistent DMA allocator. > > -- > 2.17.1 >
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. > 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? thanks -john
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. > > 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
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
On Wed, May 6, 2020 at 9:04 AM Andrew F. Davis <afd@ti.com> wrote: > On 5/4/20 4:50 AM, Brian Starkey wrote: > > On Fri, May 01, 2020 at 11:40:16AM -0700, John Stultz wrote: > >> 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"; > If that's what the device chose to export. > 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. Eh. I don't see this as such an issue. On different systems we have different device nodes. Some boards have more or fewer NICs, or various partitions, etc. There has to be some device specific userland config that determines which partitions are mounted where (this is my "gralloc is fstab" thesis :) I think with the heaps, qualities other than name are going to be poorly specified or unenumerable, so any generic query interface is going to fall down there (and be awful to use). thanks -john
On 5/6/20 12:30 PM, John Stultz wrote: > On Wed, May 6, 2020 at 9:04 AM Andrew F. Davis <afd@ti.com> wrote: >> On 5/4/20 4:50 AM, Brian Starkey wrote: >>> On Fri, May 01, 2020 at 11:40:16AM -0700, John Stultz wrote: >>>> 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"; >> > > If that's what the device chose to export. > Well no "device" exported it, we did mostly automatically using only DT information. When making a DT I don't want to be thinking about how names will break userspace, for instance if node naming guidance is updated do apps suddenly stop working? That worries me a bit. >> 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. > > Eh. I don't see this as such an issue. On different systems we have > different device nodes. Some boards have more or fewer NICs, or > various partitions, etc. There has to be some device specific userland > config that determines which partitions are mounted where (this is my > "gralloc is fstab" thesis :) > Oh I agree here, net interface names and /dev/<hd> names have a history of changing, but those did both break a lot of apps. It could be argued they were abusing the API by making assumptions about the names, but we still have old scripts floating assuming "eth0" is going to just work.. So the sooner we get this fstab scheme in place and in practice, the fewer apps in the wild will hard-code names. > I think with the heaps, qualities other than name are going to be > poorly specified or unenumerable, so any generic query interface is > going to fall down there (and be awful to use). > Sure, so this "fstab" style config will have to be a mapping of names (which we will have to make static per heap in kernel) to properties that interest the current users of a system. For now I can only think of cached/uncached, contiguous/sg, and secure/mappable. Then maybe a list of devices that can consume buffers of that variety, should allow for simple constraint matching. I'll need to think on this a bit more as the use-cases show up.. Andrew > thanks > -john >
On Wed, May 6, 2020 at 10:35 AM Andrew F. Davis <afd@ti.com> wrote: > On 5/6/20 12:30 PM, John Stultz wrote: > > On Wed, May 6, 2020 at 9:04 AM Andrew F. Davis <afd@ti.com> wrote: > >> On 5/4/20 4:50 AM, Brian Starkey wrote: > >>> On Fri, May 01, 2020 at 11:40:16AM -0700, John Stultz wrote: > >>>> 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"; > >> > > > > If that's what the device chose to export. > > > > > Well no "device" exported it, we did mostly automatically using only DT Sorry. By "device" I meant the board/phone/system. > information. When making a DT I don't want to be thinking about how > names will break userspace, for instance if node naming guidance is > updated do apps suddenly stop working? That worries me a bit. So when folks change an existing board/system's DT, that can cause userland breakage. Be it firmware paths, or when folks moved things under an soc{ } node. But at the same time, just like each system has a different partition layout, each system may have different heaps, and its up to a system level config in userland to provide the policy of what is used where. > > Eh. I don't see this as such an issue. On different systems we have > > different device nodes. Some boards have more or fewer NICs, or > > various partitions, etc. There has to be some device specific userland > > config that determines which partitions are mounted where (this is my > > "gralloc is fstab" thesis :) > > > > Oh I agree here, net interface names and /dev/<hd> names have a history > of changing, but those did both break a lot of apps. It could be argued > they were abusing the API by making assumptions about the names, but we > still have old scripts floating assuming "eth0" is going to just work.. > > So the sooner we get this fstab scheme in place and in practice, the > fewer apps in the wild will hard-code names. Gralloc already exists on Android devices, you ask to allocate for a use case, and it picks the heap. It could be *much* simpler (rather than per-device implementations, I'm hoping to get to a single implementation with a fstab like config file), but it's already widely used. > > I think with the heaps, qualities other than name are going to be > > poorly specified or unenumerable, so any generic query interface is > > going to fall down there (and be awful to use). > > Sure, so this "fstab" style config will have to be a mapping of names > (which we will have to make static per heap in kernel) to properties I'm not sure I'm following this static per-heap requirement bit . Can you clarify? > that interest the current users of a system. For now I can only think of > cached/uncached, contiguous/sg, and secure/mappable. Then maybe a list > of devices that can consume buffers of that variety, should allow for > simple constraint matching. I'll need to think on this a bit more as the > use-cases show up.. There's a lot of other cases that are common on Android. One CMA heap might be sized and reserved for camera usage, so it doesn't have to compete with other CMA users to quickly get a bunch of frames. Where as another CMA heap might be specified for a HWFB if that has to be contiguous. Again, it's less about the specific attributes (contiguous/secure/etc - though those are important considerations when creating the mapping for it to work properly), and more of a higher level "for this use case or this pipeline, we use this heap" mapping. Just like an application might store data to /home/ which maps to to a specific partition configured on a specific system, instead of looking for things like "what partition has the most space". thanks -john
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. + - If a "linux,dma-default" property is present, then Linux will use the region for the default pool of the consistent DMA allocator.
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(+)