Re: [RFC][PATCH 1/4] devicetree: bindings: Add linux, cma-heap tag for reserved memory
On 5/6/20 12:30 PM, John Stultz wrote: > On Wed, May 6, 2020 at 9:04 AM Andrew F. Davis 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@8900"; >> > > 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/ 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 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 wrote: >>> >>> Hi, >>> >>> On Fri, May 01, 2020 at 07:39:46AM +, 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 >>>> Cc: Sumit Semwal >>>> Cc: "Andrew F. Davis" >>>> Cc: Benjamin Gaignard >>>> Cc: Liam Mark >>>> Cc: Pratik Patel >>>> Cc: Laura Abbott >>>> Cc: Brian Starkey >>>> Cc: Chenbo Feng >>>> Cc: Alistair Strachan >>>> Cc: Sandeep Patil >>>> Cc: Hridya Valsaraju >>>> Cc: Christoph Hellwig >>>> Cc: Marek Szyprowski >>>> Cc: Robin Murphy >>>> Cc: Andrew Morton >>>> Cc: devicet...@vger.kernel.org >>>> Cc: dri-devel@lists.freedesktop.org >>>> Cc: linux...@kvack.org >>>> Signed-off-by: John Stultz >>>> --- >>>> .../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@8900"; 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@2f00/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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] misc: sram: Add dma-heap-export reserved SRAM area type
On 4/24/20 8:44 PM, John Stultz wrote:
> On Fri, Apr 24, 2020 at 3:27 PM Andrew F. Davis wrote:
>> This new export type exposes to userspace the SRAM area as a DMA-Heap,
>> this allows for allocations as DMA-BUFs that can be consumed by various
>> DMA-BUF supporting devices.
>>
>> Signed-off-by: Andrew F. Davis
>
> Nice! Very excited to have the first new heap (that didn't come with
> the initial patchset)!
>
> Overall looks good! I don't have any comment on the SRAM side of
> things, but a few minor questions/nits below.
>
>> diff --git a/drivers/misc/sram-dma-heap.c b/drivers/misc/sram-dma-heap.c
>> new file mode 100644
>> index ..38df0397f294
>> --- /dev/null
>> +++ b/drivers/misc/sram-dma-heap.c
>> @@ -0,0 +1,243 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * SRAM DMA-Heap userspace exporter
>> + *
>> + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
>> + * Andrew F. Davis
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "sram.h"
>> +
>> +struct sram_dma_heap {
>> + struct dma_heap *heap;
>> + struct gen_pool *pool;
>> +};
>> +
>> +struct sram_dma_heap_buffer {
>> + struct gen_pool *pool;
>> + struct list_head attachments;
>> + struct mutex attachments_lock;
>> + unsigned long len;
>> + void *vaddr;
>> + phys_addr_t paddr;
>> +};
>> +
>> +struct dma_heap_attachment {
>> + struct device *dev;
>> + struct sg_table *table;
>> + struct list_head list;
>> +};
>> +
>> +static int dma_heap_attach(struct dma_buf *dmabuf,
>> + struct dma_buf_attachment *attachment)
>> +{
>> + struct sram_dma_heap_buffer *buffer = dmabuf->priv;
>> + struct dma_heap_attachment *a;
>> + struct sg_table *table;
>> +
>> + a = kzalloc(sizeof(*a), GFP_KERNEL);
>> + if (!a)
>> + return -ENOMEM;
>> +
>> + table = kmalloc(sizeof(*table), GFP_KERNEL);
>> + if (!table) {
>> + kfree(a);
>> + return -ENOMEM;
>> + }
>> + if (sg_alloc_table(table, 1, GFP_KERNEL)) {
>> + kfree(table);
>> + kfree(a);
>> + return -ENOMEM;
>> + }
>> + sg_set_page(table->sgl, pfn_to_page(PFN_DOWN(buffer->paddr)),
>> buffer->len, 0);
>> +
>> + a->table = table;
>> + a->dev = attachment->dev;
>> + INIT_LIST_HEAD(>list);
>> +
>> + attachment->priv = a;
>> +
>> + mutex_lock(>attachments_lock);
>> + list_add(>list, >attachments);
>> + mutex_unlock(>attachments_lock);
>> +
>> + return 0;
>> +}
>> +
>> +static void dma_heap_detatch(struct dma_buf *dmabuf,
>> +struct dma_buf_attachment *attachment)
>> +{
>> + struct sram_dma_heap_buffer *buffer = dmabuf->priv;
>> + struct dma_heap_attachment *a = attachment->priv;
>> +
>> + mutex_lock(>attachments_lock);
>> + list_del(>list);
>> + mutex_unlock(>attachments_lock);
>> +
>> + sg_free_table(a->table);
>> + kfree(a->table);
>> + kfree(a);
>> +}
>> +
>> +static struct sg_table *dma_heap_map_dma_buf(struct dma_buf_attachment
>> *attachment,
>> +enum dma_data_direction
>> direction)
>> +{
>> + struct dma_heap_attachment *a = attachment->priv;
>> + struct sg_table *table = a->table;
>> +
>> + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
>> + direction, DMA_ATTR_SKIP_CPU_SYNC))
>
> Might be nice to have a comment as to why you're using SKIP_CPU_SYNC
> and why it's safe.
>
Ack, should be simple enough to explain that SRAM is non-cached and so
this sync is not needed (and may not work either given the SRAM region
does not have valid page structures assdociated).
>> + return ERR_PTR(-ENOMEM);
>> +
>> + return table;
>> +}
>> +
>> +static void dma_heap_unmap_dma_buf(struct dma_buf_attachment *attachment,
>> + struct s
Re: [PATCH] misc: sram: Add dma-heap-export reserved SRAM area type
On 4/27/20 11:17 AM, Rob Herring wrote: > On Fri, Apr 24, 2020 at 5:27 PM Andrew F. Davis wrote: >> >> This new export type exposes to userspace the SRAM area as a DMA-Heap, >> this allows for allocations as DMA-BUFs that can be consumed by various >> DMA-BUF supporting devices. >> >> Signed-off-by: Andrew F. Davis >> --- >> .../devicetree/bindings/sram/sram.yaml| 8 + > > Separate patch and needs to go to DT list... > Okay, will split for v2. >> drivers/misc/Kconfig | 7 + >> drivers/misc/Makefile | 1 + >> drivers/misc/sram-dma-heap.c | 243 ++ >> drivers/misc/sram.c | 20 +- >> drivers/misc/sram.h | 17 ++ >> 6 files changed, 292 insertions(+), 4 deletions(-) >> create mode 100644 drivers/misc/sram-dma-heap.c >> >> diff --git a/Documentation/devicetree/bindings/sram/sram.yaml >> b/Documentation/devicetree/bindings/sram/sram.yaml >> index 7b83cc6c9bfa..b8e33c8d205d 100644 >> --- a/Documentation/devicetree/bindings/sram/sram.yaml >> +++ b/Documentation/devicetree/bindings/sram/sram.yaml >> @@ -105,6 +105,14 @@ patternProperties: >>manipulation of the page attributes. >> type: boolean >> >> + dma-heap-export: >> +description: >> + Similar to 'pool' and 'export' this region will be exported for >> use >> + by drivers, devices, and userspace using the DMA-Heaps framework. >> + NOTE: This region must be page aligned on start and end in order >> to >> + properly allow manipulation of the page attributes. >> +type: boolean > > Though I'm not sure this should be in DT. You have to change your > firmware to enable a new kernel feature? We also already have 'export' > which sounds like the same function. Or 'pool' though reading the > description, I don't really understand it's use. > Maybe I could just re-use 'export', right now that property causes the SRAM region to be exported to userspace as a file one can read/write. Exporting via dma-heaps/dma-buf allows more flexibility as one can pass the exported regions to other devices or mmap them directly in userspace. It's up to the SRAM driver maintainer if re-purposing that property in the driver is acceptable. 'Pool' doesn't make much sense to me either, it creates a gen-pool out of the region, but I cant find any users not in combination with the other properties. > What combination of all 3 of these options would be valid? > >From looking at the SRAM driver, it seems each of the option must be used exclusively per region, combining will cause issues. I can update the documentation for the same after we settle on a strategy for this new property. Andrew > Rob > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: heaps: Initialize during core instead of subsys
Some clients of DMA-Heaps probe earlier than subsys_initcall(), this can cause issues when these clients call dma_heap_add() before the core DMA-Heaps framework has initialized. DMA-Heaps should initialize during core startup to get ahead of all users. Signed-off-by: Andrew F. Davis --- drivers/dma-buf/dma-heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index afd22c9dbdcf..af6edfbeddfe 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -295,4 +295,4 @@ static int dma_heap_init(void) return 0; } -subsys_initcall(dma_heap_init); +core_initcall(dma_heap_init); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] misc: sram: Add dma-heap-export reserved SRAM area type
This new export type exposes to userspace the SRAM area as a DMA-Heap,
this allows for allocations as DMA-BUFs that can be consumed by various
DMA-BUF supporting devices.
Signed-off-by: Andrew F. Davis
---
.../devicetree/bindings/sram/sram.yaml| 8 +
drivers/misc/Kconfig | 7 +
drivers/misc/Makefile | 1 +
drivers/misc/sram-dma-heap.c | 243 ++
drivers/misc/sram.c | 20 +-
drivers/misc/sram.h | 17 ++
6 files changed, 292 insertions(+), 4 deletions(-)
create mode 100644 drivers/misc/sram-dma-heap.c
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml
b/Documentation/devicetree/bindings/sram/sram.yaml
index 7b83cc6c9bfa..b8e33c8d205d 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -105,6 +105,14 @@ patternProperties:
manipulation of the page attributes.
type: boolean
+ dma-heap-export:
+description:
+ Similar to 'pool' and 'export' this region will be exported for use
+ by drivers, devices, and userspace using the DMA-Heaps framework.
+ NOTE: This region must be page aligned on start and end in order to
+ properly allow manipulation of the page attributes.
+type: boolean
+
label:
description:
The name for the reserved partition, if omitted, the label is taken
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 99e151475d8f..10a9aed531c4 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -423,6 +423,13 @@ config SRAM
config SRAM_EXEC
bool
+config SRAM_DMA_HEAP
+ bool "Export on-chip SRAM pools using DMA-Heaps"
+ depends on DMABUF_HEAPS && SRAM
+ help
+ This driver allows the export of on-chip SRAM marked as exportable
+ to userspace using the DMA-Heaps interface.
+
config VEXPRESS_SYSCFG
bool "Versatile Express System Configuration driver"
depends on VEXPRESS_CONFIG
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 9abf2923d831..c5b5db26ebb2 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
obj-$(CONFIG_SRAM) += sram.o
obj-$(CONFIG_SRAM_EXEC)+= sram-exec.o
+obj-$(CONFIG_SRAM_DMA_HEAP)+= sram-dma-heap.o
obj-y += mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
diff --git a/drivers/misc/sram-dma-heap.c b/drivers/misc/sram-dma-heap.c
new file mode 100644
index ..38df0397f294
--- /dev/null
+++ b/drivers/misc/sram-dma-heap.c
@@ -0,0 +1,243 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SRAM DMA-Heap userspace exporter
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sram.h"
+
+struct sram_dma_heap {
+ struct dma_heap *heap;
+ struct gen_pool *pool;
+};
+
+struct sram_dma_heap_buffer {
+ struct gen_pool *pool;
+ struct list_head attachments;
+ struct mutex attachments_lock;
+ unsigned long len;
+ void *vaddr;
+ phys_addr_t paddr;
+};
+
+struct dma_heap_attachment {
+ struct device *dev;
+ struct sg_table *table;
+ struct list_head list;
+};
+
+static int dma_heap_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct sram_dma_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a;
+ struct sg_table *table;
+
+ a = kzalloc(sizeof(*a), GFP_KERNEL);
+ if (!a)
+ return -ENOMEM;
+
+ table = kmalloc(sizeof(*table), GFP_KERNEL);
+ if (!table) {
+ kfree(a);
+ return -ENOMEM;
+ }
+ if (sg_alloc_table(table, 1, GFP_KERNEL)) {
+ kfree(table);
+ kfree(a);
+ return -ENOMEM;
+ }
+ sg_set_page(table->sgl, pfn_to_page(PFN_DOWN(buffer->paddr)),
buffer->len, 0);
+
+ a->table = table;
+ a->dev = attachment->dev;
+ INIT_LIST_HEAD(>list);
+
+ attachment->priv = a;
+
+ mutex_lock(>attachments_lock);
+ list_add(>list, >attachments);
+ mutex_unlock(>attachments_lock);
+
+ return 0;
+}
+
+static void dma_heap_detatch(struct dma_buf *dmabuf,
+struct dma_buf_attachment *attachment)
+{
+ struct sram_dma_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a = attachment->priv;
+
+ mutex_lock(>attachments_lock);
+
Re: [PATCH v4 4/8] ARM: DTS: omap3: add sgx gpu child node
On 12/17/19 1:02 PM, H. Nikolaus Schaller wrote:
> and add interrupt
>
> Tested-by: H. Nikolaus Schaller # OpenPandora 600 MHz.
> Signed-off-by: H. Nikolaus Schaller
> ---
> arch/arm/boot/dts/omap34xx.dtsi | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
> index c4dd9801840d..a858a2e8002d 100644
> --- a/arch/arm/boot/dts/omap34xx.dtsi
> +++ b/arch/arm/boot/dts/omap34xx.dtsi
> @@ -159,7 +159,7 @@
>* are also different clocks, but we do not have any dts users
>* for it.
>*/
> - sgx_module: target-module@5000 {
> + target-module@5000 {
> compatible = "ti,sysc-omap2", "ti,sysc";
> reg = <0x5014 0x4>;
> reg-names = "rev";
> @@ -169,10 +169,11 @@
> #size-cells = <1>;
> ranges = <0 0x5000 0x4000>;
>
> - /*
> - * Closed source PowerVR driver, no child device
> - * binding or driver in mainline
> - */
> + sgx: gpu@0 {
> + compatible = "ti,omap3-sgx530-121",
> "img,sgx530-121", "img,sgx530";
> + reg = <0x0 0x4000>; /* 64kB */
Just for future reference, this range should be 0x1.
Andrew
> + interrupts = <21>;
> + };
> };
> };
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: Move radeon and amdgpu Kconfig options into their directories
Most Kconfig options to enable a driver are in the Kconfig file inside the relevant directory, move these two to the same. Signed-off-by: Andrew F. Davis --- Changes from v1: - Rebased drivers/gpu/drm/Kconfig| 34 -- drivers/gpu/drm/amd/amdgpu/Kconfig | 18 drivers/gpu/drm/radeon/Kconfig | 18 3 files changed, 36 insertions(+), 34 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index bfdadc3667e0..714ae842b7ce 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -231,42 +231,8 @@ source "drivers/gpu/drm/i2c/Kconfig" source "drivers/gpu/drm/arm/Kconfig" -config DRM_RADEON - tristate "ATI Radeon" - depends on DRM && PCI && MMU - select FW_LOADER -select DRM_KMS_HELPER -select DRM_TTM - select POWER_SUPPLY - select HWMON - select BACKLIGHT_CLASS_DEVICE - select INTERVAL_TREE - help - Choose this option if you have an ATI Radeon graphics card. There - are both PCI and AGP versions. You don't need to choose this to - run the Radeon in plain VGA mode. - - If M is selected, the module will be called radeon. - source "drivers/gpu/drm/radeon/Kconfig" -config DRM_AMDGPU - tristate "AMD GPU" - depends on DRM && PCI && MMU - select FW_LOADER - select DRM_KMS_HELPER - select DRM_SCHED - select DRM_TTM - select POWER_SUPPLY - select HWMON - select BACKLIGHT_CLASS_DEVICE - select INTERVAL_TREE - select CHASH - help - Choose this option if you have a recent AMD Radeon graphics card. - - If M is selected, the module will be called amdgpu. - source "drivers/gpu/drm/amd/amdgpu/Kconfig" source "drivers/gpu/drm/nouveau/Kconfig" diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig b/drivers/gpu/drm/amd/amdgpu/Kconfig index 9375e7f12420..f6100cb193fb 100644 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig @@ -1,4 +1,22 @@ # SPDX-License-Identifier: MIT + +config DRM_AMDGPU + tristate "AMD GPU" + depends on DRM && PCI && MMU + select FW_LOADER + select DRM_KMS_HELPER + select DRM_SCHED + select DRM_TTM + select POWER_SUPPLY + select HWMON + select BACKLIGHT_CLASS_DEVICE + select INTERVAL_TREE + select CHASH + help + Choose this option if you have a recent AMD Radeon graphics card. + + If M is selected, the module will be called amdgpu. + config DRM_AMDGPU_SI bool "Enable amdgpu support for SI parts" depends on DRM_AMDGPU diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig index 6f60f4840cc5..ba67b879d31d 100644 --- a/drivers/gpu/drm/radeon/Kconfig +++ b/drivers/gpu/drm/radeon/Kconfig @@ -1,4 +1,22 @@ # SPDX-License-Identifier: GPL-2.0-only + +config DRM_RADEON + tristate "ATI Radeon" + depends on DRM && PCI && MMU + select FW_LOADER + select DRM_KMS_HELPER + select DRM_TTM + select POWER_SUPPLY + select HWMON + select BACKLIGHT_CLASS_DEVICE + select INTERVAL_TREE + help + Choose this option if you have an ATI Radeon graphics card. There + are both PCI and AGP versions. You don't need to choose this to + run the Radeon in plain VGA mode. + + If M is selected, the module will be called radeon. + config DRM_RADEON_USERPTR bool "Always enable userptr support" depends on DRM_RADEON -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] Naming changes for DMA-BUF Heaps in drm-misc-next
Hello all, This is a quick series to cleanup some minor naming issues in the new DMA-BUF Heaps series on next before the names become ABI. Thanks, Andrew Andrew F. Davis (2): dma-buf: heaps: Use _IOCTL_ for userspace IOCTL identifier dma-buf: heaps: Remove redundant heap identifier from system heap name drivers/dma-buf/dma-heap.c | 4 ++-- drivers/dma-buf/heaps/system_heap.c| 2 +- include/uapi/linux/dma-heap.h | 4 ++-- tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dma-buf: heaps: Use _IOCTL_ for userspace IOCTL identifier
This is more consistent with the DMA and DRM frameworks convention. This
patch is only a name change, no logic is changed.
Signed-off-by: Andrew F. Davis
---
drivers/dma-buf/dma-heap.c | 4 ++--
include/uapi/linux/dma-heap.h | 4 ++--
tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 4f04d104ae61..a24721496114 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -107,7 +107,7 @@ static long dma_heap_ioctl_allocate(struct file *file, void
*data)
}
unsigned int dma_heap_ioctl_cmds[] = {
- DMA_HEAP_IOC_ALLOC,
+ DMA_HEAP_IOCTL_ALLOC,
};
static long dma_heap_ioctl(struct file *file, unsigned int ucmd,
@@ -153,7 +153,7 @@ static long dma_heap_ioctl(struct file *file, unsigned int
ucmd,
memset(kdata + in_size, 0, ksize - in_size);
switch (kcmd) {
- case DMA_HEAP_IOC_ALLOC:
+ case DMA_HEAP_IOCTL_ALLOC:
ret = dma_heap_ioctl_allocate(file, kdata);
break;
default:
diff --git a/include/uapi/linux/dma-heap.h b/include/uapi/linux/dma-heap.h
index 73e7f66c1cae..6f84fa08e074 100644
--- a/include/uapi/linux/dma-heap.h
+++ b/include/uapi/linux/dma-heap.h
@@ -42,12 +42,12 @@ struct dma_heap_allocation_data {
#define DMA_HEAP_IOC_MAGIC 'H'
/**
- * DOC: DMA_HEAP_IOC_ALLOC - allocate memory from pool
+ * DOC: DMA_HEAP_IOCTL_ALLOC - allocate memory from pool
*
* Takes a dma_heap_allocation_data struct and returns it with the fd field
* populated with the dmabuf handle of the allocation.
*/
-#define DMA_HEAP_IOC_ALLOC _IOWR(DMA_HEAP_IOC_MAGIC, 0x0,\
+#define DMA_HEAP_IOCTL_ALLOC _IOWR(DMA_HEAP_IOC_MAGIC, 0x0,\
struct dma_heap_allocation_data)
#endif /* _UAPI_LINUX_DMABUF_POOL_H */
diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
index 3e53ad331bdc..cd5e1f602ac9 100644
--- a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
+++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
@@ -116,7 +116,7 @@ static int dmabuf_heap_alloc_fdflags(int fd, size_t len,
unsigned int fd_flags,
if (!dmabuf_fd)
return -EINVAL;
- ret = ioctl(fd, DMA_HEAP_IOC_ALLOC, );
+ ret = ioctl(fd, DMA_HEAP_IOCTL_ALLOC, );
if (ret < 0)
return ret;
*dmabuf_fd = (int)data.fd;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] dma-buf: heaps: Remove redundant heap identifier from system heap name
The heaps are already in a directory of heaps, adding _heap to a heap name is redundant. This patch is only a name change, no logic is changed. Signed-off-by: Andrew F. Davis --- drivers/dma-buf/heaps/system_heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 1aa01e98c595..0bf688e3c023 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -109,7 +109,7 @@ static int system_heap_create(void) struct dma_heap_export_info exp_info; int ret = 0; - exp_info.name = "system_heap"; + exp_info.name = "system"; exp_info.ops = _heap_ops; exp_info.priv = NULL; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v16 1/5] dma-buf: Add dma-buf heaps framework
On 12/3/19 12:26 PM, John Stultz wrote: > From: "Andrew F. Davis" > > This framework allows a unified userspace interface for dma-buf > exporters, allowing userland to allocate specific types of memory > for use in dma-buf sharing. > > Each heap is given its own device node, which a user can allocate > a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. > > This code is an evoluiton of the Android ION implementation, > and a big thanks is due to its authors/maintainers over time > for their effort: > Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard, > Laura Abbott, and many other contributors! > > Cc: Laura Abbott > Cc: Benjamin Gaignard > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Pratik Patel > Cc: Brian Starkey > Cc: Vincent Donnefort > Cc: Sudipto Paul > Cc: Andrew F. Davis > Cc: Christoph Hellwig > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: Hridya Valsaraju > Cc: Sandeep Patil > Cc: Hillf Danton > Cc: Dave Airlie > Cc: dri-devel@lists.freedesktop.org > Reviewed-by: Brian Starkey > Acked-by: Sandeep Patil > Signed-off-by: Andrew F. Davis > Signed-off-by: John Stultz > --- > v2: > * Folded down fixes I had previously shared in implementing > heaps > * Make flags a u64 (Suggested by Laura) > * Add PAGE_ALIGN() fix to the core alloc funciton > * IOCTL fixups suggested by Brian > * Added fixes suggested by Benjamin > * Removed core stats mgmt, as that should be implemented by > per-heap code > * Changed alloc to return a dma-buf fd, rather than a buffer > (as it simplifies error handling) > v3: > * Removed scare-quotes in MAINTAINERS email address > * Get rid of .release function as it didn't do anything (from > Christoph) > * Renamed filp to file (suggested by Christoph) > * Split out ioctl handling to separate function (suggested by > Christoph) > * Add comment documenting PAGE_ALIGN usage (suggested by Brian) > * Switch from idr to Xarray (suggested by Brian) > * Fixup cdev creation (suggested by Brian) > * Avoid EXPORT_SYMBOL until we finalize modules (suggested by > Brian) > * Make struct dma_heap internal only (folded in from Andrew) > * Small cleanups suggested by GregKH > * Provide class->devnode callback to get consistent /dev/ > subdirectory naming (Suggested by Bjorn) > v4: > * Folded down dma-heap.h change that was in a following patch > * Added fd_flags entry to allocation structure and pass it > through to heap code for use on dma-buf fd creation (suggested > by Benjamin) > v5: > * Minor cleanups > v6: > * Improved error path handling, minor whitespace fixes, both > suggested by Brian > v7: > * Longer Kconfig description to quiet checkpatch warnings > * Re-add compat_ioctl bits (Hridya noticed 32bit userland wasn't > working) > v8: > * Make struct dma_heap_ops consts (Suggested by Christoph) > * Checkpatch whitespace fixups > v9: > * Minor cleanups suggested by Brian Starkey > * Rename dma_heap_get_data->dma_heap_get_drvdata suggested > by Hilf Danton > v11: > * Kconfig text improvements suggested by Randy Dunlap > v12: > * Add logic to prevent duplicately named heaps being added > * Add symbol exports for heaps as modules > v13: > * Re-remove symbol exports per discussion w/ Brian. Will > resubmit in a separte patch for review > v14: > * Reworked ioctl handler to zero fill any difference in > structure size, similar to what the DRM core does, as > suggested by Dave Airlie > * Removed now unnecessary reserved bits in allocate_data > * Added get_features ioctl as suggested by Dave Airlie > * Removed pr_warn_once messages as requested by Dave > Airlie > v15: > * Dropped the get_features ioctl as suggested by Brian > Starkey and Daniel Vetter > * Add listhead comment suggested by Sandeep Patil > * Dropped minor value in struct dma_heap as suggested by > Sandeep Patil > * Fix grammar typo from Brian Starkey > v16: > * Typo fix suggested by Hridya Valsaraju > --- > MAINTAINERS | 18 +++ > drivers/dma-buf/Kconfig | 9 ++ > drivers/dma-buf/Makefile | 1 + > drivers/dma-buf/dma-heap.c| 297 ++ > include/linux/dma-heap.h | 59 +++ > include/uapi/linux/dma-heap.h | 53 ++ > 6 files changed, 437 insertions(+) > create mode 100644 drivers/dma-buf/dma-heap.c > create mode 100644 include/linux/dma-heap.h > create mode 100644 include/uapi/linux/dma-heap.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8608724835dd..44b7cbc0ec29 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4971,6 +4971,24 @@ F: include/linux/*fence.h > F: Documentation/d
Re: [RESEND][PATCH v16 3/5] dma-buf: heaps: Add system heap to dmabuf heaps
On 12/3/19 12:26 PM, John Stultz wrote: > This patch adds system heap to the dma-buf heaps framework. > > This allows applications to get a page-allocator backed dma-buf > for non-contiguous memory. > > This code is an evolution of the Android ION implementation, so > thanks to its original authors and maintainters: > Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others! > > Cc: Laura Abbott > Cc: Benjamin Gaignard > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Pratik Patel > Cc: Brian Starkey > Cc: Vincent Donnefort > Cc: Sudipto Paul > Cc: Andrew F. Davis > Cc: Christoph Hellwig > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: Hridya Valsaraju > Cc: Sandeep Patil > Cc: Hillf Danton > Cc: Dave Airlie > Cc: dri-devel@lists.freedesktop.org > Reviewed-by: Benjamin Gaignard > Reviewed-by: Brian Starkey > Acked-by: Sandeep Patil > Acked-by: Laura Abbott > Tested-by: Ayan Kumar Halder > Signed-off-by: John Stultz > --- > v2: > * Switch allocate to return dmabuf fd > * Simplify init code > * Checkpatch fixups > * Droped dead system-contig code > v3: > * Whitespace fixups from Benjamin > * Make sure we're zeroing the allocated pages (from Liam) > * Use PAGE_ALIGN() consistently (suggested by Brian) > * Fold in new registration style from Andrew > * Avoid needless dynamic allocation of sys_heap (suggested by > Christoph) > * Minor cleanups > * Folded in changes from Andrew to use simplified page list > from the heap helpers > v4: > * Optimization to allocate pages in chunks, similar to old > pagepool code > * Use fd_flags when creating dmabuf fd (Suggested by Benjamin) > v5: > * Back out large order page allocations (was leaking memory, > as the page array didn't properly track order size) > v6: > * Minor whitespace change suggested by Brian > * Remove unused variable > v7: > * Use newly lower-cased init_heap_helper_buffer helper > * Add system heap DOS avoidance suggested by Laura from ION code > * Use new dmabuf export helper > v8: > * Make struct dma_heap_ops consts (suggested by Christoph) > * Get rid of needless struct system_heap (suggested by Christoph) > * Condense dma_heap_buffer and heap_helper_buffer (suggested by > Christoph) > * Add forgotten include file to fix build issue on x86 > v12: > * Minor tweaks to prep loading heap from module > v14: > * Fix "redundant assignment to variable ret" issue reported > by Colin King and fixed by Andrew Davis > v15: > * Drop unused heap flag from heap_helper_buffer as suggested > by Sandeep Patil > --- > drivers/dma-buf/Kconfig | 2 + > drivers/dma-buf/heaps/Kconfig | 6 ++ > drivers/dma-buf/heaps/Makefile | 1 + > drivers/dma-buf/heaps/system_heap.c | 123 > 4 files changed, 132 insertions(+) > create mode 100644 drivers/dma-buf/heaps/Kconfig > create mode 100644 drivers/dma-buf/heaps/system_heap.c > > diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig > index bffa58fc3e6e..0613bb7770f5 100644 > --- a/drivers/dma-buf/Kconfig > +++ b/drivers/dma-buf/Kconfig > @@ -53,4 +53,6 @@ menuconfig DMABUF_HEAPS > allows userspace to allocate dma-bufs that can be shared > between drivers. > > +source "drivers/dma-buf/heaps/Kconfig" > + > endmenu > diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig > new file mode 100644 > index ..205052744169 > --- /dev/null > +++ b/drivers/dma-buf/heaps/Kconfig > @@ -0,0 +1,6 @@ > +config DMABUF_HEAPS_SYSTEM > + bool "DMA-BUF System Heap" > + depends on DMABUF_HEAPS > + help > + Choose this option to enable the system dmabuf heap. The system heap > + is backed by pages from the buddy allocator. If in doubt, say Y. > diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile > index de49898112db..d1808eca2581 100644 > --- a/drivers/dma-buf/heaps/Makefile > +++ b/drivers/dma-buf/heaps/Makefile > @@ -1,2 +1,3 @@ > # SPDX-License-Identifier: GPL-2.0 > obj-y+= heap-helpers.o > +obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o > diff --git a/drivers/dma-buf/heaps/system_heap.c > b/drivers/dma-buf/heaps/system_heap.c > new file mode 100644 > index ..1aa01e98c595 > --- /dev/null > +++ b/drivers/dma-buf/heaps/system_heap.c > @@ -0,0 +1,123 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * DMABUF System heap exporter > + * > + * Copyright (C) 2011 Google, Inc. > + * Copyright (C) 2019 Linaro Ltd. > + */ > + > +#include > +#include > +#include > +#in
Re: [PATCH v16 0/5] DMA-BUF Heaps (destaging ION)
On 11/18/19 3:23 PM, John Stultz wrote: > Just wanted to resend v16 with a few minor changes. > > This patchset implements per-heap devices which can be opened > directly and then an ioctl is used to allocate a dmabuf from the > heap. > > The interface is similar, but much simpler then IONs, only > providing an ALLOC ioctl. > > Also, I've provided relatively simple system and cma heaps. > > I've booted and tested these patches with AOSP on the HiKey960 > using the kernel tree here: > > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap > > And the reviewed (+2'ed) userspace changes here: > https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 > > Compared to ION, this patchset is missing the system-contig, > carveout and chunk heaps, as I don't have a device that uses ION's Carveout and Chunk heaps got dropped from upstream, so no gap there. :) Andrew > those, so I'm unable to do much useful validation there. > Additionally we have no upstream users of chunk or carveout, > and the system-contig has been deprecated in the common/andoid-* > kernels, so this should be ok. > > I've also removed the stats accounting, since any such > accounting should be implemented by dma-buf core or the heaps > themselves. > > New in v16: > * Typo fix suggested by Hridya Valsaraju > * Add extra error and ioctl compatibility testing suggested by > Daniel Vetter to the kselftest test > > Thanks again for all the reviews and feedback! > -john > > Cc: Laura Abbott > Cc: Benjamin Gaignard > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Pratik Patel > Cc: Brian Starkey > Cc: Vincent Donnefort > Cc: Sudipto Paul > Cc: Andrew F. Davis > Cc: Christoph Hellwig > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: Hridya Valsaraju > Cc: Sandeep Patil > Cc: Hillf Danton > Cc: Dave Airlie > Cc: dri-devel@lists.freedesktop.org > > Andrew F. Davis (1): > dma-buf: Add dma-buf heaps framework > > John Stultz (4): > dma-buf: heaps: Add heap helpers > dma-buf: heaps: Add system heap to dmabuf heaps > dma-buf: heaps: Add CMA heap to dmabuf heaps > kselftests: Add dma-heap test > > MAINTAINERS | 18 + > drivers/dma-buf/Kconfig | 11 + > drivers/dma-buf/Makefile | 2 + > drivers/dma-buf/dma-heap.c| 297 + > drivers/dma-buf/heaps/Kconfig | 14 + > drivers/dma-buf/heaps/Makefile| 4 + > drivers/dma-buf/heaps/cma_heap.c | 177 > drivers/dma-buf/heaps/heap-helpers.c | 271 > drivers/dma-buf/heaps/heap-helpers.h | 53 +++ > drivers/dma-buf/heaps/system_heap.c | 123 ++ > include/linux/dma-heap.h | 59 +++ > include/uapi/linux/dma-heap.h | 53 +++ > tools/testing/selftests/dmabuf-heaps/Makefile | 6 + > .../selftests/dmabuf-heaps/dmabuf-heap.c | 396 ++ > 14 files changed, 1484 insertions(+) > create mode 100644 drivers/dma-buf/dma-heap.c > create mode 100644 drivers/dma-buf/heaps/Kconfig > create mode 100644 drivers/dma-buf/heaps/Makefile > create mode 100644 drivers/dma-buf/heaps/cma_heap.c > create mode 100644 drivers/dma-buf/heaps/heap-helpers.c > create mode 100644 drivers/dma-buf/heaps/heap-helpers.h > create mode 100644 drivers/dma-buf/heaps/system_heap.c > create mode 100644 include/linux/dma-heap.h > create mode 100644 include/uapi/linux/dma-heap.h > create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile > create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 1/5] dma-buf: Add dma-buf heaps framework
On 11/6/19 12:18 PM, Andrew F. Davis wrote:
> On 11/6/19 12:03 PM, John Stultz wrote:
>> On Wed, Nov 6, 2019 at 5:52 AM Andrew F. Davis wrote:
>>>
>>> On 11/5/19 11:22 PM, John Stultz wrote:
>>>> +unsigned int dma_heap_ioctl_cmds[] = {
>>>> + DMA_HEAP_IOC_ALLOC,
>>>> +};
>>>> +
>>>> +static long dma_heap_ioctl(struct file *file, unsigned int ucmd,
>>>> +unsigned long arg)
>>>> +{
>>>> + char stack_kdata[128];
>>>> + char *kdata = stack_kdata;
>>>> + unsigned int kcmd;
>>>> + unsigned int in_size, out_size, drv_size, ksize;
>>>> + int nr = _IOC_NR(ucmd);
>>>> + int ret = 0;
>>>> +
>>>> + if (nr >= ARRAY_SIZE(dma_heap_ioctl_cmds))
>>>> + return -EINVAL;
>>>> +
>>>> + /* Get the kernel ioctl cmd that matches */
>>>> + kcmd = dma_heap_ioctl_cmds[nr];
>>>
>>>
>>> Why do we need this indirection here and all the complexity below? I
>>> know DRM ioctl does something like this but it has a massive table,
>>> legacy ioctls, driver defined ioctls, etc..
>>>
>>> I don't expect we will ever need complex handling like this, could we
>>> switch back to the more simple handler from v13?
>>
>> I agree it does add complexity, but I'm not sure I see how to avoid
>> some of this. The logic trying to handle that the user may pass a cmd
>> that has the same _IOC_NR() as DMA_HEAP_IOC_ALLOC but not the same
>> size. So the simple "switch(cmd) { case DMA_HEAP_IOC_ALLOC:" we had
>> before won't work (as the cmd will be a different value).
>>
>
>
> DMA_HEAP_IOC_ALLOC encodes everything we need, if the size is different
> then the switch case will not match. It handled everything we have.
>
>
>> Thus why I thought the cleanest approach would be to use the
>> dma_heap_ioctl_cmds array to convert from whatever the user cmd is to
>> the matching kernel cmd value.
>>
>
>
> There are no kernel or user commands, just commands, they will match or
> they are not valid. If someday we some need a variable sized ioctl then
> we can deal with that then.
>
Had a little discussion about this on IRC #dri-devel (check logs for
today if you want to follow along). Conclusion being the way it is done
here should be fine to help support forward compatibility. If optional
extensions to the structure are made that grow the size of data passed
in then we can ignore that and zero out the returned data without harm.
It is up to the flags field to mark incompatible changes that should
error out from kernel.
Andrew
> Andrew
>
>
>> Do you have an alternative suggestion that I'm overlooking?
>>
>> thanks
>> -john
>>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 1/5] dma-buf: Add dma-buf heaps framework
On 11/6/19 12:03 PM, John Stultz wrote:
> On Wed, Nov 6, 2019 at 5:52 AM Andrew F. Davis wrote:
>>
>> On 11/5/19 11:22 PM, John Stultz wrote:
>>> +unsigned int dma_heap_ioctl_cmds[] = {
>>> + DMA_HEAP_IOC_ALLOC,
>>> +};
>>> +
>>> +static long dma_heap_ioctl(struct file *file, unsigned int ucmd,
>>> +unsigned long arg)
>>> +{
>>> + char stack_kdata[128];
>>> + char *kdata = stack_kdata;
>>> + unsigned int kcmd;
>>> + unsigned int in_size, out_size, drv_size, ksize;
>>> + int nr = _IOC_NR(ucmd);
>>> + int ret = 0;
>>> +
>>> + if (nr >= ARRAY_SIZE(dma_heap_ioctl_cmds))
>>> + return -EINVAL;
>>> +
>>> + /* Get the kernel ioctl cmd that matches */
>>> + kcmd = dma_heap_ioctl_cmds[nr];
>>
>>
>> Why do we need this indirection here and all the complexity below? I
>> know DRM ioctl does something like this but it has a massive table,
>> legacy ioctls, driver defined ioctls, etc..
>>
>> I don't expect we will ever need complex handling like this, could we
>> switch back to the more simple handler from v13?
>
> I agree it does add complexity, but I'm not sure I see how to avoid
> some of this. The logic trying to handle that the user may pass a cmd
> that has the same _IOC_NR() as DMA_HEAP_IOC_ALLOC but not the same
> size. So the simple "switch(cmd) { case DMA_HEAP_IOC_ALLOC:" we had
> before won't work (as the cmd will be a different value).
>
DMA_HEAP_IOC_ALLOC encodes everything we need, if the size is different
then the switch case will not match. It handled everything we have.
> Thus why I thought the cleanest approach would be to use the
> dma_heap_ioctl_cmds array to convert from whatever the user cmd is to
> the matching kernel cmd value.
>
There are no kernel or user commands, just commands, they will match or
they are not valid. If someday we some need a variable sized ioctl then
we can deal with that then.
Andrew
> Do you have an alternative suggestion that I'm overlooking?
>
> thanks
> -john
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 1/5] dma-buf: Add dma-buf heaps framework
On 11/5/19 11:22 PM, John Stultz wrote: > From: "Andrew F. Davis" > > This framework allows a unified userspace interface for dma-buf > exporters, allowing userland to allocate specific types of memory > for use in dma-buf sharing. > > Each heap is given its own device node, which a user can allocate > a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. > > This code is an evoluiton of the Android ION implementation, > and a big thanks is due to its authors/maintainers over time > for their effort: > Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard, > Laura Abbott, and many other contributors! > > Cc: Laura Abbott > Cc: Benjamin Gaignard > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Pratik Patel > Cc: Brian Starkey > Cc: Vincent Donnefort > Cc: Sudipto Paul > Cc: Andrew F. Davis > Cc: Christoph Hellwig > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: Hridya Valsaraju > Cc: Sandeep Patil > Cc: Hillf Danton > Cc: Dave Airlie > Cc: dri-devel@lists.freedesktop.org > Reviewed-by: Brian Starkey > Acked-by: Sandeep Patil > Signed-off-by: Andrew F. Davis > Signed-off-by: John Stultz > --- > v2: > * Folded down fixes I had previously shared in implementing > heaps > * Make flags a u64 (Suggested by Laura) > * Add PAGE_ALIGN() fix to the core alloc funciton > * IOCTL fixups suggested by Brian > * Added fixes suggested by Benjamin > * Removed core stats mgmt, as that should be implemented by > per-heap code > * Changed alloc to return a dma-buf fd, rather than a buffer > (as it simplifies error handling) > v3: > * Removed scare-quotes in MAINTAINERS email address > * Get rid of .release function as it didn't do anything (from > Christoph) > * Renamed filp to file (suggested by Christoph) > * Split out ioctl handling to separate function (suggested by > Christoph) > * Add comment documenting PAGE_ALIGN usage (suggested by Brian) > * Switch from idr to Xarray (suggested by Brian) > * Fixup cdev creation (suggested by Brian) > * Avoid EXPORT_SYMBOL until we finalize modules (suggested by > Brian) > * Make struct dma_heap internal only (folded in from Andrew) > * Small cleanups suggested by GregKH > * Provide class->devnode callback to get consistent /dev/ > subdirectory naming (Suggested by Bjorn) > v4: > * Folded down dma-heap.h change that was in a following patch > * Added fd_flags entry to allocation structure and pass it > through to heap code for use on dma-buf fd creation (suggested > by Benjamin) > v5: > * Minor cleanups > v6: > * Improved error path handling, minor whitespace fixes, both > suggested by Brian > v7: > * Longer Kconfig description to quiet checkpatch warnings > * Re-add compat_ioctl bits (Hridya noticed 32bit userland wasn't > working) > v8: > * Make struct dma_heap_ops consts (Suggested by Christoph) > * Checkpatch whitespace fixups > v9: > * Minor cleanups suggested by Brian Starkey > * Rename dma_heap_get_data->dma_heap_get_drvdata suggested > by Hilf Danton > v11: > * Kconfig text improvements suggested by Randy Dunlap > v12: > * Add logic to prevent duplicately named heaps being added > * Add symbol exports for heaps as modules > v13: > * Re-remove symbol exports per discussion w/ Brian. Will > resubmit in a separte patch for review > v14: > * Reworked ioctl handler to zero fill any difference in > structure size, similar to what the DRM core does, as > suggested by Dave Airlie > * Removed now unnecessary reserved bits in allocate_data > * Added get_features ioctl as suggested by Dave Airlie > * Removed pr_warn_once messages as requested by Dave > Airlie > v15: > * Dropped the get_features ioctl as suggested by Brian > Starkey and Daniel Vetter > * Add listhead comment suggested by Sandeep Patil > * Dropped minor value in struct dma_heap as suggested by > Sandeep Patil > * Fix grammar typo from Brian Starkey > --- > MAINTAINERS | 18 +++ > drivers/dma-buf/Kconfig | 9 ++ > drivers/dma-buf/Makefile | 1 + > drivers/dma-buf/dma-heap.c| 297 ++ > include/linux/dma-heap.h | 59 +++ > include/uapi/linux/dma-heap.h | 53 ++ > 6 files changed, 437 insertions(+) > create mode 100644 drivers/dma-buf/dma-heap.c > create mode 100644 include/linux/dma-heap.h > create mode 100644 include/uapi/linux/dma-heap.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index cba1095547fd..568f94172905 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4940,6 +4940,24 @@ F: include/linux/*fence.h > F: Documentation/driver-api/dma-buf.rst > T: git git://anongit.freedesk
Re: [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules
On 11/5/19 4:42 AM, Daniel Vetter wrote: > On Mon, Nov 04, 2019 at 10:57:44AM -0800, John Stultz wrote: >> On Mon, Nov 4, 2019 at 1:58 AM Daniel Vetter wrote: >>> On Fri, Oct 25, 2019 at 11:48:32PM +, John Stultz wrote: Now that the DMA BUF heaps core code has been queued, I wanted to send out some of the pending changes that I've been working on. For use with Android and their GKI effort, it is desired that DMA BUF heaps are able to be loaded as modules. This is required for migrating vendors off of ION which was also recently changed to support modules. So this patch series simply provides the necessary exported symbols and allows the system and CMA drivers to be built as modules. Due to the fact that dmabuf's allocated from a heap may be in use for quite some time, there isn't a way to safely unload the driver once it has been loaded. Thus these drivers do no implement module_exit() functions and will show up in lsmod as "[permanent]" Feedback and thoughts on this would be greatly appreciated! >>> >>> Do we actually want this? >> >> I guess that always depends on the definition of "we" :) >> >>> I figured if we just state that vendors should set up all the right >>> dma-buf heaps in dt, is that not enough? >> >> So even if the heaps are configured via DT (which at the moment there >> is no such binding, so that's not really a valid method yet), there's >> still the question of if the heap is necessary/makes sense on the >> device. And the DT would only control the availability of the heap >> interface, not if the heap driver is loaded or not. > > Hm I thought the cma regions are configured in DT? How does that work if > it's not using DT? > >> On the HiKey/HiKey960 boards, we have to allocate contiguous buffers >> for the display framebuffer. So gralloc uses ION to allocate from the >> CMA heap. However on the db845c, it has no such restrictions, so the >> CMA heap isn't necessary. > > Why do you have a CMA region for the 2nd board if you don't need it? > _That_ sounds like some serious memory waster, not a few lines of code > loaded for nothing :-) > >> With Android's GKI effort, there needs to be one kernel that works on >> all the devices, and they are using modules to try to minimize the >> amount of memory spent on functionality that isn't universally needed. >> So on devices that don't need the CMA heap, they'd probably prefer not >> to load the CMA dmabuf heap driver, so it would be best if it could be >> built as a module. If we want to build the CMA heap as a module, the >> symbols it uses need to be exported. > > Yeah, I guess I'm disagreeing on whether dma-buf heaps are core or not. > >>> Exporting symbols for no real in-tree users feels fishy. >> >> I'm submitting an in-tree user here. So I'm not sure what you mean? I >> suspect you're thinking there is some hidden/nefarious plan here, but >> really there isn't. > > I was working under the assumption that you're only exporting the symbols > for other heaps, and keep the current ones in-tree. Are there even any > out-of-tree dma-buf heaps still? out-of-tree and legit different use-case > I mean ofc, not just out-of-tree because inertia :-) Not sure what you mean here, hopefully all the heaps can be "in-tree" some day. https://patchwork.kernel.org/patch/10863957/ Plus some non-caching heaps and one that forces early allocation of our PAT (gart like) IP. All this stuff is going into our evil vendor tree next cycle (if not upstream by then :)), if we want some of these "specialty" heaps to go into generic kernel builds at some point they will need to be modules if the core is. Although I am still thinking Heaps should be always built in + system + CMA heaps, then the rando heaps could be modules if needed. Andrew > -Daniel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] dma-buf: heaps: remove redundant assignment to variable ret
On 10/30/19 11:02 AM, Colin King wrote:
> From: Colin Ian King
>
> The variable ret is being assigned with a value that is never
> read, it is being re-assigned the same value on the err0 exit
> path. The assignment is redundant and hence can be removed.
>
> Addresses-Coverity: ("Unused value")
> Fixes: 47a32f9c1226 ("dma-buf: heaps: Add system heap to dmabuf heaps")
> Signed-off-by: Colin Ian King
> ---
The root of the issue is that ret is not used in the error path, it
should be, I suggest this fix:
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -98,7 +98,7 @@ static int system_heap_allocate(struct dma_heap *heap,
> err0:
> kfree(helper_buffer);
>
> - return -ENOMEM;
> + return ret;
> }
>
> static const struct dma_heap_ops system_heap_ops = {
Andrew
> drivers/dma-buf/heaps/system_heap.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/dma-buf/heaps/system_heap.c
> b/drivers/dma-buf/heaps/system_heap.c
> index 455782efbb32..817a1667bd57 100644
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -55,10 +55,8 @@ static int system_heap_allocate(struct dma_heap *heap,
> helper_buffer->pages = kmalloc_array(helper_buffer->pagecount,
>sizeof(*helper_buffer->pages),
>GFP_KERNEL);
> - if (!helper_buffer->pages) {
> - ret = -ENOMEM;
> + if (!helper_buffer->pages)
> goto err0;
> - }
>
> for (pg = 0; pg < helper_buffer->pagecount; pg++) {
> /*
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 0/5] DMA-BUF Heaps (destaging ION)
On 10/22/19 3:21 AM, Neil Armstrong wrote: > Hi John, > > On 21/10/2019 21:03, John Stultz wrote: >> Lucky number 13! :) >> >> Last week in v12 I had re-added some symbol exports to support >> later patches I have pending to enable loading heaps from >> modules. He reminded me that back around v3 (its been awhile!) I >> had removed those exports due to concerns about the fact that we >> don't support module removal. >> >> So I'm respinning the patches, removing the exports again. I'll >> submit a patch to re-add them in a later series enabling moduels >> which can be reviewed indepently. >> >> With that done, lets get on to the boilerplate! >> >> The patchset implements per-heap devices which can be opened >> directly and then an ioctl is used to allocate a dmabuf from the >> heap. >> >> The interface is similar, but much simpler then IONs, only >> providing an ALLOC ioctl. >> >> Also, I've provided relatively simple system and cma heaps. >> >> I've booted and tested these patches with AOSP on the HiKey960 >> using the kernel tree here: >> >> https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap > > Do you have a 4.19 tree with the changes ? I tried but the xarray idr > replacement > is missing... so I can't test with our android-amlogic-bmeson-4.19 tree. > Just a note, we switched to xarray around v4 time frame of this series, so you may be able to find the IDR based code and plug it in for a 4.19 port. Andrew > If you can provide, I'll be happy to test the serie and the gralloc changes. > > Neil > >> >> And the userspace changes here: >> https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 >> >> Compared to ION, this patchset is missing the system-contig, >> carveout and chunk heaps, as I don't have a device that uses >> those, so I'm unable to do much useful validation there. >> Additionally we have no upstream users of chunk or carveout, >> and the system-contig has been deprecated in the common/andoid-* >> kernels, so this should be ok. >> >> I've also removed the stats accounting, since any such >> accounting should be implemented by dma-buf core or the heaps >> themselves. >> >> New in v13: >> * Re-remove symbol exports, per discussion with Brian. I'll >> resubmit these separately in a later patch so they can be >> independently reviewed >> >> thanks >> -john >> >> Cc: Laura Abbott >> Cc: Benjamin Gaignard >> Cc: Sumit Semwal >> Cc: Liam Mark >> Cc: Pratik Patel >> Cc: Brian Starkey >> Cc: Vincent Donnefort >> Cc: Sudipto Paul >> Cc: Andrew F. Davis >> Cc: Christoph Hellwig >> Cc: Chenbo Feng >> Cc: Alistair Strachan >> Cc: Hridya Valsaraju >> Cc: Hillf Danton >> Cc: dri-devel@lists.freedesktop.org >> >> >> >> Andrew F. Davis (1): >> dma-buf: Add dma-buf heaps framework >> >> John Stultz (4): >> dma-buf: heaps: Add heap helpers >> dma-buf: heaps: Add system heap to dmabuf heaps >> dma-buf: heaps: Add CMA heap to dmabuf heaps >> kselftests: Add dma-heap test >> >> MAINTAINERS | 18 ++ >> drivers/dma-buf/Kconfig | 11 + >> drivers/dma-buf/Makefile | 2 + >> drivers/dma-buf/dma-heap.c| 269 ++ >> drivers/dma-buf/heaps/Kconfig | 14 + >> drivers/dma-buf/heaps/Makefile| 4 + >> drivers/dma-buf/heaps/cma_heap.c | 178 >> drivers/dma-buf/heaps/heap-helpers.c | 268 + >> drivers/dma-buf/heaps/heap-helpers.h | 55 >> drivers/dma-buf/heaps/system_heap.c | 124 >> include/linux/dma-heap.h | 59 >> include/uapi/linux/dma-heap.h | 55 >> tools/testing/selftests/dmabuf-heaps/Makefile | 9 + >> .../selftests/dmabuf-heaps/dmabuf-heap.c | 238 >> 14 files changed, 1304 insertions(+) >> create mode 100644 drivers/dma-buf/dma-heap.c >> create mode 100644 drivers/dma-buf/heaps/Kconfig >> create mode 100644 drivers/dma-buf/heaps/Makefile >> create mode 100644 drivers/dma-buf/heaps/cma_heap.c >> create mode 100644 drivers/dma-buf/heaps/heap-helpers.c >> create mode 100644 drivers/dma-buf/heaps/heap-helpers.h >> create mode 100644 drivers/dma-buf/heaps/system_heap.c >> create mode 100644 include/linux/dma-heap.h >> create mode 100644 include/uapi/linux/dma-heap.h >> create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile >> create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c >> > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On 10/18/19 2:57 PM, Ayan Halder wrote:
> On Fri, Oct 18, 2019 at 11:49:22AM -0700, John Stultz wrote:
>> On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote:
>>> On Fri, Oct 18, 2019 at 09:55:17AM +, Brian Starkey wrote:
>>>> On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
>>>>> On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
>>>>>> On 10/17/19 3:14 PM, John Stultz wrote:
>>>>>>> But if the objection stands, do you have a proposal for an alternative
>>>>>>> way to enumerate a subset of CMA heaps?
>>>>>>>
>>>>>> When in staging ION had to reach into the CMA framework as the other
>>>>>> direction would not be allowed, so cma_for_each_area() was added. If
>>>>>> DMA-BUF heaps is not in staging then we can do the opposite, and have
>>>>>> the CMA framework register heaps itself using our framework. That way
>>>>>> the CMA system could decide what areas to export or not (maybe based on
>>>>>> a DT property or similar).
>>>>>
>>>>> Ok. Though the CMA core doesn't have much sense of DT details either,
>>>>> so it would probably have to be done in the reserved_mem logic, which
>>>>> doesn't feel right to me.
>>>>>
>>>>> I'd probably guess we should have some sort of dt binding to describe
>>>>> a dmabuf cma heap and from that node link to a CMA node via a
>>>>> memory-region phandle. Along with maybe the default heap as well? Not
>>>>> eager to get into another binding review cycle, and I'm not sure what
>>>>> non-DT systems will do yet, but I'll take a shot at it and iterate.
>>>>>
>>>>>> The end result is the same so we can make this change later (it has to
>>>>>> come after DMA-BUF heaps is in anyway).
>>>>>
>>>>> Well, I'm hesitant to merge code that exposes all the CMA heaps and
>>>>> then add patches that becomes more selective, should anyone depend on
>>>>> the initial behavior. :/
>>>>
>>>> How about only auto-adding the system default CMA region (cma->name ==
>>>> "reserved")?
>>>>
>>>> And/or the CMA auto-add could be behind a config option? It seems a
>>>> shame to further delay this, and the CMA heap itself really is useful.
>>>>
>>> A bit of a detour, comming back to the issue why the following node
>>> was not getting detected by the dma-buf heaps framework.
>>>
>>> reserved-memory {
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>> ranges;
>>>
>>> display_reserved: framebuffer@6000 {
>>> compatible = "shared-dma-pool";
>>> linux,cma-default;
>>> reusable; <<<<<<<<<<<<---This was missing
>>> in our
>>> earlier node
>>> reg = <0 0x6000 0 0x0800>;
>>> };
>>
>> Right. It has to be a CMA region for us to expose it from the cma heap.
>>
>>
>>> With 'reusable', rmem_cma_setup() succeeds , but the kernel crashes as
>>> follows :-
>>>
>>> [0.450562] WARNING: CPU: 2 PID: 1 at mm/cma.c:110
>>> cma_init_reserved_areas+0xec/0x22c
>>
>> Is the value 0x6000 you're using something you just guessed at? It
>> seems like the warning here is saying the pfn calculated from the base
>> address isn't valid.
> It is a valid memory region we use to allocate framebuffers.
But does it have a valid kernel virtual mapping? Most ARM systems (just
assuming you are working on ARM :)) that I'm familiar with have the DRAM
space starting at 0x8000 and so don't start having valid pfns until
that point. Is this address you are reserving an SRAM?
Andrew
>>
>> thanks
>> -john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
On 10/18/19 8:03 AM, Benjamin Gaignard wrote: > Le ven. 18 oct. 2019 à 13:21, Brian Starkey a écrit : >> >> On Fri, Oct 18, 2019 at 05:23:22AM +, John Stultz wrote: >>> This adds a CMA heap, which allows userspace to allocate >>> a dma-buf of contiguous memory out of a CMA region. >>> >>> This code is an evolution of the Android ION implementation, so >>> thanks to its original author and maintainters: >>> Benjamin Gaignard, Laura Abbott, and others! >>> >>> NOTE: This patch only adds the default CMA heap. We will enable >>> selectively adding other CMA memory regions to the dmabuf heaps >>> interface with a later patch (which requires a dt binding) > > Maybe we can use "no-map" DT property to trigger that. If set do not expose > the > cma heap. "no-map" means it can't be used as a regular CMA either, we want some way to both have it as a device usable CMA but also not be exposed to userspace if needed. Andrew > > Benjamin >> >> That'll teach me for reading my email in FIFO order. >> >> This approach makes sense to me. >> >> -Brian >>
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On 10/17/19 3:14 PM, John Stultz wrote: > On Wed, Oct 16, 2019 at 10:41 AM Andrew F. Davis wrote: >> On 10/14/19 5:07 AM, Brian Starkey wrote: >>> Hi Andrew, >>> >>> On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote: >>>> The CMA driver that registers these nodes will have to be expanded to >>>> export them using this framework as needed. We do something similar to >>>> export SRAM nodes: >>>> >>>> https://lkml.org/lkml/2019/3/21/575 >>>> >>>> Unlike the system/default-cma driver which can be centralized in the >>>> tree, these extra exporters will probably live out in other subsystems >>>> and so are added in later steps. >>>> >>>> Andrew >>> >>> I was under the impression that the "cma_for_each_area" loop in patch >>> 4 would do that (add_cma_heaps). Is it not the case? >>> >> >> For these cma nodes yes, I thought you meant reserved memory areas in >> general. > > Ok, sorry I didn't see this earlier, not only was I still dropped from > the To list, but the copy I got from dri-devel ended up marked as > spam. > >> Just as a side note, I'm not a huge fan of the cma_for_each_area() to >> begin with, it seems a bit out of place when they could be selectively >> added as heaps as needed. Not sure how that will work with cma nodes >> specifically assigned to devices, seems like we could just steal their >> memory space from userspace with this.. > > So this would be a concern with ION as well, since it does the same > thing because being able to allocate from multiple CMA heaps for > device specific purpose is really useful. > And at least with dmabuf heaps each heap can be given its own > permissions so there's less likelihood for any abuse as you describe. > Yes it was a problem with ION also, having individual files per heap does help with some permissions, but my issue is what if I don't want my CMA exported at all, cma_for_each_area() just grabs them all anyway. > And it also allows various device cma nodes to still be allocated from > using the same interface (rather then having to use a custom driver > ioctl for each device). > This is definitely the way to go, it's the implementation of how we get the CMAs to export in the first place that is a bit odd. > But if the objection stands, do you have a proposal for an alternative > way to enumerate a subset of CMA heaps? > When in staging ION had to reach into the CMA framework as the other direction would not be allowed, so cma_for_each_area() was added. If DMA-BUF heaps is not in staging then we can do the opposite, and have the CMA framework register heaps itself using our framework. That way the CMA system could decide what areas to export or not (maybe based on a DT property or similar). The end result is the same so we can make this change later (it has to come after DMA-BUF heaps is in anyway). Andrew > thanks > -john > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Move radeon and amdgpu Kconfig options into their directories
Most Kconfig options to enable a driver are in the Kconfig file inside the relevant directory, move these two to the same. Signed-off-by: Andrew F. Davis --- drivers/gpu/drm/Kconfig| 34 -- drivers/gpu/drm/amd/amdgpu/Kconfig | 18 drivers/gpu/drm/radeon/Kconfig | 18 3 files changed, 36 insertions(+), 34 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index e67c194c2aca..bc5329b697ad 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -203,42 +203,8 @@ source "drivers/gpu/drm/i2c/Kconfig" source "drivers/gpu/drm/arm/Kconfig" -config DRM_RADEON - tristate "ATI Radeon" - depends on DRM && PCI && MMU - select FW_LOADER -select DRM_KMS_HELPER -select DRM_TTM - select POWER_SUPPLY - select HWMON - select BACKLIGHT_CLASS_DEVICE - select INTERVAL_TREE - help - Choose this option if you have an ATI Radeon graphics card. There - are both PCI and AGP versions. You don't need to choose this to - run the Radeon in plain VGA mode. - - If M is selected, the module will be called radeon. - source "drivers/gpu/drm/radeon/Kconfig" -config DRM_AMDGPU - tristate "AMD GPU" - depends on DRM && PCI && MMU - select FW_LOADER -select DRM_KMS_HELPER - select DRM_SCHED -select DRM_TTM - select POWER_SUPPLY - select HWMON - select BACKLIGHT_CLASS_DEVICE - select INTERVAL_TREE - select CHASH - help - Choose this option if you have a recent AMD Radeon graphics card. - - If M is selected, the module will be called amdgpu. - source "drivers/gpu/drm/amd/amdgpu/Kconfig" source "drivers/gpu/drm/nouveau/Kconfig" diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig b/drivers/gpu/drm/amd/amdgpu/Kconfig index 2e98c016cb47..a53554557cc6 100644 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig @@ -1,4 +1,22 @@ # SPDX-License-Identifier: GPL-2.0-only + +config DRM_AMDGPU + tristate "AMD GPU" + depends on DRM && PCI && MMU + select FW_LOADER + select DRM_KMS_HELPER + select DRM_SCHED + select DRM_TTM + select POWER_SUPPLY + select HWMON + select BACKLIGHT_CLASS_DEVICE + select INTERVAL_TREE + select CHASH + help + Choose this option if you have a recent AMD Radeon graphics card. + + If M is selected, the module will be called amdgpu. + config DRM_AMDGPU_SI bool "Enable amdgpu support for SI parts" depends on DRM_AMDGPU diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig index 6f60f4840cc5..ba67b879d31d 100644 --- a/drivers/gpu/drm/radeon/Kconfig +++ b/drivers/gpu/drm/radeon/Kconfig @@ -1,4 +1,22 @@ # SPDX-License-Identifier: GPL-2.0-only + +config DRM_RADEON + tristate "ATI Radeon" + depends on DRM && PCI && MMU + select FW_LOADER + select DRM_KMS_HELPER + select DRM_TTM + select POWER_SUPPLY + select HWMON + select BACKLIGHT_CLASS_DEVICE + select INTERVAL_TREE + help + Choose this option if you have an ATI Radeon graphics card. There + are both PCI and AGP versions. You don't need to choose this to + run the Radeon in plain VGA mode. + + If M is selected, the module will be called radeon. + config DRM_RADEON_USERPTR bool "Always enable userptr support" depends on DRM_RADEON -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On 10/14/19 5:07 AM, Brian Starkey wrote: > Hi Andrew, > > On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote: >> The CMA driver that registers these nodes will have to be expanded to >> export them using this framework as needed. We do something similar to >> export SRAM nodes: >> >> https://lkml.org/lkml/2019/3/21/575 >> >> Unlike the system/default-cma driver which can be centralized in the >> tree, these extra exporters will probably live out in other subsystems >> and so are added in later steps. >> >> Andrew > > I was under the impression that the "cma_for_each_area" loop in patch > 4 would do that (add_cma_heaps). Is it not the case? > For these cma nodes yes, I thought you meant reserved memory areas in general. Just as a side note, I'm not a huge fan of the cma_for_each_area() to begin with, it seems a bit out of place when they could be selectively added as heaps as needed. Not sure how that will work with cma nodes specifically assigned to devices, seems like we could just steal their memory space from userspace with this.. Andrew > Thanks, > -Brian >
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On 10/9/19 1:37 PM, Ayan Halder wrote:
> On Tue, Sep 24, 2019 at 04:22:18PM +, Ayan Halder wrote:
>> On Thu, Sep 19, 2019 at 10:21:52PM +0530, Sumit Semwal wrote:
>>> Hello Christoph, everyone,
>>>
>>> On Sat, 7 Sep 2019 at 00:17, John Stultz wrote:
>>>>
>>>> Here is yet another pass at the dma-buf heaps patchset Andrew
>>>> and I have been working on which tries to destage a fair chunk
>>>> of ION functionality.
>>>>
>>>> The patchset implements per-heap devices which can be opened
>>>> directly and then an ioctl is used to allocate a dmabuf from the
>>>> heap.
>>>>
>>>> The interface is similar, but much simpler then IONs, only
>>>> providing an ALLOC ioctl.
>>>>
>>>> Also, I've provided relatively simple system and cma heaps.
>>>>
>>>> I've booted and tested these patches with AOSP on the HiKey960
>>>> using the kernel tree here:
>>>>
>>>> https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap
>>>>
>>>> And the userspace changes here:
>>>> https://android-review.googlesource.com/c/device/linaro/hikey/+/909436
>>>>
>>>> Compared to ION, this patchset is missing the system-contig,
>>>> carveout and chunk heaps, as I don't have a device that uses
>>>> those, so I'm unable to do much useful validation there.
>>>> Additionally we have no upstream users of chunk or carveout,
>>>> and the system-contig has been deprecated in the common/andoid-*
>>>> kernels, so this should be ok.
>>>>
>>>> I've also removed the stats accounting, since any such accounting
>>>> should be implemented by dma-buf core or the heaps themselves.
>>>>
>>>> Most of the changes in this revision are adddressing the more
>>>> concrete feedback from Christoph (many thanks!). Though I'm not
>>>> sure if some of the less specific feedback was completely resolved
>>>> in discussion last time around. Please let me know!
>>>
>>> It looks like most of the feedback has been taken care of. If there's
>>> no more objection to this series, I'd like to merge it in soon.
>>>
>>> If there are any more review comments, may I request you to please provide
>>> them?
>>
>> I tested these patches using our internal test suite with Arm,komeda
>> driver and the following node in dts
>>
>> reserved-memory {
>> #address-cells = <0x2>;
>> #size-cells = <0x2>;
>> ranges;
>>
>> framebuffer@6000 {
>> compatible = "shared-dma-pool";
>> linux,cma-default;
>> reg = <0x0 0x6000 0x0 0x800>;
>> };
>> }
> Apologies for the confusion, this dts node is irrelevant as our tests were
> using
> the cma heap (via /dev/dma_heap/reserved).
>
> That raises a question. How do we represent the reserved-memory nodes
> (as shown above) via the dma-buf heaps framework ?
The CMA driver that registers these nodes will have to be expanded to
export them using this framework as needed. We do something similar to
export SRAM nodes:
https://lkml.org/lkml/2019/3/21/575
Unlike the system/default-cma driver which can be centralized in the
tree, these extra exporters will probably live out in other subsystems
and so are added in later steps.
Andrew
>>
>> The tests went fine. Our tests allocates framebuffers of different
>> sizes, posts them on screen and the driver writes back to one of the
>> framebuffers. I havenot tested for any performance, latency or
>> cache management related stuff. So, it that looks appropriate, feel
>> free to add:-
>> Tested-by:- Ayan Kumar Halder
>>
>> Are you planning to write some igt tests for it ?
>>>
>>>>
>>>> New in v8:
>>>> * Make struct dma_heap_ops consts (Suggested by Christoph)
>>>> * Add flush_kernel_vmap_range/invalidate_kernel_vmap_range calls
>>>> (suggested by Christoph)
>>>> * Condense dma_heap_buffer and heap_helper_buffer (suggested by
>>>> Christoph)
>>>> * Get rid of needless struct system_heap (suggested by Christoph)
>>>> * Fix indentation by using shorter argument names (suggested by
>>>> Christoph)
>>>> * Remove unused private_flags value
>>>> * Add forgotten inc
Re: [PATCH] drm/omap: Migrate minimum FCK/PCK ratio from Kconfig to dts
On 5/28/19 4:11 AM, Tomi Valkeinen wrote: > Hi, > > On 10/05/2019 22:42, Adam Ford wrote: >> Currently the source code is compiled using hard-coded values >> from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this >> clock divider value to be moved to the device tree and be changed >> without having to recompile the kernel. >> >> Signed-off-by: Adam Ford > > I understand why you want to do this, but I'm not sure it's a good idea. > It's really something the driver should figure out, and if we add it to > the DT, it effectively becomes an ABI. > > That said... I'm not sure how good of a job the driver could ever do, as > it can't know the future scaling needs of the userspace at the time it > is configuring the clock. And so, I'm not nacking this patch, but I > don't feel very good about this patch... > > The setting also affects all outputs (exluding venc), which may not be > what the user wants. Then again, I think this setting is really only > needed on OMAP2 & 3, which have only a single output. But that's the > same with the current kconfig option, of course. > > So, the current CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK is an ugly hack, in my > opinion, and moving it to DT makes it a worse hack =). But I don't have > any good suggestions either. > Module param? Andrew > Tomi > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 2/2] soc: ti: Add Support for the TI Page-based Address Translator (PAT)
On 6/18/19 5:07 AM, Tero Kristo wrote:
> On 07/06/2019 22:35, Andrew F. Davis wrote:
>> This patch adds a driver for the Page-based Address Translator (PAT)
>> present on various TI SoCs. A PAT device performs address translation
>> using tables stored in an internal SRAM. Each PAT supports a set number
>> of pages, each occupying a programmable 4KB, 16KB, 64KB, or 1MB of
>> addresses in a window for which an incoming transaction will be
>> translated.
>>
>> Signed-off-by: Andrew F. Davis
>> ---
>> drivers/soc/ti/Kconfig | 9 +
>> drivers/soc/ti/Makefile | 1 +
>> drivers/soc/ti/ti-pat.c | 569
>> include/uapi/linux/ti-pat.h | 44 +++
>> 4 files changed, 623 insertions(+)
>> create mode 100644 drivers/soc/ti/ti-pat.c
>> create mode 100644 include/uapi/linux/ti-pat.h
>>
>> diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
>> index f0be35d3dcba..b838ae74d01f 100644
>> --- a/drivers/soc/ti/Kconfig
>> +++ b/drivers/soc/ti/Kconfig
>> @@ -86,4 +86,13 @@ config TI_SCI_INTA_MSI_DOMAIN
>> help
>> Driver to enable Interrupt Aggregator specific MSI Domain.
>> +config TI_PAT
>> + tristate "TI PAT DMA-BUF exporter"
>> + select REGMAP
>
> What is the reasoning for using regmap for internal register access? Why
> not just use direct readl/writel for everything? To me it seems this is
> only used during probe time also...
>
There are two register spaces, the configuration space, and the actual
translation table data. I use regmap for all the configuration space.
Direct readl/writel would also work, but I prefer regmap as it lets me
work with field names vs using masks and shifts, even if it adds a
little extra code in tables at the top.
>> + help
>> + Driver for TI Page-based Address Translator (PAT). This driver
>> + provides the an API allowing the remapping of a non-contiguous
>> + DMA-BUF into a contiguous one that is sutable for devices needing
>> + coniguous memory.
>
> Minor typo: contiguous.
>
ACK
>> +
>> endif # SOC_TI
>> diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
>> index b3868d392d4f..1369642b40c3 100644
>> --- a/drivers/soc/ti/Makefile
>> +++ b/drivers/soc/ti/Makefile
>> @@ -9,3 +9,4 @@ obj-$(CONFIG_AMX3_PM) += pm33xx.o
>> obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
>> obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
>> obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
>> +obj-$(CONFIG_TI_PAT) += ti-pat.o
>> diff --git a/drivers/soc/ti/ti-pat.c b/drivers/soc/ti/ti-pat.c
>> new file mode 100644
>> index ..7359ea0f7ccf
>> --- /dev/null
>> +++ b/drivers/soc/ti/ti-pat.c
>> @@ -0,0 +1,569 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * TI PAT mapped DMA-BUF memory re-exporter
>> + *
>> + * Copyright (C) 2018-2019 Texas Instruments Incorporated -
>> http://www.ti.com/
>> + * Andrew F. Davis
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +#define TI_PAT_DRIVER_NAME "ti-pat"
>
> Why do you have a define for this seeing it is only used in single
> location?
>
Just habit when starting a driver, but you are right it is not needed here.
>> +
>> +/* TI PAT MMRS registers */
>> +#define TI_PAT_MMRS_PID 0x0 /* Revision Register */
>> +#define TI_PAT_MMRS_CONFIG 0x4 /* Config Register */
>> +#define TI_PAT_MMRS_CONTROL 0x10 /* Control Register */
>> +
>> +/* TI PAT CONTROL register field values */
>> +#define TI_PAT_CONTROL_ARB_MODE_UF 0x0 /* Updates first */
>> +#define TI_PAT_CONTROL_ARB_MODE_RR 0x2 /* Round-robin */
>> +
>> +#define TI_PAT_CONTROL_PAGE_SIZE_4KB 0x0
>> +#define TI_PAT_CONTROL_PAGE_SIZE_16KB 0x1
>> +#define TI_PAT_CONTROL_PAGE_SIZE_64KB 0x2
>> +#define TI_PAT_CONTROL_PAGE_SIZE_1MB 0x3
>> +
>> +static unsigned int ti_pat_page_sizes[] = {
>> + [TI_PAT_CONTROL_PAGE_SIZE_4KB] = 4 * 1024,
>> + [TI_PAT_CONTROL_PAGE_SIZE_16KB] = 16 * 1024,
>> + [TI_PAT_CONTROL_PAGE_SIZE_64KB] = 64 * 1024,
>> + [TI_PAT_CONTROL_PAGE_SIZE_1MB] = 1024 * 1024,
>> +};
>> +
>> +enum ti_pat_mmrs_fields {
>> + /* Revision */
>> + F_PID_MAJOR,
>> + F_PID_MINOR,
Re: [PATCH v7 3/5] dma-buf: heaps: Add system heap to dmabuf heaps
On 7/25/19 9:02 AM, Christoph Hellwig wrote:
>> +struct system_heap {
>> +struct dma_heap *heap;
>> +} sys_heap;
>
> It seems like this structure could be removed and if would improve
> the code flow.
>
>> +static struct dma_heap_ops system_heap_ops = {
>> +.allocate = system_heap_allocate,
>> +};
>> +
>> +static int system_heap_create(void)
>> +{
>> +struct dma_heap_export_info exp_info;
>> +int ret = 0;
>> +
>> +exp_info.name = "system_heap";
>> +exp_info.ops = _heap_ops;
>> +exp_info.priv = _heap;
>> +
>> +sys_heap.heap = dma_heap_add(_info);
>> +if (IS_ERR(sys_heap.heap))
>> +ret = PTR_ERR(sys_heap.heap);
>> +
>> +return ret;
>
> The data structures here seem a little odd. I think you want to:
>
> - mark all dma_heap_ops instanes consts, as we generally do that for
>all structures containing function pointers
> - move the name into dma_heap_ops.
> - remove the dma_heap_export_info structure, which is a bit pointless
The idea here is to keep the struct dma_heap as an opaque pointer for
everyone but the core framework. No one should be touching the guts of
that struct (would be 'private' if we were using C++ but this is the
best we can do with C), exposing it to the exporters or the importers
will break this isolation.
This export style also matches DMA-BUF: you pass in a filled out _export
struct and it passes back a dma_buf handle. DMA-BUF unfortunately made
the internals of that struct public so they are widely used directly
(and abused in some cases) and that prevents the internals from being
easily refactored when needed.
Andrew
> - don't bother setting a private data, as you don't need it.
>If other heaps need private data I'd suggest to switch to embedding
>the dma_heap structure into containing structure insted so that you
>can use container_of to get at it.
> - also why is the free callback passed as a callback rather than
>kept in dma_heap_ops, next to the paired alloc one?
>
Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
On 7/25/19 10:30 AM, Christoph Hellwig wrote: > On Thu, Jul 25, 2019 at 10:25:50AM -0400, Andrew F. Davis wrote: >> On 7/25/19 10:11 AM, Christoph Hellwig wrote: >>> On Thu, Jul 25, 2019 at 10:10:08AM -0400, Andrew F. Davis wrote: >>>> Pages yes, but not "normal" pages from the kernel managed area. >>>> page_to_pfn() will return bad values on the pages returned by this >>>> allocator and so will any of the kernel sync/map functions. Therefor >>>> those operations cannot be common and need special per-heap handling. >>> >>> Well, that means this thing is buggy and abuses the scatterlist API >>> and we can't merge it anyway, so it is irrelevant. >>> >> >> Since when do scatterlists need to only have kernel virtual backed >> memory pages? Device memory is stored in scatterlists and >> dma_sync_sg_for_* would fail just the same when the cache ops were >> attempted. > > I'm not sure what you mean with virtual backed memory pages, as we > don't really have that concept. > > But a page in the scatterlist needs to be able to be used everywhere > we'd normally use a page, e.g. page_to_phys, page_to_pfn, kmap, > page_address (if !highmem) as consumers including the dma mapping > interface do all that. > > If you want to dma map memory that does not have page backing you > need to use dma_map_resource. > I probably should have worded that better. It does have page backing, what I meant by "page_to_pfn() will return bad values" is not that it won't give you the correct pfn, it will, but that then that pfn is not part of the normal memory space (lowmem/highmem) it's device memory, so cache ops won't work. But you should not be doing that on device memory anyway. That is a problem with Ion I want to avoid, it assumed all buffers were in DDR and so would do cache operations on them unconditionally, too many assumptions were made as too much was moved into the common core code and not enough was left for the heaps themselves to decide. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
On 7/25/19 10:11 AM, Christoph Hellwig wrote: > On Thu, Jul 25, 2019 at 10:10:08AM -0400, Andrew F. Davis wrote: >> Pages yes, but not "normal" pages from the kernel managed area. >> page_to_pfn() will return bad values on the pages returned by this >> allocator and so will any of the kernel sync/map functions. Therefor >> those operations cannot be common and need special per-heap handling. > > Well, that means this thing is buggy and abuses the scatterlist API > and we can't merge it anyway, so it is irrelevant. > Since when do scatterlists need to only have kernel virtual backed memory pages? Device memory is stored in scatterlists and dma_sync_sg_for_* would fail just the same when the cache ops were attempted. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
On 7/25/19 10:04 AM, Christoph Hellwig wrote: > On Thu, Jul 25, 2019 at 09:31:50AM -0400, Andrew F. Davis wrote: >> But that's just it, dma-buf does not assume buffers are backed by normal >> kernel managed memory, it is up to the buffer exporter where and when to >> allocate the memory. The memory backed by this SRAM buffer does not have >> the normal struct page backing. So moving the map, sync, etc functions >> to common code would fail for this and many other heap types. This was a >> major problem with Ion that prompted this new design. > > The code clearly shows it has page backing, e.g. this: > > + sg_set_page(table->sgl, pfn_to_page(PFN_DOWN(buffer->paddr)), > buffer->len, 0); > > and the fact that it (and the dma-buf API) uses scatterlists, which > requires pages. > Pages yes, but not "normal" pages from the kernel managed area. page_to_pfn() will return bad values on the pages returned by this allocator and so will any of the kernel sync/map functions. Therefor those operations cannot be common and need special per-heap handling. Andrew ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
On 7/25/19 8:48 AM, Christoph Hellwig wrote: > On Wed, Jul 24, 2019 at 07:38:07AM -0400, Laura Abbott wrote: >> It's not just an optimization for Ion though. Ion was designed to >> let the callers choose between system and multiple CMA heaps. > > Who cares about ion? That some out of tree android crap that should > not be relevant for upstream except as an example for how not to design > things.. > Tell us how you really feel about ION :) >> On other >> systems there may be multiple CMA regions dedicated to a specific >> purpose or placed at a specific address. The callers need to >> be able to choose exactly whether they want a particular CMA region >> or discontiguous regions. > > At least in cma is only used either with the global pool or a per-device > cma pool. I think if you want to make this new dma-buf API fit in with > the rest with the kernel you follow that model, and pass in a struct > device to select the particular cma area, similar how the DMA allocator > works. > This is a central allocator, it is not tied to any one device. If we knew the one device ahead of time we would just use the existing dma_alloc. We might be able to solve some of that with late mapping after all the devices attach to the buffer, but even then, which device's CMA area would we chose to use from all the attached devices? I can agree that allocating from per-device CMA using Heaps doesn't make much sense, but for global pools I'm not sure I see any way to allow devices to select which pool is right for a specific use. They don't have the full use-case information like the application does, the selection needs to be made from the application. Andrew ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
On 7/25/19 8:50 AM, Christoph Hellwig wrote: > On Wed, Jul 24, 2019 at 11:46:01AM -0400, Andrew F. Davis wrote: >> https://patchwork.kernel.org/patch/10863957/ >> >> It's actually a more simple heap type IMHO, but the logic inside is >> incompatible with the system/CMA heaps, if you move any of their code >> into the core framework then this heap stops working. Leading to out of >> tree hacks on the core to get it back functional. I see the same for the >> "complex" heaps with ION. > > Well, this mostly is just another allocator (gen_pool). And given that > the whole dma-buf infrastucture assumes things are backed by pages we > really shouldn't need much more than an alloc and a free callback (and > maybe the pgprot to map it) and handle the rest in common code. > But that's just it, dma-buf does not assume buffers are backed by normal kernel managed memory, it is up to the buffer exporter where and when to allocate the memory. The memory backed by this SRAM buffer does not have the normal struct page backing. So moving the map, sync, etc functions to common code would fail for this and many other heap types. This was a major problem with Ion that prompted this new design. Each heap type may need to do something different depending on its backing memory, moving everything to common code that is common to System and CMA heaps is would lead those being the only upstreamable heaps. Andrew
Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
On 7/24/19 2:59 AM, Christoph Hellwig wrote: > On Mon, Jul 22, 2019 at 10:04:06PM -0700, John Stultz wrote: >> Apologies, I'm not sure I'm understanding your suggestion here. >> dma_alloc_contiguous() does have some interesting optimizations >> (avoiding allocating single page from cma), though its focus on >> default area vs specific device area doesn't quite match up the usage >> model for dma heaps. Instead of allocating memory for a single >> device, we want to be able to allow userland, for a given usage mode, >> to be able to allocate a dmabuf from a specific heap of memory which >> will satisfy the usage mode for that buffer pipeline (across multiple >> devices). >> >> Now, indeed, the system and cma heaps in this patchset are a bit >> simple/trivial (though useful with my devices that require contiguous >> buffers for the display driver), but more complex ION heaps have >> traditionally stayed out of tree in vendor code, in many cases making >> incompatible tweaks to the ION core dmabuf exporter logic. > > So what would the more complicated heaps be? > https://patchwork.kernel.org/patch/10863957/ It's actually a more simple heap type IMHO, but the logic inside is incompatible with the system/CMA heaps, if you move any of their code into the core framework then this heap stops working. Leading to out of tree hacks on the core to get it back functional. I see the same for the "complex" heaps with ION. Andrew >> That's why >> dmabuf heaps is trying to destage ION in a way that allows heaps to >> implement their exporter logic themselves, so we can start pulling >> those more complicated heaps out of their vendor hidey-holes and get >> some proper upstream review. >> >> But I suspect I just am confused as to what your suggesting. Maybe >> could you expand a bit? Apologies for being a bit dense. > > My suggestion is to merge the system and CMA heaps. CMA (at least > the system-wide CMA area) is really just an optimization to get > large contigous regions more easily. We should make use of it as > transparent as possible, just like we do in the DMA code. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/5] dma-buf: heaps: Add heap helpers
On 7/24/19 2:55 AM, Christoph Hellwig wrote:
> On Tue, Jul 23, 2019 at 01:09:55PM -0700, Rob Clark wrote:
>> On Mon, Jul 22, 2019 at 9:09 PM John Stultz wrote:
>>>
>>> On Thu, Jul 18, 2019 at 3:06 AM Christoph Hellwig
>>> wrote:
Is there any exlusion between mmap / vmap and the device accessing
the data? Without that you are going to run into a lot of coherency
problems.
>>
>> dma_fence is basically the way to handle exclusion between different
>> device access (since device access tends to be asynchronous). For
>> device<->device access, each driver is expected to take care of any
>> cache(s) that the device might have. (Ie. device writing to buffer
>> should flush it's caches if needed before signalling fence to let
>> reading device know that it is safe to read, etc.)
>>
>> _begin/end_cpu_access() is intended to be the exclusion for CPU access
>> (which is synchronous)
>
> What I mean is that we need a clear state machine (preferably including
> ownership tracking ala dma-debug) where a piece of memory has one
> owner at a time that can access it. Only the owner can access is at
> that time, and at any owner switch we need to flush/invalidate all
> relevant caches. And with memory that is vmaped and mapped to userspace
> that can get really complicated.
>
> The above sounds like you have some of that in place, but we'll really
> need clear rules to make sure we don't have holes in the scheme.
>
Well then lets think on this. A given buffer can have 3 owners states
(CPU-owned, Device-owned, and Un-owned). These are based on the caching
state from the CPU perspective.
If a buffer is CPU-owned then we (Linux) can write to the buffer safely
without worry that the data is stale or that it will be accessed by the
device without having been flushed. Device-owned buffers should not be
accessed by the CPU, and inter-device synchronization should be handled
by fencing as Rob points out. Un-owned is how a buffer starts for
consistency and to prevent unneeded cache operations on unwritten buffers.
We also need to track the mapping states, 4 states for this, CPU-mapped,
Device-mapped, CPU/Device-mapped, unmapped. Should be self explanatory,
map_dma_buf maps towards the device, mmap/vmap/kmap towards the CPU.
Leaving a buffer mapped by the CPU while device access takes place is
safe as long as ownership is taken before any access. One more point, we
assume reference counting for the below discussion, for instance
unmap_dma_buf refers to the last device unmapping, map_dma_buf refers
only to the first.
This gives 12 combined states, if we assume a buffer will always be
owned when it has someone mapping it, either CPU or device or both, then
we can drop 3 states. If a buffer is only mapped into one space, then
that space owns it, this drops 2 cross-owned states. Lastly if not
mapped by either space then the buffer becomes un-owned (and the backing
memory can be freed or migrated as needed). Leaving us 5 valid states.
* Un-Owned Un-Mapped
* Device-Owned Device-Mapped
* Device-Owned CPU/Device-Mapped
* CPU-Owned CPU-Mapped
* CPU-Owned CPU/Device-Mapped
There are 6 DMA-BUF operations (classes) on a buffer:
* map_dma_buf
* unmap_dma_buf
* begin_cpu_access
* end_cpu_access
* mmap/vmap/kmap
* ummanp/vunmap/kunmap
From all this I've suggest the following state-machine(in DOT language):
Note: Buffers start in "Un-Owned Un-Mapped" and can only be freed from
that state.
Note: Commented out states/transitions are not valid but here to prove
completeness
---
digraph dma_buf_buffer_states
{
label = "DMA-BUF Buffer states";
uo_um [ label="Un-Owned\nUn-Mapped" ];
// uo_dm [ label="Un-Owned\nDevice-Mapped" ];
// uo_cm [ label="Un-Owned\nCPU-Mapped" ];
// uo_cdm [ label="Un-Owned\nCPU/Device-Mapped" ];
// do_um [ label="Device-Owned\nUn-Mapped" ];
do_dm [ label="Device-Owned\nDevice-Mapped" ];
// do_cm [ label="Device-Owned\nCPU-Mapped" ];
do_cdm [ label="Device-Owned\nCPU/Device-Mapped" ];
// co_um [ label="CPU-Owned\nUn-Mapped" ];
// co_dm [ label="CPU-Owned\nDevice-Mapped" ];
co_cm [ label="CPU-Owned\nCPU-Mapped" ];
co_cdm [ label="CPU-Owned\nCPU/Device-Mapped" ];
/* From Un-Owned Un-Mapped */
uo_um -> do_dm [ label="map_dma_buf" ];
// uo_um ->[ label="unmap_dma_buf" ];
// uo_um ->[ label="begin_cpu_access" ];
// uo_um ->[ label="end_cpu_access" ];
uo_um -> co_cm [ label="mmap/vmap/kmap" ];
// uo_um ->[ label="ummanp/vunmap/kunmap" ];
/* From Device-Owned Device-Mapped */
do_dm -> do_dm [ label="map_dma_buf" ];
do_dm -> uo_um [ label="unmap_dma_buf" ];
// do_dm ->[
[RFC PATCH 2/2] soc: ti: Add Support for the TI Page-based Address Translator (PAT)
This patch adds a driver for the Page-based Address Translator (PAT)
present on various TI SoCs. A PAT device performs address translation
using tables stored in an internal SRAM. Each PAT supports a set number
of pages, each occupying a programmable 4KB, 16KB, 64KB, or 1MB of
addresses in a window for which an incoming transaction will be
translated.
Signed-off-by: Andrew F. Davis
---
drivers/soc/ti/Kconfig | 9 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti-pat.c | 569
include/uapi/linux/ti-pat.h | 44 +++
4 files changed, 623 insertions(+)
create mode 100644 drivers/soc/ti/ti-pat.c
create mode 100644 include/uapi/linux/ti-pat.h
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index f0be35d3dcba..b838ae74d01f 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -86,4 +86,13 @@ config TI_SCI_INTA_MSI_DOMAIN
help
Driver to enable Interrupt Aggregator specific MSI Domain.
+config TI_PAT
+ tristate "TI PAT DMA-BUF exporter"
+ select REGMAP
+ help
+ Driver for TI Page-based Address Translator (PAT). This driver
+ provides the an API allowing the remapping of a non-contiguous
+ DMA-BUF into a contiguous one that is sutable for devices needing
+ coniguous memory.
+
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index b3868d392d4f..1369642b40c3 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_AMX3_PM) += pm33xx.o
obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
obj-$(CONFIG_TI_SCI_PM_DOMAINS)+= ti_sci_pm_domains.o
obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
+obj-$(CONFIG_TI_PAT) += ti-pat.o
diff --git a/drivers/soc/ti/ti-pat.c b/drivers/soc/ti/ti-pat.c
new file mode 100644
index ..7359ea0f7ccf
--- /dev/null
+++ b/drivers/soc/ti/ti-pat.c
@@ -0,0 +1,569 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI PAT mapped DMA-BUF memory re-exporter
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define TI_PAT_DRIVER_NAME "ti-pat"
+
+/* TI PAT MMRS registers */
+#define TI_PAT_MMRS_PID0x0 /* Revision Register */
+#define TI_PAT_MMRS_CONFIG 0x4 /* Config Register */
+#define TI_PAT_MMRS_CONTROL0x10 /* Control Register */
+
+/* TI PAT CONTROL register field values */
+#define TI_PAT_CONTROL_ARB_MODE_UF 0x0 /* Updates first */
+#define TI_PAT_CONTROL_ARB_MODE_RR 0x2 /* Round-robin */
+
+#define TI_PAT_CONTROL_PAGE_SIZE_4KB 0x0
+#define TI_PAT_CONTROL_PAGE_SIZE_16KB 0x1
+#define TI_PAT_CONTROL_PAGE_SIZE_64KB 0x2
+#define TI_PAT_CONTROL_PAGE_SIZE_1MB 0x3
+
+static unsigned int ti_pat_page_sizes[] = {
+ [TI_PAT_CONTROL_PAGE_SIZE_4KB] = 4 * 1024,
+ [TI_PAT_CONTROL_PAGE_SIZE_16KB] = 16 * 1024,
+ [TI_PAT_CONTROL_PAGE_SIZE_64KB] = 64 * 1024,
+ [TI_PAT_CONTROL_PAGE_SIZE_1MB] = 1024 * 1024,
+};
+
+enum ti_pat_mmrs_fields {
+ /* Revision */
+ F_PID_MAJOR,
+ F_PID_MINOR,
+
+ /* Controls */
+ F_CONTROL_ARB_MODE,
+ F_CONTROL_PAGE_SIZE,
+ F_CONTROL_REPLACE_OID_EN,
+ F_CONTROL_EN,
+
+ /* sentinel */
+ F_MAX_FIELDS
+};
+
+static const struct reg_field ti_pat_mmrs_reg_fields[] = {
+ /* Revision */
+ [F_PID_MAJOR] = REG_FIELD(TI_PAT_MMRS_PID, 8, 10),
+ [F_PID_MINOR] = REG_FIELD(TI_PAT_MMRS_PID, 0, 5),
+ /* Controls */
+ [F_CONTROL_ARB_MODE]= REG_FIELD(TI_PAT_MMRS_CONTROL, 6, 7),
+ [F_CONTROL_PAGE_SIZE] = REG_FIELD(TI_PAT_MMRS_CONTROL, 4, 5),
+ [F_CONTROL_REPLACE_OID_EN] = REG_FIELD(TI_PAT_MMRS_CONTROL, 1, 1),
+ [F_CONTROL_EN] = REG_FIELD(TI_PAT_MMRS_CONTROL, 0, 0),
+};
+
+/**
+ * struct ti_pat_data - PAT device instance data
+ * @dev: PAT device structure
+ * @mdev: misc device
+ * @mmrs_map: Register map of MMRS region
+ * @table_base: Base address of TABLE region
+ */
+struct ti_pat_data {
+ struct device *dev;
+ struct miscdevice mdev;
+ struct regmap *mmrs_map;
+ struct regmap_field *mmrs_fields[F_MAX_FIELDS];
+ void __iomem *table_base;
+ unsigned int page_count;
+ unsigned int page_size;
+ phys_addr_t window_base;
+ struct gen_pool *pool;
+};
+
+struct ti_pat_dma_buf_attachment {
+ struct device *dev;
+ struct sg_table *table;
+ struct ti_pat_buffer *buffer;
+ struct list_head list;
+};
+
+struct ti_pat_buffer {
+ struct ti_pat_data *pat;
+ struct dma_buf *i_dma_buf;
+ size_t size;
+ unsigned long offset;
+ struct dma_buf *e_dma_b
[RFC PATCH 0/2] Support for TI Page-based Address Translator
to be allocated as contiguous from the start, this leads to a lot of unneeded use of carveout/CMA memory. With this driver on the other hand, we allocate regular non-contiguous system memory (again using DMA-BUF heaps, but ION could work here too), then only when a buffer is about to be sent to the display we pass the handle to this DMA-BUF to our driver here and take the handle it gives back and pass that to the display instead. As said, it is probably not the ideal solution but it does work and was used for some early testing of the IP. Well, sorry for the wall of text. Any and all suggestions very welcome and appreciated. Thanks, Andrew [0] http://www.ti.com/lit/pdf/spruil1 [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c [2] https://lkml.org/lkml/2019/6/6/1211 Andrew F. Davis (2): dt-bindings: soc: ti: Add TI PAT bindings soc: ti: Add Support for the TI Page-based Address Translator (PAT) .../devicetree/bindings/misc/ti,pat.txt | 34 ++ drivers/soc/ti/Kconfig| 9 + drivers/soc/ti/Makefile | 1 + drivers/soc/ti/ti-pat.c | 569 ++ include/uapi/linux/ti-pat.h | 44 ++ 5 files changed, 657 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/ti,pat.txt create mode 100644 drivers/soc/ti/ti-pat.c create mode 100644 include/uapi/linux/ti-pat.h -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 1/2] dt-bindings: soc: ti: Add TI PAT bindings
This patch adds the bindings for the Page-based Address Translator (PAT)
present on various TI SoCs. A Page-based Address Translator (PAT) device
performs address translation using tables stored in an internal SRAM.
Each PAT supports a set number of pages, each occupying a programmable
4KB, 16KB, 64KB, or 1MB of addresses in a window for which an incoming
transaction will be translated.
Signed-off-by: Andrew F. Davis
---
.../devicetree/bindings/misc/ti,pat.txt | 34 +++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/ti,pat.txt
diff --git a/Documentation/devicetree/bindings/misc/ti,pat.txt
b/Documentation/devicetree/bindings/misc/ti,pat.txt
new file mode 100644
index ..fac20d45ad4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/ti,pat.txt
@@ -0,0 +1,34 @@
+Texas Instruments Page-based Address Translator (PAT) driver binding
+
+
+A Page-based Address Translator (PAT) device performs address translation
+using tables stored in an internal SRAM. Each PAT supports a set number of
+pages, each occupying a programmable 4KB, 16KB, 64KB, or 1MB of addresses
+in a window for which an incoming transaction will be translated.
+
+TI-PAT controller Device Node
+=
+
+The TI-PAT node describes the Texas Instrument's Page-based Address
+Translator (PAT).
+
+Required properties:
+---
+- compatible: should be "ti,j721e-pat"
+- reg-names:
+ mmrs - Memory mapped registers region
+ table - Location of the table of translation pages
+ window - Window of memory addresses translated by this PAT
+- reg: register addresses corresponding to the above
+
+Example:
+
+navss_pat0: pat@3101 {
+ compatible = "ti,j721e-pat";
+ reg = <0x00 0x3101 0x00 0x0100>,
+ <0x00 0x3640 0x00 0x0004>,
+ <0x48 0x 0x00 0x4000>;
+ reg-names = "mmrs",
+ "table",
+ "window";
+};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Make mmap callback actually optional
On 4/1/19 2:13 AM, Daniel Vetter wrote:
> On Fri, Mar 29, 2019 at 11:52:01AM -0500, Andrew F. Davis wrote:
>> The docs state the callback is optional but it is not, make it optional.
>>
>> Signed-off-by: Andrew F. Davis
>
> There's a bunch of dummy mmap implementations we could remove with this,
> would be nice to follow up.
>
Was cleaning up some dummy kmap implementations when I found that many
had dummy mmap also, so plan was if this goes in I'll be able to zap
them both in one go. That or actually add valid kmap where appropriate.
Either way will be following up.
Andrew
> Reviewed-by: Daniel Vetter
>
>> ---
>> drivers/dma-buf/dma-buf.c | 11 +--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 7c858020d14b..4d4ae9fe9ac8 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -90,6 +90,10 @@ static int dma_buf_mmap_internal(struct file *file,
>> struct vm_area_struct *vma)
>>
>> dmabuf = file->private_data;
>>
>> +/* check if buffer supports mmap */
>> +if (!dmabuf->ops->mmap)
>> +return -EINVAL;
>> +
>> /* check for overflowing the buffer's size */
>> if (vma->vm_pgoff + vma_pages(vma) >
>> dmabuf->size >> PAGE_SHIFT)
>> @@ -404,8 +408,7 @@ struct dma_buf *dma_buf_export(const struct
>> dma_buf_export_info *exp_info)
>>|| !exp_info->ops
>>|| !exp_info->ops->map_dma_buf
>>|| !exp_info->ops->unmap_dma_buf
>> - || !exp_info->ops->release
>> - || !exp_info->ops->mmap)) {
>> + || !exp_info->ops->release)) {
>> return ERR_PTR(-EINVAL);
>> }
>>
>> @@ -906,6 +909,10 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
>> vm_area_struct *vma,
>> if (WARN_ON(!dmabuf || !vma))
>> return -EINVAL;
>>
>> +/* check if buffer supports mmap */
>> +if (!dmabuf->ops->mmap)
>> +return -EINVAL;
>> +
>> /* check for offset overflow */
>> if (pgoff + vma_pages(vma) < pgoff)
>> return -EOVERFLOW;
>> --
>> 2.21.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: Make mmap callback actually optional
The docs state the callback is optional but it is not, make it optional.
Signed-off-by: Andrew F. Davis
---
drivers/dma-buf/dma-buf.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 7c858020d14b..4d4ae9fe9ac8 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -90,6 +90,10 @@ static int dma_buf_mmap_internal(struct file *file, struct
vm_area_struct *vma)
dmabuf = file->private_data;
+ /* check if buffer supports mmap */
+ if (!dmabuf->ops->mmap)
+ return -EINVAL;
+
/* check for overflowing the buffer's size */
if (vma->vm_pgoff + vma_pages(vma) >
dmabuf->size >> PAGE_SHIFT)
@@ -404,8 +408,7 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
|| !exp_info->ops
|| !exp_info->ops->map_dma_buf
|| !exp_info->ops->unmap_dma_buf
- || !exp_info->ops->release
- || !exp_info->ops->mmap)) {
+ || !exp_info->ops->release)) {
return ERR_PTR(-EINVAL);
}
@@ -906,6 +909,10 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
+ /* check if buffer supports mmap */
+ if (!dmabuf->ops->mmap)
+ return -EINVAL;
+
/* check for offset overflow */
if (pgoff + vma_pages(vma) < pgoff)
return -EOVERFLOW;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 4/6 v3] dma-buf: heaps: Add CMA heap to dmabuf heapss
On 3/28/19 7:16 PM, John Stultz wrote:
> This adds a CMA heap, which allows userspace to allocate
> a dma-buf of contiguous memory out of a CMA region.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original author and maintainters:
> Benjamin Gaignard, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
> Cc: Xu YiPing
> Cc: "Chenfeng (puck)"
> Cc: butao
> Cc: "Xiaqing (A)"
> Cc: Yudongbin
> Cc: Christoph Hellwig
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> v2:
> * Switch allocate to return dmabuf fd
> * Simplify init code
> * Checkpatch fixups
> v3:
> * Switch to inline function for to_cma_heap()
> * Minor cleanups suggested by Brian
> * Fold in new registration style from Andrew
> * Folded in changes from Andrew to use simplified page list
> from the heap helpers
> ---
> drivers/dma-buf/heaps/Kconfig| 8 ++
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/cma_heap.c | 170
> +++
> 3 files changed, 179 insertions(+)
> create mode 100644 drivers/dma-buf/heaps/cma_heap.c
>
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index 2050527..a5eef06 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -4,3 +4,11 @@ config DMABUF_HEAPS_SYSTEM
> help
> Choose this option to enable the system dmabuf heap. The system heap
> is backed by pages from the buddy allocator. If in doubt, say Y.
> +
> +config DMABUF_HEAPS_CMA
> + bool "DMA-BUF CMA Heap"
> + depends on DMABUF_HEAPS && DMA_CMA
> + help
> + Choose this option to enable dma-buf CMA heap. This heap is backed
> + by the Contiguous Memory Allocator (CMA). If your system has these
> + regions, you should say Y here.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index d1808ec..6e54cde 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-y+= heap-helpers.o
> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o
> +obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> b/drivers/dma-buf/heaps/cma_heap.c
> new file mode 100644
> index 000..f4485c60
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -0,0 +1,170 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF CMA heap exporter
> + *
> + * Copyright (C) 2012, 2019 Linaro Ltd.
> + * Author: for ST-Ericsson.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "heap-helpers.h"
> +
> +struct cma_heap {
> + struct dma_heap *heap;
> + struct cma *cma;
> +};
> +
> +static void cma_heap_free(struct heap_helper_buffer *buffer)
> +{
> + struct cma_heap *cma_heap = dma_heap_get_data(buffer->heap_buffer.heap);
> + struct page *pages = buffer->priv_virt;
> + unsigned long nr_pages;
> +
> + nr_pages = buffer->heap_buffer.size >> PAGE_SHIFT;
Could also use the count in helper_buffer->pagecount.
> +
> + /* free page list */
> + kfree(buffer->pages);
> + /* release memory */
> + cma_release(cma_heap->cma, pages, nr_pages);
> + kfree(buffer);
> +}
> +
> +/* dmabuf heap CMA operations functions */
> +static int cma_heap_allocate(struct dma_heap *heap,
> + unsigned long len,
> + unsigned long flags)
> +{
> + struct cma_heap *cma_heap = dma_heap_get_data(heap);
> + struct heap_helper_buffer *helper_buffer;
> + struct page *pages;
> + size_t size = PAGE_ALIGN(len);
> + unsigned long nr_pages = size >> PAGE_SHIFT;
> + unsigned long align = get_order(size);
> + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> + struct dma_buf *dmabuf;
> + int ret = -ENOMEM;
> + pgoff_t pg;
> +
> + if (align > CONFIG_CMA_ALIGNMENT)
> + align = CONFIG_CMA_ALIGNMENT;
> +
> + helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
> + if (!helper_buffer)
> + return -ENOMEM;
> +
> + INIT_HEAP_
[PATCH] drm/nouveau: remove unneeded conversions to bool
Found with scripts/coccinelle/misc/boolconv.cocci.
Signed-off-by: Andrew F. Davis
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 1543c2f8d3d3..c010a7dda618 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -240,7 +240,7 @@ nouveau_ttm_init(struct nouveau_drm *drm)
_bo_driver,
dev->anon_inode->i_mapping,
DRM_FILE_PAGE_OFFSET,
- drm->client.mmu.dmabits <= 32 ? true : false);
+ drm->client.mmu.dmabits <= 32);
if (ret) {
NV_ERROR(drm, "error initialising bo driver, %d\n", ret);
return ret;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 4/6 v3] dma-buf: heaps: Add CMA heap to dmabuf heapss
On 3/29/19 10:30 AM, Benjamin Gaignard wrote:
> Le ven. 29 mars 2019 à 16:19, Andrew F. Davis a écrit :
>>
>> On 3/29/19 9:44 AM, Benjamin Gaignard wrote:
>>> Le ven. 29 mars 2019 à 01:16, John Stultz a écrit :
>>>>
>>>> This adds a CMA heap, which allows userspace to allocate
>>>> a dma-buf of contiguous memory out of a CMA region.
>>>>
>>>> This code is an evolution of the Android ION implementation, so
>>>> thanks to its original author and maintainters:
>>>> Benjamin Gaignard, Laura Abbott, and others!
>>>>
>>>> Cc: Laura Abbott
>>>> Cc: Benjamin Gaignard
>>>> Cc: Sumit Semwal
>>>> Cc: Liam Mark
>>>> Cc: Pratik Patel
>>>> Cc: Brian Starkey
>>>> Cc: Vincent Donnefort
>>>> Cc: Sudipto Paul
>>>> Cc: Andrew F. Davis
>>>> Cc: Xu YiPing
>>>> Cc: "Chenfeng (puck)"
>>>> Cc: butao
>>>> Cc: "Xiaqing (A)"
>>>> Cc: Yudongbin
>>>> Cc: Christoph Hellwig
>>>> Cc: Chenbo Feng
>>>> Cc: Alistair Strachan
>>>> Cc: dri-devel@lists.freedesktop.org
>>>> Signed-off-by: John Stultz
>>>> ---
>>>> v2:
>>>> * Switch allocate to return dmabuf fd
>>>> * Simplify init code
>>>> * Checkpatch fixups
>>>> v3:
>>>> * Switch to inline function for to_cma_heap()
>>>> * Minor cleanups suggested by Brian
>>>> * Fold in new registration style from Andrew
>>>> * Folded in changes from Andrew to use simplified page list
>>>> from the heap helpers
>>>> ---
>>>> drivers/dma-buf/heaps/Kconfig| 8 ++
>>>> drivers/dma-buf/heaps/Makefile | 1 +
>>>> drivers/dma-buf/heaps/cma_heap.c | 170
>>>> +++
>>>> 3 files changed, 179 insertions(+)
>>>> create mode 100644 drivers/dma-buf/heaps/cma_heap.c
>>>>
>>>> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
>>>> index 2050527..a5eef06 100644
>>>> --- a/drivers/dma-buf/heaps/Kconfig
>>>> +++ b/drivers/dma-buf/heaps/Kconfig
>>>> @@ -4,3 +4,11 @@ config DMABUF_HEAPS_SYSTEM
>>>> help
>>>> Choose this option to enable the system dmabuf heap. The system
>>>> heap
>>>> is backed by pages from the buddy allocator. If in doubt, say Y.
>>>> +
>>>> +config DMABUF_HEAPS_CMA
>>>> + bool "DMA-BUF CMA Heap"
>>>> + depends on DMABUF_HEAPS && DMA_CMA
>>>> + help
>>>> + Choose this option to enable dma-buf CMA heap. This heap is
>>>> backed
>>>> + by the Contiguous Memory Allocator (CMA). If your system has
>>>> these
>>>> + regions, you should say Y here.
>>>> diff --git a/drivers/dma-buf/heaps/Makefile
>>>> b/drivers/dma-buf/heaps/Makefile
>>>> index d1808ec..6e54cde 100644
>>>> --- a/drivers/dma-buf/heaps/Makefile
>>>> +++ b/drivers/dma-buf/heaps/Makefile
>>>> @@ -1,3 +1,4 @@
>>>> # SPDX-License-Identifier: GPL-2.0
>>>> obj-y += heap-helpers.o
>>>> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
>>>> +obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
>>>> diff --git a/drivers/dma-buf/heaps/cma_heap.c
>>>> b/drivers/dma-buf/heaps/cma_heap.c
>>>> new file mode 100644
>>>> index 000..f4485c60
>>>> --- /dev/null
>>>> +++ b/drivers/dma-buf/heaps/cma_heap.c
>>>> @@ -0,0 +1,170 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * DMABUF CMA heap exporter
>>>> + *
>>>> + * Copyright (C) 2012, 2019 Linaro Ltd.
>>>> + * Author: for ST-Ericsson.
>>>> + */
>>>> +
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +
>>>> +#include "heap-helpers.h"
>>>> +
>>>> +struct cma_heap {
>>>> + struct dma_heap *heap;
>>>> + struct cma *cma;
>>>> +};
>>>> +
>>>&
Re: [RFC][PATCH 4/6 v3] dma-buf: heaps: Add CMA heap to dmabuf heapss
On 3/29/19 9:44 AM, Benjamin Gaignard wrote:
> Le ven. 29 mars 2019 à 01:16, John Stultz a écrit :
>>
>> This adds a CMA heap, which allows userspace to allocate
>> a dma-buf of contiguous memory out of a CMA region.
>>
>> This code is an evolution of the Android ION implementation, so
>> thanks to its original author and maintainters:
>> Benjamin Gaignard, Laura Abbott, and others!
>>
>> Cc: Laura Abbott
>> Cc: Benjamin Gaignard
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Pratik Patel
>> Cc: Brian Starkey
>> Cc: Vincent Donnefort
>> Cc: Sudipto Paul
>> Cc: Andrew F. Davis
>> Cc: Xu YiPing
>> Cc: "Chenfeng (puck)"
>> Cc: butao
>> Cc: "Xiaqing (A)"
>> Cc: Yudongbin
>> Cc: Christoph Hellwig
>> Cc: Chenbo Feng
>> Cc: Alistair Strachan
>> Cc: dri-devel@lists.freedesktop.org
>> Signed-off-by: John Stultz
>> ---
>> v2:
>> * Switch allocate to return dmabuf fd
>> * Simplify init code
>> * Checkpatch fixups
>> v3:
>> * Switch to inline function for to_cma_heap()
>> * Minor cleanups suggested by Brian
>> * Fold in new registration style from Andrew
>> * Folded in changes from Andrew to use simplified page list
>> from the heap helpers
>> ---
>> drivers/dma-buf/heaps/Kconfig| 8 ++
>> drivers/dma-buf/heaps/Makefile | 1 +
>> drivers/dma-buf/heaps/cma_heap.c | 170
>> +++
>> 3 files changed, 179 insertions(+)
>> create mode 100644 drivers/dma-buf/heaps/cma_heap.c
>>
>> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
>> index 2050527..a5eef06 100644
>> --- a/drivers/dma-buf/heaps/Kconfig
>> +++ b/drivers/dma-buf/heaps/Kconfig
>> @@ -4,3 +4,11 @@ config DMABUF_HEAPS_SYSTEM
>> help
>> Choose this option to enable the system dmabuf heap. The system
>> heap
>> is backed by pages from the buddy allocator. If in doubt, say Y.
>> +
>> +config DMABUF_HEAPS_CMA
>> + bool "DMA-BUF CMA Heap"
>> + depends on DMABUF_HEAPS && DMA_CMA
>> + help
>> + Choose this option to enable dma-buf CMA heap. This heap is backed
>> + by the Contiguous Memory Allocator (CMA). If your system has these
>> + regions, you should say Y here.
>> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
>> index d1808ec..6e54cde 100644
>> --- a/drivers/dma-buf/heaps/Makefile
>> +++ b/drivers/dma-buf/heaps/Makefile
>> @@ -1,3 +1,4 @@
>> # SPDX-License-Identifier: GPL-2.0
>> obj-y += heap-helpers.o
>> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
>> +obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
>> diff --git a/drivers/dma-buf/heaps/cma_heap.c
>> b/drivers/dma-buf/heaps/cma_heap.c
>> new file mode 100644
>> index 000..f4485c60
>> --- /dev/null
>> +++ b/drivers/dma-buf/heaps/cma_heap.c
>> @@ -0,0 +1,170 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * DMABUF CMA heap exporter
>> + *
>> + * Copyright (C) 2012, 2019 Linaro Ltd.
>> + * Author: for ST-Ericsson.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "heap-helpers.h"
>> +
>> +struct cma_heap {
>> + struct dma_heap *heap;
>> + struct cma *cma;
>> +};
>> +
>> +static void cma_heap_free(struct heap_helper_buffer *buffer)
>> +{
>> + struct cma_heap *cma_heap =
>> dma_heap_get_data(buffer->heap_buffer.heap);
>> + struct page *pages = buffer->priv_virt;
>> + unsigned long nr_pages;
>> +
>> + nr_pages = buffer->heap_buffer.size >> PAGE_SHIFT;
>> +
>> + /* free page list */
>> + kfree(buffer->pages);
>> + /* release memory */
>> + cma_release(cma_heap->cma, pages, nr_pages);
>> + kfree(buffer);
>> +}
>> +
>> +/* dmabuf heap CMA operations functions */
>> +static int cma_heap_allocate(struct dma_heap *heap,
>> + unsigned long len,
>> + unsigned long flags)
>> +{
>> + struct cma_heap *cma_heap = dma_heap_get_data(heap);
>> + struct heap_helper_buffer *helper_buffer;
>> + str
Re: [RFC][PATCH 2/6 v3] dma-buf: heaps: Add heap helpers
On 3/28/19 7:15 PM, John Stultz wrote:
> Add generic helper dmabuf ops for dma heaps, so we can reduce
> the amount of duplicative code for the exported dmabufs.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original authors and maintainters:
> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
> Cc: Xu YiPing
> Cc: "Chenfeng (puck)"
> Cc: butao
> Cc: "Xiaqing (A)"
> Cc: Yudongbin
> Cc: Christoph Hellwig
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> v2:
> * Removed cache management performance hack that I had
> accidentally folded in.
> * Removed stats code that was in helpers
> * Lots of checkpatch cleanups
>
> v3:
> * Uninline INIT_HEAP_HELPER_BUFFER (suggested by Christoph)
> * Switch to WARN on buffer destroy failure (suggested by Brian)
> * buffer->kmap_cnt decrementing cleanup (suggested by Christoph)
> * Extra buffer->vaddr checking in dma_heap_dma_buf_kmap
> (suggested by Brian)
> * Switch to_helper_buffer from macro to inline function
> (suggested by Benjamin)
> * Rename kmap->vmap (folded in from Andrew)
> * Use vmap for vmapping - not begin_cpu_access (folded in from
> Andrew)
> * Drop kmap for now, as its optional (folded in from Andrew)
> * Fold dma_heap_map_user into the single caller (foled in from
> Andrew)
> * Folded in patch from Andrew to track page list per heap not
> sglist, which simplifies the tracking logic
> ---
> drivers/dma-buf/Makefile | 1 +
> drivers/dma-buf/heaps/Makefile | 2 +
> drivers/dma-buf/heaps/heap-helpers.c | 261
> +++
> drivers/dma-buf/heaps/heap-helpers.h | 55
> include/linux/dma-heap.h | 14 +-
> 5 files changed, 320 insertions(+), 13 deletions(-)
> create mode 100644 drivers/dma-buf/heaps/Makefile
> create mode 100644 drivers/dma-buf/heaps/heap-helpers.c
> create mode 100644 drivers/dma-buf/heaps/heap-helpers.h
>
> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
> index b0332f1..09c2f2d 100644
> --- a/drivers/dma-buf/Makefile
> +++ b/drivers/dma-buf/Makefile
> @@ -1,4 +1,5 @@
> obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
> +obj-$(CONFIG_DMABUF_HEAPS) += heaps/
> obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
> obj-$(CONFIG_SYNC_FILE) += sync_file.o
> obj-$(CONFIG_SW_SYNC)+= sw_sync.o sync_debug.o
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> new file mode 100644
> index 000..de49898
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +obj-y+= heap-helpers.o
> diff --git a/drivers/dma-buf/heaps/heap-helpers.c
> b/drivers/dma-buf/heaps/heap-helpers.c
> new file mode 100644
> index 000..00cbdbb
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/heap-helpers.c
> @@ -0,0 +1,261 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "heap-helpers.h"
> +
> +void INIT_HEAP_HELPER_BUFFER(struct heap_helper_buffer *buffer,
> + void (*free)(struct heap_helper_buffer *))
> +{
> + buffer->private_flags = 0;
> + buffer->priv_virt = NULL;
> + mutex_init(>lock);
> + buffer->vmap_cnt = 0;
> + buffer->vaddr = NULL;
> + INIT_LIST_HEAD(>attachments);
> + buffer->free = free;
> +}
> +
> +
> +static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
> +{
> + void *vaddr;
> +
> + vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, PAGE_KERNEL);
> + if (!vaddr)
> + return ERR_PTR(-ENOMEM);
> +
> + return vaddr;
> +}
> +
> +void dma_heap_buffer_destroy(struct dma_heap_buffer *heap_buffer)
> +{
> + struct heap_helper_buffer *buffer = to_helper_buffer(heap_buffer);
> +
> + if (buffer->vmap_cnt > 0) {
> + WARN("%s: buffer still mapped in the kernel\n",
> + __func__);
> + vunmap(buffer->vaddr);
> + }
> +
> + buffer->free(buffer);
> +}
> +
> +static void *dma_heap_buffer_vmap_get(struct dma_heap_buffer *heap
Re: [RFC][PATCH 0/6 v3] DMA-BUF Heaps (destaging ION)
On 3/28/19 7:15 PM, John Stultz wrote:
> Here is another RFC of the dma-buf heaps patchset Andrew and I
> have been working on which tries to destage a fair chunk of ION
> functionality.
>
> The patchset implements per-heap devices which can be opened
> directly and then an ioctl is used to allocate a dmabuf from the
> heap.
>
> The interface is similar, but much simpler then IONs, only
> providing an ALLOC ioctl.
>
> Also, I've provided simple system and cma heaps. The system
> heap in particular is missing the page-pool optimizations ION
> had, but works well enough to validate the interface.
>
> I've booted and tested these patches with AOSP on the HiKey960
> using the kernel tree here:
>
> https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap
>
> And the userspace changes here:
> https://android-review.googlesource.com/c/device/linaro/hikey/+/909436
>
>
> Compared to ION, this patchset is missing the system-contig,
> carveout and chunk heaps, as I don't have a device that uses
> those, so I'm unable to do much useful validation there.
> Additionally we have no upstream users of chunk or carveout,
> and the system-contig has been deprecated in the common/andoid-*
> kernels, so this should be ok.
>
I'd like to go over my use-cases for a moment to see if we can get some
agreement on what to do with the carveout/chunk heaps.
We used DRM (omapdrm) to get buffers for display, GPU, and multi-media.
Our out-of-tree CMEM driver[0] for remote processing (OpenCL/CV/VX)
buffers. And for secure heaps we use what are basically slightly
modified ION carveout heaps.
Now with the DMA-Heap framework what we can do is for sub-systems with
IOMMUs use 'system' heap (GPU). For those that need contiguous memory
(display, MM) we have 'cma' heap (and maybe 'system-contig' at some
point). For our SRAM areas used in remote processing I've posted an RFC
for a heap[1] to provide allocations from those areas.
The above leaves one last gap for us, uncached/unmapped areas from
regular memory. I propose this is where we use the 'carveout' heap.
Right now to get some contiguous/cached memory with DT you can:
reserved-memory {
[...]
cma_memory {
compatible = "shared-dma-pool";
reg = <0x7900 0x40>;
reusable;
};
coherent_memory@7800 {
reg = <0x7800 0x80>;
no-map;
};
};
'cma_memory' will show up as a 'cma' heap, so all good there.
Looking at 'coherent_memory' it will not have valid backing 'struct
page' and so cannot be given cached mappings as the standard dma memory
ops would fail. This would give this area the right properties for both
users who don't want to do all the cache maintenance ops (Liam?) and for
secure heaps that have restrictions on access from Linux running CPU.
The question then is how to mark these areas for export with DMA-Heaps?
Maybe a cma_for_each_area() like function but for dma coherent areas?
Anyway for now this is not super important and I can post a patchset at
some later point for this when I get it working and tested internally.
[0]
http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_CMEM.html
[1] https://patchwork.kernel.org/patch/10863957/
Thanks,
Andrew
> I've also removed the stats accounting for now, since it should
> be implemented by the heaps themselves.
>
>
> New in v3:
> * Proper /dev/heap/* names on both Android and classic Linux
> environments
> * Major rework of the helper code from Andrew
> * Dummy test device added to test importing
> * *Lots* of cleanups suggested by many (thank you for all the
> input)!
>
>
> Outstanding concerns:
> * Potential need for private flags in interface for secure
> heaps. Need to better understand secure heap usage.
> * Making sure the performance issues from potentially unnecessary
> cache-management operations can be resolved properly for system
> and cma heaps (outstanding issue from ION).
>
>
> Eventual TODOS:
> * Sanity filtering for heap names
> * Reimplement performance optimizations for system heap
> * Add stats accounting to system/cma heaps
> * Make the kselftest more useful
> * Add other heaps folks see as useful (would love to get
> some help from actual carveout/chunk users)!
>
> That said, the main user-interface is shaping up and I wanted
> to get some input on the device model (particularly from GreKH)
> and any other API/ABI specific input.
>
> thanks
> -john
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
Re: [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers
On 3/5/19 2:54 PM, John Stultz wrote:
> Add generic helper dmabuf ops for dma heaps, so we can reduce
> the amount of duplicative code for the exported dmabufs.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original authors and maintainters:
> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Greg KH
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Brian Starkey
> Cc: Andrew F. Davis
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> v2:
> * Removed cache management performance hack that I had
> accidentally folded in.
> * Removed stats code that was in helpers
> * Lots of checkpatch cleanups
> ---
> drivers/dma-buf/Makefile | 1 +
> drivers/dma-buf/heaps/Makefile | 2 +
> drivers/dma-buf/heaps/heap-helpers.c | 335
> +++
> drivers/dma-buf/heaps/heap-helpers.h | 48 +
> 4 files changed, 386 insertions(+)
> create mode 100644 drivers/dma-buf/heaps/Makefile
> create mode 100644 drivers/dma-buf/heaps/heap-helpers.c
> create mode 100644 drivers/dma-buf/heaps/heap-helpers.h
>
> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
> index b0332f1..09c2f2d 100644
> --- a/drivers/dma-buf/Makefile
> +++ b/drivers/dma-buf/Makefile
> @@ -1,4 +1,5 @@
> obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
> +obj-$(CONFIG_DMABUF_HEAPS) += heaps/
> obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
> obj-$(CONFIG_SYNC_FILE) += sync_file.o
> obj-$(CONFIG_SW_SYNC)+= sw_sync.o sync_debug.o
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> new file mode 100644
> index 000..de49898
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +obj-y+= heap-helpers.o
> diff --git a/drivers/dma-buf/heaps/heap-helpers.c
> b/drivers/dma-buf/heaps/heap-helpers.c
> new file mode 100644
> index 000..ae5e9d0
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/heap-helpers.c
> @@ -0,0 +1,335 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "heap-helpers.h"
> +
> +
> +static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
> +{
> + struct scatterlist *sg;
> + int i, j;
> + void *vaddr;
> + pgprot_t pgprot;
> + struct sg_table *table = buffer->sg_table;
> + int npages = PAGE_ALIGN(buffer->heap_buffer.size) / PAGE_SIZE;
> + struct page **pages = vmalloc(array_size(npages,
> + sizeof(struct page *)));
> + struct page **tmp = pages;
> +
> + if (!pages)
> + return ERR_PTR(-ENOMEM);
> +
> + pgprot = PAGE_KERNEL;
> +
> + for_each_sg(table->sgl, sg, table->nents, i) {
> + int npages_this_entry = PAGE_ALIGN(sg->length) / PAGE_SIZE;
> + struct page *page = sg_page(sg);
> +
> + WARN_ON(i >= npages);
> + for (j = 0; j < npages_this_entry; j++)
> + *(tmp++) = page++;
> + }
> + vaddr = vmap(pages, npages, VM_MAP, pgprot);
> + vfree(pages);
> +
> + if (!vaddr)
> + return ERR_PTR(-ENOMEM);
> +
> + return vaddr;
> +}
> +
> +static int dma_heap_map_user(struct heap_helper_buffer *buffer,
> + struct vm_area_struct *vma)
> +{
> + struct sg_table *table = buffer->sg_table;
> + unsigned long addr = vma->vm_start;
> + unsigned long offset = vma->vm_pgoff * PAGE_SIZE;
> + struct scatterlist *sg;
> + int i;
> + int ret;
> +
> + for_each_sg(table->sgl, sg, table->nents, i) {
> + struct page *page = sg_page(sg);
> + unsigned long remainder = vma->vm_end - addr;
> + unsigned long len = sg->length;
> +
> + if (offset >= sg->length) {
> + offset -= sg->length;
> + continue;
> + } else if (offset) {
> + page += offset / PAGE_SIZE;
> + len = sg->length - offset;
> + offset = 0;
> + }
> + len = min(len, remainder);
> + ret = remap_pfn_range(vma, addr, page_to_pfn(page), len,
> + vma->v
Re: [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers
On 3/19/19 9:26 AM, Brian Starkey wrote:
> Hi John,
>
> On Tue, Mar 05, 2019 at 12:54:30PM -0800, John Stultz wrote:
>
> ...
>
>> +
>> +void dma_heap_buffer_destroy(struct dma_heap_buffer *heap_buffer)
>> +{
>> +struct heap_helper_buffer *buffer = to_helper_buffer(heap_buffer);
>> +
>> +if (buffer->kmap_cnt > 0) {
>> +pr_warn_once("%s: buffer still mapped in the kernel\n",
>> + __func__);
>
> Could be worth something louder like a full WARN.
>
>> +vunmap(buffer->vaddr);
>> +}
>> +
>> +buffer->free(buffer);
>> +}
>> +
>
> ...
>
>> +
>> +static void *dma_heap_dma_buf_kmap(struct dma_buf *dmabuf,
>> +unsigned long offset)
>> +{
>> +struct dma_heap_buffer *heap_buffer = dmabuf->priv;
>> +struct heap_helper_buffer *buffer = to_helper_buffer(heap_buffer);
>> +
>> +return buffer->vaddr + offset * PAGE_SIZE;
>
> I think it'd be good to check for NULL vaddr and return NULL in that
> case. Less chance of an invalid pointer being accidentally used then.
>
Why do we assume vaddr is set at all here? I'm guessing we expected
dma_heap_map_kernel to have been called, that is not going to always be
the case. kmap should perform it's own single page kmap here and not
rely on the clunky full buffer vmap (which is probably broken on 32bit
systems here when the buffers are large).
Andrew
> Thanks,
> -Brian
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dma-buf: Remove leftover [un]map_atomic comments
The map_atomic/unmap_atomic callbacks have been removed, remove
the related comments.
Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
Signed-off-by: Andrew F. Davis
---
include/linux/dma-buf.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 58725f890b5b..e4a8dab2bc54 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -39,11 +39,6 @@ struct dma_buf_attachment;
/**
* struct dma_buf_ops - operations possible on struct dma_buf
- * @map_atomic: [optional] maps a page from the buffer into kernel address
- * space, users may not block until the subsequent unmap call.
- * This callback must not sleep.
- * @unmap_atomic: [optional] unmaps a atomically mapped page from the buffer.
- * This Callback must not sleep.
* @map: [optional] maps a page from the buffer into kernel address space.
* @unmap: [optional] unmaps a page from the buffer.
* @vmap: [optional] creates a virtual mapping for the buffer into kernel
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] dma-buf: Update [un]map documentation to match the other functions
Other function have inline documentation, a couple still have
theirs at the top of the structure, update the docs and move
them inline.
Signed-off-by: Andrew F. Davis
---
include/linux/dma-buf.h | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index e4a8dab2bc54..a0bd071466fc 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -39,8 +39,6 @@ struct dma_buf_attachment;
/**
* struct dma_buf_ops - operations possible on struct dma_buf
- * @map: [optional] maps a page from the buffer into kernel address space.
- * @unmap: [optional] unmaps a page from the buffer.
* @vmap: [optional] creates a virtual mapping for the buffer into kernel
* address space. Same restrictions as for vmap and friends apply.
* @vunmap: [optional] unmaps a vmap from the buffer
@@ -200,8 +198,6 @@ struct dma_buf_ops {
* to be restarted.
*/
int (*end_cpu_access)(struct dma_buf *, enum dma_data_direction);
- void *(*map)(struct dma_buf *, unsigned long);
- void (*unmap)(struct dma_buf *, unsigned long, void *);
/**
* @mmap:
@@ -240,6 +236,31 @@ struct dma_buf_ops {
*/
int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
+ /**
+* @map:
+*
+* Maps a page from the buffer into kernel address space. The page is
+* specified by offset into the buffer in PAGE_SIZE units.
+*
+* This callback is optional.
+*
+* Returns:
+*
+* Virtual address pointer where requested page can be accessed. NULL
+* on error or when this function is unimplemented by the exporter.
+*/
+ void *(*map)(struct dma_buf *, unsigned long);
+
+ /**
+* @unmap:
+*
+* Unmaps a page from the buffer. Page offset and address pointer should
+* be the same as the one passed to and returned by matching call to
map.
+*
+* This callback is optional.
+*/
+ void (*unmap)(struct dma_buf *, unsigned long, void *);
+
void *(*vmap)(struct dma_buf *);
void (*vunmap)(struct dma_buf *, void *vaddr);
};
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH] misc: sram: Add dma-heap-export reserved SRAM area type
This new export type exposes to userspace the SRAM area as a DMA-Heap,
this allows for allocations as DMA-BUFs that can be consumed by various
DMA-BUF supporting devices.
Signed-off-by: Andrew F. Davis
---
Hello all,
This is an example user of the currently RFC DMA-HEAP framework. It
exports a defined SRAM area showing how various memory presenting
devices can use the DMA-HEAP framework to provide DMA-BUF allocations
to userspace and other devices.
It has a couple problems still, one being that the SRAM subsystem
probes before the DMA-BUF subsystem, can the SRAM driver be changed
from postcore_initcall to subsys_initcall or even device_initcall?
Thanks,
Andrew
.../devicetree/bindings/sram/sram.txt | 7 +-
drivers/misc/Kconfig | 7 +
drivers/misc/Makefile | 1 +
drivers/misc/sram-dma-heap.c | 235 ++
drivers/misc/sram.c | 20 +-
drivers/misc/sram.h | 17 ++
6 files changed, 282 insertions(+), 5 deletions(-)
create mode 100644 drivers/misc/sram-dma-heap.c
diff --git a/Documentation/devicetree/bindings/sram/sram.txt
b/Documentation/devicetree/bindings/sram/sram.txt
index e98908bd4227..c5584f1f6ae8 100644
--- a/Documentation/devicetree/bindings/sram/sram.txt
+++ b/Documentation/devicetree/bindings/sram/sram.txt
@@ -43,11 +43,16 @@ Optional properties in the area nodes:
- export : indicates that the reserved SRAM area may be accessed outside
of the kernel, e.g. by bootloader or userspace
- protect-exec : Same as 'pool' above but with the additional
-constraint that code wil be run from the region and
+constraint that code will be run from the region and
that the memory is maintained as read-only, executable
during code execution. NOTE: This region must be page
aligned on start and end in order to properly allow
manipulation of the page attributes.
+- dma-heap-export : Similar to 'pool' and 'export' this region will be
+ exported for use by drivers, devices, and userspace
+ using the DMA-Heaps framework. NOTE: This region must
+ be page aligned on start and end in order to properly
+ allow manipulation of the page attributes.
- label : the name for the reserved partition, if omitted, the label
is taken from the node name excluding the unit address.
- clocks : a list of phandle and clock specifier pair that controls the
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 42ab8ec92a04..5e655890458d 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -487,6 +487,13 @@ config SRAM
config SRAM_EXEC
bool
+config SRAM_DMA_HEAP
+ bool "Export on-chip SRAM pools using DMA-Heaps"
+ depends on SRAM
+ help
+ This driver allows the export of on-chip SRAM marked as exportable
+ to userspace using the DMA-Heaps interface.
+
config VEXPRESS_SYSCFG
bool "Versatile Express System Configuration driver"
depends on VEXPRESS_CONFIG
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d5b7d3404dc7..f9db5326e0f7 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
obj-$(CONFIG_SRAM) += sram.o
obj-$(CONFIG_SRAM_EXEC)+= sram-exec.o
+obj-$(CONFIG_SRAM_DMA_HEAP)+= sram-dma-heap.o
obj-y += mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
diff --git a/drivers/misc/sram-dma-heap.c b/drivers/misc/sram-dma-heap.c
new file mode 100644
index ..bc930fced648
--- /dev/null
+++ b/drivers/misc/sram-dma-heap.c
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SRAM DMA-Heaps userspace exporter
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sram.h"
+
+struct sram_dma_heap {
+ struct dma_heap heap;
+ struct gen_pool *pool;
+};
+
+struct sram_dma_heap_buffer {
+ struct gen_pool *pool;
+ struct list_head attachments;
+ struct mutex attachments_lock;
+ unsigned long len;
+ unsigned long vaddr;
+ phys_addr_t paddr;
+};
+
+struct dma_heaps_attachment {
+ struct device *dev;
+ struct sg_table *table;
+ struct list_head list;
+};
+
+static int dma_heap_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct sram_dma_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heaps_attachment *a;
+ struct sg_table *ta
Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)
On 3/20/19 4:16 AM, Benjamin Gaignard wrote: > Le mar. 19 mars 2019 à 23:36, John Stultz a écrit : >> >> On Tue, Mar 19, 2019 at 2:58 PM Rob Clark wrote: >>> >>> On Tue, Mar 19, 2019 at 1:00 PM Andrew F. Davis wrote: >>>> >>>> On 3/19/19 11:54 AM, Benjamin Gaignard wrote: >>>>> Le mer. 13 mars 2019 à 23:31, John Stultz a >>>>> écrit : >>>>>> >>>>>> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark wrote: >>>>>>> On Tue, 5 Mar 2019, John Stultz wrote: >>>>>>>> >>>>>>>> Eventual TODOS: >>>>>>>> * Reimplement page-pool for system heap (working on this) >>>>>>>> * Add stats accounting to system/cma heaps >>>>>>>> * Make the kselftest actually useful >>>>>>>> * Add other heaps folks see as useful (would love to get >>>>>>>> some help from actual carveout/chunk users)! >>>>>>> >>>>>>> We use a modified carveout heap for certain secure use cases. >>>>>> >>>>>> Cool! It would be great to see if you have any concerns about adding >>>>>> such a secure-carveout heap to this framework. I suspect it would be >>>>>> fairly similar to how its integrated into ION, but particularly I'd be >>>>>> interested in issues around the lack of private flags and other >>>>>> allocation arguments like alignment. >>>>>> >>>>>>> Although there would probably be some benefit in discssing how the >>>>>>> dma-buf >>>>>>> heap framework may want to support >>>>>>> secure heaps in the future it is a large topic which I assume you don't >>>>>>> want to tackle now. >>>>>> >>>>>> So I suspect others (Benjamin?) would have a more informed opinion on >>>>>> the details, but the intent is to allow secure heap implementations. >>>>>> I'm not sure what areas of concern you have for this allocation >>>>>> framework in particular? >>>>> >>>>> yes I would be great to understand how you provide the information to >>>>> tell that a dmabuf >>>>> is secure (or not) since we can't add flag in dmabuf structure itself. >>>>> An option is manage >>>>> the access rights when a device attach itself to the dmabuf but in >>>>> this case you need define >>>>> a list of allowed devices per heap... >>>>> If you have a good solution for secure heaps you are welcome :-) >>>>> >>>> >>>> Do we really need any of that? A secure buffer is secured by the >>>> hardware firewalls that keep out certain IP (including often the >>>> processor running Linux). So the only thing we need to track internally >>>> is that we should not allow mmap/kmap on the buffer. That can be done in >>>> the per-heap layer, everything else stays the same as a standard >>>> carveout heap. >>> >>> For at least some hw the importing driver needs to configure things >>> differently for secure buffers :-/ >> >> Does the import ioctl need/use a flag for that then? Userland already >> has to keep meta-data about dmabufs around. > > To secure a buffer you need to know who is allowed to write/read it and > hardware block involved in the dataflow may need to know that the buffer > is secure to configure themself. > As example for a video decoding you allow hw video decoder to read in > a buffer and display to read it. You can also allow cpu to write on the buffer > to add subtitles. For that we need to be able to mmap/kmap the buffer. > Using a carveout heap for secure buffer mean that you reserved a large > memory region only for this purpose, that isn't possible on embedded device > where we are always limited in memory so we use CMA. > In the past I have used dmabuf's attach function to know who write into > the buffer and then configure who will be able to read it. It was working well > but the issue was how to in generic way this behavior. > Okay, I think I see what you are saying now. The way we handle secure playback is to firewall everything upfront and it is up to the application to inform the hardware about what it can and cannot do to the buffer, or simply not ask anything not allowed (E.g. writeback the decrypted stream) else it will get a firewall exception. The buffer itself doesn't have to carry any information. It sounds like you want the hardware driver to be able to detect the use-case based on the buffer itself and configure itself accordingly? Or the exporter at attach time to check access permissions? The first would need a change to DMA-BUF framework, maybe an added flag. The second would just need a heap exporter with the system wide smarts, but as you say that is not very generic.. Andrew >> >> thanks >> -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)
On 3/19/19 11:54 AM, Benjamin Gaignard wrote: > Le mer. 13 mars 2019 à 23:31, John Stultz a écrit : >> >> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark wrote: >>> On Tue, 5 Mar 2019, John Stultz wrote: Eventual TODOS: * Reimplement page-pool for system heap (working on this) * Add stats accounting to system/cma heaps * Make the kselftest actually useful * Add other heaps folks see as useful (would love to get some help from actual carveout/chunk users)! >>> >>> We use a modified carveout heap for certain secure use cases. >> >> Cool! It would be great to see if you have any concerns about adding >> such a secure-carveout heap to this framework. I suspect it would be >> fairly similar to how its integrated into ION, but particularly I'd be >> interested in issues around the lack of private flags and other >> allocation arguments like alignment. >> >>> Although there would probably be some benefit in discssing how the dma-buf >>> heap framework may want to support >>> secure heaps in the future it is a large topic which I assume you don't >>> want to tackle now. >> >> So I suspect others (Benjamin?) would have a more informed opinion on >> the details, but the intent is to allow secure heap implementations. >> I'm not sure what areas of concern you have for this allocation >> framework in particular? > > yes I would be great to understand how you provide the information to > tell that a dmabuf > is secure (or not) since we can't add flag in dmabuf structure itself. > An option is manage > the access rights when a device attach itself to the dmabuf but in > this case you need define > a list of allowed devices per heap... > If you have a good solution for secure heaps you are welcome :-) > Do we really need any of that? A secure buffer is secured by the hardware firewalls that keep out certain IP (including often the processor running Linux). So the only thing we need to track internally is that we should not allow mmap/kmap on the buffer. That can be done in the per-heap layer, everything else stays the same as a standard carveout heap. Andrew > Benjamin >> >>> We don't have any non-secure carveout heap use cases but the client use >>> case I have seen usually revolve around >>> wanting large allocations to succeed very quickly. >>> For example I have seen camera use cases which do very large allocations >>> on camera bootup from the carveout heap, these allocations would come from >>> the carveout heap and fallback to the system heap when the carveout heap >>> was full. >>> Actual non-secure carveout heap can perhaps provide more detail. >> >> Yea, I'm aware that folks still see carveout as preferable to CMA due >> to more consistent/predictable allocation latency. I think we still >> have the issue that we don't have bindings to establish/configure >> carveout regions w/ dts, and I'm not really wanting to hold up the >> allocation API on that issue. >> >> >>> Since we are making some fundamental changes to how ION worked and since >>> Android is likely also be the largest user of the dma-buf heaps framework >>> I think it would be good >>> to have a path to resolve the issues which are currently preventing >>> commercial Android releases from moving to the upstream version of ION. >> >> Yea, I do see solving the cache management efficiency issues as >> critical for the dmabuf heaps to be actually usable (my previous >> version of this patchset accidentally had my hacks to improve >> performance rolled in!). And there are discussions going on in >> various channels to try to figure out how to either change Android to >> use dma-bufs more in line with how upstream expects, or what more >> generic dma-buf changes we may need to allow Android to use dmabufs >> with the expected performance they need. >> >>> I can understand if you don't necessarily want to put all/any of these >>> changes into the dma-buf heaps framework as part of this series, but my >>> hope is we can get >>> the upstream community and the Android framework team to agree on what >>> upstreamable changes to dma-buf heaps framework, and/or the Android >>> framework, would be required in order for Android to move to the upstream >>> dma-buf heaps framework for commercial devices. >> >> Yes. Though I also don't want to get the bigger dma-buf usage >> discussion (which really affects all dmabuf exporters) too tied up >> with this patch sets attempt to provide a usable allocation interface. >> Part of the problem that I think we've seen with ION is that there is >> a nest of of related issues, and the entire thing is just too big to >> address at once, which I think is part of why ION has sat in staging >> for so long. This patchset just tries to provide an dmabuf allocation >> interface, and a few example exporter heap types. >> >>> I don't mean to make this specific to Android, but my assumption is that >>> many of the ION/dma-buf heaps issues which affect Android would likely >>> affect other new large
Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework
On 3/19/19 7:08 AM, Brian Starkey wrote:
> Hi John,
>
> On Tue, Mar 05, 2019 at 12:54:29PM -0800, John Stultz wrote:
>> From: "Andrew F. Davis"
>
> [snip]
>
>> +
>> +#define NUM_HEAP_MINORS 128
>> +static DEFINE_IDR(dma_heap_idr);
>> +static DEFINE_MUTEX(minor_lock); /* Protect idr accesses */
>
> I saw that Matthew Wilcox is trying to nuke idr:
> https://patchwork.freedesktop.org/series/57073/
>
> Perhaps a different data structure could be considered? (I don't have
> an informed opinion on which).
>
Looks like XArray is the suggested replacement. Should be easy enough,
the minor number would just index to our heap struct directly, I'll give
it a shot and see.
>> +
>> +dev_t dma_heap_devt;
>> +struct class *dma_heap_class;
>> +struct list_head dma_heap_list;
>> +struct dentry *dma_heap_debug_root;
>> +
>> +static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
>> + unsigned int flags)
>> +{
>> +len = PAGE_ALIGN(len);
>> +if (!len)
>> +return -EINVAL;
>
> I think aligning len to pages only makes sense if heaps are going to
> allocate aligned to pages too. Perhaps that's an implicit assumption?
> If so, lets document it.
>
> Why not let the heaps take care of aligning len however they want
> though?
>
This is how I originally had it, but I think we couldn't find any case
where you would want an the start or end of a buffer to not fall on a
page boundary here. It would only lead to problems. As you say though,
nothing keeping us from moving that into the heaps themselves.
> ...
>
>> +
>> +int dma_heap_add(struct dma_heap *heap)
>> +{
>> +struct device *dev_ret;
>> +int ret;
>> +
>> +if (!heap->name || !strcmp(heap->name, "")) {
>> +pr_err("dma_heap: Cannot add heap without a name\n");
>> +return -EINVAL;
>> +}
>> +
>> +if (!heap->ops || !heap->ops->allocate) {
>> +pr_err("dma_heap: Cannot add heap with invalid ops struct\n");
>> +return -EINVAL;
>> +}
>> +
>> +/* Find unused minor number */
>> +mutex_lock(_lock);
>> +ret = idr_alloc(_heap_idr, heap, 0, NUM_HEAP_MINORS, GFP_KERNEL);
>> +mutex_unlock(_lock);
>> +if (ret < 0) {
>> +pr_err("dma_heap: Unable to get minor number for heap\n");
>> +return ret;
>> +}
>> +heap->minor = ret;
>> +
>> +/* Create device */
>> +heap->heap_devt = MKDEV(MAJOR(dma_heap_devt), heap->minor);
>> +dev_ret = device_create(dma_heap_class,
>> +NULL,
>> +heap->heap_devt,
>> +NULL,
>> +heap->name);
>> +if (IS_ERR(dev_ret)) {
>> +pr_err("dma_heap: Unable to create char device\n");
>> +return PTR_ERR(dev_ret);
>> +}
>> +
>> +/* Add device */
>> +cdev_init(>heap_cdev, _heap_fops);
>> +ret = cdev_add(>heap_cdev, dma_heap_devt, NUM_HEAP_MINORS);
>
> Shouldn't this be s/dma_heap_devt/heap->heap_devt/ and a count of 1?
>
Hmm, strange this ever worked before..
> Also would it be better to have cdev_add/device_create the other way
> around? First create the char device, then once it's all set up
> register it with sysfs.
>
Yes that does seem to be more common, lets flip it.
>> +if (ret < 0) {
>> +device_destroy(dma_heap_class, heap->heap_devt);
>> +pr_err("dma_heap: Unable to add char device\n");
>> +return ret;
>> +}
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(dma_heap_add);
>
> Until we've figured out how modules are going to work, I still think
> it would be a good idea to not export this.
>
Agree.
Andrew
> Cheers,
> -Brian
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers
On 3/15/19 4:06 AM, Christoph Hellwig wrote: >> +ret = remap_pfn_range(vma, addr, page_to_pfn(page), len, >> + vma->vm_page_prot); > > So the same chunk could be mapped to userspace and vmap, and later on > also DMA mapped. Who is going to take care of cache aliasing as I > see nothing of that in this series? > We should only have one type of memory per heap so all mappings will have the same type. That should solve the ARM specific issues, but I'm guessing you are thinking of more tricky architectures where all mappings need to be tracked and cleaned/invalidated.. For that I think we will have to track each right? How do others handle that, we can't be the first to offer cached buffers to userspace. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework
On 3/15/19 3:18 PM, Laura Abbott wrote: > On 3/5/19 12:54 PM, John Stultz wrote: >> +DMA-BUF HEAPS FRAMEWORK >> +M: Laura Abbott >> +R: Liam Mark >> +R: Brian Starkey >> +R: "Andrew F. Davis" >> +R: John Stultz >> +S: Maintained >> +L: linux-me...@vger.kernel.org >> +L: dri-devel@lists.freedesktop.org >> +L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) >> +F: include/uapi/linux/dma-heap.h >> +F: include/linux/dma-heap.h >> +F: drivers/dma-buf/dma-heap.c >> +F: drivers/dma-buf/heaps/* >> +T: git git://anongit.freedesktop.org/drm/drm-misc > > So I talked about this with Sumit privately but I think > it might make sense to have me step down as maintainer when > this goes out of staging. I mostly worked on Ion at my > previous position and anything I do now is mostly a side > project. I still want to see it succeed which is why I > took on the maintainer role but I don't want to become blocking > for people who have a stronger vision about where this needs > to go (see also, I'm not working with this on a daily basis). > > If you just want someone to help review or take patches > to be pulled, I'm happy to do so but I'd hate to become > the bottleneck on getting things done for people who > are attempting to do real work. > We could consider this as an "ION inspired" framework, and treat it like an extension of DMA-BUF. In which case Sumit could become the default Maintainer if he's up for it. Andrew > Thanks, > Laura ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework
On 3/15/19 3:54 AM, Christoph Hellwig wrote:
>> +static int dma_heap_release(struct inode *inode, struct file *filp)
>> +{
>> +filp->private_data = NULL;
>> +
>> +return 0;
>> +}
>
> No point in clearing ->private_data, the file is about to be freed.
>
This was leftover from when release had some memory to free, will remove.
>> +
>> +static long dma_heap_ioctl(struct file *filp, unsigned int cmd,
>> + unsigned long arg)
>
> Pleae don't use the weird legacy filp naming, file is a perfectly
> valid and readable default name for struct file pointers.
>
Thanks for info, I saw both used and this was used where I found the
prototype so I used it too, will fix.
>> +{
>> +switch (cmd) {
>> +case DMA_HEAP_IOC_ALLOC:
>> +{
>> +struct dma_heap_allocation_data heap_allocation;
>> +struct dma_heap *heap = filp->private_data;
>> +int fd;
>
> Please split each ioctl into a separate function from the very start,
> otherwise this will grow into a spaghetty mess sooner than you can
> see cheese.
>
Good idea, will fix.
>> +dev_ret = device_create(dma_heap_class,
>> +NULL,
>> +heap->heap_devt,
>> +NULL,
>> +heap->name);
>
> No need this weird argument alignment.
>
I kinda like it this way, if everything cant fit on one line then
everything gets its own line, seems more consistent. If there is strong
objection I can fix.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers
On 3/13/19 5:57 PM, Liam Mark wrote:
> On Wed, 13 Mar 2019, Andrew F. Davis wrote:
>
>> On 3/13/19 3:18 PM, Liam Mark wrote:
>>> On Tue, 5 Mar 2019, John Stultz wrote:
>>>
>>>> Add generic helper dmabuf ops for dma heaps, so we can reduce
>>>> the amount of duplicative code for the exported dmabufs.
>>>>
>>>> This code is an evolution of the Android ION implementation, so
>>>> thanks to its original authors and maintainters:
>>>> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>>>>
>>>> Cc: Laura Abbott
>>>> Cc: Benjamin Gaignard
>>>> Cc: Greg KH
>>>> Cc: Sumit Semwal
>>>> Cc: Liam Mark
>>>> Cc: Brian Starkey
>>>> Cc: Andrew F. Davis
>>>> Cc: Chenbo Feng
>>>> Cc: Alistair Strachan
>>>> Cc: dri-devel@lists.freedesktop.org
>>>> Signed-off-by: John Stultz
>>>> ---
>>>> v2:
>>>> * Removed cache management performance hack that I had
>>>> accidentally folded in.
>>>> * Removed stats code that was in helpers
>>>> * Lots of checkpatch cleanups
>>>> ---
>>>> drivers/dma-buf/Makefile | 1 +
>>>> drivers/dma-buf/heaps/Makefile | 2 +
>>>> drivers/dma-buf/heaps/heap-helpers.c | 335
>>>> +++
>>>> drivers/dma-buf/heaps/heap-helpers.h | 48 +
>>>> 4 files changed, 386 insertions(+)
>>>> create mode 100644 drivers/dma-buf/heaps/Makefile
>>>> create mode 100644 drivers/dma-buf/heaps/heap-helpers.c
>>>> create mode 100644 drivers/dma-buf/heaps/heap-helpers.h
>>>>
>>>> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
>>>> index b0332f1..09c2f2d 100644
>>>> --- a/drivers/dma-buf/Makefile
>>>> +++ b/drivers/dma-buf/Makefile
>>>> @@ -1,4 +1,5 @@
>>>> obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o
>>>> seqno-fence.o
>>>> +obj-$(CONFIG_DMABUF_HEAPS)+= heaps/
>>>> obj-$(CONFIG_DMABUF_HEAPS)+= dma-heap.o
>>>> obj-$(CONFIG_SYNC_FILE) += sync_file.o
>>>> obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
>>>> diff --git a/drivers/dma-buf/heaps/Makefile
>>>> b/drivers/dma-buf/heaps/Makefile
>>>> new file mode 100644
>>>> index 000..de49898
>>>> --- /dev/null
>>>> +++ b/drivers/dma-buf/heaps/Makefile
>>>> @@ -0,0 +1,2 @@
>>>> +# SPDX-License-Identifier: GPL-2.0
>>>> +obj-y += heap-helpers.o
>>>> diff --git a/drivers/dma-buf/heaps/heap-helpers.c
>>>> b/drivers/dma-buf/heaps/heap-helpers.c
>>>> new file mode 100644
>>>> index 000..ae5e9d0
>>>> --- /dev/null
>>>> +++ b/drivers/dma-buf/heaps/heap-helpers.c
>>>> @@ -0,0 +1,335 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +
>>>> +#include "heap-helpers.h"
>>>> +
>>>> +
>>>> +static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
>>>> +{
>>>> + struct scatterlist *sg;
>>>> + int i, j;
>>>> + void *vaddr;
>>>> + pgprot_t pgprot;
>>>> + struct sg_table *table = buffer->sg_table;
>>>> + int npages = PAGE_ALIGN(buffer->heap_buffer.size) / PAGE_SIZE;
>>>> + struct page **pages = vmalloc(array_size(npages,
>>>> + sizeof(struct page *)));
>>>> + struct page **tmp = pages;
>>>> +
>>>> + if (!pages)
>>>> + return ERR_PTR(-ENOMEM);
>>>> +
>>>> + pgprot = PAGE_KERNEL;
>>>> +
>>>> + for_each_sg(table->sgl, sg, table->nents, i) {
>>>> + int npages_this_entry = PAGE_ALIGN(sg->length) / PAGE_SIZE;
>>>> + struct page *page = sg_page(sg);
>>>> +
>>>> + WARN_ON(i >= npages);
>>>> + for (j = 0; j < npages_this_entry; j++)
>>>> + *(tmp++) = page++;
>>>> + }
>>>> + vaddr = vmap(pages, npages, V
Re: [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers
On 3/13/19 3:18 PM, Liam Mark wrote:
> On Tue, 5 Mar 2019, John Stultz wrote:
>
>> Add generic helper dmabuf ops for dma heaps, so we can reduce
>> the amount of duplicative code for the exported dmabufs.
>>
>> This code is an evolution of the Android ION implementation, so
>> thanks to its original authors and maintainters:
>> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>>
>> Cc: Laura Abbott
>> Cc: Benjamin Gaignard
>> Cc: Greg KH
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Brian Starkey
>> Cc: Andrew F. Davis
>> Cc: Chenbo Feng
>> Cc: Alistair Strachan
>> Cc: dri-devel@lists.freedesktop.org
>> Signed-off-by: John Stultz
>> ---
>> v2:
>> * Removed cache management performance hack that I had
>> accidentally folded in.
>> * Removed stats code that was in helpers
>> * Lots of checkpatch cleanups
>> ---
>> drivers/dma-buf/Makefile | 1 +
>> drivers/dma-buf/heaps/Makefile | 2 +
>> drivers/dma-buf/heaps/heap-helpers.c | 335
>> +++
>> drivers/dma-buf/heaps/heap-helpers.h | 48 +
>> 4 files changed, 386 insertions(+)
>> create mode 100644 drivers/dma-buf/heaps/Makefile
>> create mode 100644 drivers/dma-buf/heaps/heap-helpers.c
>> create mode 100644 drivers/dma-buf/heaps/heap-helpers.h
>>
>> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
>> index b0332f1..09c2f2d 100644
>> --- a/drivers/dma-buf/Makefile
>> +++ b/drivers/dma-buf/Makefile
>> @@ -1,4 +1,5 @@
>> obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
>> +obj-$(CONFIG_DMABUF_HEAPS) += heaps/
>> obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
>> obj-$(CONFIG_SYNC_FILE) += sync_file.o
>> obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
>> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
>> new file mode 100644
>> index 000..de49898
>> --- /dev/null
>> +++ b/drivers/dma-buf/heaps/Makefile
>> @@ -0,0 +1,2 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +obj-y += heap-helpers.o
>> diff --git a/drivers/dma-buf/heaps/heap-helpers.c
>> b/drivers/dma-buf/heaps/heap-helpers.c
>> new file mode 100644
>> index 000..ae5e9d0
>> --- /dev/null
>> +++ b/drivers/dma-buf/heaps/heap-helpers.c
>> @@ -0,0 +1,335 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "heap-helpers.h"
>> +
>> +
>> +static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
>> +{
>> +struct scatterlist *sg;
>> +int i, j;
>> +void *vaddr;
>> +pgprot_t pgprot;
>> +struct sg_table *table = buffer->sg_table;
>> +int npages = PAGE_ALIGN(buffer->heap_buffer.size) / PAGE_SIZE;
>> +struct page **pages = vmalloc(array_size(npages,
>> + sizeof(struct page *)));
>> +struct page **tmp = pages;
>> +
>> +if (!pages)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +pgprot = PAGE_KERNEL;
>> +
>> +for_each_sg(table->sgl, sg, table->nents, i) {
>> +int npages_this_entry = PAGE_ALIGN(sg->length) / PAGE_SIZE;
>> +struct page *page = sg_page(sg);
>> +
>> +WARN_ON(i >= npages);
>> +for (j = 0; j < npages_this_entry; j++)
>> +*(tmp++) = page++;
>> +}
>> +vaddr = vmap(pages, npages, VM_MAP, pgprot);
>> +vfree(pages);
>> +
>> +if (!vaddr)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +return vaddr;
>> +}
>> +
>> +static int dma_heap_map_user(struct heap_helper_buffer *buffer,
>> + struct vm_area_struct *vma)
>> +{
>> +struct sg_table *table = buffer->sg_table;
>> +unsigned long addr = vma->vm_start;
>> +unsigned long offset = vma->vm_pgoff * PAGE_SIZE;
>> +struct scatterlist *sg;
>> +int i;
>> +int ret;
>> +
>> +for_each_sg(table->sgl, sg, table->nents, i) {
>> +struct page *page = sg_page(sg);
>> +unsigned long remainder = vma->vm_end - addr;
>> +unsigned long len = sg->length;
>> +
>> +if (offset
Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework
On 3/6/19 1:03 PM, John Stultz wrote:
> On Wed, Mar 6, 2019 at 10:18 AM Andrew F. Davis wrote:
>>
>> On 3/5/19 2:54 PM, John Stultz wrote:
>>> From: "Andrew F. Davis"
>>>
>>> This framework allows a unified userspace interface for dma-buf
>>> exporters, allowing userland to allocate specific types of
>>> memory for use in dma-buf sharing.
>>>
>>> Each heap is given its own device node, which a user can
>>> allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
>>>
>>> This code is an evoluiton of the Android ION implementation,
>>> and a big thanks is due to its authors/maintainers over time
>>> for their effort:
>>> Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
>>> Laura Abbott, and many other contributors!
>>>
>>> Cc: Laura Abbott
>>> Cc: Benjamin Gaignard
>>> Cc: Greg KH
>>> Cc: Sumit Semwal
>>> Cc: Liam Mark
>>> Cc: Brian Starkey
>>> Cc: Andrew F. Davis
>>> Cc: Chenbo Feng
>>> Cc: Alistair Strachan
>>> Cc: dri-devel@lists.freedesktop.org
>>> Signed-off-by: Andrew F. Davis
>>> [jstultz: reworded commit message, and lots of cleanups]
>>> Signed-off-by: John Stultz
>>> ---
>>> v2:
>>> * Folded down fixes I had previously shared in implementing
>>> heaps
>>> * Make flags a u64 (Suggested by Laura)
>>> * Add PAGE_ALIGN() fix to the core alloc funciton
>>> * IOCTL fixups suggested by Brian
>>> * Added fixes suggested by Benjamin
>>> * Removed core stats mgmt, as that should be implemented by
>>> per-heap code
>>> * Changed alloc to return a dma-buf fd, rather then a buffer
>>> (as it simplifies error handling)
>>> ---
>>> MAINTAINERS | 16
>>> drivers/dma-buf/Kconfig | 8 ++
>>> drivers/dma-buf/Makefile | 1 +
>>> drivers/dma-buf/dma-heap.c| 191
>>> ++
>>> include/linux/dma-heap.h | 65 ++
>>> include/uapi/linux/dma-heap.h | 52
>>> 6 files changed, 333 insertions(+)
>>> create mode 100644 drivers/dma-buf/dma-heap.c
>>> create mode 100644 include/linux/dma-heap.h
>>> create mode 100644 include/uapi/linux/dma-heap.h
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index ac2e518..a661e19 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -4621,6 +4621,22 @@ F: include/linux/*fence.h
>>> F: Documentation/driver-api/dma-buf.rst
>>> T: git git://anongit.freedesktop.org/drm/drm-misc
>>>
>>> +DMA-BUF HEAPS FRAMEWORK
>>> +M: Laura Abbott
>>> +R: Liam Mark
>>> +R: Brian Starkey
>>> +R: "Andrew F. Davis"
>>
>> Quotes not needed in maintainers file.
>
> Whatever you say, "Andrew F. Davis", or whomever you really are! ;)
>
<_<
>_>
>
>>> +
>>> + if (heap_allocation.fd ||
>>> + heap_allocation.reserved0 ||
>>> + heap_allocation.reserved1 ||
>>> + heap_allocation.reserved2) {
>>
>> Seems too many reserved, I can understand one, but if we ever needed all
>> of these we would be better off just adding another alloc ioctl.
>
> Well, we have to have one u32 for padding. And I figured if we needed
> anything more then a u32, then we're in for 2 more.
>
> And I think the potential of the alignment and heap-private flags, I
> worry we might want to have something, but I guess we could just add
> a new ioctl and keep the support for the old one if folks prefer.
>
>>> +int dma_heap_add(struct dma_heap *heap)
>>> +{
>>> + struct device *dev_ret;
>>> + int ret;
>>> +
>>> + if (!heap->name || !strcmp(heap->name, "")) {
>>> + pr_err("dma_heap: Cannot add heap without a name\n");
>>
>> As these names end up as the dev name in the file system we may want to
>> check for invalid names, there is probably a helper for that somewhere.
>
> Hrm. I'll have to look.
>
>>> +struct dma_heap {
>>> + const char *name;
>>> + struct dma_heap_ops *ops;
>>> + unsigned int minor;
>>> + dev_t heap_devt;
>>> + struct cdev heap_cdev;
>>> +};
>>
>> Still not sure about this, all of the members in this struct are
>
Re: [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test
On 3/6/19 12:19 PM, John Stultz wrote:
> On Wed, Mar 6, 2019 at 10:15 AM Andrew F. Davis wrote:
>>
>> On 3/6/19 10:14 AM, Benjamin Gaignard wrote:
>>> Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>>>>
>>>> Add very trivial allocation test for dma-heaps.
>>>>
>>>> TODO: Need to actually do some validation on
>>>> the returned dma-buf.
>>>>
>>>> Cc: Laura Abbott
>>>> Cc: Benjamin Gaignard
>>>> Cc: Greg KH
>>>> Cc: Sumit Semwal
>>>> Cc: Liam Mark
>>>> Cc: Brian Starkey
>>>> Cc: Andrew F. Davis
>>>> Cc: Chenbo Feng
>>>> Cc: Alistair Strachan
>>>> Cc: dri-devel@lists.freedesktop.org
>>>> Signed-off-by: John Stultz
>>>> ---
>>>> v2: Switched to use reworked dma-heap apis
>>>> ---
>>>> tools/testing/selftests/dmabuf-heaps/Makefile | 11 +++
>>>> tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 96
>>>> ++
>>>> 2 files changed, 107 insertions(+)
>>>> create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
>>>> create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>>>>
>>>> diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
>>>> b/tools/testing/selftests/dmabuf-heaps/Makefile
>>>> new file mode 100644
>>>> index 000..c414ad3
>>>> --- /dev/null
>>>> +++ b/tools/testing/selftests/dmabuf-heaps/Makefile
>>>> @@ -0,0 +1,11 @@
>>>> +# SPDX-License-Identifier: GPL-2.0
>>>> +CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
>>>> +#LDLIBS += -lrt -lpthread -lm
>>>> +
>>>> +# these are all "safe" tests that don't modify
>>>> +# system time or require escalated privileges
>>>> +TEST_GEN_PROGS = dmabuf-heap
>>>> +
>>>> +
>>>> +include ../lib.mk
>>>> +
>>>> diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>>>> b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>>>> new file mode 100644
>>>> index 000..06837a4
>>>> --- /dev/null
>>>> +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>>>> @@ -0,0 +1,96 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +
>>>> +#include "../../../../include/uapi/linux/dma-heap.h"
>>>> +
>>>> +#define DEVPATH "/dev/dma_heap"
>>>> +
>>>> +int dmabuf_heap_open(char *name)
>>>> +{
>>>> + int ret, fd;
>>>> + char buf[256];
>>>> +
>>>> + ret = sprintf(buf, "%s/%s", DEVPATH, name);
>>>> + if (ret < 0) {
>>>> + printf("sprintf failed!\n");
>>>> + return ret;
>>>> + }
>>>> +
>>>> + fd = open(buf, O_RDWR);
>>>> + if (fd < 0)
>>>> + printf("open %s failed!\n", buf);
>>>> + return fd;
>>>> +}
>>>> +
>>>> +int dmabuf_heap_alloc(int fd, size_t len, unsigned int flags, int
>>>> *dmabuf_fd)
>>>> +{
>>>> + struct dma_heap_allocation_data data = {
>>>> + .len = len,
>>>> + .flags = flags,
>>>> + };
>>>> + int ret;
>>>> +
>>>> + if (dmabuf_fd == NULL)
>>>> + return -EINVAL;
>>>> +
>>>> + ret = ioctl(fd, DMA_HEAP_IOC_ALLOC, );
>>>> + if (ret < 0)
>>>> + return ret;
>>>> + *dmabuf_fd = (int)data.fd;
>>>> + return ret;
>>>> +}
>>>> +
>>>> +#define ONE_MEG (1024*1024)
>>>> +
>>>> +void do_test(char *heap_name)
>>>> +{
>>>> + int heap_fd = -1, dmabuf_fd = -1;
>>>> + int ret;
>>>> +
>>>> + printf("Testing heap: %s\n", heap_name);
>>>> +
>>>> + heap_fd = dmabuf_heap_open(heap_name);
>>>> + if (heap_fd < 0)
>>>> + return;
>>>> +
>>>> + printf("Allocating 1 MEG\n");
>>>> + ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, _fd);
>>>> + if (ret)
>>>> + goto out;
>>>> +
>>>> + /* DO SOMETHING WITH THE DMABUF HERE? */
>>>
>>> You can do a call to mmap and write a pattern in the buffer.
>>>
>>
>> mmap is optional for DMA-BUFs, only attach/map are required. To test
>> those we would need a dummy device, so a test kernel module may be
>> needed to really exercise this.
>>
>> I have one I use for ION buffer testing, it consumes a DMA-BUF passed
>> from userspace, attach/maps it to a dummy device then return the
>> physical address of the first page of the buffer for validation. Might
>> be a good test, but dummy devices don't always have the proper dma
>> attributes set like a real device does, so it may also fail for some
>> otherwise valid buffers.
>
> Cool! Do you mind sharing that? I might try to rework and integrate it
> into this patchset?
>
Sure, top two patches here:
> https://git.ti.com/ti-analog-linux-kernel/afd-analog/commits/dma-buf-to-phys
Andrew
> thanks
> -john
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test
On 3/6/19 10:14 AM, Benjamin Gaignard wrote:
> Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>>
>> Add very trivial allocation test for dma-heaps.
>>
>> TODO: Need to actually do some validation on
>> the returned dma-buf.
>>
>> Cc: Laura Abbott
>> Cc: Benjamin Gaignard
>> Cc: Greg KH
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Brian Starkey
>> Cc: Andrew F. Davis
>> Cc: Chenbo Feng
>> Cc: Alistair Strachan
>> Cc: dri-devel@lists.freedesktop.org
>> Signed-off-by: John Stultz
>> ---
>> v2: Switched to use reworked dma-heap apis
>> ---
>> tools/testing/selftests/dmabuf-heaps/Makefile | 11 +++
>> tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 96
>> ++
>> 2 files changed, 107 insertions(+)
>> create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
>> create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>>
>> diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
>> b/tools/testing/selftests/dmabuf-heaps/Makefile
>> new file mode 100644
>> index 000..c414ad3
>> --- /dev/null
>> +++ b/tools/testing/selftests/dmabuf-heaps/Makefile
>> @@ -0,0 +1,11 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
>> +#LDLIBS += -lrt -lpthread -lm
>> +
>> +# these are all "safe" tests that don't modify
>> +# system time or require escalated privileges
>> +TEST_GEN_PROGS = dmabuf-heap
>> +
>> +
>> +include ../lib.mk
>> +
>> diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>> b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>> new file mode 100644
>> index 000..06837a4
>> --- /dev/null
>> +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>> @@ -0,0 +1,96 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "../../../../include/uapi/linux/dma-heap.h"
>> +
>> +#define DEVPATH "/dev/dma_heap"
>> +
>> +int dmabuf_heap_open(char *name)
>> +{
>> + int ret, fd;
>> + char buf[256];
>> +
>> + ret = sprintf(buf, "%s/%s", DEVPATH, name);
>> + if (ret < 0) {
>> + printf("sprintf failed!\n");
>> + return ret;
>> + }
>> +
>> + fd = open(buf, O_RDWR);
>> + if (fd < 0)
>> + printf("open %s failed!\n", buf);
>> + return fd;
>> +}
>> +
>> +int dmabuf_heap_alloc(int fd, size_t len, unsigned int flags, int
>> *dmabuf_fd)
>> +{
>> + struct dma_heap_allocation_data data = {
>> + .len = len,
>> + .flags = flags,
>> + };
>> + int ret;
>> +
>> + if (dmabuf_fd == NULL)
>> + return -EINVAL;
>> +
>> + ret = ioctl(fd, DMA_HEAP_IOC_ALLOC, );
>> + if (ret < 0)
>> + return ret;
>> + *dmabuf_fd = (int)data.fd;
>> + return ret;
>> +}
>> +
>> +#define ONE_MEG (1024*1024)
>> +
>> +void do_test(char *heap_name)
>> +{
>> + int heap_fd = -1, dmabuf_fd = -1;
>> + int ret;
>> +
>> + printf("Testing heap: %s\n", heap_name);
>> +
>> + heap_fd = dmabuf_heap_open(heap_name);
>> + if (heap_fd < 0)
>> + return;
>> +
>> + printf("Allocating 1 MEG\n");
>> + ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, _fd);
>> + if (ret)
>> + goto out;
>> +
>> + /* DO SOMETHING WITH THE DMABUF HERE? */
>
> You can do a call to mmap and write a pattern in the buffer.
>
mmap is optional for DMA-BUFs, only attach/map are required. To test
those we would need a dummy device, so a test kernel module may be
needed to really exercise this.
I have one I use for ION buffer testing, it consumes a DMA-BUF passed
from userspace, attach/maps it to a dummy device then return the
physical address of the first page of the buffer for validation. Might
be a good test, but dummy devices don't always have the proper dma
attributes set like a real device does, so it may also fail for some
otherwise valid buffers.
Andrew
> Benjamin
>> +
>> +out:
>> + if (dmabuf_fd >= 0)
>> + close(dmabuf_fd);
>> + if (heap_fd >= 0)
>> + close(heap_fd);
>> +}
>> +
>> +
>> +int main(void)
>> +{
>> + DIR *d;
>> + struct dirent *dir;
>> +
>> + d = opendir(DEVPATH);
>> + if (!d) {
>> + printf("No %s directory?\n", DEVPATH);
>> + return -1;
>> + }
>> +
>> + while ((dir = readdir(d)) != NULL)
>> + do_test(dir->d_name);
>> +
>> +
>> + return 0;
>> +}
>> --
>> 2.7.4
>>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework
On 3/5/19 2:54 PM, John Stultz wrote: > From: "Andrew F. Davis" > > This framework allows a unified userspace interface for dma-buf > exporters, allowing userland to allocate specific types of > memory for use in dma-buf sharing. > > Each heap is given its own device node, which a user can > allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. > > This code is an evoluiton of the Android ION implementation, > and a big thanks is due to its authors/maintainers over time > for their effort: > Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard, > Laura Abbott, and many other contributors! > > Cc: Laura Abbott > Cc: Benjamin Gaignard > Cc: Greg KH > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Brian Starkey > Cc: Andrew F. Davis > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Andrew F. Davis > [jstultz: reworded commit message, and lots of cleanups] > Signed-off-by: John Stultz > --- > v2: > * Folded down fixes I had previously shared in implementing > heaps > * Make flags a u64 (Suggested by Laura) > * Add PAGE_ALIGN() fix to the core alloc funciton > * IOCTL fixups suggested by Brian > * Added fixes suggested by Benjamin > * Removed core stats mgmt, as that should be implemented by > per-heap code > * Changed alloc to return a dma-buf fd, rather then a buffer > (as it simplifies error handling) > --- > MAINTAINERS | 16 > drivers/dma-buf/Kconfig | 8 ++ > drivers/dma-buf/Makefile | 1 + > drivers/dma-buf/dma-heap.c| 191 > ++ > include/linux/dma-heap.h | 65 ++ > include/uapi/linux/dma-heap.h | 52 > 6 files changed, 333 insertions(+) > create mode 100644 drivers/dma-buf/dma-heap.c > create mode 100644 include/linux/dma-heap.h > create mode 100644 include/uapi/linux/dma-heap.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index ac2e518..a661e19 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4621,6 +4621,22 @@ F: include/linux/*fence.h > F: Documentation/driver-api/dma-buf.rst > T: git git://anongit.freedesktop.org/drm/drm-misc > > +DMA-BUF HEAPS FRAMEWORK > +M: Laura Abbott > +R: Liam Mark > +R: Brian Starkey > +R: "Andrew F. Davis" Quotes not needed in maintainers file. > +R: John Stultz > +S: Maintained > +L: linux-me...@vger.kernel.org > +L: dri-devel@lists.freedesktop.org > +L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) > +F: include/uapi/linux/dma-heap.h > +F: include/linux/dma-heap.h > +F: drivers/dma-buf/dma-heap.c > +F: drivers/dma-buf/heaps/* > +T: git git://anongit.freedesktop.org/drm/drm-misc > + > DMA GENERIC OFFLOAD ENGINE SUBSYSTEM > M: Vinod Koul > L: dmaeng...@vger.kernel.org > diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig > index 2e5a0fa..09c61db 100644 > --- a/drivers/dma-buf/Kconfig > +++ b/drivers/dma-buf/Kconfig > @@ -39,4 +39,12 @@ config UDMABUF > A driver to let userspace turn memfd regions into dma-bufs. > Qemu can use this to create host dmabufs for guest framebuffers. > > +menuconfig DMABUF_HEAPS > + bool "DMA-BUF Userland Memory Heaps" > + select DMA_SHARED_BUFFER > + help > + Choose this option to enable the DMA-BUF userland memory heaps, > + this allows userspace to allocate dma-bufs that can be shared between > + drivers. > + > endmenu > diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile > index 0913a6c..b0332f1 100644 > --- a/drivers/dma-buf/Makefile > +++ b/drivers/dma-buf/Makefile > @@ -1,4 +1,5 @@ > obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o > +obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o > obj-$(CONFIG_SYNC_FILE) += sync_file.o > obj-$(CONFIG_SW_SYNC)+= sw_sync.o sync_debug.o > obj-$(CONFIG_UDMABUF)+= udmabuf.o > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > new file mode 100644 > index 000..14b3975 > --- /dev/null > +++ b/drivers/dma-buf/dma-heap.c > @@ -0,0 +1,191 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Framework for userspace DMA-BUF allocations > + * > + * Copyright (C) 2011 Google, Inc. > + * Copyright (C) 2019 Linaro Ltd. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +#define DEVNAME "dma_heap" > + > +#define NUM_HEAP_MINORS
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 3/4/19 7:16 PM, John Stultz wrote:
> On Mon, Mar 4, 2019 at 6:53 AM Andrew F. Davis wrote:
>> On 3/1/19 6:06 AM, Brian Starkey wrote:
>>> On Mon, Feb 25, 2019 at 08:36:04AM -0600, Andrew F. Davis wrote:
>>>> +static long dma_heap_ioctl(struct file *filp, unsigned int cmd, unsigned
>>>> long arg)
>>>> +{
>>>> +switch (cmd) {
>>>> +case DMA_HEAP_IOC_ALLOC:
>>>> +{
>>>> +struct dma_heap_allocation_data heap_allocation;
>>>> +struct dma_heap *heap = filp->private_data;
>>>> +int fd;
>>>> +
>>>> +if (copy_from_user(_allocation, (void __user *)arg,
>>>> _IOC_SIZE(cmd)))
>>>> +return -EFAULT;
>>>
>>> Am I right in thinking "cmd" comes from userspace? It might be a good
>>> idea to not trust _IOC_SIZE(cmd) and use our own. I'm looking at
>>> Documentation/ioctl/botching-up-ioctls.txt and drm_ioctl()
>>>
>>
>> Yes cmd is from userspace, but we are in a switch-case that has already
>> matched cmd == DMA_HEAP_IOC_ALLOC which is sized correctly.
>>
>
> Well, even so, I went through and made this cleanup over the weekend,
> as sizeof(heap_allocation) is probably more straight forward.
>
> The current patchset against v5.0 (with hikey960 patches), which
> includes the flags and other suggested changes is here:
>
> https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap
>
> W/ userland support here:
> https://android-review.googlesource.com/c/device/linaro/hikey/+/909436
>
> I'm hoping to send this out for a real RFC in the next few days. So
> Andrew, if you can check it out and make sure it suits you ok I'd
> appreciate it!
>
Nothing at a high level, couple little things I can just point out when
you RFC, I think this is in good shape for a real RFC.
>>>> +heap->num_of_buffers = 0;
>>>> +heap->num_of_alloc_bytes = 0;
>>>> +heap->alloc_bytes_wm = 0;
>>>> +spin_lock_init(>stat_lock);
>>>> +heap_root = debugfs_create_dir(heap->name, dma_heap_debug_root);
>>>> +debugfs_create_u64("num_of_buffers", 0444, heap_root,
>>>> >num_of_buffers);
>>>> +debugfs_create_u64("num_of_alloc_bytes", 0444, heap_root,
>>>> >num_of_alloc_bytes);
>>>> +debugfs_create_u64("alloc_bytes_wm", 0444, heap_root,
>>>> >alloc_bytes_wm);
>>>
>>> I can see it being useful to be able to reset this one.
>>>
>>
>> Agree, looks like these will be pulled into the heaps themselves in the
>> next rev John is working on, so shouldn't matter here.
>
> Yea. Sort of half-way done on this. I yanked the stats, but haven't
> re-added them back to the heaps yet.
>
>> What we are moving to is a better (I think) ownership model. 'DMA-heaps'
>> only tracks 'heaps', 'heaps' track their 'buffers'. In the above we have
>> 'DMA-heaps' tracking info on 'buffers', bypassing the 'heaps' layer, so
>> in the next rev will be the 'DMA-heaps' core asks the 'heaps' to report
>> back stats.
>
> Yea. This matches my plan.
>
>>>> +/*
>>>> + * mappings of this buffer should be un-cached, otherwise dmabuf heaps
>>>> will
>>>> + * need cache maintenance using DMA_BUF_SYNC_* when the buffer is mapped
>>>> for dma
>>>> + */
>>>> +#define DMA_HEAP_FLAG_COHERENT 1
>>>
>>> I'm not really clear on the intention of this flag, and I do think
>>> that "COHERENT" is a confusing/overloaded term.
>>>
>>
>> It is, I wanted to use the term as used by the other DMA frameworks, but
>> I don't really like it either.
>>
>>> To me, if the buffer is actually coherent with DMA masters, then
>>> there's no need for any cache maintenance - which is the opposite of
>>> what the comment says.
>>>
>>
>> Buffers themselves can't be (non)coherent, they are just memory, masters
>> on a bus can have coherent interactions depending on which masters are
>> talking and how the buffer in question is managed. So really the term
>> isn't right almost anywhere as it only applies from the perspective of
>> the local core (running Linux) and only if simply not locally caching
>> the buffer is enough to make it "coherent". But that is a rant best
>> saved for another time.
>>
>> For us lets drop that flag, if you want to allocate from
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 3/1/19 6:06 AM, Brian Starkey wrote: > Hi Andrew, > > Sorry for not managing to comment on this sooner, I've had a crazy few > days. > > As the others have said, I quite like the direction here. > > On Mon, Feb 25, 2019 at 08:36:04AM -0600, Andrew F. Davis wrote: >> This framework allows a unified userspace interface for dma-buf >> exporters, allowing userland to allocate specific types of memory >> for use in dma-buf sharing. >> >> Each heap is given its own device node, which a user can allocate >> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. >> >> Signed-off-by: Andrew F. Davis >> --- >> >> Hello all, >> >> I had a little less time over the weekend than I thought I would to >> clean this up more and finish the first set of user heaps, but wanted >> to get this out anyway. >> >> ION in its current form assumes a lot about the memory it exports and >> these assumptions lead to restrictions on the full range of operations >> dma-buf's can produce. Due to this if we are to add this as an extension >> of the core dma-buf then it should only be the user-space advertisement >> and allocation front-end. All dma-buf exporting and operation need to be >> placed in the control of the exporting heap. The core becomes rather >> small, just a few hundred lines you see here. This is not to say we >> should not provide helpers to make the heap exporters more simple, but >> they should only be helpers and not enforced by the core framework. >> >> Basic use model here is an exporter (dedicated heap memory driver, CMA, >> System, etc.) registers with the framework by providing a struct >> dma_heap_info which gives us the needed info to export this heap to >> userspace as a device node. Next a user will request an allocation, >> the IOCTL is parsed and the request made to a heap provided alloc() op. >> The heap should return the filled out struct dma_heap_buffer, including >> exporting the buffer as a dma-buf. This dma-buf we then return to the >> user as a fd. Buffer free is still a bit open as we need to update some >> stats and free some memory, but the release operation is controlled by >> the heap exporter, so some hook will have to be created. >> >> It all needs a bit more work, and I'm sure I'll find missing parts when >> I add some more heaps, but hopefully this framework is simple enough that >> it does not impede the implementation of all functionality once provided >> by ION (shrinker, delayed free), nor any new functionality needed for >> future heap exporting devices. >> >> Thanks, >> Andrew >> >> drivers/dma-buf/Kconfig | 12 ++ >> drivers/dma-buf/Makefile | 1 + >> drivers/dma-buf/dma-heap.c| 268 ++ >> include/linux/dma-heap.h | 57 >> include/uapi/linux/dma-heap.h | 54 +++ >> 5 files changed, 392 insertions(+) >> create mode 100644 drivers/dma-buf/dma-heap.c >> create mode 100644 include/linux/dma-heap.h >> create mode 100644 include/uapi/linux/dma-heap.h >> >> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig >> index 2e5a0faa2cb1..30b0d7c83945 100644 >> --- a/drivers/dma-buf/Kconfig >> +++ b/drivers/dma-buf/Kconfig >> @@ -39,4 +39,16 @@ config UDMABUF >>A driver to let userspace turn memfd regions into dma-bufs. >>Qemu can use this to create host dmabufs for guest framebuffers. >> >> +menuconfig DMABUF_HEAPS >> +bool "DMA-BUF Userland Memory Heaps" >> +depends on HAS_DMA && MMU >> +select GENERIC_ALLOCATOR >> +select DMA_SHARED_BUFFER >> +help >> + Choose this option to enable the DMA-BUF userland memory heaps, >> + this allows userspace to allocate dma-bufs that can be shared between >> + drivers. >> + >> +source "drivers/dma-buf/heaps/Kconfig" >> + >> endmenu >> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile >> index 0913a6ccab5a..b0332f143413 100644 >> --- a/drivers/dma-buf/Makefile >> +++ b/drivers/dma-buf/Makefile >> @@ -1,4 +1,5 @@ >> obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o >> +obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o >> obj-$(CONFIG_SYNC_FILE) += sync_file.o >> obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o >> obj-$(CONFIG_UDMABUF) += udmabuf.o >> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c >> new file mode 100644 >> index ..72ed22
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 2/27/19 3:55 PM, John Stultz wrote: > On Wed, Feb 27, 2019 at 8:38 AM Andrew F. Davis wrote: >> >> On 2/26/19 5:40 PM, John Stultz wrote: >>> On Tue, Feb 26, 2019 at 11:21 AM John Stultz wrote: >>> I've updated the patches here: >>> kernel: >>> https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap >>> userland: >>> https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 >>> >>> >>>> I also realized some of Benajmin's error path improvements are going >>>> to be hard to fix w/ my current code, specifically having the allocate >>>> op do the allocation of the dma_heap_buffer (since we don't have a >>>> free op, if something fails creating the dmabuf fd in the core, we >>>> don't have a hook to release the dma_heap_buffer and heap private >>>> data). >>> >> >> We can always add back the free op, the alternative is to have the heap >> export the fd. >> >> I'm not sure either is needed though, when we >> dma_buf_put(buffer->dmabuf) on the error path it should trigger the >> release op, and that can cleanup the allocations in the heap. > > Good point, but I worry that's a bit subtle. > > Also doing the stuff with the helpers where we have to register a free > callback is kind of ugly, and I personally like the symmetry of having > free hooks if we have allocation hooks (even if the dmabuf release > hook initiates the free call). > I do like the symmetry of a free op, just not sure how or what should be done in it that couldn't be taken care of in the dmabuf.release op.. >>> I also realized doing my development and testing against my >>> hikey960-mainline-WIP branch, I accidentally folded in an ion hack I >>> was using to reduce cache operations, so I'll need to undo that in the >>> heap-helpers.c. But at least we have a rough validation point for the >>> design. >>> >> >> Great! The details of the heap-helpers can always get fixed up at a >> later point, validation of the core working is really good to hear. >> > > Let me know if you have any further feedback or changes to integrate. > I've got to get back to some other work, but will try to take a > cleanup pass in the next few days. > I've got no other feedback right now. I'm guessing we will try a first non-RFC sometime in the next couple weeks for the sake of getting Greg's eyes on this, can see where it goes from there. Thanks, Andrew > thanks > -john > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 2/26/19 5:40 PM, John Stultz wrote: > On Tue, Feb 26, 2019 at 11:21 AM John Stultz wrote: >> >> On Tue, Feb 26, 2019 at 6:47 AM Andrew F. Davis wrote: >>> On 2/26/19 12:20 AM, John Stultz wrote: >>>> It boots w/ AOSP, and allocations seem to work, but there's something >>>> wrong with the dmabuf mmaping which casues the homescreen to crash >>>> over and over. >>>> (userland patches updated here: >>>> https://android-review.googlesource.com/c/device/linaro/hikey/+/909436) >>>> >>> >>> Interesting, I wonder if the caching stuff is not right here, I'll see >>> if I can get this working on my side (AOSP on Beagle x15). >>> >> >> Let me know if you figure anything out, I'll also be looking at this today. >> > > Ok. Figured out the issue. There was a missing: > len = PAGE_ALIGN(len) > assignment that the core used to do before calling the heap alloc op. > Ah, that was my bad then, I dropped that line thinking the heaps should take care of it, forcing allocation to the page length does make sense though, we cant pass any less back to userspace. > Adding that into the heap alloc op got it booting ok w/ AOSP. > > I've updated the patches here: > kernel: > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap > userland: > https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 > > >> I also realized some of Benajmin's error path improvements are going >> to be hard to fix w/ my current code, specifically having the allocate >> op do the allocation of the dma_heap_buffer (since we don't have a >> free op, if something fails creating the dmabuf fd in the core, we >> don't have a hook to release the dma_heap_buffer and heap private >> data). > We can always add back the free op, the alternative is to have the heap export the fd. I'm not sure either is needed though, when we dma_buf_put(buffer->dmabuf) on the error path it should trigger the release op, and that can cleanup the allocations in the heap. > I also realized doing my development and testing against my > hikey960-mainline-WIP branch, I accidentally folded in an ion hack I > was using to reduce cache operations, so I'll need to undo that in the > heap-helpers.c. But at least we have a rough validation point for the > design. > Great! The details of the heap-helpers can always get fixed up at a later point, validation of the core working is really good to hear. Thanks, Andrew > thanks > -john > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 2/26/19 8:12 AM, Benjamin Gaignard wrote: > Le lun. 25 févr. 2019 à 15:36, Andrew F. Davis a écrit : >> >> This framework allows a unified userspace interface for dma-buf >> exporters, allowing userland to allocate specific types of memory >> for use in dma-buf sharing. >> >> Each heap is given its own device node, which a user can allocate >> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. >> >> Signed-off-by: Andrew F. Davis >> --- >> >> Hello all, >> >> I had a little less time over the weekend than I thought I would to >> clean this up more and finish the first set of user heaps, but wanted >> to get this out anyway. >> >> ION in its current form assumes a lot about the memory it exports and >> these assumptions lead to restrictions on the full range of operations >> dma-buf's can produce. Due to this if we are to add this as an extension >> of the core dma-buf then it should only be the user-space advertisement >> and allocation front-end. All dma-buf exporting and operation need to be >> placed in the control of the exporting heap. The core becomes rather >> small, just a few hundred lines you see here. This is not to say we >> should not provide helpers to make the heap exporters more simple, but >> they should only be helpers and not enforced by the core framework. >> >> Basic use model here is an exporter (dedicated heap memory driver, CMA, >> System, etc.) registers with the framework by providing a struct >> dma_heap_info which gives us the needed info to export this heap to >> userspace as a device node. Next a user will request an allocation, >> the IOCTL is parsed and the request made to a heap provided alloc() op. >> The heap should return the filled out struct dma_heap_buffer, including >> exporting the buffer as a dma-buf. This dma-buf we then return to the >> user as a fd. Buffer free is still a bit open as we need to update some >> stats and free some memory, but the release operation is controlled by >> the heap exporter, so some hook will have to be created. >> >> It all needs a bit more work, and I'm sure I'll find missing parts when >> I add some more heaps, but hopefully this framework is simple enough that >> it does not impede the implementation of all functionality once provided >> by ION (shrinker, delayed free), nor any new functionality needed for >> future heap exporting devices. >> >> Thanks, >> Andrew > > Overall I like the idea but I think "dma_heap" will be confusing like > dma_buf is because it isn't > related to DMA engine. The intention was to keep things consistent within dma_buf and dma_fence names, originally this was dmabuf_heap, right before I posted I did a mass rename, so if there is push back here then it can always be mass renamed again. > I would like to see how this could be used with exiting allocator like > CMA or genalloc. > > Benjamin > >> >> drivers/dma-buf/Kconfig | 12 ++ >> drivers/dma-buf/Makefile | 1 + >> drivers/dma-buf/dma-heap.c| 268 ++ >> include/linux/dma-heap.h | 57 >> include/uapi/linux/dma-heap.h | 54 +++ >> 5 files changed, 392 insertions(+) >> create mode 100644 drivers/dma-buf/dma-heap.c >> create mode 100644 include/linux/dma-heap.h >> create mode 100644 include/uapi/linux/dma-heap.h >> >> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig >> index 2e5a0faa2cb1..30b0d7c83945 100644 >> --- a/drivers/dma-buf/Kconfig >> +++ b/drivers/dma-buf/Kconfig >> @@ -39,4 +39,16 @@ config UDMABUF >> A driver to let userspace turn memfd regions into dma-bufs. >> Qemu can use this to create host dmabufs for guest framebuffers. >> >> +menuconfig DMABUF_HEAPS >> + bool "DMA-BUF Userland Memory Heaps" >> + depends on HAS_DMA && MMU > > Why do you put MMU dependency ? > >> + select GENERIC_ALLOCATOR > > Maybe I have miss it but I don't see the need to select GENERIC_ALLOCATOR > For the two above they are leftover from ION when the heaps where more tightly coupled with the core, these can now be moved out to the individual heaps that use them. >> + select DMA_SHARED_BUFFER >> + help >> + Choose this option to enable the DMA-BUF userland memory heaps, >> + this allows userspace to allocate dma-bufs that can be shared >> between >> + drivers. >> + >> +source "drivers/dma-buf/heaps/Kconfig" >> + >> endmenu >> diff --git a/d
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 2/26/19 12:20 AM, John Stultz wrote: > On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote: >> >> This framework allows a unified userspace interface for dma-buf >> exporters, allowing userland to allocate specific types of memory >> for use in dma-buf sharing. >> >> Each heap is given its own device node, which a user can allocate >> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. >> >> Signed-off-by: Andrew F. Davis >> --- >> >> Hello all, >> >> I had a little less time over the weekend than I thought I would to >> clean this up more and finish the first set of user heaps, but wanted >> to get this out anyway. >> >> ION in its current form assumes a lot about the memory it exports and >> these assumptions lead to restrictions on the full range of operations >> dma-buf's can produce. Due to this if we are to add this as an extension >> of the core dma-buf then it should only be the user-space advertisement >> and allocation front-end. All dma-buf exporting and operation need to be >> placed in the control of the exporting heap. The core becomes rather >> small, just a few hundred lines you see here. This is not to say we >> should not provide helpers to make the heap exporters more simple, but >> they should only be helpers and not enforced by the core framework. >> >> Basic use model here is an exporter (dedicated heap memory driver, CMA, >> System, etc.) registers with the framework by providing a struct >> dma_heap_info which gives us the needed info to export this heap to >> userspace as a device node. Next a user will request an allocation, >> the IOCTL is parsed and the request made to a heap provided alloc() op. >> The heap should return the filled out struct dma_heap_buffer, including >> exporting the buffer as a dma-buf. This dma-buf we then return to the >> user as a fd. Buffer free is still a bit open as we need to update some >> stats and free some memory, but the release operation is controlled by >> the heap exporter, so some hook will have to be created. >> >> It all needs a bit more work, and I'm sure I'll find missing parts when >> I add some more heaps, but hopefully this framework is simple enough that >> it does not impede the implementation of all functionality once provided >> by ION (shrinker, delayed free), nor any new functionality needed for >> future heap exporting devices. > > I took your patch here, made some small reworks as I mentioned > earlier, and tried to add some generic helpers and the system and cma > heaps integrated. > > You can find the changes added on top of your patch here: > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap > > I propose we should squish down the first three changes down into the > core patch if you agree. > All looks good to me. One thing I'm still unsure of is moving struct dma_heap out into the public interface header. That struct contains framework internal only info (device nodes, stats, etc.) that should not be exposed to the outside world. I think of them as private members of our class (too much C++ work lately), if we need to expose any members of that struct then we can add accessors as needed. > The helper functions need some work and cleanup, right now I'm only > exposing the dmabuf ops and realistically folks will probably want to > fill part of the ops with custom things. > Yes, the current set of helper dma-buf-ops work well for pre-allocated page-struct-backed memory buffers (basically sg list). For buffers allocated outside of normal RAM, secure (unmapped) heaps, and attach time allocated heaps all kinda break down with the current helpers. But that's the best part of helpers, you don't need to use them if you don't want :) > It boots w/ AOSP, and allocations seem to work, but there's something > wrong with the dmabuf mmaping which casues the homescreen to crash > over and over. > (userland patches updated here: > https://android-review.googlesource.com/c/device/linaro/hikey/+/909436) > Interesting, I wonder if the caching stuff is not right here, I'll see if I can get this working on my side (AOSP on Beagle x15). Thanks, Andrew > But that's about as far as I can do tonight, so I'm crashing and will > see what you think tomorrow. :) > > thanks > -john > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 2/25/19 9:53 PM, Sumit Semwal wrote: > On Mon, 25 Feb 2019 at 20:06, Andrew F. Davis wrote: >> >> This framework allows a unified userspace interface for dma-buf >> exporters, allowing userland to allocate specific types of memory >> for use in dma-buf sharing. >> >> Each heap is given its own device node, which a user can allocate >> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. >> >> Signed-off-by: Andrew F. Davis >> --- >> >> Hello all, >> >> I had a little less time over the weekend than I thought I would to >> clean this up more and finish the first set of user heaps, but wanted >> to get this out anyway. >> >> ION in its current form assumes a lot about the memory it exports and >> these assumptions lead to restrictions on the full range of operations >> dma-buf's can produce. Due to this if we are to add this as an extension >> of the core dma-buf then it should only be the user-space advertisement >> and allocation front-end. All dma-buf exporting and operation need to be >> placed in the control of the exporting heap. The core becomes rather >> small, just a few hundred lines you see here. This is not to say we >> should not provide helpers to make the heap exporters more simple, but >> they should only be helpers and not enforced by the core framework. > > As an idea, I really like the direction for this. It gives a good > amount of flexibilty for exporters. So definitely thanks to John and > you for taking the plunge there :) > >> >> Basic use model here is an exporter (dedicated heap memory driver, CMA, >> System, etc.) registers with the framework by providing a struct >> dma_heap_info which gives us the needed info to export this heap to >> userspace as a device node. Next a user will request an allocation, >> the IOCTL is parsed and the request made to a heap provided alloc() op. >> The heap should return the filled out struct dma_heap_buffer, including >> exporting the buffer as a dma-buf. This dma-buf we then return to the >> user as a fd. Buffer free is still a bit open as we need to update some >> stats and free some memory, but the release operation is controlled by >> the heap exporter, so some hook will have to be created. >> >> It all needs a bit more work, and I'm sure I'll find missing parts when >> I add some more heaps, but hopefully this framework is simple enough that >> it does not impede the implementation of all functionality once provided >> by ION (shrinker, delayed free), nor any new functionality needed for >> future heap exporting devices. >> > Other than current heaps, the secure heaps have been talked about > quite a bit in the past, so I will check with Linaro's security group > on them trying out the next version as well. As I also moonlight as a Linaro member engineer as part of SWG (andrew.da...@linaro.org) I've talked with Joakim and Etienne about the secure (unmapped) heaps, adding those are already baked into my plans here :) Andrew > We also would need to do a performance comparison, so that's another > activity to be added. >> Thanks, >> Andrew > Best, > Sumit. >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 2/25/19 6:55 PM, John Stultz wrote:
> On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote:
>> +static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
>> unsigned int flags)
>> +{
>> + struct dma_heap_buffer *buffer;
>> + int fd, ret;
>> +
>> + buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
>> + if (!buffer)
>> + return -ENOMEM;
>> +
>> + buffer->heap = heap;
>> + ret = heap->ops->allocate(heap, buffer, len, flags);
>> + if (ret) {
>> + kfree(buffer);
>> + return ret;
>> + }
>
> Similarly, I think the struct dma_heap_buffer, should be allocated and
> returned by the heap's allocate function.
>
That sound good, we could also then remove the free in buffer_free(),
just wasn't sure about object lifetimes causing issues if it was freed
early and the framework still needed something from it.
Andrew
> That way it can allocate its own larger structure (with the
> dma_heap_buffer as part of it) with private fields, and use
> container_of() to traverse from the buffer to the private data.
>
> Once I get things building, I'll share my changes.
>
> thanks
> -john
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 2/25/19 6:20 PM, John Stultz wrote: > On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote: >> >> This framework allows a unified userspace interface for dma-buf >> exporters, allowing userland to allocate specific types of memory >> for use in dma-buf sharing. >> >> Each heap is given its own device node, which a user can allocate >> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. >> >> Signed-off-by: Andrew F. Davis >> --- >> >> Hello all, >> >> I had a little less time over the weekend than I thought I would to >> clean this up more and finish the first set of user heaps, but wanted >> to get this out anyway. >> >> ION in its current form assumes a lot about the memory it exports and >> these assumptions lead to restrictions on the full range of operations >> dma-buf's can produce. Due to this if we are to add this as an extension >> of the core dma-buf then it should only be the user-space advertisement >> and allocation front-end. All dma-buf exporting and operation need to be >> placed in the control of the exporting heap. The core becomes rather >> small, just a few hundred lines you see here. This is not to say we >> should not provide helpers to make the heap exporters more simple, but >> they should only be helpers and not enforced by the core framework. >> >> Basic use model here is an exporter (dedicated heap memory driver, CMA, >> System, etc.) registers with the framework by providing a struct >> dma_heap_info which gives us the needed info to export this heap to >> userspace as a device node. Next a user will request an allocation, >> the IOCTL is parsed and the request made to a heap provided alloc() op. >> The heap should return the filled out struct dma_heap_buffer, including >> exporting the buffer as a dma-buf. This dma-buf we then return to the >> user as a fd. Buffer free is still a bit open as we need to update some >> stats and free some memory, but the release operation is controlled by >> the heap exporter, so some hook will have to be created. >> >> It all needs a bit more work, and I'm sure I'll find missing parts when >> I add some more heaps, but hopefully this framework is simple enough that >> it does not impede the implementation of all functionality once provided >> by ION (shrinker, delayed free), nor any new functionality needed for >> future heap exporting devices. >> >> Thanks, >> Andrew >> >> drivers/dma-buf/Kconfig | 12 ++ >> drivers/dma-buf/Makefile | 1 + >> drivers/dma-buf/dma-heap.c| 268 ++ >> include/linux/dma-heap.h | 57 >> include/uapi/linux/dma-heap.h | 54 +++ >> 5 files changed, 392 insertions(+) >> create mode 100644 drivers/dma-buf/dma-heap.c >> create mode 100644 include/linux/dma-heap.h >> create mode 100644 include/uapi/linux/dma-heap.h >> >> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig >> index 2e5a0faa2cb1..30b0d7c83945 100644 >> --- a/drivers/dma-buf/Kconfig >> +++ b/drivers/dma-buf/Kconfig >> @@ -39,4 +39,16 @@ config UDMABUF >> A driver to let userspace turn memfd regions into dma-bufs. >> Qemu can use this to create host dmabufs for guest framebuffers. >> >> +menuconfig DMABUF_HEAPS >> + bool "DMA-BUF Userland Memory Heaps" >> + depends on HAS_DMA && MMU >> + select GENERIC_ALLOCATOR >> + select DMA_SHARED_BUFFER >> + help >> + Choose this option to enable the DMA-BUF userland memory heaps, >> + this allows userspace to allocate dma-bufs that can be shared >> between >> + drivers. >> + >> +source "drivers/dma-buf/heaps/Kconfig" >> + >> endmenu >> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile >> index 0913a6ccab5a..b0332f143413 100644 >> --- a/drivers/dma-buf/Makefile >> +++ b/drivers/dma-buf/Makefile >> @@ -1,4 +1,5 @@ >> obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o >> +obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o >> obj-$(CONFIG_SYNC_FILE)+= sync_file.o >> obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o >> obj-$(CONFIG_UDMABUF) += udmabuf.o >> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c >> new file mode 100644 >> index ..72ed225fa892 >> --- /dev/null >> +++ b/drivers/dma-buf/dma-heap.c >> @@ -0,0 +1,268 @@ >> +// SPDX-License-Identifier: GPL-2.
[EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
This framework allows a unified userspace interface for dma-buf exporters, allowing userland to allocate specific types of memory for use in dma-buf sharing. Each heap is given its own device node, which a user can allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. Signed-off-by: Andrew F. Davis --- Hello all, I had a little less time over the weekend than I thought I would to clean this up more and finish the first set of user heaps, but wanted to get this out anyway. ION in its current form assumes a lot about the memory it exports and these assumptions lead to restrictions on the full range of operations dma-buf's can produce. Due to this if we are to add this as an extension of the core dma-buf then it should only be the user-space advertisement and allocation front-end. All dma-buf exporting and operation need to be placed in the control of the exporting heap. The core becomes rather small, just a few hundred lines you see here. This is not to say we should not provide helpers to make the heap exporters more simple, but they should only be helpers and not enforced by the core framework. Basic use model here is an exporter (dedicated heap memory driver, CMA, System, etc.) registers with the framework by providing a struct dma_heap_info which gives us the needed info to export this heap to userspace as a device node. Next a user will request an allocation, the IOCTL is parsed and the request made to a heap provided alloc() op. The heap should return the filled out struct dma_heap_buffer, including exporting the buffer as a dma-buf. This dma-buf we then return to the user as a fd. Buffer free is still a bit open as we need to update some stats and free some memory, but the release operation is controlled by the heap exporter, so some hook will have to be created. It all needs a bit more work, and I'm sure I'll find missing parts when I add some more heaps, but hopefully this framework is simple enough that it does not impede the implementation of all functionality once provided by ION (shrinker, delayed free), nor any new functionality needed for future heap exporting devices. Thanks, Andrew drivers/dma-buf/Kconfig | 12 ++ drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-heap.c| 268 ++ include/linux/dma-heap.h | 57 include/uapi/linux/dma-heap.h | 54 +++ 5 files changed, 392 insertions(+) create mode 100644 drivers/dma-buf/dma-heap.c create mode 100644 include/linux/dma-heap.h create mode 100644 include/uapi/linux/dma-heap.h diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index 2e5a0faa2cb1..30b0d7c83945 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -39,4 +39,16 @@ config UDMABUF A driver to let userspace turn memfd regions into dma-bufs. Qemu can use this to create host dmabufs for guest framebuffers. +menuconfig DMABUF_HEAPS + bool "DMA-BUF Userland Memory Heaps" + depends on HAS_DMA && MMU + select GENERIC_ALLOCATOR + select DMA_SHARED_BUFFER + help + Choose this option to enable the DMA-BUF userland memory heaps, + this allows userspace to allocate dma-bufs that can be shared between + drivers. + +source "drivers/dma-buf/heaps/Kconfig" + endmenu diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index 0913a6ccab5a..b0332f143413 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -1,4 +1,5 @@ obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o +obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o obj-$(CONFIG_SYNC_FILE)+= sync_file.o obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o obj-$(CONFIG_UDMABUF) += udmabuf.o diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c new file mode 100644 index ..72ed225fa892 --- /dev/null +++ b/drivers/dma-buf/dma-heap.c @@ -0,0 +1,268 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Framework for userspace DMA-BUF allocations + * + * Copyright (C) 2011 Google, Inc. + * Copyright (C) 2019 Linaro Ltd. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#define DEVNAME "dma_heap" + +#define NUM_HEAP_MINORS 128 +static DEFINE_IDR(dma_heap_idr); +static DEFINE_MUTEX(minor_lock); /* Protect idr accesses */ + +dev_t dma_heap_devt; +struct class *dma_heap_class; +struct list_head dma_heap_list; +struct dentry *dma_heap_debug_root; + +/** + * struct dma_heap - represents a dmabuf heap in the system + * @name: used for debugging/device-node name + * @ops: ops struct for this heap + * @minor minor number of this heap device + * @heap_devt heap device node + * @heap_cdev heap char device + * @num_of_buffers the number of currently allocated buffers + * @num_of_all
Re: [EARLY RFC][PATCH 0/4] dmabuf pools infrastructure (destaging ION)
On 2/21/19 1:40 AM, John Stultz wrote: > Here is a very early peek at my dmabuf pools patchset, which > tries to destage a fair chunk of ION functionality. > > This build and boots, but I've not gotten to testing the actual > pool devices yet (need to write some kselftests)! I just wanted > some early feedback on the overall direction. > > The patchset implements per-pool devices (extending my ion > per-heap devices patchset from last week), which can be opened > directly and then an ioctl is used to allocate a dmabuf from the > pool. > > The interface is similar, but simpler then IONs, only providing > an ALLOC ioctl. > > Also, I've only destaged the system/system-contig and cma pools, > since the ION carveout and chunk heaps depended on out of tree > board files to initialize those heaps. I'll leave that to folks > who are actually using those heaps. > > Let me know what you think! > +1 Was this source not pulled from -next, I have some fixes in next that I don't see in this code, so I won't review the code itself just yet (it is and early RFC after all). For the concept itself I have a couple small suggestions: I'm not sure I like the name. "Pool" in the context of DMA-BUF feels like it means something else, like some new feature of DMA-BUFs exporters/importers can use for making buffer pools. How about just keep the "heap" terminology to prevent too much re-wording. Maybe just call this dma-buf/heaps/ ? Although the differed free stuff is nice and should be available, I don't think it needs to be part of the first set of de-staged features. It is a bolt-on feature that can be added later, making this first patchset more simple. In the same way I would like to see the changes suggested in one of the other threads implemented. Basically let the heaps(pools?) provide their own struct dma_buf_ops. If this is to be an extension of dma-buf then it shouldn't be making forcing the use of its own dma_buf_ops like ION did. Instead it should just handle the userspace exporting API only. We can always provide helpers for the basic dma_buf_ops for consistency and code-reuse, but the heaps themselves should have full control if/when to use them. It might be easier to show this all by example, I'll put together my own rough RFC over the weekend if that is okay with you (not trying to walk over your work here or anything, just want to show what I'm thinking if any of the above doesn't make sense) :) Thanks, Andrew > thanks > -john > > Cc: Laura Abbott > Cc: Benjamin Gaignard > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Brian Starkey > Cc: Andrew F. Davis > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: dri-devel@lists.freedesktop.org > > John Stultz (4): > dma-buf: Add dma-buf pools framework > dma-buf: pools: Add page-pool for dma-buf pools > dma-buf: pools: Add system/system-contig pools to dmabuf pools > dma-buf: pools: Add CMA pool to dmabuf pools > > MAINTAINERS | 13 + > drivers/dma-buf/Kconfig | 2 + > drivers/dma-buf/Makefile | 1 + > drivers/dma-buf/pools/Kconfig| 25 ++ > drivers/dma-buf/pools/Makefile | 4 + > drivers/dma-buf/pools/cma_pool.c | 143 > drivers/dma-buf/pools/dmabuf-pools.c | 670 > +++ > drivers/dma-buf/pools/dmabuf-pools.h | 295 +++ > drivers/dma-buf/pools/page_pool.c| 157 > drivers/dma-buf/pools/pool-helpers.c | 317 + > drivers/dma-buf/pools/pool-ioctl.c | 94 + > drivers/dma-buf/pools/system_pool.c | 374 +++ > include/uapi/linux/dmabuf-pools.h| 59 +++ > 13 files changed, 2154 insertions(+) > create mode 100644 drivers/dma-buf/pools/Kconfig > create mode 100644 drivers/dma-buf/pools/Makefile > create mode 100644 drivers/dma-buf/pools/cma_pool.c > create mode 100644 drivers/dma-buf/pools/dmabuf-pools.c > create mode 100644 drivers/dma-buf/pools/dmabuf-pools.h > create mode 100644 drivers/dma-buf/pools/page_pool.c > create mode 100644 drivers/dma-buf/pools/pool-helpers.c > create mode 100644 drivers/dma-buf/pools/pool-ioctl.c > create mode 100644 drivers/dma-buf/pools/system_pool.c > create mode 100644 include/uapi/linux/dmabuf-pools.h > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EARLY RFC][PATCH 3/4] ion: Add HEAP_INFO ioctl to be able to fetch heap type
On 2/19/19 3:13 PM, Laura Abbott wrote:
> On 2/15/19 12:24 PM, John Stultz wrote:
>> The per-device heaps don't support HEAP_QUERY ioctl, since
>> the name is provided in the devnode path and the heapid isn't
>> useful with the new interface (one uses the fd of heapdevice).
>>
>> But, one missing bit of functionality is a way to find the
>> heap type. So provide a HEAP_INFO ioctl which exposes the
>> heap type out so there is the potential for some sort of
>> dynamic heap matching/discovery.
>>
>> Most likely this IOCTL will be useful when extended to allow
>> some sort of opaque constraint bitfield to be shared so userland
>> can match heaps with devices in a fully dynamic way.
>>
>
> We've been waiting on the constraint solving for a while and
> it's never really happened :(
>
Most likely there will never be a one-size-fits-all solution here. So
allowing for an extensible ABI that permits new information to be
exported as needed will be important.
> It certainly works but I'm concerned about adding this and
> then finding (yet again) that it doesn't work. We're
> getting the heap name now but do we lose anything if we
> don't expose it as part of the ABI?
>
We can always add more ioctls, we cant go back and remove the old ones
if we make them too clunky and have to remove something they expose. A
simple starting ABI seems to make the most sense here. Even heap type
doesn't look like a good thing to expose, it is just as static and
one-off as heap name, I don't see it having all that much use :/
Andrew
>> Cc: Laura Abbott
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Brian Starkey
>> Cc: Andrew F. Davis
>> Cc: Alistair Strachan
>> Cc: dri-devel@lists.freedesktop.org
>> Signed-off-by: John Stultz
>> ---
>> drivers/staging/android/ion/ion-ioctl.c | 12
>> drivers/staging/android/uapi/ion.h | 22 ++
>> 2 files changed, 34 insertions(+)
>>
>> diff --git a/drivers/staging/android/ion/ion-ioctl.c
>> b/drivers/staging/android/ion/ion-ioctl.c
>> index ea8d263..6db5969 100644
>> --- a/drivers/staging/android/ion/ion-ioctl.c
>> +++ b/drivers/staging/android/ion/ion-ioctl.c
>> @@ -14,6 +14,7 @@ union ion_ioctl_arg {
>> struct ion_allocation_data allocation;
>> struct ion_heap_allocation_data heap_allocation;
>> struct ion_heap_query query;
>> + struct ion_heap_info heap_info;
>> u32 version;
>> };
>> @@ -149,6 +150,17 @@ long ion_heap_ioctl(struct file *filp, unsigned
>> int cmd, unsigned long arg)
>> break;
>> }
>> + case ION_IOC_HEAP_INFO:
>> + {
>> + struct miscdevice *miscdev = filp->private_data;
>> + struct ion_heap *heap;
>> +
>> + heap = container_of(miscdev, struct ion_heap, heap_dev);
>> +
>> + data.heap_info.type = heap->type;
>> +
>> + break;
>> + }
>> case ION_IOC_VERSION:
>> data.version = ION_VERSION;
>> break;
>> diff --git a/drivers/staging/android/uapi/ion.h
>> b/drivers/staging/android/uapi/ion.h
>> index 20db09f..1b3ca1e 100644
>> --- a/drivers/staging/android/uapi/ion.h
>> +++ b/drivers/staging/android/uapi/ion.h
>> @@ -111,6 +111,19 @@ struct ion_heap_data {
>> };
>> /**
>> + * struct ion_heap_info - Info about the heap
>> + *
>> + */
>> +struct ion_heap_info {
>> + __u32 type;
>> + __u32 reserved0;
>> + __u32 reserved1;
>> + __u32 reserved2;
>> + __u32 reserved3;
>> + __u32 reserved4;
>> +};
>> +
>> +/**
>> * struct ion_heap_query - collection of data about all heaps
>> * @cnt - total number of heaps to be copied
>> * @heaps - buffer to copy heap data
>> @@ -159,4 +172,13 @@ struct ion_heap_query {
>> #define ION_IOC_HEAP_ALLOC _IOWR(ION_IOC_MAGIC, 10, \
>> struct ion_heap_allocation_data)
>> +/**
>> + * DOC: ION_IOC_HEAP_INFO - allocate memory from heap
>> + *
>> + * Takes an ion_heap_query structure and populates information about
>> + * available Ion heaps.
>> + */
>> +#define ION_IOC_HEAP_INFO _IOWR(ION_IOC_MAGIC, 11, \
>> + struct ion_heap_allocation_data)
>> +
>> #endif /* _UAPI_LINUX_ION_H */
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EARLY RFC][PATCH 0/4] ION per heap devices
On 2/19/19 3:25 PM, Laura Abbott wrote: > On 2/15/19 12:24 PM, John Stultz wrote: >> This is a *very early RFC* (it builds, that's all I'll say :) >> but I wanted to share it to get some initial feedback before I >> go down the rabit hole of trying to adapt the Android userland >> code to get this fully validated. >> >> This patchset tries to implement the per-heap devices for ION. >> The main benefit is that it avoids multiplexing heap operations >> through the /dev/ion interface, and allows for each heap to have >> its own permissions/sepolicy rules. >> >> Feedback would be greatly appreciated! >> thanks >> -john >> >> Cc: Laura Abbott >> Cc: Sumit Semwal >> Cc: Liam Mark >> Cc: Brian Starkey >> Cc: Andrew F. Davis >> Cc: Alistair Strachan >> Cc: dri-devel@lists.freedesktop.org >> >> John Stultz (4): >> ion: Add ION_VERSION ioctl >> ion: Initial hack to create per heap devices >> ion: Add HEAP_INFO ioctl to be able to fetch heap type >> ion: Make "legacy" /dev/ion support optional >> >> drivers/staging/android/ion/Kconfig | 7 +++ >> drivers/staging/android/ion/ion-ioctl.c | 80 >> + >> drivers/staging/android/ion/ion.c | 51 - >> drivers/staging/android/ion/ion.h | 6 +++ >> drivers/staging/android/uapi/ion.h | 57 +++ >> 5 files changed, 191 insertions(+), 10 deletions(-) >> > > So it occurs to me if this is going to be a new ABI > all together maybe we should just declare a new allocation ioctl > to be used with it. We can keep the old ioctls around > for legacy use cases and maybe eventually delete them > and just use the new allocation ioctl with the new > split heaps. > Why keep the old ones, this is staging, there are no legacy users (that matter to kernel).. Slowing progress for the sake of backwards compat with staging just slows the de-staging down. Andrew > Thanks, > Laura ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] staging: android: ion: Allocate from heap ID directly without mask
On 2/15/19 1:01 PM, John Stultz wrote:
> On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
>>
>> Hi John,
>>
>> On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
>>>
>> [snip]
>>
>>> Some thoughts, as this ABI break has the potential to be pretty painful.
>>>
>>> 1) Unfortunately, this ABI is exposed *through* libion via
>>> ion_alloc/ion_alloc_fd out to gralloc implementations. Which means it
>>> will have a wider impact to vendor userland code.
>>
>> I figured libion could fairly easily loop through all the set bits in
>> heap_mask and call the ioctl for each until it succeeds. That
>> preserves the old behaviour from the libion clients' perspective.
>
> Potentially, though that implicitly still caps the heaps to 32. So
> I'm not sure what the net benefit would be.
>
That is a libion problem, libion can expose an un-capped API and users
can migrate.
>
>>> 2) For patches that cause ABI breaks, it might be good to make it
>>> clear in the commit what the userland impact looks like in userspace,
>>> possibly with an example, so the poor folks who bisect down the change
>>> as breaking their system in a year or so have a clear example as to
>>> what they need to change in their code.
>>>
>>> 3) Also, its not clear how a given userland should distinguish between
>>> the different ABIs. We already have logic in libion to distinguish
>>> between pre-4.12 legacy and post-4.12 implementations (using implicit
>>> ion_free() behavior). I don't see any such check we can make with this
>>> code. Adding another ABI version may require we provide an actual
>>> interface version ioctl.
>>>
>>
>> A slightly fragile/ugly approach might be to attempt a small
>> allocation with a heap_mask of 0x. On an "old" implementation,
>> you'd expect that to succeed, whereas it would/could be made to fail
>> in the "new" one.
>
> Yea I think having a proper ION_IOC_VERSION is going to be necessary.
>
I think that will be helpful to have ready the future just looking at
the way libdrm does things, but not right now as backwards compatibility
with staging code is not a reasonable thing to do.
> I'm hoping to send out an ugly first stab at the kernel side for
> switching to per-heap devices (with a config for keeping /dev/ion for
> legacy compat), which I hope will address the core issue this patch
> does (moving away from heap masks to specifically requested heaps).
>
Yes, that would remove the need for what this patch does.
Question though, what does the user side look like for this? With the
old /dev/ion we would:
ion_fd = open("/dev/ion")
ask for a list of heaps (ioctl on ion_fd)
iterate over the details of each heap
pick the best heap for the job
request allocation from that heap (ioctl on ion_fd)
with per-heap devs we need some way to iterate all over heap devices in
a system, and extract details from each heap device. Maybe we leave
/dev/ion but it's only job is to service ION_IOC_HEAP_QUERY requests but
instead of heap numbers it returns heap names, then device files just
match those names. Then we go allocate() from those.
If all that is addressed in your patch-set then feel free to ignore this
question :)
Andrew
> thanks
> -john
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] staging: android: ion: Allocate from heap ID directly without mask
On 2/15/19 1:58 PM, John Stultz wrote:
> On Fri, Feb 15, 2019 at 11:22 AM Andrew F. Davis wrote:
>>
>> On 2/15/19 1:01 PM, John Stultz wrote:
>>> On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
>>>> On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
>>>>> 2) For patches that cause ABI breaks, it might be good to make it
>>>>> clear in the commit what the userland impact looks like in userspace,
>>>>> possibly with an example, so the poor folks who bisect down the change
>>>>> as breaking their system in a year or so have a clear example as to
>>>>> what they need to change in their code.
>>>>>
>>>>> 3) Also, its not clear how a given userland should distinguish between
>>>>> the different ABIs. We already have logic in libion to distinguish
>>>>> between pre-4.12 legacy and post-4.12 implementations (using implicit
>>>>> ion_free() behavior). I don't see any such check we can make with this
>>>>> code. Adding another ABI version may require we provide an actual
>>>>> interface version ioctl.
>>>>>
>>>>
>>>> A slightly fragile/ugly approach might be to attempt a small
>>>> allocation with a heap_mask of 0x. On an "old" implementation,
>>>> you'd expect that to succeed, whereas it would/could be made to fail
>>>> in the "new" one.
>>>
>>> Yea I think having a proper ION_IOC_VERSION is going to be necessary.
>>>
>>
>> I think that will be helpful to have ready the future just looking at
>> the way libdrm does things, but not right now as backwards compatibility
>> with staging code is not a reasonable thing to do.
>
> I'm not sure I'm following what you mean here? While we don't have
> any commitment to userland for interfaces in staging, the reality is
> that there are a fair number of users affected, and we probably should
> avoid causing any needless pain if possible.
>
> Further, as part of my work, I try to keep the hikey boards with an
> array of kernels (4.4, 4.9, 4.14, 4.19 and mainline) running with AOSP
> master. Having hard build breaks so AOSP has to have build time
> dependencies on newer or older kernels is a big pain, and the 4.12 ABI
> break was not easy.
>
> So yea, I don't think we should tie our hands in reworking the
> interfaces, but it would be nice to avoid having subtle ABI changes
> that don't have clear ways for userland to detect which interface
> version its using.
>
Let me preference this by pointing out I've dealt with the same pain
internally with our Android and soon to also in AOSP for the Beagle x15
boards[0].. But my stance matches Christoph's in the other ION thread:
https://lkml.org/lkml/2019/1/19/53
The more freely we can make ABI changes here in staging the quicker we
can get this out of staging where the ABI can be locked down.
ION_IOC_VERSION should solve this anyway.
>>> I'm hoping to send out an ugly first stab at the kernel side for
>>> switching to per-heap devices (with a config for keeping /dev/ion for
>>> legacy compat), which I hope will address the core issue this patch
>>> does (moving away from heap masks to specifically requested heaps).
>>>
>>
>> Yes, that would remove the need for what this patch does.
>> Question though, what does the user side look like for this? With the
>> old /dev/ion we would:
>>
>> ion_fd = open("/dev/ion")
>> ask for a list of heaps (ioctl on ion_fd)
>> iterate over the details of each heap
>> pick the best heap for the job
>> request allocation from that heap (ioctl on ion_fd)
>>
>> with per-heap devs we need some way to iterate all over heap devices in
>> a system, and extract details from each heap device. Maybe we leave
>> /dev/ion but it's only job is to service ION_IOC_HEAP_QUERY requests but
>> instead of heap numbers it returns heap names, then device files just
>> match those names. Then we go allocate() from those.
>>
>
>
> So my initial thought is we simply use a /dev/ion_heaps/ dir which has
> a list of heap devicenodes. /dev/ion goes away.
>
> Currently ION_IOC_HEAP_QUERY returns:
> char name[MAX_HEAP_NAME];
> __u32 type;
> __u32 heap_id;
>
> The names are discoverable via "ls /dev/ion_heaps/"
>
> The heap_id is really only useful as a handle, and after opening the
> heap device, we'll have the fd to use.
>
So why have heap_id at all then?
> The only detail we're missing is the type. I'm a little skeptical how
> useful type is, but worse case we p
Re: [PATCH 2/4] staging: android: ion: Restrict cache maintenance to dma mapped memory
On 1/29/19 5:44 PM, Liam Mark wrote:
> On Fri, 18 Jan 2019, Liam Mark wrote:
>
>> On Fri, 18 Jan 2019, Andrew F. Davis wrote:
>>
>>> On 1/18/19 12:37 PM, Liam Mark wrote:
>>>> The ION begin_cpu_access and end_cpu_access functions use the
>>>> dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
>>>> maintenance.
>>>>
>>>> Currently it is possible to apply cache maintenance, via the
>>>> begin_cpu_access and end_cpu_access APIs, to ION buffers which are not
>>>> dma mapped.
>>>>
>>>> The dma sync sg APIs should not be called on sg lists which have not been
>>>> dma mapped as this can result in cache maintenance being applied to the
>>>> wrong address. If an sg list has not been dma mapped then its dma_address
>>>> field has not been populated, some dma ops such as the swiotlb_dma_ops ops
>>>> use the dma_address field to calculate the address onto which to apply
>>>> cache maintenance.
>>>>
>>>> Also I don’t think we want CMOs to be applied to a buffer which is not
>>>> dma mapped as the memory should already be coherent for access from the
>>>> CPU. Any CMOs required for device access taken care of in the
>>>> dma_buf_map_attachment and dma_buf_unmap_attachment calls.
>>>> So really it only makes sense for begin_cpu_access and end_cpu_access to
>>>> apply CMOs if the buffer is dma mapped.
>>>>
>>>> Fix the ION begin_cpu_access and end_cpu_access functions to only apply
>>>> cache maintenance to buffers which are dma mapped.
>>>>
>>>> Fixes: 2a55e7b5e544 ("staging: android: ion: Call dma_map_sg for syncing
>>>> and mapping")
>>>> Signed-off-by: Liam Mark
>>>> ---
>>>> drivers/staging/android/ion/ion.c | 26 +-
>>>> 1 file changed, 21 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/staging/android/ion/ion.c
>>>> b/drivers/staging/android/ion/ion.c
>>>> index 6f5afab7c1a1..1fe633a7fdba 100644
>>>> --- a/drivers/staging/android/ion/ion.c
>>>> +++ b/drivers/staging/android/ion/ion.c
>>>> @@ -210,6 +210,7 @@ struct ion_dma_buf_attachment {
>>>>struct device *dev;
>>>>struct sg_table *table;
>>>>struct list_head list;
>>>> + bool dma_mapped;
>>>> };
>>>>
>>>> static int ion_dma_buf_attach(struct dma_buf *dmabuf,
>>>> @@ -231,6 +232,7 @@ static int ion_dma_buf_attach(struct dma_buf *dmabuf,
>>>>
>>>>a->table = table;
>>>>a->dev = attachment->dev;
>>>> + a->dma_mapped = false;
>>>>INIT_LIST_HEAD(>list);
>>>>
>>>>attachment->priv = a;
>>>> @@ -261,12 +263,18 @@ static struct sg_table *ion_map_dma_buf(struct
>>>> dma_buf_attachment *attachment,
>>>> {
>>>>struct ion_dma_buf_attachment *a = attachment->priv;
>>>>struct sg_table *table;
>>>> + struct ion_buffer *buffer = attachment->dmabuf->priv;
>>>>
>>>>table = a->table;
>>>>
>>>> + mutex_lock(>lock);
>>>>if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
>>>> - direction))
>>>> + direction)) {
>>>> + mutex_unlock(>lock);
>>>>return ERR_PTR(-ENOMEM);
>>>> + }
>>>> + a->dma_mapped = true;
>>>> + mutex_unlock(>lock);
>>>>
>>>>return table;
>>>> }
>>>> @@ -275,7 +283,13 @@ static void ion_unmap_dma_buf(struct
>>>> dma_buf_attachment *attachment,
>>>> struct sg_table *table,
>>>> enum dma_data_direction direction)
>>>> {
>>>> + struct ion_dma_buf_attachment *a = attachment->priv;
>>>> + struct ion_buffer *buffer = attachment->dmabuf->priv;
>>>> +
>>>> + mutex_lock(>lock);
>>>>dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
>>>> + a->dma_mapped = false;
>>>> + mutex_unlock(>lock);
>>>> }
>>>>
>>>> static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
>>>> @@ -346,8 +360,9 @@ static int ion_dma_buf_begin_cpu_a
[PATCH v2] staging: android: ion: Allocate from heap ID directly without mask
Previously the heap to allocate from was selected by a mask of allowed
heap types. This may have been done as a primitive form of constraint
solving, the first heap type that matched any set bit of the heap mask
was allocated from, unless that heap was excluded by having its heap
ID bit not set in the separate passed in heap ID mask.
The heap type does not really represent constraints that should be
matched against to begin with. So the patch [0] removed the the heap type
mask matching but unfortunately left the heap ID mask check (possibly by
mistake or to preserve API). Therefor we now only have a mask of heap
IDs, but heap IDs are unique identifiers and have nothing to do with the
underlying heap, so mask matching is not useful here. This also limits us
to 32 heaps total in a system.
With the heap query API users can find the right heap based on type or
name themselves then just supply the ID for that heap. Remove heap ID
mask and allow users to specify heap ID directly by its number.
I know this is an ABI break, but we are in staging so lets get this over
with now rather than limit ourselves later.
[0] commit 2bb9f5034ec7 ("gpu: ion: Remove heapmask from client")
Signed-off-by: Andrew F. Davis
---
This also means we don't need to store the available heaps in a plist,
we only operation we care about is lookup, so a better data structure
should be chosen at some point, regular list or xarray maybe?
This is base on -next as to be on top of the other taken Ion patches.
Changes from v1:
- Fix spelling in commit message
- Cleanup logic per Brian's suggestion
drivers/staging/android/ion/ion.c | 28 +---
drivers/staging/android/uapi/ion.h | 6 ++
2 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 92c2914239e3..b0b0d0b587c2 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -387,7 +387,7 @@ static const struct dma_buf_ops dma_buf_ops = {
.unmap = ion_dma_buf_kunmap,
};
-static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
+static int ion_alloc(size_t len, unsigned int heap_id, unsigned int flags)
{
struct ion_device *dev = internal_dev;
struct ion_buffer *buffer = NULL;
@@ -396,27 +396,25 @@ static int ion_alloc(size_t len, unsigned int
heap_id_mask, unsigned int flags)
int fd;
struct dma_buf *dmabuf;
- pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
-len, heap_id_mask, flags);
- /*
-* traverse the list of heaps available in this system in priority
-* order. If the heap type is supported by the client, and matches the
-* request of the caller allocate from it. Repeat until allocate has
-* succeeded or all heaps have been tried
-*/
+ pr_debug("%s: len %zu heap_id %u flags %x\n", __func__,
+len, heap_id, flags);
+
len = PAGE_ALIGN(len);
if (!len)
return -EINVAL;
+ /*
+* Traverse the list of heaps available in this system. If the
+* heap id matches the request of the caller allocate from it.
+*/
down_read(>lock);
plist_for_each_entry(heap, >heaps, node) {
- /* if the caller didn't specify this heap id */
- if (!((1 << heap->id) & heap_id_mask))
- continue;
- buffer = ion_buffer_create(heap, dev, len, flags);
- if (!IS_ERR(buffer))
+ /* if the caller specified this heap id */
+ if (heap->id == heap_id) {
+ buffer = ion_buffer_create(heap, dev, len, flags);
break;
+ }
}
up_read(>lock);
@@ -541,7 +539,7 @@ static long ion_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
int fd;
fd = ion_alloc(data.allocation.len,
- data.allocation.heap_id_mask,
+ data.allocation.heap_id,
data.allocation.flags);
if (fd < 0)
return fd;
diff --git a/drivers/staging/android/uapi/ion.h
b/drivers/staging/android/uapi/ion.h
index 5d7009884c13..6a78a1e23251 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -35,8 +35,6 @@ enum ion_heap_type {
*/
};
-#define ION_NUM_HEAP_IDS (sizeof(unsigned int) * 8)
-
/**
* allocation flags - the lower 16 bits are used by core ion, the upper 16
* bits are reserved for use by the heaps themselves.
@@ -59,7 +57,7 @@ enum ion_heap_type {
/**
* struct ion_allocation_data - metadata passed from userspace for allocations
* @len: size of the allocation
Re: [PATCH] staging: android: ion: Allocate from heap ID directly without mask
On 1/24/19 9:24 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Wed, Jan 23, 2019 at 01:28:35PM -0600, Andrew F. Davis wrote:
>> Previously the heap to allocate from was selected by a mask of allowed
>> heap types. This may have been done as a primitive form of constraint
>> solving, the first heap type that matched any set bit of the heap mask
>> was allocated from, unless that heap was excluded by having its heap
>> ID bit not set in the separate passed in heap ID mask.
>
> I checked our gralloc and it's not using the current "keep trying
> until one succeeds" functionality, but it might be worth explicitly
> calling out in the commit message that this will also disappear with
> the new API. Maybe someone cares about that.
>
I couldn't find any users either, I'll make a note anyway.
>>
>> The heap type does not really represent constraints that should be
>> matched against to begin with. So the patch [0] removed the the heap type
>> mask matching but unfortunately left the heap ID mask check (possibly by
>> mistake or to preserve API). Therefor we now only have a mask of heap
>> IDs, but heap IDs are unique identifiers and have nothing to do with the
>> underling heap, so mask matching is not useful here. This also limits us
>
> s/underling/underlying/
>
ACK
>> to 32 heaps total in a system.
>>
>> With the heap query API users can find the right heap based on type or
>> name themselves then just supply the ID for that heap. Remove heap ID
>> mask and allow users to specify heap ID directly by its number.
>>
>> I know this is an ABI break, but we are in staging so lets get this over
>> with now rather than limit ourselves later.
>
> What do you think about renaming ion_allocation_data.unused to heap_id
> and adding a flag instead? It's adding cruft to a staging API, but it
> might soften the transition. The "old way" could get completely
> removed just before destaging. Just a thought.
>
Sounds confusing, backwards compatibility in staging just doesn't seem
like the right thing to do.
Plus I have (probably false) hope that we *are* close destaging. So I
don't want to leave stuff for later.
>>
>> [0] 2bb9f5034ec7 ("gpu: ion: Remove heapmask from client")
>>
>> Signed-off-by: Andrew F. Davis
>> ---
>>
>> This also means we don't need to store the available heaps in a plist,
>> we only operation we care about is lookup, so a better data structure
>> should be chosen at some point, regular list or xarray maybe?
>>
>> This is base on -next as to be on top of the other taken Ion patches.
>>
>> drivers/staging/android/ion/ion.c | 21 ++---
>> drivers/staging/android/uapi/ion.h | 6 ++
>> 2 files changed, 12 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion.c
>> b/drivers/staging/android/ion/ion.c
>> index 92c2914239e3..06dd5bb10ecb 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion.c
>> @@ -387,7 +387,7 @@ static const struct dma_buf_ops dma_buf_ops = {
>> .unmap = ion_dma_buf_kunmap,
>> };
>>
>> -static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int
>> flags)
>> +static int ion_alloc(size_t len, unsigned int heap_id, unsigned int flags)
>> {
>> struct ion_device *dev = internal_dev;
>> struct ion_buffer *buffer = NULL;
>> @@ -396,23 +396,22 @@ static int ion_alloc(size_t len, unsigned int
>> heap_id_mask, unsigned int flags)
>> int fd;
>> struct dma_buf *dmabuf;
>>
>> -pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
>> - len, heap_id_mask, flags);
>> -/*
>> - * traverse the list of heaps available in this system in priority
>> - * order. If the heap type is supported by the client, and matches the
>> - * request of the caller allocate from it. Repeat until allocate has
>> - * succeeded or all heaps have been tried
>> - */
>> +pr_debug("%s: len %zu heap_id %u flags %x\n", __func__,
>> + len, heap_id, flags);
>> +
>> len = PAGE_ALIGN(len);
>>
>> if (!len)
>> return -EINVAL;
>>
>> +/*
>> + * Traverse the list of heaps available in this system. If the
>> + * heap id matches the request of the caller allocate from it.
>> + */
>> down_read(>lock);
>> plist_for_each_entry(heap, >heaps, node) {
>> /* if the caller didn't specify this heap id
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/23/19 11:11 AM, Brian Starkey wrote: > Hi Andrew, > > On Wed, Jan 23, 2019 at 10:51:24AM -0600, Andrew F. Davis wrote: >> On 1/22/19 11:33 AM, Sumit Semwal wrote: >>> Hello everyone, >>> >>> Sincere apologies for chiming in a bit late here, but was off due to >>> some health issues. >>> >> >> Hope you are feeling better friend :) >> >> Looks like this email was a bit broken and you replied again, the >> responses are a little different in each email, so I'd like to respond >> to bits of both, I'll fix up the formatting. >> >>> Also, adding Daniel Vetter to the mix, since he has been one of the >>> core guys who shaped up dma-buf as it is today. >>> >>> On Tue, 22 Jan 2019 at 02:51, Andrew F. Davis wrote: >>>> >>>> On 1/21/19 5:22 AM, Brian Starkey wrote: >> >> [snip] >> >>>>> >>>>> Actually I meant in the kernel, in exporters. I haven't seen anyone >>>>> using the API as it was intended (defer allocation until first map, >>>>> migrate between different attachments, etc.). Mostly, backing storage >>>>> seems to get allocated at the point of export, and device mappings are >>>>> often held persistently (e.g. the DRM prime code maps the buffer at >>>>> import time, and keeps it mapped: drm_gem_prime_import_dev). >>>>> >>>> >>> >>> So I suppose some clarification on the 'intended use' part of dma-buf >>> about deferred allocation is due, so here it is: (Daniel, please feel >>> free to chime in with your opinion here) >>> >>> - dma-buf was of course designed as a framework to help intelligent >>> exporters to defer allocation until first map, and be able to migrate >>> backing storage if required etc. At the same time, it is not a >>> _requirement_ from any exporter, so exporters so far have just used it >>> as a convenient mechanism for zero-copy. >>> - ION is one of the few dma-buf exporters in kernel, which satisfies a >>> certain set of expectations from its users. >>> >> >> The issue here is that Ion is blocking the ability to late allocate, it >> expects its heaps to have the memory ready at allocation time. My point >> being if the DMA-BUFs intended design was to allow this then Ion should >> respect that and also allow the same from its heap exporters. >> >>>> I haven't either, which is a shame as it allows for some really useful >>>> management strategies for shared memory resources. I'm working on one >>>> such case right now, maybe I'll get to be the first to upstream one :) >>>> >>> That will be a really good thing! Though perhaps we ought to think if >>> for what you're trying to do, is ION the right place, or should you >>> have a device-specific exporter, available to users via dma-buf apis? >>> >> >> I'm starting to question if Ion is the right place myself.. >> >> At a conceptual level I don't believe userspace should be picking the >> backing memory type. This is because the right type of backing memory >> for a task will change from system to system. The kernel should abstract >> away these hardware differences from userspace as much as it can to >> allow portable code. >> >> For instance a device may need a contiguous buffer on one system but the >> same device on another may have some IOMMU. So which type of memory do >> we allocate? Same issue for cacheability and other properties. >> >> What we need is a central allocator with full system knowledge to do the >> choosing for us. It seems many agree with the above and I take >> inspiration from your cenalloc patchset. The thing I'm not sure about is >> letting the device drivers set their constraints, because they also >> don't have the full system integration details. For cases where devices >> are behind an IOMMU it is easy enough for the device to know, but what >> about when we have external MMUs out on the bus for anyone to use (I'm >> guessing you remember TILER..). >> >> I would propose the central allocator keep per-system knowledge (or >> fetch it from DT, or if this is considered policy then userspace) which >> it can use to directly check the attached devices and pick the right memory. >> >> Anyway the central system allocator could handle 90% of cases I can >> think of, and this is where Ion comes back in, the other cases would >> still require the program to manually pick the right memory (maybe for >>
[PATCH] staging: android: ion: Allocate from heap ID directly without mask
Previously the heap to allocate from was selected by a mask of allowed
heap types. This may have been done as a primitive form of constraint
solving, the first heap type that matched any set bit of the heap mask
was allocated from, unless that heap was excluded by having its heap
ID bit not set in the separate passed in heap ID mask.
The heap type does not really represent constraints that should be
matched against to begin with. So the patch [0] removed the the heap type
mask matching but unfortunately left the heap ID mask check (possibly by
mistake or to preserve API). Therefor we now only have a mask of heap
IDs, but heap IDs are unique identifiers and have nothing to do with the
underling heap, so mask matching is not useful here. This also limits us
to 32 heaps total in a system.
With the heap query API users can find the right heap based on type or
name themselves then just supply the ID for that heap. Remove heap ID
mask and allow users to specify heap ID directly by its number.
I know this is an ABI break, but we are in staging so lets get this over
with now rather than limit ourselves later.
[0] 2bb9f5034ec7 ("gpu: ion: Remove heapmask from client")
Signed-off-by: Andrew F. Davis
---
This also means we don't need to store the available heaps in a plist,
we only operation we care about is lookup, so a better data structure
should be chosen at some point, regular list or xarray maybe?
This is base on -next as to be on top of the other taken Ion patches.
drivers/staging/android/ion/ion.c | 21 ++---
drivers/staging/android/uapi/ion.h | 6 ++
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 92c2914239e3..06dd5bb10ecb 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -387,7 +387,7 @@ static const struct dma_buf_ops dma_buf_ops = {
.unmap = ion_dma_buf_kunmap,
};
-static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
+static int ion_alloc(size_t len, unsigned int heap_id, unsigned int flags)
{
struct ion_device *dev = internal_dev;
struct ion_buffer *buffer = NULL;
@@ -396,23 +396,22 @@ static int ion_alloc(size_t len, unsigned int
heap_id_mask, unsigned int flags)
int fd;
struct dma_buf *dmabuf;
- pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
-len, heap_id_mask, flags);
- /*
-* traverse the list of heaps available in this system in priority
-* order. If the heap type is supported by the client, and matches the
-* request of the caller allocate from it. Repeat until allocate has
-* succeeded or all heaps have been tried
-*/
+ pr_debug("%s: len %zu heap_id %u flags %x\n", __func__,
+len, heap_id, flags);
+
len = PAGE_ALIGN(len);
if (!len)
return -EINVAL;
+ /*
+* Traverse the list of heaps available in this system. If the
+* heap id matches the request of the caller allocate from it.
+*/
down_read(>lock);
plist_for_each_entry(heap, >heaps, node) {
/* if the caller didn't specify this heap id */
- if (!((1 << heap->id) & heap_id_mask))
+ if (heap->id != heap_id)
continue;
buffer = ion_buffer_create(heap, dev, len, flags);
if (!IS_ERR(buffer))
@@ -541,7 +540,7 @@ static long ion_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
int fd;
fd = ion_alloc(data.allocation.len,
- data.allocation.heap_id_mask,
+ data.allocation.heap_id,
data.allocation.flags);
if (fd < 0)
return fd;
diff --git a/drivers/staging/android/uapi/ion.h
b/drivers/staging/android/uapi/ion.h
index 5d7009884c13..6a78a1e23251 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -35,8 +35,6 @@ enum ion_heap_type {
*/
};
-#define ION_NUM_HEAP_IDS (sizeof(unsigned int) * 8)
-
/**
* allocation flags - the lower 16 bits are used by core ion, the upper 16
* bits are reserved for use by the heaps themselves.
@@ -59,7 +57,7 @@ enum ion_heap_type {
/**
* struct ion_allocation_data - metadata passed from userspace for allocations
* @len: size of the allocation
- * @heap_id_mask: mask of heap ids to allocate from
+ * @heap_id: heap id to allocate from
* @flags: flags passed to heap
* @handle:pointer that will be populated with a cookie to use to
* refer to this allocation
@@ -68,7 +66,7 @@ enum ion_heap_type {
*/
struct
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/22/19 9:23 PM, Sumit Semwal wrote: > Hello everyone, > > (Thanks to Dan for letting me know my last email got corrupted :/ - > resending it here) > Hmm, this one seems a bit messed up also (Thunderbird doesn't seem to like it at least). [snip] > - from dma-buf PoV, ION is an exporter of dma-buf buffers, for its users > that have specific requirements. > This is what I'm hoping to change up a little bit, Ion shouldn't be the exporter, its heaps should be the exporters (manage the dma_buf_ops), Ion would only do advertising of available heaps and allow allocating DMA-BUFs from them. IMO that would clear up the other discussions going on right now about how Ion should handle different dma-buf syncing tasks, it simply wouldn't :). Plus Ion core gets slimmed down, maybe even enough for destaging.. >> I haven't either, which is a shame as it allows for some really useful >> management strategies for shared memory resources. I'm working on one >> such case right now, maybe I'll get to be the first to upstream one :) >> > Yes, it would, and great that you're looking to be the first one to do it :) > >> > I wasn't aware that CPU access before first device access was >> > considered an abuse of the API - it seems like a valid thing to want >> > to do. >> > >> >> That's just it, I don't know if it is an abuse of API, I'm trying to get >> some clarity on that. If we do want to allow early CPU access then that >> seems to be in contrast to the idea of deferred allocation until first >> device map, what is supposed to backing the buffer if no devices have >> attached or mapped yet? Just some system memory followed by migration on >> the first attach to the proper backing? Seems too time wasteful to be >> have a valid use. >> >> Maybe it should be up to the exporter if early CPU access is allowed? >> >> I'm hoping someone with authority over the DMA-BUF framework can clarify >> original intentions here. >> > > I suppose dma-buf as a framework can't know or decide what the exporter > wants or can do - whether the exporter wants to use it for 'only > zero-copy', or do some intelligent things behind the scene, I think > should be best left to the exporter. > > Hope this helps, Yes, these inputs are very helpful, thanks, Andrew > Sumit. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/22/19 11:33 AM, Sumit Semwal wrote: > Hello everyone, > > Sincere apologies for chiming in a bit late here, but was off due to > some health issues. > Hope you are feeling better friend :) Looks like this email was a bit broken and you replied again, the responses are a little different in each email, so I'd like to respond to bits of both, I'll fix up the formatting. > Also, adding Daniel Vetter to the mix, since he has been one of the > core guys who shaped up dma-buf as it is today. > > On Tue, 22 Jan 2019 at 02:51, Andrew F. Davis wrote: >> >> On 1/21/19 5:22 AM, Brian Starkey wrote: [snip] >>> >>> Actually I meant in the kernel, in exporters. I haven't seen anyone >>> using the API as it was intended (defer allocation until first map, >>> migrate between different attachments, etc.). Mostly, backing storage >>> seems to get allocated at the point of export, and device mappings are >>> often held persistently (e.g. the DRM prime code maps the buffer at >>> import time, and keeps it mapped: drm_gem_prime_import_dev). >>> >> > > So I suppose some clarification on the 'intended use' part of dma-buf > about deferred allocation is due, so here it is: (Daniel, please feel > free to chime in with your opinion here) > > - dma-buf was of course designed as a framework to help intelligent > exporters to defer allocation until first map, and be able to migrate > backing storage if required etc. At the same time, it is not a > _requirement_ from any exporter, so exporters so far have just used it > as a convenient mechanism for zero-copy. > - ION is one of the few dma-buf exporters in kernel, which satisfies a > certain set of expectations from its users. > The issue here is that Ion is blocking the ability to late allocate, it expects its heaps to have the memory ready at allocation time. My point being if the DMA-BUFs intended design was to allow this then Ion should respect that and also allow the same from its heap exporters. >> I haven't either, which is a shame as it allows for some really useful >> management strategies for shared memory resources. I'm working on one >> such case right now, maybe I'll get to be the first to upstream one :) >> > That will be a really good thing! Though perhaps we ought to think if > for what you're trying to do, is ION the right place, or should you > have a device-specific exporter, available to users via dma-buf apis? > I'm starting to question if Ion is the right place myself.. At a conceptual level I don't believe userspace should be picking the backing memory type. This is because the right type of backing memory for a task will change from system to system. The kernel should abstract away these hardware differences from userspace as much as it can to allow portable code. For instance a device may need a contiguous buffer on one system but the same device on another may have some IOMMU. So which type of memory do we allocate? Same issue for cacheability and other properties. What we need is a central allocator with full system knowledge to do the choosing for us. It seems many agree with the above and I take inspiration from your cenalloc patchset. The thing I'm not sure about is letting the device drivers set their constraints, because they also don't have the full system integration details. For cases where devices are behind an IOMMU it is easy enough for the device to know, but what about when we have external MMUs out on the bus for anyone to use (I'm guessing you remember TILER..). I would propose the central allocator keep per-system knowledge (or fetch it from DT, or if this is considered policy then userspace) which it can use to directly check the attached devices and pick the right memory. Anyway the central system allocator could handle 90% of cases I can think of, and this is where Ion comes back in, the other cases would still require the program to manually pick the right memory (maybe for performance reasons, etc.). So my vision is to have Ion as the the main front-end for DMA-BUF allocations, and expose the central allocator through it (maybe as a default heap type that can be populated on a per-system basis), but also have other individual heap types exported for the edge cases where manual selection is needed like we do now. Hence why Ion should allow direct control of the dma_buf_ops from the heaps, so we can build central allocators as Ion heaps. If I'm off into the weeds here and you have some other ideas I'm all ears. Andrew >>> I wasn't aware that CPU access before first device access was >>> considered an abuse of the API - it seems like a valid thing to want >>> to do. >>> >> >> That's just it, I don't know if it is an abuse of API, I'm trying to get >> some clarity on
Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes
On 1/21/19 4:12 PM, Liam Mark wrote: > On Mon, 21 Jan 2019, Christoph Hellwig wrote: > >> On Mon, Jan 21, 2019 at 11:44:10AM -0800, Liam Mark wrote: >>> The main use case is for allowing clients to pass in >>> DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance >>> which happens in dma_buf_map_attachment and dma_buf_unmap_attachment. In >>> ION the buffers aren't usually accessed from the CPU so this allows >>> clients to often avoid doing unnecessary cache maintenance. >> >> This can't work. The cpu can still easily speculate into this area. > > Can you provide more detail on your concern here. > The use case I am thinking about here is a cached buffer which is accessed > by a non IO-coherent device (quite a common use case for ION). > > Guessing on your concern: > The speculative access can be an issue if you are going to access the > buffer from the CPU after the device has written to it, however if you > know you aren't going to do any CPU access before the buffer is again > returned to the device then I don't think the speculative access is a > concern. > >> Moreover in general these operations should be cheap if the addresses >> aren't cached. >> > > I am thinking of use cases with cached buffers here, so CMO isn't cheap. > These buffers are cacheable, not cached, if you haven't written anything the data wont actually be in cache. And in the case of speculative cache filling the lines are marked clean. In either case the only cost is the little 7 instruction loop calling the clean/invalidate instruction (dc civac for ARMv8) for the cache-lines. Unless that is the cost you are trying to avoid? In that case if you are mapping and unmapping so much that the little CMO here is hurting performance then I would argue your usage is broken and needs to be re-worked a bit. Andrew > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes
On 1/21/19 4:18 PM, Liam Mark wrote: > On Mon, 21 Jan 2019, Andrew F. Davis wrote: > >> On 1/21/19 2:20 PM, Liam Mark wrote: >>> On Mon, 21 Jan 2019, Andrew F. Davis wrote: >>> >>>> On 1/21/19 1:44 PM, Liam Mark wrote: >>>>> On Mon, 21 Jan 2019, Christoph Hellwig wrote: >>>>> >>>>>> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote: >>>>>>>> And who is going to decide which ones to pass? And who documents >>>>>>>> which ones are safe? >>>>>>>> >>>>>>>> I'd much rather have explicit, well documented dma-buf flags that >>>>>>>> might get translated to the DMA API flags, which are not error checked, >>>>>>>> not very well documented and way to easy to get wrong. >>>>>>>> >>>>>>> >>>>>>> I'm not sure having flags in dma-buf really solves anything >>>>>>> given drivers can use the attributes directly with dma_map >>>>>>> anyway, which is what we're looking to do. The intention >>>>>>> is for the driver creating the dma_buf attachment to have >>>>>>> the knowledge of which flags to use. >>>>>> >>>>>> Well, there are very few flags that you can simply use for all calls of >>>>>> dma_map*. And given how badly these flags are defined I just don't want >>>>>> people to add more places where they indirectly use these flags, as >>>>>> it will be more than enough work to clean up the current mess. >>>>>> >>>>>> What flag(s) do you want to pass this way, btw? Maybe that is where >>>>>> the problem is. >>>>>> >>>>> >>>>> The main use case is for allowing clients to pass in >>>>> DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance >>>>> which happens in dma_buf_map_attachment and dma_buf_unmap_attachment. In >>>>> ION the buffers aren't usually accessed from the CPU so this allows >>>>> clients to often avoid doing unnecessary cache maintenance. >>>>> >>>> >>>> How can a client know that no CPU access has occurred that needs to be >>>> flushed out? >>>> >>> >>> I have left this to clients, but if they own the buffer they can have the >>> knowledge as to whether CPU access is needed in that use case (example for >>> post-processing). >>> >>> For example with the previous version of ION we left all decisions of >>> whether cache maintenance was required up to the client, they would use >>> the ION cache maintenance IOCTL to force cache maintenance only when it >>> was required. >>> In these cases almost all of the access was being done by the device and >>> in the rare cases CPU access was required clients would initiate the >>> required cache maintenance before and after the CPU access. >>> >> >> I think we have different definitions of "client", I'm talking about the >> DMA-BUF client (the importer), that is who can set this flag. It seems >> you mean the userspace application, which has no control over this flag. >> > > I am also talking about dma-buf clients, I am referring to both the > userspace and kernel component of the client. For example our Camera ION > client has both a usersapce and kernel component and they have ION > buffers, which they control the access to, which may or may not be > accessed by the CPU in certain uses cases. > I know they often work together, but for this discussion it would be good to keep kernel clients and usperspace clients separate. There are three types of actors at play here, userspace clients, kernel clients, and exporters. DMA-BUF only provides the basic sync primitive + mmap directly to userspace, both operations are fulfilled by the exporter. This patch is about adding more control to the kernel side clients. The kernel side clients cannot know what userspace or other kernel side clients have done with the buffer, *only* the exporter has the whole picture. Therefor neither type of client should be deciding if the CPU needs flushed or not, only the exporter, based on the type of buffer, the current set attachments, and previous actions (is this first attachment, CPU get access in-between, etc...) can make this decision. You goal seems to be to avoid unneeded CPU side CMOs when a device detaches and another attaches with no CPU access in-between, right? That's reasonable to me, but it must be the exporter who keeps track and skips the CMO. This patch allows the client to tell the exporter the CMO is not needed and that is not safe. Andrew > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/21/19 5:22 AM, Brian Starkey wrote:
> Hi,
>
> Sorry for being a bit sporadic on this. I was out travelling last week
> with little time for email.
>
> On Fri, Jan 18, 2019 at 11:16:31AM -0600, Andrew F. Davis wrote:
>> On 1/17/19 7:11 PM, Liam Mark wrote:
>>> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/16/19 4:54 PM, Liam Mark wrote:
>>>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>>>
>>>>>> On 1/16/19 9:19 AM, Brian Starkey wrote:
>>>>>>> Hi :-)
>>>>>>>
>>>>>>> On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew F. Davis wrote:
>>>>>>>> On 1/15/19 12:38 PM, Andrew F. Davis wrote:
>>>>>>>>> On 1/15/19 11:45 AM, Liam Mark wrote:
>>>>>>>>>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>>>>>>>>>>
>>>>>>>>>>> On 1/14/19 11:13 AM, Liam Mark wrote:
>>>>>>>>>>>> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Buffers may not be mapped from the CPU so skip cache maintenance
>>>>>>>>>>>>> here.
>>>>>>>>>>>>> Accesses from the CPU to a cached heap should be bracketed with
>>>>>>>>>>>>> {begin,end}_cpu_access calls so maintenance should not be needed
>>>>>>>>>>>>> anyway.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Andrew F. Davis
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> drivers/staging/android/ion/ion.c | 7 ---
>>>>>>>>>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/drivers/staging/android/ion/ion.c
>>>>>>>>>>>>> b/drivers/staging/android/ion/ion.c
>>>>>>>>>>>>> index 14e48f6eb734..09cb5a8e2b09 100644
>>>>>>>>>>>>> --- a/drivers/staging/android/ion/ion.c
>>>>>>>>>>>>> +++ b/drivers/staging/android/ion/ion.c
>>>>>>>>>>>>> @@ -261,8 +261,8 @@ static struct sg_table
>>>>>>>>>>>>> *ion_map_dma_buf(struct dma_buf_attachment *attachment,
>>>>>>>>>>>>>
>>>>>>>>>>>>> table = a->table;
>>>>>>>>>>>>>
>>>>>>>>>>>>> - if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
>>>>>>>>>>>>> - direction))
>>>>>>>>>>>>> + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
>>>>>>>>>>>>> + direction, DMA_ATTR_SKIP_CPU_SYNC))
>>>>>>>>>>>>
>>>>>>>>>>>> Unfortunately I don't think you can do this for a couple reasons.
>>>>>>>>>>>> You can't rely on {begin,end}_cpu_access calls to do cache
>>>>>>>>>>>> maintenance.
>>>>>>>>>>>> If the calls to {begin,end}_cpu_access were made before the call
>>>>>>>>>>>> to
>>>>>>>>>>>> dma_buf_attach then there won't have been a device attached so the
>>>>>>>>>>>> calls
>>>>>>>>>>>> to {begin,end}_cpu_access won't have done any cache maintenance.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That should be okay though, if you have no attachments (or all
>>>>>>>>>>> attachments are IO-coherent) then there is no need for cache
>>>>>>>>>>> maintenance. Unless you mean a sequence where a non-io-coherent
>>>>>>>>>>> device
>>>>>>>>>>> is attached later after data has already been written. Does that
>>>>>>>>>>> sequence need supporting?
>>>>>>>>>>
>>>>>>>>>> Yes, but
Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes
On 1/21/19 2:20 PM, Liam Mark wrote: > On Mon, 21 Jan 2019, Andrew F. Davis wrote: > >> On 1/21/19 1:44 PM, Liam Mark wrote: >>> On Mon, 21 Jan 2019, Christoph Hellwig wrote: >>> >>>> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote: >>>>>> And who is going to decide which ones to pass? And who documents >>>>>> which ones are safe? >>>>>> >>>>>> I'd much rather have explicit, well documented dma-buf flags that >>>>>> might get translated to the DMA API flags, which are not error checked, >>>>>> not very well documented and way to easy to get wrong. >>>>>> >>>>> >>>>> I'm not sure having flags in dma-buf really solves anything >>>>> given drivers can use the attributes directly with dma_map >>>>> anyway, which is what we're looking to do. The intention >>>>> is for the driver creating the dma_buf attachment to have >>>>> the knowledge of which flags to use. >>>> >>>> Well, there are very few flags that you can simply use for all calls of >>>> dma_map*. And given how badly these flags are defined I just don't want >>>> people to add more places where they indirectly use these flags, as >>>> it will be more than enough work to clean up the current mess. >>>> >>>> What flag(s) do you want to pass this way, btw? Maybe that is where >>>> the problem is. >>>> >>> >>> The main use case is for allowing clients to pass in >>> DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance >>> which happens in dma_buf_map_attachment and dma_buf_unmap_attachment. In >>> ION the buffers aren't usually accessed from the CPU so this allows >>> clients to often avoid doing unnecessary cache maintenance. >>> >> >> How can a client know that no CPU access has occurred that needs to be >> flushed out? >> > > I have left this to clients, but if they own the buffer they can have the > knowledge as to whether CPU access is needed in that use case (example for > post-processing). > > For example with the previous version of ION we left all decisions of > whether cache maintenance was required up to the client, they would use > the ION cache maintenance IOCTL to force cache maintenance only when it > was required. > In these cases almost all of the access was being done by the device and > in the rare cases CPU access was required clients would initiate the > required cache maintenance before and after the CPU access. > I think we have different definitions of "client", I'm talking about the DMA-BUF client (the importer), that is who can set this flag. It seems you mean the userspace application, which has no control over this flag. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes
On 1/21/19 1:44 PM, Liam Mark wrote: > On Mon, 21 Jan 2019, Christoph Hellwig wrote: > >> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote: And who is going to decide which ones to pass? And who documents which ones are safe? I'd much rather have explicit, well documented dma-buf flags that might get translated to the DMA API flags, which are not error checked, not very well documented and way to easy to get wrong. >>> >>> I'm not sure having flags in dma-buf really solves anything >>> given drivers can use the attributes directly with dma_map >>> anyway, which is what we're looking to do. The intention >>> is for the driver creating the dma_buf attachment to have >>> the knowledge of which flags to use. >> >> Well, there are very few flags that you can simply use for all calls of >> dma_map*. And given how badly these flags are defined I just don't want >> people to add more places where they indirectly use these flags, as >> it will be more than enough work to clean up the current mess. >> >> What flag(s) do you want to pass this way, btw? Maybe that is where >> the problem is. >> > > The main use case is for allowing clients to pass in > DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance > which happens in dma_buf_map_attachment and dma_buf_unmap_attachment. In > ION the buffers aren't usually accessed from the CPU so this allows > clients to often avoid doing unnecessary cache maintenance. > How can a client know that no CPU access has occurred that needs to be flushed out? > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/18/19 3:43 PM, Liam Mark wrote:
> On Fri, 18 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/17/19 7:04 PM, Liam Mark wrote:
>>> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/16/19 4:48 PM, Liam Mark wrote:
>>>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>>>
>>>>>> On 1/15/19 1:05 PM, Laura Abbott wrote:
>>>>>>> On 1/15/19 10:38 AM, Andrew F. Davis wrote:
>>>>>>>> On 1/15/19 11:45 AM, Liam Mark wrote:
>>>>>>>>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>>>>>>>>>
>>>>>>>>>> On 1/14/19 11:13 AM, Liam Mark wrote:
>>>>>>>>>>> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Buffers may not be mapped from the CPU so skip cache maintenance
>>>>>>>>>>>> here.
>>>>>>>>>>>> Accesses from the CPU to a cached heap should be bracketed with
>>>>>>>>>>>> {begin,end}_cpu_access calls so maintenance should not be needed
>>>>>>>>>>>> anyway.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Andrew F. Davis
>>>>>>>>>>>> ---
>>>>>>>>>>>> drivers/staging/android/ion/ion.c | 7 ---
>>>>>>>>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/staging/android/ion/ion.c
>>>>>>>>>>>> b/drivers/staging/android/ion/ion.c
>>>>>>>>>>>> index 14e48f6eb734..09cb5a8e2b09 100644
>>>>>>>>>>>> --- a/drivers/staging/android/ion/ion.c
>>>>>>>>>>>> +++ b/drivers/staging/android/ion/ion.c
>>>>>>>>>>>> @@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct
>>>>>>>>>>>> dma_buf_attachment *attachment,
>>>>>>>>>>>> table = a->table;
>>>>>>>>>>>> - if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
>>>>>>>>>>>> - direction))
>>>>>>>>>>>> + if (!dma_map_sg_attrs(attachment->dev, table->sgl,
>>>>>>>>>>>> table->nents,
>>>>>>>>>>>> + direction, DMA_ATTR_SKIP_CPU_SYNC))
>>>>>>>>>>>
>>>>>>>>>>> Unfortunately I don't think you can do this for a couple reasons.
>>>>>>>>>>> You can't rely on {begin,end}_cpu_access calls to do cache
>>>>>>>>>>> maintenance.
>>>>>>>>>>> If the calls to {begin,end}_cpu_access were made before the call to
>>>>>>>>>>> dma_buf_attach then there won't have been a device attached so the
>>>>>>>>>>> calls
>>>>>>>>>>> to {begin,end}_cpu_access won't have done any cache maintenance.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That should be okay though, if you have no attachments (or all
>>>>>>>>>> attachments are IO-coherent) then there is no need for cache
>>>>>>>>>> maintenance. Unless you mean a sequence where a non-io-coherent
>>>>>>>>>> device
>>>>>>>>>> is attached later after data has already been written. Does that
>>>>>>>>>> sequence need supporting?
>>>>>>>>>
>>>>>>>>> Yes, but also I think there are cases where CPU access can happen
>>>>>>>>> before
>>>>>>>>> in Android, but I will focus on later for now.
>>>>>>>>>
>>>>>>>>>> DMA-BUF doesn't have to allocate the backing
>>>>>>>>>> memory until map_dma_buf() time, and that should only happen after
>>>>>>>>>> all
>>>>>>>>>> the devices have attached so it can know where to put the buffer. So
>>>>>>>>>> w
Re: [PATCH 00/14] Misc ION cleanups and adding unmapped heap
On 1/18/19 2:19 PM, Laura Abbott wrote: > On 1/16/19 8:05 AM, Andrew F. Davis wrote: >> On 1/15/19 12:58 PM, Laura Abbott wrote: >>> On 1/15/19 9:47 AM, Andrew F. Davis wrote: >>>> On 1/14/19 8:39 PM, Laura Abbott wrote: >>>>> On 1/11/19 10:05 AM, Andrew F. Davis wrote: >>>>>> Hello all, >>>>>> >>>>>> This is a set of (hopefully) non-controversial cleanups for the ION >>>>>> framework and current set of heaps. These were found as I start to >>>>>> familiarize myself with the framework to help in whatever way I >>>>>> can in getting all this up to the standards needed for de-staging. >>>>>> >>>>>> I would like to get some ideas of what is left to work on to get ION >>>>>> out of staging. Has there been some kind of agreement on what ION >>>>>> should >>>>>> eventually end up being? To me it looks like it is being whittled >>>>>> away at >>>>>> to it's most core functions. To me that is looking like being a >>>>>> DMA-BUF >>>>>> user-space front end, simply advertising available memory backings >>>>>> in a >>>>>> system and providing allocations as DMA-BUF handles. If this is the >>>>>> case >>>>>> then it looks close to being ready to me at least, but I would >>>>>> love to >>>>>> hear any other opinions and concerns. >>>>>> >>>>> >>>>> Yes, at this point the only functionality that people are really >>>>> depending on is the ability to allocate a dma_buf easily from >>>>> userspace. >>>>> >>>>>> Back to this patchset, the last patch may be a bit different than the >>>>>> others, it adds an unmapped heaps type and creation helper. I >>>>>> wanted to >>>>>> get this in to show off another heap type and maybe some issues we >>>>>> may >>>>>> have with the current ION framework. The unmapped heap is used >>>>>> when the >>>>>> backing memory should not (or cannot) be touched. Currently this kind >>>>>> of heap is used for firewalled secure memory that can be allocated >>>>>> like >>>>>> normal heap memory but only used by secure devices (OP-TEE, crypto >>>>>> HW, >>>>>> etc). It is basically just copied from the "carveout" heap type with >>>>>> the >>>>>> only difference being it is not mappable to userspace and we do not >>>>>> clear >>>>>> the memory (as we should not map it either). So should this really >>>>>> be a >>>>>> new heap type? Or maybe advertised as a carveout heap but with an >>>>>> additional allocation flag? Perhaps we do away with "types" >>>>>> altogether >>>>>> and just have flags, coherent/non-coherent, mapped/unmapped, etc. >>>>>> >>>>>> Maybe more thinking will be needed afterall.. >>>>>> >>>>> >>>>> So the cleanup looks okay (I need to finish reviewing) but I'm not a >>>>> fan of adding another heaptype without solving the problem of adding >>>>> some sort of devicetree binding or other method of allocating and >>>>> placing Ion heaps. That plus uncached buffers are one of the big >>>>> open problems that need to be solved for destaging Ion. See >>>>> https://lore.kernel.org/lkml/20181120164636.jcw7li2uaa3cmwc3@DESKTOP-E1NTVVP.localdomain/ >>>>> >>>>> >>>>> >>>>> for some background on that problem. >>>>> >>>> >>>> I'm under the impression that adding heaps like carveouts/chunk will be >>>> rather system specific and so do not lend themselves well to a >>>> universal >>>> DT style exporter. For instance a carveout memory space can be reported >>>> by a device at runtime, then the driver managing that device should go >>>> and use the carveout heap helpers to export that heap. If this is the >>>> case then I'm not sure it is a problem for the ION core framework to >>>> solve, but rather the users of it to figure out how best to create the >>>> various heaps. All Ion needs to do is allow exporting and advertising >>>
Re: [PATCH 11/14] staging: android: ion: Allow heap name to be null
On 1/18/19 1:53 PM, Laura Abbott wrote: > On 1/16/19 9:12 AM, Andrew F. Davis wrote: >> On 1/16/19 9:28 AM, Brian Starkey wrote: >>> Hi Andrew, >>> >>> On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote: >>>> The heap name can be used for debugging but otherwise does not seem >>>> to be required and no other part of the code will fail if left NULL >>>> except here. We can make it required and check for it at some point, >>>> for now lets just prevent this from causing a NULL pointer exception. >>> >>> I'm not so keen on this one. In the "new" API with heap querying, the >>> name string is the only way to identify the heap. I think Laura >>> mentioned at XDC2017 that it was expected that userspace should use >>> the strings to find the heap they want. >>> >> >> Right now the names are only for debug. I accidentally left the name >> null once and got a kernel crash. This is the only spot where it is >> needed so I fixed it up. The other option is to make the name mandatory >> and properly error out, I don't want to do that right now until the >> below discussion is had to see if names really do matter or not. >> > > Yes, the heap names are part of the query API and are the expected > way to identify individual heaps for the API at the moment so having > a null heap name is incorrect. The heap name seemed like the best way > to identify heaps to userspace but if you have an alternative proposal > I'd be interested. > Not sure I have a better proposal right now, I'll re-work this patch to force heap names to be populated before ion_device_add_heap() instead. (do you think that function name is now is a misnomer? how do you feel about renaming that to just ion_add_heap()?) Andrew > Thanks, > Laura > >> > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/18/19 2:31 PM, Laura Abbott wrote:
> On 1/17/19 8:13 AM, Andrew F. Davis wrote:
>> On 1/16/19 4:48 PM, Liam Mark wrote:
>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/15/19 1:05 PM, Laura Abbott wrote:
>>>>> On 1/15/19 10:38 AM, Andrew F. Davis wrote:
>>>>>> On 1/15/19 11:45 AM, Liam Mark wrote:
>>>>>>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>>>>>>>
>>>>>>>> On 1/14/19 11:13 AM, Liam Mark wrote:
>>>>>>>>> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>>>>>>>>>
>>>>>>>>>> Buffers may not be mapped from the CPU so skip cache maintenance
>>>>>>>>>> here.
>>>>>>>>>> Accesses from the CPU to a cached heap should be bracketed with
>>>>>>>>>> {begin,end}_cpu_access calls so maintenance should not be needed
>>>>>>>>>> anyway.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Andrew F. Davis
>>>>>>>>>> ---
>>>>>>>>>> drivers/staging/android/ion/ion.c | 7 ---
>>>>>>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/staging/android/ion/ion.c
>>>>>>>>>> b/drivers/staging/android/ion/ion.c
>>>>>>>>>> index 14e48f6eb734..09cb5a8e2b09 100644
>>>>>>>>>> --- a/drivers/staging/android/ion/ion.c
>>>>>>>>>> +++ b/drivers/staging/android/ion/ion.c
>>>>>>>>>> @@ -261,8 +261,8 @@ static struct sg_table
>>>>>>>>>> *ion_map_dma_buf(struct
>>>>>>>>>> dma_buf_attachment *attachment,
>>>>>>>>>> table = a->table;
>>>>>>>>>> - if (!dma_map_sg(attachment->dev, table->sgl,
>>>>>>>>>> table->nents,
>>>>>>>>>> - direction))
>>>>>>>>>> + if (!dma_map_sg_attrs(attachment->dev, table->sgl,
>>>>>>>>>> table->nents,
>>>>>>>>>> + direction, DMA_ATTR_SKIP_CPU_SYNC))
>>>>>>>>>
>>>>>>>>> Unfortunately I don't think you can do this for a couple reasons.
>>>>>>>>> You can't rely on {begin,end}_cpu_access calls to do cache
>>>>>>>>> maintenance.
>>>>>>>>> If the calls to {begin,end}_cpu_access were made before the
>>>>>>>>> call to
>>>>>>>>> dma_buf_attach then there won't have been a device attached so the
>>>>>>>>> calls
>>>>>>>>> to {begin,end}_cpu_access won't have done any cache maintenance.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That should be okay though, if you have no attachments (or all
>>>>>>>> attachments are IO-coherent) then there is no need for cache
>>>>>>>> maintenance. Unless you mean a sequence where a non-io-coherent
>>>>>>>> device
>>>>>>>> is attached later after data has already been written. Does that
>>>>>>>> sequence need supporting?
>>>>>>>
>>>>>>> Yes, but also I think there are cases where CPU access can happen
>>>>>>> before
>>>>>>> in Android, but I will focus on later for now.
>>>>>>>
>>>>>>>> DMA-BUF doesn't have to allocate the backing
>>>>>>>> memory until map_dma_buf() time, and that should only happen
>>>>>>>> after all
>>>>>>>> the devices have attached so it can know where to put the
>>>>>>>> buffer. So we
>>>>>>>> shouldn't expect any CPU access to buffers before all the
>>>>>>>> devices are
>>>>>>>> attached and mapped, right?
>>>>>>>>
>>>>>>>
>>>>>>> Here is an example where CPU access can happen later in Android.
>>>>>>>
>>>>>>> Camera device records video -> software post processing -> video
Re: [PATCH 2/4] staging: android: ion: Restrict cache maintenance to dma mapped memory
On 1/18/19 12:37 PM, Liam Mark wrote:
> The ION begin_cpu_access and end_cpu_access functions use the
> dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
> maintenance.
>
> Currently it is possible to apply cache maintenance, via the
> begin_cpu_access and end_cpu_access APIs, to ION buffers which are not
> dma mapped.
>
> The dma sync sg APIs should not be called on sg lists which have not been
> dma mapped as this can result in cache maintenance being applied to the
> wrong address. If an sg list has not been dma mapped then its dma_address
> field has not been populated, some dma ops such as the swiotlb_dma_ops ops
> use the dma_address field to calculate the address onto which to apply
> cache maintenance.
>
> Also I don’t think we want CMOs to be applied to a buffer which is not
> dma mapped as the memory should already be coherent for access from the
> CPU. Any CMOs required for device access taken care of in the
> dma_buf_map_attachment and dma_buf_unmap_attachment calls.
> So really it only makes sense for begin_cpu_access and end_cpu_access to
> apply CMOs if the buffer is dma mapped.
>
> Fix the ION begin_cpu_access and end_cpu_access functions to only apply
> cache maintenance to buffers which are dma mapped.
>
> Fixes: 2a55e7b5e544 ("staging: android: ion: Call dma_map_sg for syncing and
> mapping")
> Signed-off-by: Liam Mark
> ---
> drivers/staging/android/ion/ion.c | 26 +-
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c
> index 6f5afab7c1a1..1fe633a7fdba 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -210,6 +210,7 @@ struct ion_dma_buf_attachment {
> struct device *dev;
> struct sg_table *table;
> struct list_head list;
> + bool dma_mapped;
> };
>
> static int ion_dma_buf_attach(struct dma_buf *dmabuf,
> @@ -231,6 +232,7 @@ static int ion_dma_buf_attach(struct dma_buf *dmabuf,
>
> a->table = table;
> a->dev = attachment->dev;
> + a->dma_mapped = false;
> INIT_LIST_HEAD(>list);
>
> attachment->priv = a;
> @@ -261,12 +263,18 @@ static struct sg_table *ion_map_dma_buf(struct
> dma_buf_attachment *attachment,
> {
> struct ion_dma_buf_attachment *a = attachment->priv;
> struct sg_table *table;
> + struct ion_buffer *buffer = attachment->dmabuf->priv;
>
> table = a->table;
>
> + mutex_lock(>lock);
> if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
> - direction))
> + direction)) {
> + mutex_unlock(>lock);
> return ERR_PTR(-ENOMEM);
> + }
> + a->dma_mapped = true;
> + mutex_unlock(>lock);
>
> return table;
> }
> @@ -275,7 +283,13 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment
> *attachment,
> struct sg_table *table,
> enum dma_data_direction direction)
> {
> + struct ion_dma_buf_attachment *a = attachment->priv;
> + struct ion_buffer *buffer = attachment->dmabuf->priv;
> +
> + mutex_lock(>lock);
> dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
> + a->dma_mapped = false;
> + mutex_unlock(>lock);
> }
>
> static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
> @@ -346,8 +360,9 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf
> *dmabuf,
>
> mutex_lock(>lock);
> list_for_each_entry(a, >attachments, list) {
When no devices are attached then buffer->attachments is empty and the
below does not run, so if I understand this patch correctly then what
you are protecting against is CPU access in the window after
dma_buf_attach but before dma_buf_map.
This is the kind of thing that again makes me think a couple more
ordering requirements on DMA-BUF ops are needed. DMA-BUFs do not require
the backing memory to be allocated until map time, this is why the
dma_address field would still be null as you note in the commit message.
So why should the CPU be performing accesses on a buffer that is not
actually backed yet?
I can think of two solutions:
1) Only allow CPU access (mmap, kmap, {begin,end}_cpu_access) while at
least one device is mapped.
2) Treat the CPU access request like the a device map request and
trigger the allocation of backing memory just like if a device map had
come in.
I know the current Ion heaps (and most other DMA-BUF exporters) all do
the allocation up front so the memory is already there, but DMA-BUF was
designed with late allocation in mind. I have a use-case I'm working on
that finally exercises this DMA-BUF functionality and I would like to
have it export through ION. This patch doesn't prevent that, but seems
like it is endorsing the the idea that buffers always need to be backed,
even before device attach/map is has occurred.
Either of the
Re: [PATCH 1/4] staging: android: ion: Support cpu access during dma_buf_detach
On 1/18/19 12:37 PM, Liam Mark wrote:
> Often userspace doesn't know when the kernel will be calling dma_buf_detach
> on the buffer.
> If userpace starts its CPU access at the same time as the sg list is being
> freed it could end up accessing the sg list after it has been freed.
>
> Thread A Thread B
> - DMA_BUF_IOCTL_SYNC IOCT
> - ion_dma_buf_begin_cpu_access
> - list_for_each_entry
> - ion_dma_buf_detatch
>- free_duped_table
>- dma_sync_sg_for_cpu
>
The window for this seems really small, but it does seem technically
possible, good find. for what it's worth:
Acked-by: Andrew F. Davis
> Fix this by getting the ion_buffer lock before freeing the sg table memory.
>
> Fixes: 2a55e7b5e544 ("staging: android: ion: Call dma_map_sg for syncing and
> mapping")
> Signed-off-by: Liam Mark
> ---
> drivers/staging/android/ion/ion.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c
> index a0802de8c3a1..6f5afab7c1a1 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -248,10 +248,10 @@ static void ion_dma_buf_detatch(struct dma_buf *dmabuf,
> struct ion_dma_buf_attachment *a = attachment->priv;
> struct ion_buffer *buffer = dmabuf->priv;
>
> - free_duped_table(a->table);
> mutex_lock(>lock);
> list_del(>list);
> mutex_unlock(>lock);
> + free_duped_table(a->table);
>
> kfree(a);
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/17/19 7:11 PM, Liam Mark wrote:
> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/16/19 4:54 PM, Liam Mark wrote:
>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/16/19 9:19 AM, Brian Starkey wrote:
>>>>> Hi :-)
>>>>>
>>>>> On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew F. Davis wrote:
>>>>>> On 1/15/19 12:38 PM, Andrew F. Davis wrote:
>>>>>>> On 1/15/19 11:45 AM, Liam Mark wrote:
>>>>>>>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>>>>>>>>
>>>>>>>>> On 1/14/19 11:13 AM, Liam Mark wrote:
>>>>>>>>>> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>>>>>>>>>>
>>>>>>>>>>> Buffers may not be mapped from the CPU so skip cache maintenance
>>>>>>>>>>> here.
>>>>>>>>>>> Accesses from the CPU to a cached heap should be bracketed with
>>>>>>>>>>> {begin,end}_cpu_access calls so maintenance should not be needed
>>>>>>>>>>> anyway.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Andrew F. Davis
>>>>>>>>>>> ---
>>>>>>>>>>> drivers/staging/android/ion/ion.c | 7 ---
>>>>>>>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/staging/android/ion/ion.c
>>>>>>>>>>> b/drivers/staging/android/ion/ion.c
>>>>>>>>>>> index 14e48f6eb734..09cb5a8e2b09 100644
>>>>>>>>>>> --- a/drivers/staging/android/ion/ion.c
>>>>>>>>>>> +++ b/drivers/staging/android/ion/ion.c
>>>>>>>>>>> @@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct
>>>>>>>>>>> dma_buf_attachment *attachment,
>>>>>>>>>>>
>>>>>>>>>>> table = a->table;
>>>>>>>>>>>
>>>>>>>>>>> - if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
>>>>>>>>>>> - direction))
>>>>>>>>>>> + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
>>>>>>>>>>> + direction, DMA_ATTR_SKIP_CPU_SYNC))
>>>>>>>>>>
>>>>>>>>>> Unfortunately I don't think you can do this for a couple reasons.
>>>>>>>>>> You can't rely on {begin,end}_cpu_access calls to do cache
>>>>>>>>>> maintenance.
>>>>>>>>>> If the calls to {begin,end}_cpu_access were made before the call to
>>>>>>>>>> dma_buf_attach then there won't have been a device attached so the
>>>>>>>>>> calls
>>>>>>>>>> to {begin,end}_cpu_access won't have done any cache maintenance.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That should be okay though, if you have no attachments (or all
>>>>>>>>> attachments are IO-coherent) then there is no need for cache
>>>>>>>>> maintenance. Unless you mean a sequence where a non-io-coherent device
>>>>>>>>> is attached later after data has already been written. Does that
>>>>>>>>> sequence need supporting?
>>>>>>>>
>>>>>>>> Yes, but also I think there are cases where CPU access can happen
>>>>>>>> before
>>>>>>>> in Android, but I will focus on later for now.
>>>>>>>>
>>>>>>>>> DMA-BUF doesn't have to allocate the backing
>>>>>>>>> memory until map_dma_buf() time, and that should only happen after all
>>>>>>>>> the devices have attached so it can know where to put the buffer. So
>>>>>>>>> we
>>>>>>>>> shouldn't expect any CPU access to buffers before all the devices are
>>>>>>>>> attached and mapped, right?
>>>>>>>>>
>>>>>>>>
>>
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/17/19 7:04 PM, Liam Mark wrote:
> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/16/19 4:48 PM, Liam Mark wrote:
>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/15/19 1:05 PM, Laura Abbott wrote:
>>>>> On 1/15/19 10:38 AM, Andrew F. Davis wrote:
>>>>>> On 1/15/19 11:45 AM, Liam Mark wrote:
>>>>>>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>>>>>>>
>>>>>>>> On 1/14/19 11:13 AM, Liam Mark wrote:
>>>>>>>>> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>>>>>>>>>
>>>>>>>>>> Buffers may not be mapped from the CPU so skip cache maintenance
>>>>>>>>>> here.
>>>>>>>>>> Accesses from the CPU to a cached heap should be bracketed with
>>>>>>>>>> {begin,end}_cpu_access calls so maintenance should not be needed
>>>>>>>>>> anyway.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Andrew F. Davis
>>>>>>>>>> ---
>>>>>>>>>> drivers/staging/android/ion/ion.c | 7 ---
>>>>>>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/staging/android/ion/ion.c
>>>>>>>>>> b/drivers/staging/android/ion/ion.c
>>>>>>>>>> index 14e48f6eb734..09cb5a8e2b09 100644
>>>>>>>>>> --- a/drivers/staging/android/ion/ion.c
>>>>>>>>>> +++ b/drivers/staging/android/ion/ion.c
>>>>>>>>>> @@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct
>>>>>>>>>> dma_buf_attachment *attachment,
>>>>>>>>>> table = a->table;
>>>>>>>>>> - if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
>>>>>>>>>> - direction))
>>>>>>>>>> + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
>>>>>>>>>> + direction, DMA_ATTR_SKIP_CPU_SYNC))
>>>>>>>>>
>>>>>>>>> Unfortunately I don't think you can do this for a couple reasons.
>>>>>>>>> You can't rely on {begin,end}_cpu_access calls to do cache
>>>>>>>>> maintenance.
>>>>>>>>> If the calls to {begin,end}_cpu_access were made before the call to
>>>>>>>>> dma_buf_attach then there won't have been a device attached so the
>>>>>>>>> calls
>>>>>>>>> to {begin,end}_cpu_access won't have done any cache maintenance.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That should be okay though, if you have no attachments (or all
>>>>>>>> attachments are IO-coherent) then there is no need for cache
>>>>>>>> maintenance. Unless you mean a sequence where a non-io-coherent device
>>>>>>>> is attached later after data has already been written. Does that
>>>>>>>> sequence need supporting?
>>>>>>>
>>>>>>> Yes, but also I think there are cases where CPU access can happen before
>>>>>>> in Android, but I will focus on later for now.
>>>>>>>
>>>>>>>> DMA-BUF doesn't have to allocate the backing
>>>>>>>> memory until map_dma_buf() time, and that should only happen after all
>>>>>>>> the devices have attached so it can know where to put the buffer. So we
>>>>>>>> shouldn't expect any CPU access to buffers before all the devices are
>>>>>>>> attached and mapped, right?
>>>>>>>>
>>>>>>>
>>>>>>> Here is an example where CPU access can happen later in Android.
>>>>>>>
>>>>>>> Camera device records video -> software post processing -> video device
>>>>>>> (who does compression of raw data) and writes to a file
>>>>>>>
>>>>>>> In this example assume the buffer is cached and the devices are not
>>>>>>> IO-coherent (quite common).
>>>>>>>
>>>>>
Re: [PATCH 12/14] staging: android: ion: Declare helpers for carveout and chunk heaps
On 1/18/19 3:59 AM, Greg Kroah-Hartman wrote: > On Fri, Jan 11, 2019 at 12:05:21PM -0600, Andrew F. Davis wrote: >> When enabled the helpers functions for creating carveout and chunk heaps >> should have declarations in the ION header. > > Why? No one calls these from what I can tell. > > Which makes me believe we should just delete the > drivers/staging/android/ion/ion_carveout_heap.c and > drivers/staging/android/ion/ion_chunk_heap.c files as there are no > in-tree users? > > Any objection to me doing that? > I use those when creating carveout heaps. My exporter is out of tree still as it uses DT and the proper bindings have not been agreed upon yet. These helpers also make good heap creation references, even if not called by anyone in-tree right now. Thanks, Andrew > thanks, > > greg k-h > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
