[RFC][PATCH 0/2] Devicetree bindings for Ion

[RFC][PATCH 0/2] Devicetree bindings for Ion

[Laura Abbott]

From: Laura Abbott <laura@labbott.name>


Hi,

At the last Plumbers and Linaro Connect, there was some discussion
related to Ion. One of the items that came up towards eventually
getting Ion out of staging was some concept of stable devicetree
bindings. This is a proof of concept for bindings.

Most of this is based on previously submitted work
(https://lkml.org/lkml/2015/6/30/425 thank you Andrew Andrianov for
getting this started!) and also the
out of tree qcom bindings (available somewhere on codeaurora.org).
As the title indicates, this is an RFC and the purpose here is to
get feedback on if these bindings would potentially work. If there
are platforms out there that don't use devicetree, the bindings
would hopefully also serve as a guide for how to setup the platform
data for heaps like CMA.

One of the big things this series improves on is giving a standard
mechanism for defining and allocating memory for all heap types.
DMA/CMA is handled as well as memory for carveout and chunk heaps.

Further TODO:
- Need to fixup include paths so heap types can be cleanly included
  in DTS files
- Figure out callbacks or similar for support custom platform heaps

Laura Abbott (2):
  WIP: Devicetree bindings for Ion
  staging: ion: Add files for parsing the devicetree (WIP)

 drivers/staging/android/ion/Kconfig        |  10 ++
 drivers/staging/android/ion/Makefile       |   7 +-
 drivers/staging/android/ion/devicetree.txt |  53 +++++++++
 drivers/staging/android/ion/ion_of.c       | 185 +++++++++++++++++++++++++++++
 drivers/staging/android/ion/ion_of.h       |   3 +
 5 files changed, 255 insertions(+), 3 deletions(-)
 create mode 100644 drivers/staging/android/ion/devicetree.txt
 create mode 100644 drivers/staging/android/ion/ion_of.c
 create mode 100644 drivers/staging/android/ion/ion_of.h

-- 
2.4.3

[RFC][PATCH 0/2] Devicetree bindings for Ion

[Laura Abbott]

From: Laura Abbott <laura-0PSzFVTn/CLa5EbDDlwbIw@public.gmane.org>


Hi,

At the last Plumbers and Linaro Connect, there was some discussion
related to Ion. One of the items that came up towards eventually
getting Ion out of staging was some concept of stable devicetree
bindings. This is a proof of concept for bindings.

Most of this is based on previously submitted work
(https://lkml.org/lkml/2015/6/30/425 thank you Andrew Andrianov for
getting this started!) and also the
out of tree qcom bindings (available somewhere on codeaurora.org).
As the title indicates, this is an RFC and the purpose here is to
get feedback on if these bindings would potentially work. If there
are platforms out there that don't use devicetree, the bindings
would hopefully also serve as a guide for how to setup the platform
data for heaps like CMA.

One of the big things this series improves on is giving a standard
mechanism for defining and allocating memory for all heap types.
DMA/CMA is handled as well as memory for carveout and chunk heaps.

Further TODO:
- Need to fixup include paths so heap types can be cleanly included
  in DTS files
- Figure out callbacks or similar for support custom platform heaps

Laura Abbott (2):
  WIP: Devicetree bindings for Ion
  staging: ion: Add files for parsing the devicetree (WIP)

 drivers/staging/android/ion/Kconfig        |  10 ++
 drivers/staging/android/ion/Makefile       |   7 +-
 drivers/staging/android/ion/devicetree.txt |  53 +++++++++
 drivers/staging/android/ion/ion_of.c       | 185 +++++++++++++++++++++++++++++
 drivers/staging/android/ion/ion_of.h       |   3 +
 5 files changed, 255 insertions(+), 3 deletions(-)
 create mode 100644 drivers/staging/android/ion/devicetree.txt
 create mode 100644 drivers/staging/android/ion/ion_of.c
 create mode 100644 drivers/staging/android/ion/ion_of.h

-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 0/2] Devicetree bindings for Ion

[Laura Abbott]

From: Laura Abbott <laura@labbott.name>


Hi,

At the last Plumbers and Linaro Connect, there was some discussion
related to Ion. One of the items that came up towards eventually
getting Ion out of staging was some concept of stable devicetree
bindings. This is a proof of concept for bindings.

Most of this is based on previously submitted work
(https://lkml.org/lkml/2015/6/30/425 thank you Andrew Andrianov for
getting this started!) and also the
out of tree qcom bindings (available somewhere on codeaurora.org).
As the title indicates, this is an RFC and the purpose here is to
get feedback on if these bindings would potentially work. If there
are platforms out there that don't use devicetree, the bindings
would hopefully also serve as a guide for how to setup the platform
data for heaps like CMA.

One of the big things this series improves on is giving a standard
mechanism for defining and allocating memory for all heap types.
DMA/CMA is handled as well as memory for carveout and chunk heaps.

Further TODO:
- Need to fixup include paths so heap types can be cleanly included
  in DTS files
- Figure out callbacks or similar for support custom platform heaps

Laura Abbott (2):
  WIP: Devicetree bindings for Ion
  staging: ion: Add files for parsing the devicetree (WIP)

 drivers/staging/android/ion/Kconfig        |  10 ++
 drivers/staging/android/ion/Makefile       |   7 +-
 drivers/staging/android/ion/devicetree.txt |  53 +++++++++
 drivers/staging/android/ion/ion_of.c       | 185 +++++++++++++++++++++++++++++
 drivers/staging/android/ion/ion_of.h       |   3 +
 5 files changed, 255 insertions(+), 3 deletions(-)
 create mode 100644 drivers/staging/android/ion/devicetree.txt
 create mode 100644 drivers/staging/android/ion/ion_of.c
 create mode 100644 drivers/staging/android/ion/ion_of.h

-- 
2.4.3

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

From: Laura Abbott <laura@labbott.name>


This adds a base set of devicetree bindings for the Ion memory
manager. This supports setting up the generic set of heaps and
their properties.

Signed-off-by: Laura Abbott <laura@labbott.name>
Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
---
 drivers/staging/android/ion/devicetree.txt | 53 ++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 drivers/staging/android/ion/devicetree.txt

diff --git a/drivers/staging/android/ion/devicetree.txt b/drivers/staging/android/ion/devicetree.txt
new file mode 100644
index 0000000..4a0c941
--- /dev/null
+++ b/drivers/staging/android/ion/devicetree.txt
@@ -0,0 +1,53 @@
+Ion Memory Manager
+
+Ion is a memory manager that allows for sharing of buffers via dma-buf.
+Ion allows for different types of allocation via an abstraction called
+a 'heap'. A heap represents a specific type of memory. Each heap has
+a different type. There can be multiple instances of the same heap
+type.
+
+Required properties for Ion
+
+- compatible: "linux,ion"
+
+All child nodes of a linux,ion node are interpreted as heaps
+
+required properties for heaps
+
+- linux,ion-heap-id: The Ion heap id used for allocation selection
+- linux,ion-heap-type: Ion heap type defined in ion.h
+- linux,ion-heap-name: Human readble name of the heap
+
+
+Optional properties
+- memory-region: A phandle to a memory region. Required for DMA heap type
+(see reserved-memory.txt for details on the reservation)
+- linux,ion-heap-align: Alignment for the heap.
+
+Example:
+
+	ion {
+		compatbile = "linux,ion";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ion-system-heap {
+			linux,ion-heap-id = <0>;
+			linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
+			linux,ion-heap-name = "system";
+		};
+
+		ion-camera-region {
+			linux,ion-heap-id = <1>;
+			linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
+			linux,ion-heap-name = "camera"
+			memory-region = <&camera_region>;
+		};
+
+		ion-fb-region {
+			linux,ion-heap-id = <2>;
+			linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
+			linux,ion-heap-name = "fb"
+			memory-region = <&fb_region>;
+		};
+	}
-- 
2.4.3

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

From: Laura Abbott <laura@labbott.name>


This adds a base set of devicetree bindings for the Ion memory
manager. This supports setting up the generic set of heaps and
their properties.

Signed-off-by: Laura Abbott <laura@labbott.name>
Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
---
 drivers/staging/android/ion/devicetree.txt | 53 ++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 drivers/staging/android/ion/devicetree.txt

diff --git a/drivers/staging/android/ion/devicetree.txt b/drivers/staging/android/ion/devicetree.txt
new file mode 100644
index 0000000..4a0c941
--- /dev/null
+++ b/drivers/staging/android/ion/devicetree.txt
@@ -0,0 +1,53 @@
+Ion Memory Manager
+
+Ion is a memory manager that allows for sharing of buffers via dma-buf.
+Ion allows for different types of allocation via an abstraction called
+a 'heap'. A heap represents a specific type of memory. Each heap has
+a different type. There can be multiple instances of the same heap
+type.
+
+Required properties for Ion
+
+- compatible: "linux,ion"
+
+All child nodes of a linux,ion node are interpreted as heaps
+
+required properties for heaps
+
+- linux,ion-heap-id: The Ion heap id used for allocation selection
+- linux,ion-heap-type: Ion heap type defined in ion.h
+- linux,ion-heap-name: Human readble name of the heap
+
+
+Optional properties
+- memory-region: A phandle to a memory region. Required for DMA heap type
+(see reserved-memory.txt for details on the reservation)
+- linux,ion-heap-align: Alignment for the heap.
+
+Example:
+
+	ion {
+		compatbile = "linux,ion";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ion-system-heap {
+			linux,ion-heap-id = <0>;
+			linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
+			linux,ion-heap-name = "system";
+		};
+
+		ion-camera-region {
+			linux,ion-heap-id = <1>;
+			linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
+			linux,ion-heap-name = "camera"
+			memory-region = <&camera_region>;
+		};
+
+		ion-fb-region {
+			linux,ion-heap-id = <2>;
+			linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
+			linux,ion-heap-name = "fb"
+			memory-region = <&fb_region>;
+		};
+	}
-- 
2.4.3

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

From: Laura Abbott <laura@labbott.name>


This adds a base set of devicetree bindings for the Ion memory
manager. This supports setting up the generic set of heaps and
their properties.

Signed-off-by: Laura Abbott <laura@labbott.name>
Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
---
 drivers/staging/android/ion/devicetree.txt | 53 ++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 drivers/staging/android/ion/devicetree.txt

diff --git a/drivers/staging/android/ion/devicetree.txt b/drivers/staging/android/ion/devicetree.txt
new file mode 100644
index 0000000..4a0c941
--- /dev/null
+++ b/drivers/staging/android/ion/devicetree.txt
@@ -0,0 +1,53 @@
+Ion Memory Manager
+
+Ion is a memory manager that allows for sharing of buffers via dma-buf.
+Ion allows for different types of allocation via an abstraction called
+a 'heap'. A heap represents a specific type of memory. Each heap has
+a different type. There can be multiple instances of the same heap
+type.
+
+Required properties for Ion
+
+- compatible: "linux,ion"
+
+All child nodes of a linux,ion node are interpreted as heaps
+
+required properties for heaps
+
+- linux,ion-heap-id: The Ion heap id used for allocation selection
+- linux,ion-heap-type: Ion heap type defined in ion.h
+- linux,ion-heap-name: Human readble name of the heap
+
+
+Optional properties
+- memory-region: A phandle to a memory region. Required for DMA heap type
+(see reserved-memory.txt for details on the reservation)
+- linux,ion-heap-align: Alignment for the heap.
+
+Example:
+
+	ion {
+		compatbile = "linux,ion";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ion-system-heap {
+			linux,ion-heap-id = <0>;
+			linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
+			linux,ion-heap-name = "system";
+		};
+
+		ion-camera-region {
+			linux,ion-heap-id = <1>;
+			linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
+			linux,ion-heap-name = "camera"
+			memory-region = <&camera_region>;
+		};
+
+		ion-fb-region {
+			linux,ion-heap-id = <2>;
+			linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
+			linux,ion-heap-name = "fb"
+			memory-region = <&fb_region>;
+		};
+	}
-- 
2.4.3

[RFC][PATCH 2/2] staging: ion: Add files for parsing the devicetree (WIP)

[Laura Abbott]

From: Laura Abbott <laura@labbott.name>


Devicetree is the preferred mechanism for platform definition
these days. Add a set of files for supporting Ion with devicetree.
This includes a set of bindings for heaps common across all
devices and parsing methods. Clients may use the standard
bindings or they can call the parsing functions along with
their own parsing for platform specific heaps.

Signed-off-by: Laura Abbott <laura@labbott.name>
Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
---
 drivers/staging/android/ion/Kconfig  |  10 ++
 drivers/staging/android/ion/Makefile |   7 +-
 drivers/staging/android/ion/ion_of.c | 185 +++++++++++++++++++++++++++++++++++
 drivers/staging/android/ion/ion_of.h |   3 +
 4 files changed, 202 insertions(+), 3 deletions(-)
 create mode 100644 drivers/staging/android/ion/ion_of.c
 create mode 100644 drivers/staging/android/ion/ion_of.h

diff --git a/drivers/staging/android/ion/Kconfig b/drivers/staging/android/ion/Kconfig
index 3452346..9b6d65d 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -33,3 +33,13 @@ config ION_TEGRA
 	help
 	  Choose this option if you wish to use ion on an nVidia Tegra.
 
+config ION_OF
+	bool "Devicetree support for Ion"
+	depends on ION && OF
+	help
+	  Provides base support for defining Ion heaps in devicetree
+	  and setting them up. Also includes functions for platforms
+	  to parse the devicetree and expand for their own custom
+	  extensions
+
+	  If using Ion and devicetree, you should say Y here
diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
index b56fd2b..6602512 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -5,6 +5,7 @@ ifdef CONFIG_COMPAT
 obj-$(CONFIG_ION) += compat_ion.o
 endif
 
-obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
-obj-$(CONFIG_ION_TEGRA) += tegra/
-
+obj-$(CONFIG_ION_DUMMY)   += ion_dummy_driver.o
+obj-$(CONFIG_ION_PHYSMEM) += ion_physmem.o
+obj-$(CONFIG_ION_TEGRA)   += tegra/
+obj-$(CONFIG_ION_OF) +=	ion_of.o ion_physmem.o
diff --git a/drivers/staging/android/ion/ion_of.c b/drivers/staging/android/ion/ion_of.c
new file mode 100644
index 0000000..3c9b1e5
--- /dev/null
+++ b/drivers/staging/android/ion/ion_of.c
@@ -0,0 +1,185 @@
+/*
+ * Based on work from:
+ *   Andrew Andrianov <andrew@ncrmnt.org>
+ *   Google
+ *   The Linux Foundation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/cma.h>
+#include <linux/dma-contiguous.h>
+#include <linux/io.h>
+#include <linux/of_reserved_mem.h>
+#include "ion.h"
+#include "ion_priv.h"
+
+/*
+ * Future work: allow callback function for each heap?
+ */
+
+int ion_parse_dt_heap_common(struct device_node *heap_node,
+			struct ion_platform_heap *heap)
+{
+	u32 ion_heap_id, ion_heap_align, ion_heap_type;
+	const char *ion_heap_name;
+	int ret;
+
+	ret =  of_property_read_string(heap_node, "linux,ion-heap-name",
+					&ion_heap_name);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(heap_node, "linux,ion-heap-id",
+					&ion_heap_id);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(heap_node, "linux,ion-heap-type",
+					&ion_heap_type);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(heap_node, "linux,ion-heap-align",
+					&ion_heap_align);
+	if (ret)
+		/* align is optional so make the alignemnt page size */
+		ion_heap_align = PAGE_SIZE;
+
+	heap->id = ion_heap_id;
+	heap->type = ion_heap_type;
+	heap->name = ion_heap_name;
+	heap->align = ion_heap_align;
+	pr_info("%s: id %d type %d name %s align %x\n",
+			__func__,
+			ion_heap_id, ion_heap_type,
+			ion_heap_name, ion_heap_align);
+	return 0;
+}
+
+int ion_setup_heap_common(struct platform_device *parent,
+			struct device_node *heap_node,
+			struct ion_platform_heap *heap)
+{
+	int ret = 0;
+
+	switch (heap->type) {
+		case ION_HEAP_TYPE_CARVEOUT:
+		case ION_HEAP_TYPE_CHUNK:
+			if (heap->base && heap->size)
+				return 0;
+
+			ret = of_reserved_mem_device_init(heap->priv);
+			break;
+		default:
+			break;
+	}
+
+	return ret;
+}
+
+struct ion_platform_data *ion_parse_dt(struct platform_device *pdev)
+{
+	int num_heaps, ret;
+	const struct device_node *dt_node = pdev->dev.of_node;
+	struct device_node *node;
+	struct ion_platform_heap *heaps;
+	struct ion_platform_data *data;
+	int i = 0;
+
+	num_heaps = of_get_available_child_count(dt_node);
+
+	if (!num_heaps)
+		return ERR_PTR(-EINVAL);
+
+	heaps = devm_kzalloc(&pdev->dev,
+				sizeof(struct ion_platform_heap)*num_heaps,
+				GFP_KERNEL);
+	if (!heaps)
+		return ERR_PTR(-ENOMEM);
+
+	data = devm_kzalloc(&pdev->dev, sizeof(struct ion_platform_data),
+				GFP_KERNEL);
+	if (!data)
+		return ERR_PTR(-ENOMEM);
+
+	for_each_available_child_of_node(dt_node, node) {
+		struct platform_device *heap_pdev;
+
+		ret = ion_parse_dt_heap_common(node, &heaps[i]);
+		if (ret)
+			return ERR_PTR(ret);
+
+		heap_pdev = of_platform_device_create(node, heaps[i].name,
+							&pdev->dev);
+		if (!pdev)
+			return ERR_PTR(-ENOMEM);
+		heap_pdev->dev.platform_data = &heaps[i];
+
+		heaps[i].priv = &heap_pdev->dev;
+
+		ret = ion_setup_heap_common(pdev, node, &heaps[i]);
+		if (ret)
+			return ERR_PTR(ret);
+		i++;
+
+		/* TODO custom callback */
+	}
+
+
+	data->heaps = heaps;
+	data->nr = num_heaps;
+	return data;
+}
+
+#ifdef CONFIG_OF_RESERVED_MEM
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+#include <linux/of_reserved_mem.h>
+
+static int rmem_ion_device_init(struct reserved_mem *rmem, struct device *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct ion_platform_heap *heap = pdev->dev.platform_data;
+
+	heap->base = rmem->base;
+	heap->base = rmem->size;
+	pr_debug("%s: heap %s base %pa size %pa dev %p\n", __func__,
+			heap->name, &rmem->base, &rmem->size, dev);
+	return 0;
+}
+
+static void rmem_ion_device_release(struct reserved_mem *rmem,
+					struct device *dev)
+{
+	return;
+}
+
+static const struct reserved_mem_ops rmem_dma_ops = {
+	.device_init	= rmem_ion_device_init,
+	.device_release	= rmem_ion_device_release,
+};
+
+static int __init rmem_ion_setup(struct reserved_mem *rmem)
+{
+	phys_addr_t size = rmem->size;
+
+	size = size / 1024;
+
+	pr_info("Ion memory setup at %pa size %pa MiB\n",
+		&rmem->base, &size);
+	rmem->ops = &rmem_dma_ops;
+	return 0;
+}
+RESERVEDMEM_OF_DECLARE(ion, "ion-region", rmem_ion_setup);
+#endif
diff --git a/drivers/staging/android/ion/ion_of.h b/drivers/staging/android/ion/ion_of.h
new file mode 100644
index 0000000..b4d1b6d
--- /dev/null
+++ b/drivers/staging/android/ion/ion_of.h
@@ -0,0 +1,3 @@
+/* YES I NEED HEADER */
+
+struct ion_platform_data *ion_parse_dt(struct platform_device *pdev);
-- 
2.4.3

[RFC][PATCH 2/2] staging: ion: Add files for parsing the devicetree (WIP)

[Laura Abbott]

From: Laura Abbott <laura@labbott.name>


Devicetree is the preferred mechanism for platform definition
these days. Add a set of files for supporting Ion with devicetree.
This includes a set of bindings for heaps common across all
devices and parsing methods. Clients may use the standard
bindings or they can call the parsing functions along with
their own parsing for platform specific heaps.

Signed-off-by: Laura Abbott <laura@labbott.name>
Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
---
 drivers/staging/android/ion/Kconfig  |  10 ++
 drivers/staging/android/ion/Makefile |   7 +-
 drivers/staging/android/ion/ion_of.c | 185 +++++++++++++++++++++++++++++++++++
 drivers/staging/android/ion/ion_of.h |   3 +
 4 files changed, 202 insertions(+), 3 deletions(-)
 create mode 100644 drivers/staging/android/ion/ion_of.c
 create mode 100644 drivers/staging/android/ion/ion_of.h

diff --git a/drivers/staging/android/ion/Kconfig b/drivers/staging/android/ion/Kconfig
index 3452346..9b6d65d 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -33,3 +33,13 @@ config ION_TEGRA
 	help
 	  Choose this option if you wish to use ion on an nVidia Tegra.
 
+config ION_OF
+	bool "Devicetree support for Ion"
+	depends on ION && OF
+	help
+	  Provides base support for defining Ion heaps in devicetree
+	  and setting them up. Also includes functions for platforms
+	  to parse the devicetree and expand for their own custom
+	  extensions
+
+	  If using Ion and devicetree, you should say Y here
diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
index b56fd2b..6602512 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -5,6 +5,7 @@ ifdef CONFIG_COMPAT
 obj-$(CONFIG_ION) += compat_ion.o
 endif
 
-obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
-obj-$(CONFIG_ION_TEGRA) += tegra/
-
+obj-$(CONFIG_ION_DUMMY)   += ion_dummy_driver.o
+obj-$(CONFIG_ION_PHYSMEM) += ion_physmem.o
+obj-$(CONFIG_ION_TEGRA)   += tegra/
+obj-$(CONFIG_ION_OF) +=	ion_of.o ion_physmem.o
diff --git a/drivers/staging/android/ion/ion_of.c b/drivers/staging/android/ion/ion_of.c
new file mode 100644
index 0000000..3c9b1e5
--- /dev/null
+++ b/drivers/staging/android/ion/ion_of.c
@@ -0,0 +1,185 @@
+/*
+ * Based on work from:
+ *   Andrew Andrianov <andrew@ncrmnt.org>
+ *   Google
+ *   The Linux Foundation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/cma.h>
+#include <linux/dma-contiguous.h>
+#include <linux/io.h>
+#include <linux/of_reserved_mem.h>
+#include "ion.h"
+#include "ion_priv.h"
+
+/*
+ * Future work: allow callback function for each heap?
+ */
+
+int ion_parse_dt_heap_common(struct device_node *heap_node,
+			struct ion_platform_heap *heap)
+{
+	u32 ion_heap_id, ion_heap_align, ion_heap_type;
+	const char *ion_heap_name;
+	int ret;
+
+	ret =  of_property_read_string(heap_node, "linux,ion-heap-name",
+					&ion_heap_name);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(heap_node, "linux,ion-heap-id",
+					&ion_heap_id);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(heap_node, "linux,ion-heap-type",
+					&ion_heap_type);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(heap_node, "linux,ion-heap-align",
+					&ion_heap_align);
+	if (ret)
+		/* align is optional so make the alignemnt page size */
+		ion_heap_align = PAGE_SIZE;
+
+	heap->id = ion_heap_id;
+	heap->type = ion_heap_type;
+	heap->name = ion_heap_name;
+	heap->align = ion_heap_align;
+	pr_info("%s: id %d type %d name %s align %x\n",
+			__func__,
+			ion_heap_id, ion_heap_type,
+			ion_heap_name, ion_heap_align);
+	return 0;
+}
+
+int ion_setup_heap_common(struct platform_device *parent,
+			struct device_node *heap_node,
+			struct ion_platform_heap *heap)
+{
+	int ret = 0;
+
+	switch (heap->type) {
+		case ION_HEAP_TYPE_CARVEOUT:
+		case ION_HEAP_TYPE_CHUNK:
+			if (heap->base && heap->size)
+				return 0;
+
+			ret = of_reserved_mem_device_init(heap->priv);
+			break;
+		default:
+			break;
+	}
+
+	return ret;
+}
+
+struct ion_platform_data *ion_parse_dt(struct platform_device *pdev)
+{
+	int num_heaps, ret;
+	const struct device_node *dt_node = pdev->dev.of_node;
+	struct device_node *node;
+	struct ion_platform_heap *heaps;
+	struct ion_platform_data *data;
+	int i = 0;
+
+	num_heaps = of_get_available_child_count(dt_node);
+
+	if (!num_heaps)
+		return ERR_PTR(-EINVAL);
+
+	heaps = devm_kzalloc(&pdev->dev,
+				sizeof(struct ion_platform_heap)*num_heaps,
+				GFP_KERNEL);
+	if (!heaps)
+		return ERR_PTR(-ENOMEM);
+
+	data = devm_kzalloc(&pdev->dev, sizeof(struct ion_platform_data),
+				GFP_KERNEL);
+	if (!data)
+		return ERR_PTR(-ENOMEM);
+
+	for_each_available_child_of_node(dt_node, node) {
+		struct platform_device *heap_pdev;
+
+		ret = ion_parse_dt_heap_common(node, &heaps[i]);
+		if (ret)
+			return ERR_PTR(ret);
+
+		heap_pdev = of_platform_device_create(node, heaps[i].name,
+							&pdev->dev);
+		if (!pdev)
+			return ERR_PTR(-ENOMEM);
+		heap_pdev->dev.platform_data = &heaps[i];
+
+		heaps[i].priv = &heap_pdev->dev;
+
+		ret = ion_setup_heap_common(pdev, node, &heaps[i]);
+		if (ret)
+			return ERR_PTR(ret);
+		i++;
+
+		/* TODO custom callback */
+	}
+
+
+	data->heaps = heaps;
+	data->nr = num_heaps;
+	return data;
+}
+
+#ifdef CONFIG_OF_RESERVED_MEM
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+#include <linux/of_reserved_mem.h>
+
+static int rmem_ion_device_init(struct reserved_mem *rmem, struct device *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct ion_platform_heap *heap = pdev->dev.platform_data;
+
+	heap->base = rmem->base;
+	heap->base = rmem->size;
+	pr_debug("%s: heap %s base %pa size %pa dev %p\n", __func__,
+			heap->name, &rmem->base, &rmem->size, dev);
+	return 0;
+}
+
+static void rmem_ion_device_release(struct reserved_mem *rmem,
+					struct device *dev)
+{
+	return;
+}
+
+static const struct reserved_mem_ops rmem_dma_ops = {
+	.device_init	= rmem_ion_device_init,
+	.device_release	= rmem_ion_device_release,
+};
+
+static int __init rmem_ion_setup(struct reserved_mem *rmem)
+{
+	phys_addr_t size = rmem->size;
+
+	size = size / 1024;
+
+	pr_info("Ion memory setup at %pa size %pa MiB\n",
+		&rmem->base, &size);
+	rmem->ops = &rmem_dma_ops;
+	return 0;
+}
+RESERVEDMEM_OF_DECLARE(ion, "ion-region", rmem_ion_setup);
+#endif
diff --git a/drivers/staging/android/ion/ion_of.h b/drivers/staging/android/ion/ion_of.h
new file mode 100644
index 0000000..b4d1b6d
--- /dev/null
+++ b/drivers/staging/android/ion/ion_of.h
@@ -0,0 +1,3 @@
+/* YES I NEED HEADER */
+
+struct ion_platform_data *ion_parse_dt(struct platform_device *pdev);
-- 
2.4.3

[RFC][PATCH 2/2] staging: ion: Add files for parsing the devicetree (WIP)

[Laura Abbott]

From: Laura Abbott <laura@labbott.name>


Devicetree is the preferred mechanism for platform definition
these days. Add a set of files for supporting Ion with devicetree.
This includes a set of bindings for heaps common across all
devices and parsing methods. Clients may use the standard
bindings or they can call the parsing functions along with
their own parsing for platform specific heaps.

Signed-off-by: Laura Abbott <laura@labbott.name>
Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
---
 drivers/staging/android/ion/Kconfig  |  10 ++
 drivers/staging/android/ion/Makefile |   7 +-
 drivers/staging/android/ion/ion_of.c | 185 +++++++++++++++++++++++++++++++++++
 drivers/staging/android/ion/ion_of.h |   3 +
 4 files changed, 202 insertions(+), 3 deletions(-)
 create mode 100644 drivers/staging/android/ion/ion_of.c
 create mode 100644 drivers/staging/android/ion/ion_of.h

diff --git a/drivers/staging/android/ion/Kconfig b/drivers/staging/android/ion/Kconfig
index 3452346..9b6d65d 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -33,3 +33,13 @@ config ION_TEGRA
 	help
 	  Choose this option if you wish to use ion on an nVidia Tegra.
 
+config ION_OF
+	bool "Devicetree support for Ion"
+	depends on ION && OF
+	help
+	  Provides base support for defining Ion heaps in devicetree
+	  and setting them up. Also includes functions for platforms
+	  to parse the devicetree and expand for their own custom
+	  extensions
+
+	  If using Ion and devicetree, you should say Y here
diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
index b56fd2b..6602512 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -5,6 +5,7 @@ ifdef CONFIG_COMPAT
 obj-$(CONFIG_ION) += compat_ion.o
 endif
 
-obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
-obj-$(CONFIG_ION_TEGRA) += tegra/
-
+obj-$(CONFIG_ION_DUMMY)   += ion_dummy_driver.o
+obj-$(CONFIG_ION_PHYSMEM) += ion_physmem.o
+obj-$(CONFIG_ION_TEGRA)   += tegra/
+obj-$(CONFIG_ION_OF) +=	ion_of.o ion_physmem.o
diff --git a/drivers/staging/android/ion/ion_of.c b/drivers/staging/android/ion/ion_of.c
new file mode 100644
index 0000000..3c9b1e5
--- /dev/null
+++ b/drivers/staging/android/ion/ion_of.c
@@ -0,0 +1,185 @@
+/*
+ * Based on work from:
+ *   Andrew Andrianov <andrew@ncrmnt.org>
+ *   Google
+ *   The Linux Foundation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/cma.h>
+#include <linux/dma-contiguous.h>
+#include <linux/io.h>
+#include <linux/of_reserved_mem.h>
+#include "ion.h"
+#include "ion_priv.h"
+
+/*
+ * Future work: allow callback function for each heap?
+ */
+
+int ion_parse_dt_heap_common(struct device_node *heap_node,
+			struct ion_platform_heap *heap)
+{
+	u32 ion_heap_id, ion_heap_align, ion_heap_type;
+	const char *ion_heap_name;
+	int ret;
+
+	ret =  of_property_read_string(heap_node, "linux,ion-heap-name",
+					&ion_heap_name);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(heap_node, "linux,ion-heap-id",
+					&ion_heap_id);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(heap_node, "linux,ion-heap-type",
+					&ion_heap_type);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(heap_node, "linux,ion-heap-align",
+					&ion_heap_align);
+	if (ret)
+		/* align is optional so make the alignemnt page size */
+		ion_heap_align = PAGE_SIZE;
+
+	heap->id = ion_heap_id;
+	heap->type = ion_heap_type;
+	heap->name = ion_heap_name;
+	heap->align = ion_heap_align;
+	pr_info("%s: id %d type %d name %s align %x\n",
+			__func__,
+			ion_heap_id, ion_heap_type,
+			ion_heap_name, ion_heap_align);
+	return 0;
+}
+
+int ion_setup_heap_common(struct platform_device *parent,
+			struct device_node *heap_node,
+			struct ion_platform_heap *heap)
+{
+	int ret = 0;
+
+	switch (heap->type) {
+		case ION_HEAP_TYPE_CARVEOUT:
+		case ION_HEAP_TYPE_CHUNK:
+			if (heap->base && heap->size)
+				return 0;
+
+			ret = of_reserved_mem_device_init(heap->priv);
+			break;
+		default:
+			break;
+	}
+
+	return ret;
+}
+
+struct ion_platform_data *ion_parse_dt(struct platform_device *pdev)
+{
+	int num_heaps, ret;
+	const struct device_node *dt_node = pdev->dev.of_node;
+	struct device_node *node;
+	struct ion_platform_heap *heaps;
+	struct ion_platform_data *data;
+	int i = 0;
+
+	num_heaps = of_get_available_child_count(dt_node);
+
+	if (!num_heaps)
+		return ERR_PTR(-EINVAL);
+
+	heaps = devm_kzalloc(&pdev->dev,
+				sizeof(struct ion_platform_heap)*num_heaps,
+				GFP_KERNEL);
+	if (!heaps)
+		return ERR_PTR(-ENOMEM);
+
+	data = devm_kzalloc(&pdev->dev, sizeof(struct ion_platform_data),
+				GFP_KERNEL);
+	if (!data)
+		return ERR_PTR(-ENOMEM);
+
+	for_each_available_child_of_node(dt_node, node) {
+		struct platform_device *heap_pdev;
+
+		ret = ion_parse_dt_heap_common(node, &heaps[i]);
+		if (ret)
+			return ERR_PTR(ret);
+
+		heap_pdev = of_platform_device_create(node, heaps[i].name,
+							&pdev->dev);
+		if (!pdev)
+			return ERR_PTR(-ENOMEM);
+		heap_pdev->dev.platform_data = &heaps[i];
+
+		heaps[i].priv = &heap_pdev->dev;
+
+		ret = ion_setup_heap_common(pdev, node, &heaps[i]);
+		if (ret)
+			return ERR_PTR(ret);
+		i++;
+
+		/* TODO custom callback */
+	}
+
+
+	data->heaps = heaps;
+	data->nr = num_heaps;
+	return data;
+}
+
+#ifdef CONFIG_OF_RESERVED_MEM
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+#include <linux/of_reserved_mem.h>
+
+static int rmem_ion_device_init(struct reserved_mem *rmem, struct device *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct ion_platform_heap *heap = pdev->dev.platform_data;
+
+	heap->base = rmem->base;
+	heap->base = rmem->size;
+	pr_debug("%s: heap %s base %pa size %pa dev %p\n", __func__,
+			heap->name, &rmem->base, &rmem->size, dev);
+	return 0;
+}
+
+static void rmem_ion_device_release(struct reserved_mem *rmem,
+					struct device *dev)
+{
+	return;
+}
+
+static const struct reserved_mem_ops rmem_dma_ops = {
+	.device_init	= rmem_ion_device_init,
+	.device_release	= rmem_ion_device_release,
+};
+
+static int __init rmem_ion_setup(struct reserved_mem *rmem)
+{
+	phys_addr_t size = rmem->size;
+
+	size = size / 1024;
+
+	pr_info("Ion memory setup at %pa size %pa MiB\n",
+		&rmem->base, &size);
+	rmem->ops = &rmem_dma_ops;
+	return 0;
+}
+RESERVEDMEM_OF_DECLARE(ion, "ion-region", rmem_ion_setup);
+#endif
diff --git a/drivers/staging/android/ion/ion_of.h b/drivers/staging/android/ion/ion_of.h
new file mode 100644
index 0000000..b4d1b6d
--- /dev/null
+++ b/drivers/staging/android/ion/ion_of.h
@@ -0,0 +1,3 @@
+/* YES I NEED HEADER */
+
+struct ion_platform_data *ion_parse_dt(struct platform_device *pdev);
-- 
2.4.3

[RFC PATCH] staging: ion: ion_parse_dt_heap_common() can be static

[kbuild test robot]

Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
 ion_of.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion_of.c b/drivers/staging/android/ion/ion_of.c
index 3c9b1e5..daded0c 100644
--- a/drivers/staging/android/ion/ion_of.c
+++ b/drivers/staging/android/ion/ion_of.c
@@ -28,7 +28,7 @@
  * Future work: allow callback function for each heap?
  */
 
-int ion_parse_dt_heap_common(struct device_node *heap_node,
+static int ion_parse_dt_heap_common(struct device_node *heap_node,
 			struct ion_platform_heap *heap)
 {
 	u32 ion_heap_id, ion_heap_align, ion_heap_type;
@@ -67,7 +67,7 @@ int ion_parse_dt_heap_common(struct device_node *heap_node,
 	return 0;
 }
 
-int ion_setup_heap_common(struct platform_device *parent,
+static int ion_setup_heap_common(struct platform_device *parent,
 			struct device_node *heap_node,
 			struct ion_platform_heap *heap)
 {

Re: [RFC][PATCH 2/2] staging: ion: Add files for parsing the devicetree (WIP)

[kbuild test robot]

Hi Laura,

[auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please ignore]

reproduce:
        # apt-get install sparse
        make ARCH=x86_64 allmodconfig
        make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/staging/android/ion/ion_of.c:31:5: sparse: symbol 'ion_parse_dt_heap_common' was not declared. Should it be static?
>> drivers/staging/android/ion/ion_of.c:70:5: sparse: symbol 'ion_setup_heap_common' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[RFC PATCH] staging: ion: ion_parse_dt_heap_common() can be static

[kbuild test robot]

Signed-off-by: Fengguang Wu <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 ion_of.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion_of.c b/drivers/staging/android/ion/ion_of.c
index 3c9b1e5..daded0c 100644
--- a/drivers/staging/android/ion/ion_of.c
+++ b/drivers/staging/android/ion/ion_of.c
@@ -28,7 +28,7 @@
  * Future work: allow callback function for each heap?
  */
 
-int ion_parse_dt_heap_common(struct device_node *heap_node,
+static int ion_parse_dt_heap_common(struct device_node *heap_node,
 			struct ion_platform_heap *heap)
 {
 	u32 ion_heap_id, ion_heap_align, ion_heap_type;
@@ -67,7 +67,7 @@ int ion_parse_dt_heap_common(struct device_node *heap_node,
 	return 0;
 }
 
-int ion_setup_heap_common(struct platform_device *parent,
+static int ion_setup_heap_common(struct platform_device *parent,
 			struct device_node *heap_node,
 			struct ion_platform_heap *heap)
 {
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 2/2] staging: ion: Add files for parsing the devicetree (WIP)

[kbuild test robot]

Hi Laura,

[auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please ignore]

reproduce:
        # apt-get install sparse
        make ARCH=x86_64 allmodconfig
        make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/staging/android/ion/ion_of.c:31:5: sparse: symbol 'ion_parse_dt_heap_common' was not declared. Should it be static?
>> drivers/staging/android/ion/ion_of.c:70:5: sparse: symbol 'ion_setup_heap_common' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[RFC PATCH] staging: ion: ion_parse_dt_heap_common() can be static

[kbuild test robot]

Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
 ion_of.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion_of.c b/drivers/staging/android/ion/ion_of.c
index 3c9b1e5..daded0c 100644
--- a/drivers/staging/android/ion/ion_of.c
+++ b/drivers/staging/android/ion/ion_of.c
@@ -28,7 +28,7 @@
  * Future work: allow callback function for each heap?
  */
 
-int ion_parse_dt_heap_common(struct device_node *heap_node,
+static int ion_parse_dt_heap_common(struct device_node *heap_node,
 			struct ion_platform_heap *heap)
 {
 	u32 ion_heap_id, ion_heap_align, ion_heap_type;
@@ -67,7 +67,7 @@ int ion_parse_dt_heap_common(struct device_node *heap_node,
 	return 0;
 }
 
-int ion_setup_heap_common(struct platform_device *parent,
+static int ion_setup_heap_common(struct platform_device *parent,
 			struct device_node *heap_node,
 			struct ion_platform_heap *heap)
 {

Re: [RFC][PATCH 2/2] staging: ion: Add files for parsing the devicetree (WIP)

[Andrew]

Thanks a lot for starting again with dt bindings discussion.
I got carried away by work and never had a chance for a respin of my 
ion-physmem.

I'll try to test these on actual hardware next week and provide more 
detailed
feedback. For now just a small pick:

> -
> +obj-$(CONFIG_ION_DUMMY)   += ion_dummy_driver.o
> +obj-$(CONFIG_ION_PHYSMEM) += ion_physmem.o
> +obj-$(CONFIG_ION_TEGRA)   += tegra/
> +obj-$(CONFIG_ION_OF) +=	ion_of.o ion_physmem.o

ion_physmem.o looks like the one that shouldn't be here, right?

P.S. Anyone interested in a non-android port of libion with
a few helper utils? I had to call it liblinuxion, since libion is 
something
already present in repositories.

-- 
Regards,
Andrew
RC Module

[RFC][PATCH 2/2] staging: ion: Add files for parsing the devicetree (WIP)

[Andrew]

Thanks a lot for starting again with dt bindings discussion.
I got carried away by work and never had a chance for a respin of my 
ion-physmem.

I'll try to test these on actual hardware next week and provide more 
detailed
feedback. For now just a small pick:

> -
> +obj-$(CONFIG_ION_DUMMY)   += ion_dummy_driver.o
> +obj-$(CONFIG_ION_PHYSMEM) += ion_physmem.o
> +obj-$(CONFIG_ION_TEGRA)   += tegra/
> +obj-$(CONFIG_ION_OF) +=	ion_of.o ion_physmem.o

ion_physmem.o looks like the one that shouldn't be here, right?

P.S. Anyone interested in a non-android port of libion with
a few helper utils? I had to call it liblinuxion, since libion is 
something
already present in repositories.

-- 
Regards,
Andrew
RC Module

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Rob Herring]

On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org> wrote:
> From: Laura Abbott <laura@labbott.name>
>
>
> This adds a base set of devicetree bindings for the Ion memory
> manager. This supports setting up the generic set of heaps and
> their properties.
>
> Signed-off-by: Laura Abbott <laura@labbott.name>
> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
> ---
>  drivers/staging/android/ion/devicetree.txt | 53 ++++++++++++++++++++++++++++++

I have no issue with this going in here, but I do have lots of issues
with this binding.

>  1 file changed, 53 insertions(+)
>  create mode 100644 drivers/staging/android/ion/devicetree.txt
>
> diff --git a/drivers/staging/android/ion/devicetree.txt b/drivers/staging/android/ion/devicetree.txt
> new file mode 100644
> index 0000000..4a0c941
> --- /dev/null
> +++ b/drivers/staging/android/ion/devicetree.txt
> @@ -0,0 +1,53 @@
> +Ion Memory Manager
> +
> +Ion is a memory manager that allows for sharing of buffers via dma-buf.
> +Ion allows for different types of allocation via an abstraction called
> +a 'heap'. A heap represents a specific type of memory. Each heap has
> +a different type. There can be multiple instances of the same heap
> +type.
> +
> +Required properties for Ion
> +
> +- compatible: "linux,ion"
> +
> +All child nodes of a linux,ion node are interpreted as heaps
> +
> +required properties for heaps
> +
> +- linux,ion-heap-id: The Ion heap id used for allocation selection
> +- linux,ion-heap-type: Ion heap type defined in ion.h
> +- linux,ion-heap-name: Human readble name of the heap
> +
> +
> +Optional properties
> +- memory-region: A phandle to a memory region. Required for DMA heap type
> +(see reserved-memory.txt for details on the reservation)
> +- linux,ion-heap-align: Alignment for the heap.
> +
> +Example:
> +
> +       ion {
> +               compatbile = "linux,ion";
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               ion-system-heap {
> +                       linux,ion-heap-id = <0>;
> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
> +                       linux,ion-heap-name = "system";

How does this vary across platforms? Is all of this being pushed down
to DT, because there is no coordination of this at the kernel ABI
level across platforms. In other words, why can't heap 0 be hardcoded
as system heap in the driver. It seems to me any 1 of these 3
properties could be used to derive the other 2.


> +               };
> +
> +               ion-camera-region {
> +                       linux,ion-heap-id = <1>;
> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
> +                       linux,ion-heap-name = "camera"
> +                       memory-region = <&camera_region>;

Couldn't the memory-region node with addition properties or some
standardization of existing ones provide enough information for ION's
needs?

> +               };
> +
> +               ion-fb-region {
> +                       linux,ion-heap-id = <2>;
> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
> +                       linux,ion-heap-name = "fb"
> +                       memory-region = <&fb_region>;
> +               };
> +       }
> --
> 2.4.3
>

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Rob Herring]

On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org> wrote:
> From: Laura Abbott <laura@labbott.name>
>
>
> This adds a base set of devicetree bindings for the Ion memory
> manager. This supports setting up the generic set of heaps and
> their properties.
>
> Signed-off-by: Laura Abbott <laura@labbott.name>
> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
> ---
>  drivers/staging/android/ion/devicetree.txt | 53 ++++++++++++++++++++++++++++++

I have no issue with this going in here, but I do have lots of issues
with this binding.

>  1 file changed, 53 insertions(+)
>  create mode 100644 drivers/staging/android/ion/devicetree.txt
>
> diff --git a/drivers/staging/android/ion/devicetree.txt b/drivers/staging/android/ion/devicetree.txt
> new file mode 100644
> index 0000000..4a0c941
> --- /dev/null
> +++ b/drivers/staging/android/ion/devicetree.txt
> @@ -0,0 +1,53 @@
> +Ion Memory Manager
> +
> +Ion is a memory manager that allows for sharing of buffers via dma-buf.
> +Ion allows for different types of allocation via an abstraction called
> +a 'heap'. A heap represents a specific type of memory. Each heap has
> +a different type. There can be multiple instances of the same heap
> +type.
> +
> +Required properties for Ion
> +
> +- compatible: "linux,ion"
> +
> +All child nodes of a linux,ion node are interpreted as heaps
> +
> +required properties for heaps
> +
> +- linux,ion-heap-id: The Ion heap id used for allocation selection
> +- linux,ion-heap-type: Ion heap type defined in ion.h
> +- linux,ion-heap-name: Human readble name of the heap
> +
> +
> +Optional properties
> +- memory-region: A phandle to a memory region. Required for DMA heap type
> +(see reserved-memory.txt for details on the reservation)
> +- linux,ion-heap-align: Alignment for the heap.
> +
> +Example:
> +
> +       ion {
> +               compatbile = "linux,ion";
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               ion-system-heap {
> +                       linux,ion-heap-id = <0>;
> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
> +                       linux,ion-heap-name = "system";

How does this vary across platforms? Is all of this being pushed down
to DT, because there is no coordination of this at the kernel ABI
level across platforms. In other words, why can't heap 0 be hardcoded
as system heap in the driver. It seems to me any 1 of these 3
properties could be used to derive the other 2.


> +               };
> +
> +               ion-camera-region {
> +                       linux,ion-heap-id = <1>;
> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
> +                       linux,ion-heap-name = "camera"
> +                       memory-region = <&camera_region>;

Couldn't the memory-region node with addition properties or some
standardization of existing ones provide enough information for ION's
needs?

> +               };
> +
> +               ion-fb-region {
> +                       linux,ion-heap-id = <2>;
> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
> +                       linux,ion-heap-name = "fb"
> +                       memory-region = <&fb_region>;
> +               };
> +       }
> --
> 2.4.3
>

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Rob Herring]

On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org> wrote:
> From: Laura Abbott <laura@labbott.name>
>
>
> This adds a base set of devicetree bindings for the Ion memory
> manager. This supports setting up the generic set of heaps and
> their properties.
>
> Signed-off-by: Laura Abbott <laura@labbott.name>
> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
> ---
>  drivers/staging/android/ion/devicetree.txt | 53 ++++++++++++++++++++++++++++++

I have no issue with this going in here, but I do have lots of issues
with this binding.

>  1 file changed, 53 insertions(+)
>  create mode 100644 drivers/staging/android/ion/devicetree.txt
>
> diff --git a/drivers/staging/android/ion/devicetree.txt b/drivers/staging/android/ion/devicetree.txt
> new file mode 100644
> index 0000000..4a0c941
> --- /dev/null
> +++ b/drivers/staging/android/ion/devicetree.txt
> @@ -0,0 +1,53 @@
> +Ion Memory Manager
> +
> +Ion is a memory manager that allows for sharing of buffers via dma-buf.
> +Ion allows for different types of allocation via an abstraction called
> +a 'heap'. A heap represents a specific type of memory. Each heap has
> +a different type. There can be multiple instances of the same heap
> +type.
> +
> +Required properties for Ion
> +
> +- compatible: "linux,ion"
> +
> +All child nodes of a linux,ion node are interpreted as heaps
> +
> +required properties for heaps
> +
> +- linux,ion-heap-id: The Ion heap id used for allocation selection
> +- linux,ion-heap-type: Ion heap type defined in ion.h
> +- linux,ion-heap-name: Human readble name of the heap
> +
> +
> +Optional properties
> +- memory-region: A phandle to a memory region. Required for DMA heap type
> +(see reserved-memory.txt for details on the reservation)
> +- linux,ion-heap-align: Alignment for the heap.
> +
> +Example:
> +
> +       ion {
> +               compatbile = "linux,ion";
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               ion-system-heap {
> +                       linux,ion-heap-id = <0>;
> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
> +                       linux,ion-heap-name = "system";

How does this vary across platforms? Is all of this being pushed down
to DT, because there is no coordination of this at the kernel ABI
level across platforms. In other words, why can't heap 0 be hardcoded
as system heap in the driver. It seems to me any 1 of these 3
properties could be used to derive the other 2.


> +               };
> +
> +               ion-camera-region {
> +                       linux,ion-heap-id = <1>;
> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
> +                       linux,ion-heap-name = "camera"
> +                       memory-region = <&camera_region>;

Couldn't the memory-region node with addition properties or some
standardization of existing ones provide enough information for ION's
needs?

> +               };
> +
> +               ion-fb-region {
> +                       linux,ion-heap-id = <2>;
> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
> +                       linux,ion-heap-name = "fb"
> +                       memory-region = <&fb_region>;
> +               };
> +       }
> --
> 2.4.3
>

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

On 10/6/15 3:35 PM, Rob Herring wrote:
> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org> wrote:
>> From: Laura Abbott <laura@labbott.name>
>>
>>
>> This adds a base set of devicetree bindings for the Ion memory
>> manager. This supports setting up the generic set of heaps and
>> their properties.
>>
>> Signed-off-by: Laura Abbott <laura@labbott.name>
>> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
>> ---
>>   drivers/staging/android/ion/devicetree.txt | 53 ++++++++++++++++++++++++++++++
>
> I have no issue with this going in here, but I do have lots of issues
> with this binding.
>
>>   1 file changed, 53 insertions(+)
>>   create mode 100644 drivers/staging/android/ion/devicetree.txt
>>
>> diff --git a/drivers/staging/android/ion/devicetree.txt b/drivers/staging/android/ion/devicetree.txt
>> new file mode 100644
>> index 0000000..4a0c941
>> --- /dev/null
>> +++ b/drivers/staging/android/ion/devicetree.txt
>> @@ -0,0 +1,53 @@
>> +Ion Memory Manager
>> +
>> +Ion is a memory manager that allows for sharing of buffers via dma-buf.
>> +Ion allows for different types of allocation via an abstraction called
>> +a 'heap'. A heap represents a specific type of memory. Each heap has
>> +a different type. There can be multiple instances of the same heap
>> +type.
>> +
>> +Required properties for Ion
>> +
>> +- compatible: "linux,ion"
>> +
>> +All child nodes of a linux,ion node are interpreted as heaps
>> +
>> +required properties for heaps
>> +
>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>> +- linux,ion-heap-name: Human readble name of the heap
>> +
>> +
>> +Optional properties
>> +- memory-region: A phandle to a memory region. Required for DMA heap type
>> +(see reserved-memory.txt for details on the reservation)
>> +- linux,ion-heap-align: Alignment for the heap.
>> +
>> +Example:
>> +
>> +       ion {
>> +               compatbile = "linux,ion";
>> +               #address-cells = <1>;
>> +               #size-cells = <0>;
>> +
>> +               ion-system-heap {
>> +                       linux,ion-heap-id = <0>;
>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>> +                       linux,ion-heap-name = "system";
>
> How does this vary across platforms? Is all of this being pushed down
> to DT, because there is no coordination of this at the kernel ABI
> level across platforms. In other words, why can't heap 0 be hardcoded
> as system heap in the driver. It seems to me any 1 of these 3
> properties could be used to derive the other 2.
>

Right now there is no guarantee heap IDs will be the same across
platforms. The heap IDs are currently part of the userspace ABI
as well since userspace clients must pass in a mask of the heap
IDs to allocate from. If we assume all existing clients could change,
heaps such as the system heap could be mandated to have the same
heap ID but we'd still run into problems if you have multiple
heaps of the same type (e.g. multiple carveouts)

An alternative might be to have each heap just be a compatible string
and pull everything (id, type etc.) into C files for setup. I debated
doing that but decided to try putting everything in DT for my first
pass.

>
>> +               };
>> +
>> +               ion-camera-region {
>> +                       linux,ion-heap-id = <1>;
>> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>> +                       linux,ion-heap-name = "camera"
>> +                       memory-region = <&camera_region>;
>
> Couldn't the memory-region node with addition properties or some
> standardization of existing ones provide enough information for ION's
> needs?
>

I think we could probably derive most of it from the memory-region right
now. If it's reusable, it's DMA, if not it goes to a carveout. Name can
come from the node name. heap ID and whether or not a region is a chunk
heap could be added as properties.

We'd still need to be able to get the same information for heaps that
don't correspond to a specific region like the system heap.

>> +               };
>> +
>> +               ion-fb-region {
>> +                       linux,ion-heap-id = <2>;
>> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>> +                       linux,ion-heap-name = "fb"
>> +                       memory-region = <&fb_region>;
>> +               };
>> +       }
>> --
>> 2.4.3
>>

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

On 10/6/15 3:35 PM, Rob Herring wrote:
> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org> wrote:
>> From: Laura Abbott <laura@labbott.name>
>>
>>
>> This adds a base set of devicetree bindings for the Ion memory
>> manager. This supports setting up the generic set of heaps and
>> their properties.
>>
>> Signed-off-by: Laura Abbott <laura@labbott.name>
>> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
>> ---
>>   drivers/staging/android/ion/devicetree.txt | 53 ++++++++++++++++++++++++++++++
>
> I have no issue with this going in here, but I do have lots of issues
> with this binding.
>
>>   1 file changed, 53 insertions(+)
>>   create mode 100644 drivers/staging/android/ion/devicetree.txt
>>
>> diff --git a/drivers/staging/android/ion/devicetree.txt b/drivers/staging/android/ion/devicetree.txt
>> new file mode 100644
>> index 0000000..4a0c941
>> --- /dev/null
>> +++ b/drivers/staging/android/ion/devicetree.txt
>> @@ -0,0 +1,53 @@
>> +Ion Memory Manager
>> +
>> +Ion is a memory manager that allows for sharing of buffers via dma-buf.
>> +Ion allows for different types of allocation via an abstraction called
>> +a 'heap'. A heap represents a specific type of memory. Each heap has
>> +a different type. There can be multiple instances of the same heap
>> +type.
>> +
>> +Required properties for Ion
>> +
>> +- compatible: "linux,ion"
>> +
>> +All child nodes of a linux,ion node are interpreted as heaps
>> +
>> +required properties for heaps
>> +
>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>> +- linux,ion-heap-name: Human readble name of the heap
>> +
>> +
>> +Optional properties
>> +- memory-region: A phandle to a memory region. Required for DMA heap type
>> +(see reserved-memory.txt for details on the reservation)
>> +- linux,ion-heap-align: Alignment for the heap.
>> +
>> +Example:
>> +
>> +       ion {
>> +               compatbile = "linux,ion";
>> +               #address-cells = <1>;
>> +               #size-cells = <0>;
>> +
>> +               ion-system-heap {
>> +                       linux,ion-heap-id = <0>;
>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>> +                       linux,ion-heap-name = "system";
>
> How does this vary across platforms? Is all of this being pushed down
> to DT, because there is no coordination of this at the kernel ABI
> level across platforms. In other words, why can't heap 0 be hardcoded
> as system heap in the driver. It seems to me any 1 of these 3
> properties could be used to derive the other 2.
>

Right now there is no guarantee heap IDs will be the same across
platforms. The heap IDs are currently part of the userspace ABI
as well since userspace clients must pass in a mask of the heap
IDs to allocate from. If we assume all existing clients could change,
heaps such as the system heap could be mandated to have the same
heap ID but we'd still run into problems if you have multiple
heaps of the same type (e.g. multiple carveouts)

An alternative might be to have each heap just be a compatible string
and pull everything (id, type etc.) into C files for setup. I debated
doing that but decided to try putting everything in DT for my first
pass.

>
>> +               };
>> +
>> +               ion-camera-region {
>> +                       linux,ion-heap-id = <1>;
>> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>> +                       linux,ion-heap-name = "camera"
>> +                       memory-region = <&camera_region>;
>
> Couldn't the memory-region node with addition properties or some
> standardization of existing ones provide enough information for ION's
> needs?
>

I think we could probably derive most of it from the memory-region right
now. If it's reusable, it's DMA, if not it goes to a carveout. Name can
come from the node name. heap ID and whether or not a region is a chunk
heap could be added as properties.

We'd still need to be able to get the same information for heaps that
don't correspond to a specific region like the system heap.

>> +               };
>> +
>> +               ion-fb-region {
>> +                       linux,ion-heap-id = <2>;
>> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>> +                       linux,ion-heap-name = "fb"
>> +                       memory-region = <&fb_region>;
>> +               };
>> +       }
>> --
>> 2.4.3
>>

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

On 10/6/15 3:35 PM, Rob Herring wrote:
> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org> wrote:
>> From: Laura Abbott <laura@labbott.name>
>>
>>
>> This adds a base set of devicetree bindings for the Ion memory
>> manager. This supports setting up the generic set of heaps and
>> their properties.
>>
>> Signed-off-by: Laura Abbott <laura@labbott.name>
>> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
>> ---
>>   drivers/staging/android/ion/devicetree.txt | 53 ++++++++++++++++++++++++++++++
>
> I have no issue with this going in here, but I do have lots of issues
> with this binding.
>
>>   1 file changed, 53 insertions(+)
>>   create mode 100644 drivers/staging/android/ion/devicetree.txt
>>
>> diff --git a/drivers/staging/android/ion/devicetree.txt b/drivers/staging/android/ion/devicetree.txt
>> new file mode 100644
>> index 0000000..4a0c941
>> --- /dev/null
>> +++ b/drivers/staging/android/ion/devicetree.txt
>> @@ -0,0 +1,53 @@
>> +Ion Memory Manager
>> +
>> +Ion is a memory manager that allows for sharing of buffers via dma-buf.
>> +Ion allows for different types of allocation via an abstraction called
>> +a 'heap'. A heap represents a specific type of memory. Each heap has
>> +a different type. There can be multiple instances of the same heap
>> +type.
>> +
>> +Required properties for Ion
>> +
>> +- compatible: "linux,ion"
>> +
>> +All child nodes of a linux,ion node are interpreted as heaps
>> +
>> +required properties for heaps
>> +
>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>> +- linux,ion-heap-name: Human readble name of the heap
>> +
>> +
>> +Optional properties
>> +- memory-region: A phandle to a memory region. Required for DMA heap type
>> +(see reserved-memory.txt for details on the reservation)
>> +- linux,ion-heap-align: Alignment for the heap.
>> +
>> +Example:
>> +
>> +       ion {
>> +               compatbile = "linux,ion";
>> +               #address-cells = <1>;
>> +               #size-cells = <0>;
>> +
>> +               ion-system-heap {
>> +                       linux,ion-heap-id = <0>;
>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>> +                       linux,ion-heap-name = "system";
>
> How does this vary across platforms? Is all of this being pushed down
> to DT, because there is no coordination of this at the kernel ABI
> level across platforms. In other words, why can't heap 0 be hardcoded
> as system heap in the driver. It seems to me any 1 of these 3
> properties could be used to derive the other 2.
>

Right now there is no guarantee heap IDs will be the same across
platforms. The heap IDs are currently part of the userspace ABI
as well since userspace clients must pass in a mask of the heap
IDs to allocate from. If we assume all existing clients could change,
heaps such as the system heap could be mandated to have the same
heap ID but we'd still run into problems if you have multiple
heaps of the same type (e.g. multiple carveouts)

An alternative might be to have each heap just be a compatible string
and pull everything (id, type etc.) into C files for setup. I debated
doing that but decided to try putting everything in DT for my first
pass.

>
>> +               };
>> +
>> +               ion-camera-region {
>> +                       linux,ion-heap-id = <1>;
>> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>> +                       linux,ion-heap-name = "camera"
>> +                       memory-region = <&camera_region>;
>
> Couldn't the memory-region node with addition properties or some
> standardization of existing ones provide enough information for ION's
> needs?
>

I think we could probably derive most of it from the memory-region right
now. If it's reusable, it's DMA, if not it goes to a carveout. Name can
come from the node name. heap ID and whether or not a region is a chunk
heap could be added as properties.

We'd still need to be able to get the same information for heaps that
don't correspond to a specific region like the system heap.

>> +               };
>> +
>> +               ion-fb-region {
>> +                       linux,ion-heap-id = <2>;
>> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>> +                       linux,ion-heap-name = "fb"
>> +                       memory-region = <&fb_region>;
>> +               };
>> +       }
>> --
>> 2.4.3
>>

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Andrew]

On 2015-10-07 02:01, Laura Abbott wrote:
> On 10/6/15 3:35 PM, Rob Herring wrote:
>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott 
>> <labbott@fedoraproject.org> wrote:
>>> From: Laura Abbott <laura@labbott.name>
>>> 
>>> 
>>> This adds a base set of devicetree bindings for the Ion memory
>>> manager. This supports setting up the generic set of heaps and
>>> their properties.
>>> 
>>> Signed-off-by: Laura Abbott <laura@labbott.name>
>>> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
>>> ---
>>>   drivers/staging/android/ion/devicetree.txt | 53 
>>> ++++++++++++++++++++++++++++++
>> 
>> I have no issue with this going in here, but I do have lots of issues
>> with this binding.
>> 
>>>   1 file changed, 53 insertions(+)
>>>   create mode 100644 drivers/staging/android/ion/devicetree.txt
>>> 
>>> diff --git a/drivers/staging/android/ion/devicetree.txt 
>>> b/drivers/staging/android/ion/devicetree.txt
>>> new file mode 100644
>>> index 0000000..4a0c941
>>> --- /dev/null
>>> +++ b/drivers/staging/android/ion/devicetree.txt
>>> @@ -0,0 +1,53 @@
>>> +Ion Memory Manager
>>> +
>>> +Ion is a memory manager that allows for sharing of buffers via 
>>> dma-buf.
>>> +Ion allows for different types of allocation via an abstraction 
>>> called
>>> +a 'heap'. A heap represents a specific type of memory. Each heap has
>>> +a different type. There can be multiple instances of the same heap
>>> +type.
>>> +
>>> +Required properties for Ion
>>> +
>>> +- compatible: "linux,ion"
>>> +
>>> +All child nodes of a linux,ion node are interpreted as heaps
>>> +
>>> +required properties for heaps
>>> +
>>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>>> +- linux,ion-heap-name: Human readble name of the heap
>>> +
>>> +
>>> +Optional properties
>>> +- memory-region: A phandle to a memory region. Required for DMA heap 
>>> type
>>> +(see reserved-memory.txt for details on the reservation)
>>> +- linux,ion-heap-align: Alignment for the heap.
>>> +
>>> +Example:
>>> +
>>> +       ion {
>>> +               compatbile = "linux,ion";
>>> +               #address-cells = <1>;
>>> +               #size-cells = <0>;
>>> +
>>> +               ion-system-heap {
>>> +                       linux,ion-heap-id = <0>;
>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>> +                       linux,ion-heap-name = "system";
>> 
>> How does this vary across platforms? Is all of this being pushed down
>> to DT, because there is no coordination of this at the kernel ABI
>> level across platforms. In other words, why can't heap 0 be hardcoded
>> as system heap in the driver. It seems to me any 1 of these 3
>> properties could be used to derive the other 2.
>> 
> 
> Right now there is no guarantee heap IDs will be the same across
> platforms. The heap IDs are currently part of the userspace ABI
> as well since userspace clients must pass in a mask of the heap
> IDs to allocate from. If we assume all existing clients could change,
> heaps such as the system heap could be mandated to have the same
> heap ID but we'd still run into problems if you have multiple
> heaps of the same type (e.g. multiple carveouts)

I don't really like the idea of enforcing any IDs here. As of now
heap ids are generally something VERY platform-specific
(or even product-specific). Personally I'd prefer something like this
for userspace apps:

int id1 = ion_get_heap_id("camera");
if (id1 < 0) {
       fprintf(stderr, "Invalid heap id");
       exit(1);
}

int id2 = ion_get_heap_id("backup-heap");
if (id2 < 0) {
       fprintf(stderr, "Invalid heap id");
       exit(1);
}

...

int ret = ion_alloc(fd, 0x100, 0x4,
               (id1 | id2),
               0, &handle);


What concerns kernel stuff, things are simpler - we may just pass the 
heap to use
by a reference in devicetree node for that driver. Something like that:

...
                ion-decoder-region : region_ddr {
                        linux,ion-heap-id = <1>;
                        linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
                        linux,ion-heap-name = "decoder_mem"
                        memory-region = <&camera_region>;
                 };
...
                 video_decoder@80180000 {
                         compatible = "acme,h266dec";
                         reg = <0x80180000 0x20000>,
                         reg-names = "registers";
                         interrupts = <12>;
                         interrupt-parent = <&vic1>;
                         ion-heaps-for-buffers = <&ion-decoder-region>
                 };



> 
> An alternative might be to have each heap just be a compatible string
> and pull everything (id, type etc.) into C files for setup. I debated
> doing that but decided to try putting everything in DT for my first
> pass.
> 
>> 
>>> +               };
>>> +
>>> +               ion-camera-region {
>>> +                       linux,ion-heap-id = <1>;
>>> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>>> +                       linux,ion-heap-name = "camera"
>>> +                       memory-region = <&camera_region>;
>> 
>> Couldn't the memory-region node with addition properties or some
>> standardization of existing ones provide enough information for ION's
>> needs?
>> 
> 
> I think we could probably derive most of it from the memory-region 
> right
> now. If it's reusable, it's DMA, if not it goes to a carveout. Name can
> come from the node name. heap ID and whether or not a region is a chunk
> heap could be added as properties.
> 
> We'd still need to be able to get the same information for heaps that
> don't correspond to a specific region like the system heap.
> 
>>> +               };
>>> +
>>> +               ion-fb-region {
>>> +                       linux,ion-heap-id = <2>;
>>> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>>> +                       linux,ion-heap-name = "fb"
>>> +                       memory-region = <&fb_region>;
>>> +               };
>>> +       }
>>> --
>>> 2.4.3
>>> 

-- 
Regards,
Andrew

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Andrew]

On 2015-10-07 02:01, Laura Abbott wrote:
> On 10/6/15 3:35 PM, Rob Herring wrote:
>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott 
>> <labbott-rxtnV0ftBwyoClj4AeEUq9i2O/JbrIOy@public.gmane.org> wrote:
>>> From: Laura Abbott <laura-0PSzFVTn/CLa5EbDDlwbIw@public.gmane.org>
>>> 
>>> 
>>> This adds a base set of devicetree bindings for the Ion memory
>>> manager. This supports setting up the generic set of heaps and
>>> their properties.
>>> 
>>> Signed-off-by: Laura Abbott <laura-0PSzFVTn/CLa5EbDDlwbIw@public.gmane.org>
>>> Signed-off-by: Andrew Andrianov <andrew-g16cbSVCqPUdnm+yROfE0A@public.gmane.org>
>>> ---
>>>   drivers/staging/android/ion/devicetree.txt | 53 
>>> ++++++++++++++++++++++++++++++
>> 
>> I have no issue with this going in here, but I do have lots of issues
>> with this binding.
>> 
>>>   1 file changed, 53 insertions(+)
>>>   create mode 100644 drivers/staging/android/ion/devicetree.txt
>>> 
>>> diff --git a/drivers/staging/android/ion/devicetree.txt 
>>> b/drivers/staging/android/ion/devicetree.txt
>>> new file mode 100644
>>> index 0000000..4a0c941
>>> --- /dev/null
>>> +++ b/drivers/staging/android/ion/devicetree.txt
>>> @@ -0,0 +1,53 @@
>>> +Ion Memory Manager
>>> +
>>> +Ion is a memory manager that allows for sharing of buffers via 
>>> dma-buf.
>>> +Ion allows for different types of allocation via an abstraction 
>>> called
>>> +a 'heap'. A heap represents a specific type of memory. Each heap has
>>> +a different type. There can be multiple instances of the same heap
>>> +type.
>>> +
>>> +Required properties for Ion
>>> +
>>> +- compatible: "linux,ion"
>>> +
>>> +All child nodes of a linux,ion node are interpreted as heaps
>>> +
>>> +required properties for heaps
>>> +
>>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>>> +- linux,ion-heap-name: Human readble name of the heap
>>> +
>>> +
>>> +Optional properties
>>> +- memory-region: A phandle to a memory region. Required for DMA heap 
>>> type
>>> +(see reserved-memory.txt for details on the reservation)
>>> +- linux,ion-heap-align: Alignment for the heap.
>>> +
>>> +Example:
>>> +
>>> +       ion {
>>> +               compatbile = "linux,ion";
>>> +               #address-cells = <1>;
>>> +               #size-cells = <0>;
>>> +
>>> +               ion-system-heap {
>>> +                       linux,ion-heap-id = <0>;
>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>> +                       linux,ion-heap-name = "system";
>> 
>> How does this vary across platforms? Is all of this being pushed down
>> to DT, because there is no coordination of this at the kernel ABI
>> level across platforms. In other words, why can't heap 0 be hardcoded
>> as system heap in the driver. It seems to me any 1 of these 3
>> properties could be used to derive the other 2.
>> 
> 
> Right now there is no guarantee heap IDs will be the same across
> platforms. The heap IDs are currently part of the userspace ABI
> as well since userspace clients must pass in a mask of the heap
> IDs to allocate from. If we assume all existing clients could change,
> heaps such as the system heap could be mandated to have the same
> heap ID but we'd still run into problems if you have multiple
> heaps of the same type (e.g. multiple carveouts)

I don't really like the idea of enforcing any IDs here. As of now
heap ids are generally something VERY platform-specific
(or even product-specific). Personally I'd prefer something like this
for userspace apps:

int id1 = ion_get_heap_id("camera");
if (id1 < 0) {
       fprintf(stderr, "Invalid heap id");
       exit(1);
}

int id2 = ion_get_heap_id("backup-heap");
if (id2 < 0) {
       fprintf(stderr, "Invalid heap id");
       exit(1);
}

...

int ret = ion_alloc(fd, 0x100, 0x4,
               (id1 | id2),
               0, &handle);


What concerns kernel stuff, things are simpler - we may just pass the 
heap to use
by a reference in devicetree node for that driver. Something like that:

...
                ion-decoder-region : region_ddr {
                        linux,ion-heap-id = <1>;
                        linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
                        linux,ion-heap-name = "decoder_mem"
                        memory-region = <&camera_region>;
                 };
...
                 video_decoder@80180000 {
                         compatible = "acme,h266dec";
                         reg = <0x80180000 0x20000>,
                         reg-names = "registers";
                         interrupts = <12>;
                         interrupt-parent = <&vic1>;
                         ion-heaps-for-buffers = <&ion-decoder-region>
                 };



> 
> An alternative might be to have each heap just be a compatible string
> and pull everything (id, type etc.) into C files for setup. I debated
> doing that but decided to try putting everything in DT for my first
> pass.
> 
>> 
>>> +               };
>>> +
>>> +               ion-camera-region {
>>> +                       linux,ion-heap-id = <1>;
>>> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>>> +                       linux,ion-heap-name = "camera"
>>> +                       memory-region = <&camera_region>;
>> 
>> Couldn't the memory-region node with addition properties or some
>> standardization of existing ones provide enough information for ION's
>> needs?
>> 
> 
> I think we could probably derive most of it from the memory-region 
> right
> now. If it's reusable, it's DMA, if not it goes to a carveout. Name can
> come from the node name. heap ID and whether or not a region is a chunk
> heap could be added as properties.
> 
> We'd still need to be able to get the same information for heaps that
> don't correspond to a specific region like the system heap.
> 
>>> +               };
>>> +
>>> +               ion-fb-region {
>>> +                       linux,ion-heap-id = <2>;
>>> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>>> +                       linux,ion-heap-name = "fb"
>>> +                       memory-region = <&fb_region>;
>>> +               };
>>> +       }
>>> --
>>> 2.4.3
>>> 

-- 
Regards,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Andrew]

On 2015-10-07 02:01, Laura Abbott wrote:
> On 10/6/15 3:35 PM, Rob Herring wrote:
>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott 
>> <labbott@fedoraproject.org> wrote:
>>> From: Laura Abbott <laura@labbott.name>
>>> 
>>> 
>>> This adds a base set of devicetree bindings for the Ion memory
>>> manager. This supports setting up the generic set of heaps and
>>> their properties.
>>> 
>>> Signed-off-by: Laura Abbott <laura@labbott.name>
>>> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
>>> ---
>>>   drivers/staging/android/ion/devicetree.txt | 53 
>>> ++++++++++++++++++++++++++++++
>> 
>> I have no issue with this going in here, but I do have lots of issues
>> with this binding.
>> 
>>>   1 file changed, 53 insertions(+)
>>>   create mode 100644 drivers/staging/android/ion/devicetree.txt
>>> 
>>> diff --git a/drivers/staging/android/ion/devicetree.txt 
>>> b/drivers/staging/android/ion/devicetree.txt
>>> new file mode 100644
>>> index 0000000..4a0c941
>>> --- /dev/null
>>> +++ b/drivers/staging/android/ion/devicetree.txt
>>> @@ -0,0 +1,53 @@
>>> +Ion Memory Manager
>>> +
>>> +Ion is a memory manager that allows for sharing of buffers via 
>>> dma-buf.
>>> +Ion allows for different types of allocation via an abstraction 
>>> called
>>> +a 'heap'. A heap represents a specific type of memory. Each heap has
>>> +a different type. There can be multiple instances of the same heap
>>> +type.
>>> +
>>> +Required properties for Ion
>>> +
>>> +- compatible: "linux,ion"
>>> +
>>> +All child nodes of a linux,ion node are interpreted as heaps
>>> +
>>> +required properties for heaps
>>> +
>>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>>> +- linux,ion-heap-name: Human readble name of the heap
>>> +
>>> +
>>> +Optional properties
>>> +- memory-region: A phandle to a memory region. Required for DMA heap 
>>> type
>>> +(see reserved-memory.txt for details on the reservation)
>>> +- linux,ion-heap-align: Alignment for the heap.
>>> +
>>> +Example:
>>> +
>>> +       ion {
>>> +               compatbile = "linux,ion";
>>> +               #address-cells = <1>;
>>> +               #size-cells = <0>;
>>> +
>>> +               ion-system-heap {
>>> +                       linux,ion-heap-id = <0>;
>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>> +                       linux,ion-heap-name = "system";
>> 
>> How does this vary across platforms? Is all of this being pushed down
>> to DT, because there is no coordination of this at the kernel ABI
>> level across platforms. In other words, why can't heap 0 be hardcoded
>> as system heap in the driver. It seems to me any 1 of these 3
>> properties could be used to derive the other 2.
>> 
> 
> Right now there is no guarantee heap IDs will be the same across
> platforms. The heap IDs are currently part of the userspace ABI
> as well since userspace clients must pass in a mask of the heap
> IDs to allocate from. If we assume all existing clients could change,
> heaps such as the system heap could be mandated to have the same
> heap ID but we'd still run into problems if you have multiple
> heaps of the same type (e.g. multiple carveouts)

I don't really like the idea of enforcing any IDs here. As of now
heap ids are generally something VERY platform-specific
(or even product-specific). Personally I'd prefer something like this
for userspace apps:

int id1 = ion_get_heap_id("camera");
if (id1 < 0) {
       fprintf(stderr, "Invalid heap id");
       exit(1);
}

int id2 = ion_get_heap_id("backup-heap");
if (id2 < 0) {
       fprintf(stderr, "Invalid heap id");
       exit(1);
}

...

int ret = ion_alloc(fd, 0x100, 0x4,
               (id1 | id2),
               0, &handle);


What concerns kernel stuff, things are simpler - we may just pass the 
heap to use
by a reference in devicetree node for that driver. Something like that:

...
                ion-decoder-region : region_ddr {
                        linux,ion-heap-id = <1>;
                        linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
                        linux,ion-heap-name = "decoder_mem"
                        memory-region = <&camera_region>;
                 };
...
                 video_decoder at 80180000 {
                         compatible = "acme,h266dec";
                         reg = <0x80180000 0x20000>,
                         reg-names = "registers";
                         interrupts = <12>;
                         interrupt-parent = <&vic1>;
                         ion-heaps-for-buffers = <&ion-decoder-region>
                 };



> 
> An alternative might be to have each heap just be a compatible string
> and pull everything (id, type etc.) into C files for setup. I debated
> doing that but decided to try putting everything in DT for my first
> pass.
> 
>> 
>>> +               };
>>> +
>>> +               ion-camera-region {
>>> +                       linux,ion-heap-id = <1>;
>>> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>>> +                       linux,ion-heap-name = "camera"
>>> +                       memory-region = <&camera_region>;
>> 
>> Couldn't the memory-region node with addition properties or some
>> standardization of existing ones provide enough information for ION's
>> needs?
>> 
> 
> I think we could probably derive most of it from the memory-region 
> right
> now. If it's reusable, it's DMA, if not it goes to a carveout. Name can
> come from the node name. heap ID and whether or not a region is a chunk
> heap could be added as properties.
> 
> We'd still need to be able to get the same information for heaps that
> don't correspond to a specific region like the system heap.
> 
>>> +               };
>>> +
>>> +               ion-fb-region {
>>> +                       linux,ion-heap-id = <2>;
>>> +                       linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>>> +                       linux,ion-heap-name = "fb"
>>> +                       memory-region = <&fb_region>;
>>> +               };
>>> +       }
>>> --
>>> 2.4.3
>>> 

-- 
Regards,
Andrew

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Rob Herring]

On Wed, Oct 7, 2015 at 5:36 AM, Andrew <andrew@ncrmnt.org> wrote:
> On 2015-10-07 02:01, Laura Abbott wrote:
>>
>> On 10/6/15 3:35 PM, Rob Herring wrote:
>>>
>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org>
>>> wrote:
>>>>
>>>> From: Laura Abbott <laura@labbott.name>
>>>>
>>>>
>>>> This adds a base set of devicetree bindings for the Ion memory
>>>> manager. This supports setting up the generic set of heaps and
>>>> their properties.
>>>>
>>>> Signed-off-by: Laura Abbott <laura@labbott.name>
>>>> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
>>>> ---
>>>>   drivers/staging/android/ion/devicetree.txt | 53
>>>> ++++++++++++++++++++++++++++++
>>>
>>>
>>> I have no issue with this going in here, but I do have lots of issues
>>> with this binding.
>>>
>>>>   1 file changed, 53 insertions(+)
>>>>   create mode 100644 drivers/staging/android/ion/devicetree.txt
>>>>
>>>> diff --git a/drivers/staging/android/ion/devicetree.txt
>>>> b/drivers/staging/android/ion/devicetree.txt
>>>> new file mode 100644
>>>> index 0000000..4a0c941
>>>> --- /dev/null
>>>> +++ b/drivers/staging/android/ion/devicetree.txt
>>>> @@ -0,0 +1,53 @@
>>>> +Ion Memory Manager
>>>> +
>>>> +Ion is a memory manager that allows for sharing of buffers via dma-buf.
>>>> +Ion allows for different types of allocation via an abstraction called
>>>> +a 'heap'. A heap represents a specific type of memory. Each heap has
>>>> +a different type. There can be multiple instances of the same heap
>>>> +type.
>>>> +
>>>> +Required properties for Ion
>>>> +
>>>> +- compatible: "linux,ion"
>>>> +
>>>> +All child nodes of a linux,ion node are interpreted as heaps
>>>> +
>>>> +required properties for heaps
>>>> +
>>>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>>>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>>>> +- linux,ion-heap-name: Human readble name of the heap
>>>> +
>>>> +
>>>> +Optional properties
>>>> +- memory-region: A phandle to a memory region. Required for DMA heap
>>>> type
>>>> +(see reserved-memory.txt for details on the reservation)
>>>> +- linux,ion-heap-align: Alignment for the heap.
>>>> +
>>>> +Example:
>>>> +
>>>> +       ion {
>>>> +               compatbile = "linux,ion";
>>>> +               #address-cells = <1>;
>>>> +               #size-cells = <0>;
>>>> +
>>>> +               ion-system-heap {
>>>> +                       linux,ion-heap-id = <0>;
>>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>> +                       linux,ion-heap-name = "system";
>>>
>>>
>>> How does this vary across platforms? Is all of this being pushed down
>>> to DT, because there is no coordination of this at the kernel ABI
>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>> as system heap in the driver. It seems to me any 1 of these 3
>>> properties could be used to derive the other 2.
>>>
>>
>> Right now there is no guarantee heap IDs will be the same across
>> platforms. The heap IDs are currently part of the userspace ABI
>> as well since userspace clients must pass in a mask of the heap
>> IDs to allocate from. If we assume all existing clients could change,
>> heaps such as the system heap could be mandated to have the same
>> heap ID but we'd still run into problems if you have multiple
>> heaps of the same type (e.g. multiple carveouts)

Vendors largely ignore the kernel-userspace ABI and anything in
staging is not a ABI. So arguments about what the ABI is currently is
pointless IMO.

Pushing an inconsistent kernel ABI to DT is not the answer.

>
> I don't really like the idea of enforcing any IDs here. As of now
> heap ids are generally something VERY platform-specific
> (or even product-specific). Personally I'd prefer something like this
> for userspace apps:
>
> int id1 = ion_get_heap_id("camera");
> if (id1 < 0) {
>       fprintf(stderr, "Invalid heap id");
>       exit(1);
> }
>
> int id2 = ion_get_heap_id("backup-heap");
> if (id2 < 0) {
>       fprintf(stderr, "Invalid heap id");
>       exit(1);
> }

We've learned that creating number spaces like this are bad (irqs,
gpios, /dev nodes). We should move away from that. Why should
userspace care about IDs or what the IDs are? An ID is just encoding
certain implicit requirements. So are the strings here. Users should
express what capabilities, restrictions, etc. they have, and then the
kernel can find the best heap.

> ...
>
> int ret = ion_alloc(fd, 0x100, 0x4,
>               (id1 | id2),
>               0, &handle);
>
>
> What concerns kernel stuff, things are simpler - we may just pass the heap
> to use
> by a reference in devicetree node for that driver. Something like that:
>
> ...
>                ion-decoder-region : region_ddr {
>                        linux,ion-heap-id = <1>;
>                        linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>                        linux,ion-heap-name = "decoder_mem"
>                        memory-region = <&camera_region>;
>                 };
> ...
>                 video_decoder@80180000 {
>                         compatible = "acme,h266dec";
>                         reg = <0x80180000 0x20000>,
>                         reg-names = "registers";
>                         interrupts = <12>;
>                         interrupt-parent = <&vic1>;
>                         ion-heaps-for-buffers = <&ion-decoder-region>

This is how memory-region is supposed to work. I don't see why we need
an additional level of indirection.

Rob

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Rob Herring]

On Wed, Oct 7, 2015 at 5:36 AM, Andrew <andrew-g16cbSVCqPUdnm+yROfE0A@public.gmane.org> wrote:
> On 2015-10-07 02:01, Laura Abbott wrote:
>>
>> On 10/6/15 3:35 PM, Rob Herring wrote:
>>>
>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott-rxtnV0ftBwyoClj4AeEUq9i2O/JbrIOy@public.gmane.org>
>>> wrote:
>>>>
>>>> From: Laura Abbott <laura-0PSzFVTn/CLa5EbDDlwbIw@public.gmane.org>
>>>>
>>>>
>>>> This adds a base set of devicetree bindings for the Ion memory
>>>> manager. This supports setting up the generic set of heaps and
>>>> their properties.
>>>>
>>>> Signed-off-by: Laura Abbott <laura-0PSzFVTn/CLa5EbDDlwbIw@public.gmane.org>
>>>> Signed-off-by: Andrew Andrianov <andrew-g16cbSVCqPUdnm+yROfE0A@public.gmane.org>
>>>> ---
>>>>   drivers/staging/android/ion/devicetree.txt | 53
>>>> ++++++++++++++++++++++++++++++
>>>
>>>
>>> I have no issue with this going in here, but I do have lots of issues
>>> with this binding.
>>>
>>>>   1 file changed, 53 insertions(+)
>>>>   create mode 100644 drivers/staging/android/ion/devicetree.txt
>>>>
>>>> diff --git a/drivers/staging/android/ion/devicetree.txt
>>>> b/drivers/staging/android/ion/devicetree.txt
>>>> new file mode 100644
>>>> index 0000000..4a0c941
>>>> --- /dev/null
>>>> +++ b/drivers/staging/android/ion/devicetree.txt
>>>> @@ -0,0 +1,53 @@
>>>> +Ion Memory Manager
>>>> +
>>>> +Ion is a memory manager that allows for sharing of buffers via dma-buf.
>>>> +Ion allows for different types of allocation via an abstraction called
>>>> +a 'heap'. A heap represents a specific type of memory. Each heap has
>>>> +a different type. There can be multiple instances of the same heap
>>>> +type.
>>>> +
>>>> +Required properties for Ion
>>>> +
>>>> +- compatible: "linux,ion"
>>>> +
>>>> +All child nodes of a linux,ion node are interpreted as heaps
>>>> +
>>>> +required properties for heaps
>>>> +
>>>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>>>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>>>> +- linux,ion-heap-name: Human readble name of the heap
>>>> +
>>>> +
>>>> +Optional properties
>>>> +- memory-region: A phandle to a memory region. Required for DMA heap
>>>> type
>>>> +(see reserved-memory.txt for details on the reservation)
>>>> +- linux,ion-heap-align: Alignment for the heap.
>>>> +
>>>> +Example:
>>>> +
>>>> +       ion {
>>>> +               compatbile = "linux,ion";
>>>> +               #address-cells = <1>;
>>>> +               #size-cells = <0>;
>>>> +
>>>> +               ion-system-heap {
>>>> +                       linux,ion-heap-id = <0>;
>>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>> +                       linux,ion-heap-name = "system";
>>>
>>>
>>> How does this vary across platforms? Is all of this being pushed down
>>> to DT, because there is no coordination of this at the kernel ABI
>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>> as system heap in the driver. It seems to me any 1 of these 3
>>> properties could be used to derive the other 2.
>>>
>>
>> Right now there is no guarantee heap IDs will be the same across
>> platforms. The heap IDs are currently part of the userspace ABI
>> as well since userspace clients must pass in a mask of the heap
>> IDs to allocate from. If we assume all existing clients could change,
>> heaps such as the system heap could be mandated to have the same
>> heap ID but we'd still run into problems if you have multiple
>> heaps of the same type (e.g. multiple carveouts)

Vendors largely ignore the kernel-userspace ABI and anything in
staging is not a ABI. So arguments about what the ABI is currently is
pointless IMO.

Pushing an inconsistent kernel ABI to DT is not the answer.

>
> I don't really like the idea of enforcing any IDs here. As of now
> heap ids are generally something VERY platform-specific
> (or even product-specific). Personally I'd prefer something like this
> for userspace apps:
>
> int id1 = ion_get_heap_id("camera");
> if (id1 < 0) {
>       fprintf(stderr, "Invalid heap id");
>       exit(1);
> }
>
> int id2 = ion_get_heap_id("backup-heap");
> if (id2 < 0) {
>       fprintf(stderr, "Invalid heap id");
>       exit(1);
> }

We've learned that creating number spaces like this are bad (irqs,
gpios, /dev nodes). We should move away from that. Why should
userspace care about IDs or what the IDs are? An ID is just encoding
certain implicit requirements. So are the strings here. Users should
express what capabilities, restrictions, etc. they have, and then the
kernel can find the best heap.

> ...
>
> int ret = ion_alloc(fd, 0x100, 0x4,
>               (id1 | id2),
>               0, &handle);
>
>
> What concerns kernel stuff, things are simpler - we may just pass the heap
> to use
> by a reference in devicetree node for that driver. Something like that:
>
> ...
>                ion-decoder-region : region_ddr {
>                        linux,ion-heap-id = <1>;
>                        linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>                        linux,ion-heap-name = "decoder_mem"
>                        memory-region = <&camera_region>;
>                 };
> ...
>                 video_decoder@80180000 {
>                         compatible = "acme,h266dec";
>                         reg = <0x80180000 0x20000>,
>                         reg-names = "registers";
>                         interrupts = <12>;
>                         interrupt-parent = <&vic1>;
>                         ion-heaps-for-buffers = <&ion-decoder-region>

This is how memory-region is supposed to work. I don't see why we need
an additional level of indirection.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Rob Herring]

On Wed, Oct 7, 2015 at 5:36 AM, Andrew <andrew@ncrmnt.org> wrote:
> On 2015-10-07 02:01, Laura Abbott wrote:
>>
>> On 10/6/15 3:35 PM, Rob Herring wrote:
>>>
>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org>
>>> wrote:
>>>>
>>>> From: Laura Abbott <laura@labbott.name>
>>>>
>>>>
>>>> This adds a base set of devicetree bindings for the Ion memory
>>>> manager. This supports setting up the generic set of heaps and
>>>> their properties.
>>>>
>>>> Signed-off-by: Laura Abbott <laura@labbott.name>
>>>> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
>>>> ---
>>>>   drivers/staging/android/ion/devicetree.txt | 53
>>>> ++++++++++++++++++++++++++++++
>>>
>>>
>>> I have no issue with this going in here, but I do have lots of issues
>>> with this binding.
>>>
>>>>   1 file changed, 53 insertions(+)
>>>>   create mode 100644 drivers/staging/android/ion/devicetree.txt
>>>>
>>>> diff --git a/drivers/staging/android/ion/devicetree.txt
>>>> b/drivers/staging/android/ion/devicetree.txt
>>>> new file mode 100644
>>>> index 0000000..4a0c941
>>>> --- /dev/null
>>>> +++ b/drivers/staging/android/ion/devicetree.txt
>>>> @@ -0,0 +1,53 @@
>>>> +Ion Memory Manager
>>>> +
>>>> +Ion is a memory manager that allows for sharing of buffers via dma-buf.
>>>> +Ion allows for different types of allocation via an abstraction called
>>>> +a 'heap'. A heap represents a specific type of memory. Each heap has
>>>> +a different type. There can be multiple instances of the same heap
>>>> +type.
>>>> +
>>>> +Required properties for Ion
>>>> +
>>>> +- compatible: "linux,ion"
>>>> +
>>>> +All child nodes of a linux,ion node are interpreted as heaps
>>>> +
>>>> +required properties for heaps
>>>> +
>>>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>>>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>>>> +- linux,ion-heap-name: Human readble name of the heap
>>>> +
>>>> +
>>>> +Optional properties
>>>> +- memory-region: A phandle to a memory region. Required for DMA heap
>>>> type
>>>> +(see reserved-memory.txt for details on the reservation)
>>>> +- linux,ion-heap-align: Alignment for the heap.
>>>> +
>>>> +Example:
>>>> +
>>>> +       ion {
>>>> +               compatbile = "linux,ion";
>>>> +               #address-cells = <1>;
>>>> +               #size-cells = <0>;
>>>> +
>>>> +               ion-system-heap {
>>>> +                       linux,ion-heap-id = <0>;
>>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>> +                       linux,ion-heap-name = "system";
>>>
>>>
>>> How does this vary across platforms? Is all of this being pushed down
>>> to DT, because there is no coordination of this at the kernel ABI
>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>> as system heap in the driver. It seems to me any 1 of these 3
>>> properties could be used to derive the other 2.
>>>
>>
>> Right now there is no guarantee heap IDs will be the same across
>> platforms. The heap IDs are currently part of the userspace ABI
>> as well since userspace clients must pass in a mask of the heap
>> IDs to allocate from. If we assume all existing clients could change,
>> heaps such as the system heap could be mandated to have the same
>> heap ID but we'd still run into problems if you have multiple
>> heaps of the same type (e.g. multiple carveouts)

Vendors largely ignore the kernel-userspace ABI and anything in
staging is not a ABI. So arguments about what the ABI is currently is
pointless IMO.

Pushing an inconsistent kernel ABI to DT is not the answer.

>
> I don't really like the idea of enforcing any IDs here. As of now
> heap ids are generally something VERY platform-specific
> (or even product-specific). Personally I'd prefer something like this
> for userspace apps:
>
> int id1 = ion_get_heap_id("camera");
> if (id1 < 0) {
>       fprintf(stderr, "Invalid heap id");
>       exit(1);
> }
>
> int id2 = ion_get_heap_id("backup-heap");
> if (id2 < 0) {
>       fprintf(stderr, "Invalid heap id");
>       exit(1);
> }

We've learned that creating number spaces like this are bad (irqs,
gpios, /dev nodes). We should move away from that. Why should
userspace care about IDs or what the IDs are? An ID is just encoding
certain implicit requirements. So are the strings here. Users should
express what capabilities, restrictions, etc. they have, and then the
kernel can find the best heap.

> ...
>
> int ret = ion_alloc(fd, 0x100, 0x4,
>               (id1 | id2),
>               0, &handle);
>
>
> What concerns kernel stuff, things are simpler - we may just pass the heap
> to use
> by a reference in devicetree node for that driver. Something like that:
>
> ...
>                ion-decoder-region : region_ddr {
>                        linux,ion-heap-id = <1>;
>                        linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>                        linux,ion-heap-name = "decoder_mem"
>                        memory-region = <&camera_region>;
>                 };
> ...
>                 video_decoder at 80180000 {
>                         compatible = "acme,h266dec";
>                         reg = <0x80180000 0x20000>,
>                         reg-names = "registers";
>                         interrupts = <12>;
>                         interrupt-parent = <&vic1>;
>                         ion-heaps-for-buffers = <&ion-decoder-region>

This is how memory-region is supposed to work. I don't see why we need
an additional level of indirection.

Rob

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Andrew]

On 2015-10-07 21:36, Rob Herring wrote:
> On Wed, Oct 7, 2015 at 5:36 AM, Andrew <andrew@ncrmnt.org> wrote:
>> On 2015-10-07 02:01, Laura Abbott wrote:
>>> 
>>> On 10/6/15 3:35 PM, Rob Herring wrote:
>>>> 
>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott 
>>>> <labbott@fedoraproject.org>
>>>> wrote:
>>>>> 
>>>>> From: Laura Abbott <laura@labbott.name>
>>>>> 
>>>>> 
>>>>> This adds a base set of devicetree bindings for the Ion memory
>>>>> manager. This supports setting up the generic set of heaps and
>>>>> their properties.
>>>>> 
>>>>> Signed-off-by: Laura Abbott <laura@labbott.name>
>>>>> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
>>>>> ---
>>>>>   drivers/staging/android/ion/devicetree.txt | 53
>>>>> ++++++++++++++++++++++++++++++
>>>> 
>>>> 
>>>> I have no issue with this going in here, but I do have lots of 
>>>> issues
>>>> with this binding.
>>>> 
>>>>>   1 file changed, 53 insertions(+)
>>>>>   create mode 100644 drivers/staging/android/ion/devicetree.txt
>>>>> 
>>>>> diff --git a/drivers/staging/android/ion/devicetree.txt
>>>>> b/drivers/staging/android/ion/devicetree.txt
>>>>> new file mode 100644
>>>>> index 0000000..4a0c941
>>>>> --- /dev/null
>>>>> +++ b/drivers/staging/android/ion/devicetree.txt
>>>>> @@ -0,0 +1,53 @@
>>>>> +Ion Memory Manager
>>>>> +
>>>>> +Ion is a memory manager that allows for sharing of buffers via 
>>>>> dma-buf.
>>>>> +Ion allows for different types of allocation via an abstraction 
>>>>> called
>>>>> +a 'heap'. A heap represents a specific type of memory. Each heap 
>>>>> has
>>>>> +a different type. There can be multiple instances of the same heap
>>>>> +type.
>>>>> +
>>>>> +Required properties for Ion
>>>>> +
>>>>> +- compatible: "linux,ion"
>>>>> +
>>>>> +All child nodes of a linux,ion node are interpreted as heaps
>>>>> +
>>>>> +required properties for heaps
>>>>> +
>>>>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>>>>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>>>>> +- linux,ion-heap-name: Human readble name of the heap
>>>>> +
>>>>> +
>>>>> +Optional properties
>>>>> +- memory-region: A phandle to a memory region. Required for DMA 
>>>>> heap
>>>>> type
>>>>> +(see reserved-memory.txt for details on the reservation)
>>>>> +- linux,ion-heap-align: Alignment for the heap.
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> +       ion {
>>>>> +               compatbile = "linux,ion";
>>>>> +               #address-cells = <1>;
>>>>> +               #size-cells = <0>;
>>>>> +
>>>>> +               ion-system-heap {
>>>>> +                       linux,ion-heap-id = <0>;
>>>>> +                       linux,ion-heap-type = 
>>>>> <ION_SYSTEM_HEAP_TYPE>;
>>>>> +                       linux,ion-heap-name = "system";
>>>> 
>>>> 
>>>> How does this vary across platforms? Is all of this being pushed 
>>>> down
>>>> to DT, because there is no coordination of this at the kernel ABI
>>>> level across platforms. In other words, why can't heap 0 be 
>>>> hardcoded
>>>> as system heap in the driver. It seems to me any 1 of these 3
>>>> properties could be used to derive the other 2.
>>>> 
>>> 
>>> Right now there is no guarantee heap IDs will be the same across
>>> platforms. The heap IDs are currently part of the userspace ABI
>>> as well since userspace clients must pass in a mask of the heap
>>> IDs to allocate from. If we assume all existing clients could change,
>>> heaps such as the system heap could be mandated to have the same
>>> heap ID but we'd still run into problems if you have multiple
>>> heaps of the same type (e.g. multiple carveouts)
> 
> Vendors largely ignore the kernel-userspace ABI and anything in
> staging is not a ABI. So arguments about what the ABI is currently is
> pointless IMO.
> 
> Pushing an inconsistent kernel ABI to DT is not the answer.

Totally agree here.

> 
>> 
>> I don't really like the idea of enforcing any IDs here. As of now
>> heap ids are generally something VERY platform-specific
>> (or even product-specific). Personally I'd prefer something like this
>> for userspace apps:
>> 
>> int id1 = ion_get_heap_id("camera");
>> if (id1 < 0) {
>>       fprintf(stderr, "Invalid heap id");
>>       exit(1);
>> }
>> 
>> int id2 = ion_get_heap_id("backup-heap");
>> if (id2 < 0) {
>>       fprintf(stderr, "Invalid heap id");
>>       exit(1);
>> }
> 
> We've learned that creating number spaces like this are bad (irqs,
> gpios, /dev nodes). We should move away from that. Why should
> userspace care about IDs or what the IDs are? An ID is just encoding
> certain implicit requirements. So are the strings here. Users should
> express what capabilities, restrictions, etc. they have, and then the
> kernel can find the best heap.

I'd argue about that point, since sometimes kernel might NOT know
all the hardware details behind some of the heaps or how they are going 
to
be used. Hence it can't decide a proper heap. And that's where things 
get ugly.

Real-world example: There are several on-chip SRAM banks that make up 
several
heaps. Say, IM0, IM1, IM2.

Technically - they are all DMA, and all work. But the hardware guys hand 
you
a handful of weird recommendations, like:
* Decoder will work faster if you use bank IM2 for internal buffers,
and prefer DDR bank A for decoded frames.
* DSP should stick with IM1, and please prefer DDR bank B for buffers

When several such devices are involved in one chain - things may get
even weirder. Having manual control over where allocations are made 
allows
us to keep all these voodoo magicks away from the kernel and (hopefully) 
keep
vendors from dirty hacks into ion itself.

> 
>> ...
>> 
>> int ret = ion_alloc(fd, 0x100, 0x4,
>>               (id1 | id2),
>>               0, &handle);
>> 
>> 
>> What concerns kernel stuff, things are simpler - we may just pass the 
>> heap
>> to use
>> by a reference in devicetree node for that driver. Something like 
>> that:
>> 
>> ...
>>                ion-decoder-region : region_ddr {
>>                        linux,ion-heap-id = <1>;
>>                        linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>>                        linux,ion-heap-name = "decoder_mem"
>>                        memory-region = <&camera_region>;
>>                 };
>> ...
>>                 video_decoder@80180000 {
>>                         compatible = "acme,h266dec";
>>                         reg = <0x80180000 0x20000>,
>>                         reg-names = "registers";
>>                         interrupts = <12>;
>>                         interrupt-parent = <&vic1>;
>>                         ion-heaps-for-buffers = <&ion-decoder-region>
> 
> This is how memory-region is supposed to work. I don't see why we need
> an additional level of indirection.

I don't see right now a clean way of getting ion heap id from driver 
when
having a memory-region referenced there. Correct me if if I'm all wrong 
about it.

> 
> Rob

-- 
Regards,
Andrew
RC Module

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Andrew]

On 2015-10-07 21:36, Rob Herring wrote:
> On Wed, Oct 7, 2015 at 5:36 AM, Andrew <andrew-g16cbSVCqPUdnm+yROfE0A@public.gmane.org> wrote:
>> On 2015-10-07 02:01, Laura Abbott wrote:
>>> 
>>> On 10/6/15 3:35 PM, Rob Herring wrote:
>>>> 
>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott 
>>>> <labbott-rxtnV0ftBwyoClj4AeEUq9i2O/JbrIOy@public.gmane.org>
>>>> wrote:
>>>>> 
>>>>> From: Laura Abbott <laura-0PSzFVTn/CLa5EbDDlwbIw@public.gmane.org>
>>>>> 
>>>>> 
>>>>> This adds a base set of devicetree bindings for the Ion memory
>>>>> manager. This supports setting up the generic set of heaps and
>>>>> their properties.
>>>>> 
>>>>> Signed-off-by: Laura Abbott <laura-0PSzFVTn/CLa5EbDDlwbIw@public.gmane.org>
>>>>> Signed-off-by: Andrew Andrianov <andrew-g16cbSVCqPUdnm+yROfE0A@public.gmane.org>
>>>>> ---
>>>>>   drivers/staging/android/ion/devicetree.txt | 53
>>>>> ++++++++++++++++++++++++++++++
>>>> 
>>>> 
>>>> I have no issue with this going in here, but I do have lots of 
>>>> issues
>>>> with this binding.
>>>> 
>>>>>   1 file changed, 53 insertions(+)
>>>>>   create mode 100644 drivers/staging/android/ion/devicetree.txt
>>>>> 
>>>>> diff --git a/drivers/staging/android/ion/devicetree.txt
>>>>> b/drivers/staging/android/ion/devicetree.txt
>>>>> new file mode 100644
>>>>> index 0000000..4a0c941
>>>>> --- /dev/null
>>>>> +++ b/drivers/staging/android/ion/devicetree.txt
>>>>> @@ -0,0 +1,53 @@
>>>>> +Ion Memory Manager
>>>>> +
>>>>> +Ion is a memory manager that allows for sharing of buffers via 
>>>>> dma-buf.
>>>>> +Ion allows for different types of allocation via an abstraction 
>>>>> called
>>>>> +a 'heap'. A heap represents a specific type of memory. Each heap 
>>>>> has
>>>>> +a different type. There can be multiple instances of the same heap
>>>>> +type.
>>>>> +
>>>>> +Required properties for Ion
>>>>> +
>>>>> +- compatible: "linux,ion"
>>>>> +
>>>>> +All child nodes of a linux,ion node are interpreted as heaps
>>>>> +
>>>>> +required properties for heaps
>>>>> +
>>>>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>>>>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>>>>> +- linux,ion-heap-name: Human readble name of the heap
>>>>> +
>>>>> +
>>>>> +Optional properties
>>>>> +- memory-region: A phandle to a memory region. Required for DMA 
>>>>> heap
>>>>> type
>>>>> +(see reserved-memory.txt for details on the reservation)
>>>>> +- linux,ion-heap-align: Alignment for the heap.
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> +       ion {
>>>>> +               compatbile = "linux,ion";
>>>>> +               #address-cells = <1>;
>>>>> +               #size-cells = <0>;
>>>>> +
>>>>> +               ion-system-heap {
>>>>> +                       linux,ion-heap-id = <0>;
>>>>> +                       linux,ion-heap-type = 
>>>>> <ION_SYSTEM_HEAP_TYPE>;
>>>>> +                       linux,ion-heap-name = "system";
>>>> 
>>>> 
>>>> How does this vary across platforms? Is all of this being pushed 
>>>> down
>>>> to DT, because there is no coordination of this at the kernel ABI
>>>> level across platforms. In other words, why can't heap 0 be 
>>>> hardcoded
>>>> as system heap in the driver. It seems to me any 1 of these 3
>>>> properties could be used to derive the other 2.
>>>> 
>>> 
>>> Right now there is no guarantee heap IDs will be the same across
>>> platforms. The heap IDs are currently part of the userspace ABI
>>> as well since userspace clients must pass in a mask of the heap
>>> IDs to allocate from. If we assume all existing clients could change,
>>> heaps such as the system heap could be mandated to have the same
>>> heap ID but we'd still run into problems if you have multiple
>>> heaps of the same type (e.g. multiple carveouts)
> 
> Vendors largely ignore the kernel-userspace ABI and anything in
> staging is not a ABI. So arguments about what the ABI is currently is
> pointless IMO.
> 
> Pushing an inconsistent kernel ABI to DT is not the answer.

Totally agree here.

> 
>> 
>> I don't really like the idea of enforcing any IDs here. As of now
>> heap ids are generally something VERY platform-specific
>> (or even product-specific). Personally I'd prefer something like this
>> for userspace apps:
>> 
>> int id1 = ion_get_heap_id("camera");
>> if (id1 < 0) {
>>       fprintf(stderr, "Invalid heap id");
>>       exit(1);
>> }
>> 
>> int id2 = ion_get_heap_id("backup-heap");
>> if (id2 < 0) {
>>       fprintf(stderr, "Invalid heap id");
>>       exit(1);
>> }
> 
> We've learned that creating number spaces like this are bad (irqs,
> gpios, /dev nodes). We should move away from that. Why should
> userspace care about IDs or what the IDs are? An ID is just encoding
> certain implicit requirements. So are the strings here. Users should
> express what capabilities, restrictions, etc. they have, and then the
> kernel can find the best heap.

I'd argue about that point, since sometimes kernel might NOT know
all the hardware details behind some of the heaps or how they are going 
to
be used. Hence it can't decide a proper heap. And that's where things 
get ugly.

Real-world example: There are several on-chip SRAM banks that make up 
several
heaps. Say, IM0, IM1, IM2.

Technically - they are all DMA, and all work. But the hardware guys hand 
you
a handful of weird recommendations, like:
* Decoder will work faster if you use bank IM2 for internal buffers,
and prefer DDR bank A for decoded frames.
* DSP should stick with IM1, and please prefer DDR bank B for buffers

When several such devices are involved in one chain - things may get
even weirder. Having manual control over where allocations are made 
allows
us to keep all these voodoo magicks away from the kernel and (hopefully) 
keep
vendors from dirty hacks into ion itself.

> 
>> ...
>> 
>> int ret = ion_alloc(fd, 0x100, 0x4,
>>               (id1 | id2),
>>               0, &handle);
>> 
>> 
>> What concerns kernel stuff, things are simpler - we may just pass the 
>> heap
>> to use
>> by a reference in devicetree node for that driver. Something like 
>> that:
>> 
>> ...
>>                ion-decoder-region : region_ddr {
>>                        linux,ion-heap-id = <1>;
>>                        linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>>                        linux,ion-heap-name = "decoder_mem"
>>                        memory-region = <&camera_region>;
>>                 };
>> ...
>>                 video_decoder@80180000 {
>>                         compatible = "acme,h266dec";
>>                         reg = <0x80180000 0x20000>,
>>                         reg-names = "registers";
>>                         interrupts = <12>;
>>                         interrupt-parent = <&vic1>;
>>                         ion-heaps-for-buffers = <&ion-decoder-region>
> 
> This is how memory-region is supposed to work. I don't see why we need
> an additional level of indirection.

I don't see right now a clean way of getting ion heap id from driver 
when
having a memory-region referenced there. Correct me if if I'm all wrong 
about it.

> 
> Rob

-- 
Regards,
Andrew
RC Module
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Andrew]

On 2015-10-07 21:36, Rob Herring wrote:
> On Wed, Oct 7, 2015 at 5:36 AM, Andrew <andrew@ncrmnt.org> wrote:
>> On 2015-10-07 02:01, Laura Abbott wrote:
>>> 
>>> On 10/6/15 3:35 PM, Rob Herring wrote:
>>>> 
>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott 
>>>> <labbott@fedoraproject.org>
>>>> wrote:
>>>>> 
>>>>> From: Laura Abbott <laura@labbott.name>
>>>>> 
>>>>> 
>>>>> This adds a base set of devicetree bindings for the Ion memory
>>>>> manager. This supports setting up the generic set of heaps and
>>>>> their properties.
>>>>> 
>>>>> Signed-off-by: Laura Abbott <laura@labbott.name>
>>>>> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
>>>>> ---
>>>>>   drivers/staging/android/ion/devicetree.txt | 53
>>>>> ++++++++++++++++++++++++++++++
>>>> 
>>>> 
>>>> I have no issue with this going in here, but I do have lots of 
>>>> issues
>>>> with this binding.
>>>> 
>>>>>   1 file changed, 53 insertions(+)
>>>>>   create mode 100644 drivers/staging/android/ion/devicetree.txt
>>>>> 
>>>>> diff --git a/drivers/staging/android/ion/devicetree.txt
>>>>> b/drivers/staging/android/ion/devicetree.txt
>>>>> new file mode 100644
>>>>> index 0000000..4a0c941
>>>>> --- /dev/null
>>>>> +++ b/drivers/staging/android/ion/devicetree.txt
>>>>> @@ -0,0 +1,53 @@
>>>>> +Ion Memory Manager
>>>>> +
>>>>> +Ion is a memory manager that allows for sharing of buffers via 
>>>>> dma-buf.
>>>>> +Ion allows for different types of allocation via an abstraction 
>>>>> called
>>>>> +a 'heap'. A heap represents a specific type of memory. Each heap 
>>>>> has
>>>>> +a different type. There can be multiple instances of the same heap
>>>>> +type.
>>>>> +
>>>>> +Required properties for Ion
>>>>> +
>>>>> +- compatible: "linux,ion"
>>>>> +
>>>>> +All child nodes of a linux,ion node are interpreted as heaps
>>>>> +
>>>>> +required properties for heaps
>>>>> +
>>>>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>>>>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>>>>> +- linux,ion-heap-name: Human readble name of the heap
>>>>> +
>>>>> +
>>>>> +Optional properties
>>>>> +- memory-region: A phandle to a memory region. Required for DMA 
>>>>> heap
>>>>> type
>>>>> +(see reserved-memory.txt for details on the reservation)
>>>>> +- linux,ion-heap-align: Alignment for the heap.
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> +       ion {
>>>>> +               compatbile = "linux,ion";
>>>>> +               #address-cells = <1>;
>>>>> +               #size-cells = <0>;
>>>>> +
>>>>> +               ion-system-heap {
>>>>> +                       linux,ion-heap-id = <0>;
>>>>> +                       linux,ion-heap-type = 
>>>>> <ION_SYSTEM_HEAP_TYPE>;
>>>>> +                       linux,ion-heap-name = "system";
>>>> 
>>>> 
>>>> How does this vary across platforms? Is all of this being pushed 
>>>> down
>>>> to DT, because there is no coordination of this at the kernel ABI
>>>> level across platforms. In other words, why can't heap 0 be 
>>>> hardcoded
>>>> as system heap in the driver. It seems to me any 1 of these 3
>>>> properties could be used to derive the other 2.
>>>> 
>>> 
>>> Right now there is no guarantee heap IDs will be the same across
>>> platforms. The heap IDs are currently part of the userspace ABI
>>> as well since userspace clients must pass in a mask of the heap
>>> IDs to allocate from. If we assume all existing clients could change,
>>> heaps such as the system heap could be mandated to have the same
>>> heap ID but we'd still run into problems if you have multiple
>>> heaps of the same type (e.g. multiple carveouts)
> 
> Vendors largely ignore the kernel-userspace ABI and anything in
> staging is not a ABI. So arguments about what the ABI is currently is
> pointless IMO.
> 
> Pushing an inconsistent kernel ABI to DT is not the answer.

Totally agree here.

> 
>> 
>> I don't really like the idea of enforcing any IDs here. As of now
>> heap ids are generally something VERY platform-specific
>> (or even product-specific). Personally I'd prefer something like this
>> for userspace apps:
>> 
>> int id1 = ion_get_heap_id("camera");
>> if (id1 < 0) {
>>       fprintf(stderr, "Invalid heap id");
>>       exit(1);
>> }
>> 
>> int id2 = ion_get_heap_id("backup-heap");
>> if (id2 < 0) {
>>       fprintf(stderr, "Invalid heap id");
>>       exit(1);
>> }
> 
> We've learned that creating number spaces like this are bad (irqs,
> gpios, /dev nodes). We should move away from that. Why should
> userspace care about IDs or what the IDs are? An ID is just encoding
> certain implicit requirements. So are the strings here. Users should
> express what capabilities, restrictions, etc. they have, and then the
> kernel can find the best heap.

I'd argue about that point, since sometimes kernel might NOT know
all the hardware details behind some of the heaps or how they are going 
to
be used. Hence it can't decide a proper heap. And that's where things 
get ugly.

Real-world example: There are several on-chip SRAM banks that make up 
several
heaps. Say, IM0, IM1, IM2.

Technically - they are all DMA, and all work. But the hardware guys hand 
you
a handful of weird recommendations, like:
* Decoder will work faster if you use bank IM2 for internal buffers,
and prefer DDR bank A for decoded frames.
* DSP should stick with IM1, and please prefer DDR bank B for buffers

When several such devices are involved in one chain - things may get
even weirder. Having manual control over where allocations are made 
allows
us to keep all these voodoo magicks away from the kernel and (hopefully) 
keep
vendors from dirty hacks into ion itself.

> 
>> ...
>> 
>> int ret = ion_alloc(fd, 0x100, 0x4,
>>               (id1 | id2),
>>               0, &handle);
>> 
>> 
>> What concerns kernel stuff, things are simpler - we may just pass the 
>> heap
>> to use
>> by a reference in devicetree node for that driver. Something like 
>> that:
>> 
>> ...
>>                ion-decoder-region : region_ddr {
>>                        linux,ion-heap-id = <1>;
>>                        linux,ion-heap-type = <ION_DMA_HEAP_TYPE>;
>>                        linux,ion-heap-name = "decoder_mem"
>>                        memory-region = <&camera_region>;
>>                 };
>> ...
>>                 video_decoder at 80180000 {
>>                         compatible = "acme,h266dec";
>>                         reg = <0x80180000 0x20000>,
>>                         reg-names = "registers";
>>                         interrupts = <12>;
>>                         interrupt-parent = <&vic1>;
>>                         ion-heaps-for-buffers = <&ion-decoder-region>
> 
> This is how memory-region is supposed to work. I don't see why we need
> an additional level of indirection.

I don't see right now a clean way of getting ion heap id from driver 
when
having a memory-region referenced there. Correct me if if I'm all wrong 
about it.

> 
> Rob

-- 
Regards,
Andrew
RC Module

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

On 10/7/15 11:36 AM, Rob Herring wrote:
> On Wed, Oct 7, 2015 at 5:36 AM, Andrew <andrew@ncrmnt.org> wrote:
>> On 2015-10-07 02:01, Laura Abbott wrote:
>>>
>>> On 10/6/15 3:35 PM, Rob Herring wrote:
>>>>
>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org>
>>>> wrote:
>>>>>
>>>>> From: Laura Abbott <laura@labbott.name>
>>>>>
>>>>>
>>>>> This adds a base set of devicetree bindings for the Ion memory
>>>>> manager. This supports setting up the generic set of heaps and
>>>>> their properties.
>>>>>
>>>>> Signed-off-by: Laura Abbott <laura@labbott.name>
>>>>> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
>>>>> ---
>>>>>    drivers/staging/android/ion/devicetree.txt | 53
>>>>> ++++++++++++++++++++++++++++++
>>>>
>>>>
>>>> I have no issue with this going in here, but I do have lots of issues
>>>> with this binding.
>>>>
>>>>>    1 file changed, 53 insertions(+)
>>>>>    create mode 100644 drivers/staging/android/ion/devicetree.txt
>>>>>
>>>>> diff --git a/drivers/staging/android/ion/devicetree.txt
>>>>> b/drivers/staging/android/ion/devicetree.txt
>>>>> new file mode 100644
>>>>> index 0000000..4a0c941
>>>>> --- /dev/null
>>>>> +++ b/drivers/staging/android/ion/devicetree.txt
>>>>> @@ -0,0 +1,53 @@
>>>>> +Ion Memory Manager
>>>>> +
>>>>> +Ion is a memory manager that allows for sharing of buffers via dma-buf.
>>>>> +Ion allows for different types of allocation via an abstraction called
>>>>> +a 'heap'. A heap represents a specific type of memory. Each heap has
>>>>> +a different type. There can be multiple instances of the same heap
>>>>> +type.
>>>>> +
>>>>> +Required properties for Ion
>>>>> +
>>>>> +- compatible: "linux,ion"
>>>>> +
>>>>> +All child nodes of a linux,ion node are interpreted as heaps
>>>>> +
>>>>> +required properties for heaps
>>>>> +
>>>>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>>>>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>>>>> +- linux,ion-heap-name: Human readble name of the heap
>>>>> +
>>>>> +
>>>>> +Optional properties
>>>>> +- memory-region: A phandle to a memory region. Required for DMA heap
>>>>> type
>>>>> +(see reserved-memory.txt for details on the reservation)
>>>>> +- linux,ion-heap-align: Alignment for the heap.
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> +       ion {
>>>>> +               compatbile = "linux,ion";
>>>>> +               #address-cells = <1>;
>>>>> +               #size-cells = <0>;
>>>>> +
>>>>> +               ion-system-heap {
>>>>> +                       linux,ion-heap-id = <0>;
>>>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>>> +                       linux,ion-heap-name = "system";
>>>>
>>>>
>>>> How does this vary across platforms? Is all of this being pushed down
>>>> to DT, because there is no coordination of this at the kernel ABI
>>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>>> as system heap in the driver. It seems to me any 1 of these 3
>>>> properties could be used to derive the other 2.
>>>>
>>>
>>> Right now there is no guarantee heap IDs will be the same across
>>> platforms. The heap IDs are currently part of the userspace ABI
>>> as well since userspace clients must pass in a mask of the heap
>>> IDs to allocate from. If we assume all existing clients could change,
>>> heaps such as the system heap could be mandated to have the same
>>> heap ID but we'd still run into problems if you have multiple
>>> heaps of the same type (e.g. multiple carveouts)
>
> Vendors largely ignore the kernel-userspace ABI and anything in
> staging is not a ABI. So arguments about what the ABI is currently is
> pointless IMO.
>
> Pushing an inconsistent kernel ABI to DT is not the answer.
>

I'm not sure I agree it's inconsistent because it varies across
platforms. IRQs vary across platforms (yes I know something something
hardware description). Vendors really should be caring about ABIs
and it's kind of a chicken and egg problem about when staging
driver ABIs should be considered stable. Perhaps it should be
"Pushing bad kernel ABIs to DT is not the answer" which is a
fair objection to Ion.

>>
>> I don't really like the idea of enforcing any IDs here. As of now
>> heap ids are generally something VERY platform-specific
>> (or even product-specific). Personally I'd prefer something like this
>> for userspace apps:
>>
>> int id1 = ion_get_heap_id("camera");
>> if (id1 < 0) {
>>        fprintf(stderr, "Invalid heap id");
>>        exit(1);
>> }
>>
>> int id2 = ion_get_heap_id("backup-heap");
>> if (id2 < 0) {
>>        fprintf(stderr, "Invalid heap id");
>>        exit(1);
>> }
>
> We've learned that creating number spaces like this are bad (irqs,
> gpios, /dev nodes). We should move away from that. Why should
> userspace care about IDs or what the IDs are? An ID is just encoding
> certain implicit requirements. So are the strings here. Users should
> express what capabilities, restrictions, etc. they have, and then the
> kernel can find the best heap.
>

I'd argue that the heap IDs are expressing capabilities and
restrictions. A heap ID for camera could be contiguous on
one system and discontiguous on another based on the system.
The user only gives the ID, not the type so it's ultimately
up to the kernel to decide what that heap ID means on a particular
system. Ion allows or'ing of heap IDs together and the kernel
selects them currently based on priority. What's your idea for
expressing the capabilities without resorting IDs?

I'm going to give some more thought to this but I think I
might look into just having each heap be a compatible
string. This might fit in better with something that
belongs in devicetree: each heap is describing a platform
capability (discontiguous memory, CMA, carved out, releases
bees etc.). Anything outside of a compatible string can
probably be pulled back into the kernel.

Thanks,
Laura

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

On 10/7/15 11:36 AM, Rob Herring wrote:
> On Wed, Oct 7, 2015 at 5:36 AM, Andrew <andrew-g16cbSVCqPUdnm+yROfE0A@public.gmane.org> wrote:
>> On 2015-10-07 02:01, Laura Abbott wrote:
>>>
>>> On 10/6/15 3:35 PM, Rob Herring wrote:
>>>>
>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott-rxtnV0ftBwyoClj4AeEUq9i2O/JbrIOy@public.gmane.org>
>>>> wrote:
>>>>>
>>>>> From: Laura Abbott <laura-0PSzFVTn/CLa5EbDDlwbIw@public.gmane.org>
>>>>>
>>>>>
>>>>> This adds a base set of devicetree bindings for the Ion memory
>>>>> manager. This supports setting up the generic set of heaps and
>>>>> their properties.
>>>>>
>>>>> Signed-off-by: Laura Abbott <laura-0PSzFVTn/CLa5EbDDlwbIw@public.gmane.org>
>>>>> Signed-off-by: Andrew Andrianov <andrew-g16cbSVCqPUdnm+yROfE0A@public.gmane.org>
>>>>> ---
>>>>>    drivers/staging/android/ion/devicetree.txt | 53
>>>>> ++++++++++++++++++++++++++++++
>>>>
>>>>
>>>> I have no issue with this going in here, but I do have lots of issues
>>>> with this binding.
>>>>
>>>>>    1 file changed, 53 insertions(+)
>>>>>    create mode 100644 drivers/staging/android/ion/devicetree.txt
>>>>>
>>>>> diff --git a/drivers/staging/android/ion/devicetree.txt
>>>>> b/drivers/staging/android/ion/devicetree.txt
>>>>> new file mode 100644
>>>>> index 0000000..4a0c941
>>>>> --- /dev/null
>>>>> +++ b/drivers/staging/android/ion/devicetree.txt
>>>>> @@ -0,0 +1,53 @@
>>>>> +Ion Memory Manager
>>>>> +
>>>>> +Ion is a memory manager that allows for sharing of buffers via dma-buf.
>>>>> +Ion allows for different types of allocation via an abstraction called
>>>>> +a 'heap'. A heap represents a specific type of memory. Each heap has
>>>>> +a different type. There can be multiple instances of the same heap
>>>>> +type.
>>>>> +
>>>>> +Required properties for Ion
>>>>> +
>>>>> +- compatible: "linux,ion"
>>>>> +
>>>>> +All child nodes of a linux,ion node are interpreted as heaps
>>>>> +
>>>>> +required properties for heaps
>>>>> +
>>>>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>>>>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>>>>> +- linux,ion-heap-name: Human readble name of the heap
>>>>> +
>>>>> +
>>>>> +Optional properties
>>>>> +- memory-region: A phandle to a memory region. Required for DMA heap
>>>>> type
>>>>> +(see reserved-memory.txt for details on the reservation)
>>>>> +- linux,ion-heap-align: Alignment for the heap.
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> +       ion {
>>>>> +               compatbile = "linux,ion";
>>>>> +               #address-cells = <1>;
>>>>> +               #size-cells = <0>;
>>>>> +
>>>>> +               ion-system-heap {
>>>>> +                       linux,ion-heap-id = <0>;
>>>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>>> +                       linux,ion-heap-name = "system";
>>>>
>>>>
>>>> How does this vary across platforms? Is all of this being pushed down
>>>> to DT, because there is no coordination of this at the kernel ABI
>>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>>> as system heap in the driver. It seems to me any 1 of these 3
>>>> properties could be used to derive the other 2.
>>>>
>>>
>>> Right now there is no guarantee heap IDs will be the same across
>>> platforms. The heap IDs are currently part of the userspace ABI
>>> as well since userspace clients must pass in a mask of the heap
>>> IDs to allocate from. If we assume all existing clients could change,
>>> heaps such as the system heap could be mandated to have the same
>>> heap ID but we'd still run into problems if you have multiple
>>> heaps of the same type (e.g. multiple carveouts)
>
> Vendors largely ignore the kernel-userspace ABI and anything in
> staging is not a ABI. So arguments about what the ABI is currently is
> pointless IMO.
>
> Pushing an inconsistent kernel ABI to DT is not the answer.
>

I'm not sure I agree it's inconsistent because it varies across
platforms. IRQs vary across platforms (yes I know something something
hardware description). Vendors really should be caring about ABIs
and it's kind of a chicken and egg problem about when staging
driver ABIs should be considered stable. Perhaps it should be
"Pushing bad kernel ABIs to DT is not the answer" which is a
fair objection to Ion.

>>
>> I don't really like the idea of enforcing any IDs here. As of now
>> heap ids are generally something VERY platform-specific
>> (or even product-specific). Personally I'd prefer something like this
>> for userspace apps:
>>
>> int id1 = ion_get_heap_id("camera");
>> if (id1 < 0) {
>>        fprintf(stderr, "Invalid heap id");
>>        exit(1);
>> }
>>
>> int id2 = ion_get_heap_id("backup-heap");
>> if (id2 < 0) {
>>        fprintf(stderr, "Invalid heap id");
>>        exit(1);
>> }
>
> We've learned that creating number spaces like this are bad (irqs,
> gpios, /dev nodes). We should move away from that. Why should
> userspace care about IDs or what the IDs are? An ID is just encoding
> certain implicit requirements. So are the strings here. Users should
> express what capabilities, restrictions, etc. they have, and then the
> kernel can find the best heap.
>

I'd argue that the heap IDs are expressing capabilities and
restrictions. A heap ID for camera could be contiguous on
one system and discontiguous on another based on the system.
The user only gives the ID, not the type so it's ultimately
up to the kernel to decide what that heap ID means on a particular
system. Ion allows or'ing of heap IDs together and the kernel
selects them currently based on priority. What's your idea for
expressing the capabilities without resorting IDs?

I'm going to give some more thought to this but I think I
might look into just having each heap be a compatible
string. This might fit in better with something that
belongs in devicetree: each heap is describing a platform
capability (discontiguous memory, CMA, carved out, releases
bees etc.). Anything outside of a compatible string can
probably be pulled back into the kernel.

Thanks,
Laura
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

On 10/7/15 11:36 AM, Rob Herring wrote:
> On Wed, Oct 7, 2015 at 5:36 AM, Andrew <andrew@ncrmnt.org> wrote:
>> On 2015-10-07 02:01, Laura Abbott wrote:
>>>
>>> On 10/6/15 3:35 PM, Rob Herring wrote:
>>>>
>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org>
>>>> wrote:
>>>>>
>>>>> From: Laura Abbott <laura@labbott.name>
>>>>>
>>>>>
>>>>> This adds a base set of devicetree bindings for the Ion memory
>>>>> manager. This supports setting up the generic set of heaps and
>>>>> their properties.
>>>>>
>>>>> Signed-off-by: Laura Abbott <laura@labbott.name>
>>>>> Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
>>>>> ---
>>>>>    drivers/staging/android/ion/devicetree.txt | 53
>>>>> ++++++++++++++++++++++++++++++
>>>>
>>>>
>>>> I have no issue with this going in here, but I do have lots of issues
>>>> with this binding.
>>>>
>>>>>    1 file changed, 53 insertions(+)
>>>>>    create mode 100644 drivers/staging/android/ion/devicetree.txt
>>>>>
>>>>> diff --git a/drivers/staging/android/ion/devicetree.txt
>>>>> b/drivers/staging/android/ion/devicetree.txt
>>>>> new file mode 100644
>>>>> index 0000000..4a0c941
>>>>> --- /dev/null
>>>>> +++ b/drivers/staging/android/ion/devicetree.txt
>>>>> @@ -0,0 +1,53 @@
>>>>> +Ion Memory Manager
>>>>> +
>>>>> +Ion is a memory manager that allows for sharing of buffers via dma-buf.
>>>>> +Ion allows for different types of allocation via an abstraction called
>>>>> +a 'heap'. A heap represents a specific type of memory. Each heap has
>>>>> +a different type. There can be multiple instances of the same heap
>>>>> +type.
>>>>> +
>>>>> +Required properties for Ion
>>>>> +
>>>>> +- compatible: "linux,ion"
>>>>> +
>>>>> +All child nodes of a linux,ion node are interpreted as heaps
>>>>> +
>>>>> +required properties for heaps
>>>>> +
>>>>> +- linux,ion-heap-id: The Ion heap id used for allocation selection
>>>>> +- linux,ion-heap-type: Ion heap type defined in ion.h
>>>>> +- linux,ion-heap-name: Human readble name of the heap
>>>>> +
>>>>> +
>>>>> +Optional properties
>>>>> +- memory-region: A phandle to a memory region. Required for DMA heap
>>>>> type
>>>>> +(see reserved-memory.txt for details on the reservation)
>>>>> +- linux,ion-heap-align: Alignment for the heap.
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> +       ion {
>>>>> +               compatbile = "linux,ion";
>>>>> +               #address-cells = <1>;
>>>>> +               #size-cells = <0>;
>>>>> +
>>>>> +               ion-system-heap {
>>>>> +                       linux,ion-heap-id = <0>;
>>>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>>> +                       linux,ion-heap-name = "system";
>>>>
>>>>
>>>> How does this vary across platforms? Is all of this being pushed down
>>>> to DT, because there is no coordination of this at the kernel ABI
>>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>>> as system heap in the driver. It seems to me any 1 of these 3
>>>> properties could be used to derive the other 2.
>>>>
>>>
>>> Right now there is no guarantee heap IDs will be the same across
>>> platforms. The heap IDs are currently part of the userspace ABI
>>> as well since userspace clients must pass in a mask of the heap
>>> IDs to allocate from. If we assume all existing clients could change,
>>> heaps such as the system heap could be mandated to have the same
>>> heap ID but we'd still run into problems if you have multiple
>>> heaps of the same type (e.g. multiple carveouts)
>
> Vendors largely ignore the kernel-userspace ABI and anything in
> staging is not a ABI. So arguments about what the ABI is currently is
> pointless IMO.
>
> Pushing an inconsistent kernel ABI to DT is not the answer.
>

I'm not sure I agree it's inconsistent because it varies across
platforms. IRQs vary across platforms (yes I know something something
hardware description). Vendors really should be caring about ABIs
and it's kind of a chicken and egg problem about when staging
driver ABIs should be considered stable. Perhaps it should be
"Pushing bad kernel ABIs to DT is not the answer" which is a
fair objection to Ion.

>>
>> I don't really like the idea of enforcing any IDs here. As of now
>> heap ids are generally something VERY platform-specific
>> (or even product-specific). Personally I'd prefer something like this
>> for userspace apps:
>>
>> int id1 = ion_get_heap_id("camera");
>> if (id1 < 0) {
>>        fprintf(stderr, "Invalid heap id");
>>        exit(1);
>> }
>>
>> int id2 = ion_get_heap_id("backup-heap");
>> if (id2 < 0) {
>>        fprintf(stderr, "Invalid heap id");
>>        exit(1);
>> }
>
> We've learned that creating number spaces like this are bad (irqs,
> gpios, /dev nodes). We should move away from that. Why should
> userspace care about IDs or what the IDs are? An ID is just encoding
> certain implicit requirements. So are the strings here. Users should
> express what capabilities, restrictions, etc. they have, and then the
> kernel can find the best heap.
>

I'd argue that the heap IDs are expressing capabilities and
restrictions. A heap ID for camera could be contiguous on
one system and discontiguous on another based on the system.
The user only gives the ID, not the type so it's ultimately
up to the kernel to decide what that heap ID means on a particular
system. Ion allows or'ing of heap IDs together and the kernel
selects them currently based on priority. What's your idea for
expressing the capabilities without resorting IDs?

I'm going to give some more thought to this but I think I
might look into just having each heap be a compatible
string. This might fit in better with something that
belongs in devicetree: each heap is describing a platform
capability (discontiguous memory, CMA, carved out, releases
bees etc.). Anything outside of a compatible string can
probably be pulled back into the kernel.

Thanks,
Laura

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Mitchel Humpherys]

On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com> wrote:
> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org> wrote:

[...]

>> +Example:
>> +
>> +       ion {
>> +               compatbile = "linux,ion";
>> +               #address-cells = <1>;
>> +               #size-cells = <0>;
>> +
>> +               ion-system-heap {
>> +                       linux,ion-heap-id = <0>;
>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>> +                       linux,ion-heap-name = "system";
>
> How does this vary across platforms? Is all of this being pushed down
> to DT, because there is no coordination of this at the kernel ABI
> level across platforms. In other words, why can't heap 0 be hardcoded
> as system heap in the driver. It seems to me any 1 of these 3
> properties could be used to derive the other 2.

The heap-id<->heap-type mapping isn't necessarily 1:1.  As Laura
indicated elsewhere on this thread, a given heap might need to be
contiguous on one platform but not on another.  In that case you just
swap out the heap-type here and there's no need for userspace to change.

The heap-name, OTOH, could be derived from the heap-id, which is what we
hackishly do here [1] and here[2].

[1] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n53
[2] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n398


-Mitch

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Mitchel Humpherys]

On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott-rxtnV0ftBwyoClj4AeEUq9i2O/JbrIOy@public.gmane.org> wrote:

[...]

>> +Example:
>> +
>> +       ion {
>> +               compatbile = "linux,ion";
>> +               #address-cells = <1>;
>> +               #size-cells = <0>;
>> +
>> +               ion-system-heap {
>> +                       linux,ion-heap-id = <0>;
>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>> +                       linux,ion-heap-name = "system";
>
> How does this vary across platforms? Is all of this being pushed down
> to DT, because there is no coordination of this at the kernel ABI
> level across platforms. In other words, why can't heap 0 be hardcoded
> as system heap in the driver. It seems to me any 1 of these 3
> properties could be used to derive the other 2.

The heap-id<->heap-type mapping isn't necessarily 1:1.  As Laura
indicated elsewhere on this thread, a given heap might need to be
contiguous on one platform but not on another.  In that case you just
swap out the heap-type here and there's no need for userspace to change.

The heap-name, OTOH, could be derived from the heap-id, which is what we
hackishly do here [1] and here[2].

[1] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n53
[2] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n398


-Mitch

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Mitchel Humpherys]

On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com> wrote:
> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org> wrote:

[...]

>> +Example:
>> +
>> +       ion {
>> +               compatbile = "linux,ion";
>> +               #address-cells = <1>;
>> +               #size-cells = <0>;
>> +
>> +               ion-system-heap {
>> +                       linux,ion-heap-id = <0>;
>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>> +                       linux,ion-heap-name = "system";
>
> How does this vary across platforms? Is all of this being pushed down
> to DT, because there is no coordination of this at the kernel ABI
> level across platforms. In other words, why can't heap 0 be hardcoded
> as system heap in the driver. It seems to me any 1 of these 3
> properties could be used to derive the other 2.

The heap-id<->heap-type mapping isn't necessarily 1:1.  As Laura
indicated elsewhere on this thread, a given heap might need to be
contiguous on one platform but not on another.  In that case you just
swap out the heap-type here and there's no need for userspace to change.

The heap-name, OTOH, could be derived from the heap-id, which is what we
hackishly do here [1] and here[2].

[1] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n53
[2] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n398


-Mitch

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Andrew]

On 2015-10-12 21:39, Mitchel Humpherys wrote:
> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com> 
> wrote:
>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott 
>> <labbott@fedoraproject.org> wrote:
> 
> [...]
> 
>>> +Example:
>>> +
>>> +       ion {
>>> +               compatbile = "linux,ion";
>>> +               #address-cells = <1>;
>>> +               #size-cells = <0>;
>>> +
>>> +               ion-system-heap {
>>> +                       linux,ion-heap-id = <0>;
>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>> +                       linux,ion-heap-name = "system";
>> 
>> How does this vary across platforms? Is all of this being pushed down
>> to DT, because there is no coordination of this at the kernel ABI
>> level across platforms. In other words, why can't heap 0 be hardcoded
>> as system heap in the driver. It seems to me any 1 of these 3
>> properties could be used to derive the other 2.
> 
> The heap-id<->heap-type mapping isn't necessarily 1:1.  As Laura
> indicated elsewhere on this thread, a given heap might need to be
> contiguous on one platform but not on another.  In that case you just
> swap out the heap-type here and there's no need for userspace to 
> change.
> 
> The heap-name, OTOH, could be derived from the heap-id, which is what 
> we
> hackishly do here [1] and here[2].

By the way, since we agreed that heap id and heap type mappings
are not 1:1 - we have a problem with the current API.

In userspace we currently have this:

int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask,
               unsigned int flags, ion_user_handle_t *handle);

We do not specify here what TYPE of heap we want the allocation to come 
from.
This may lead to very unpleasant stuff when porting from one platfrom to 
another.

But, manual heap id control is VERY neat, since it allows to cover a lot 
of
platform-specific cases, where allocating memory from certain heaps can
yield performance boost.

In other words - maybe we should specify both suitable heap types and 
heap ids?

> [1]
> https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n53
> [2]
> https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n398
> 
> 
> -Mitch

-- 
Regards,
Andrew

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Andrew]

On 2015-10-12 21:39, Mitchel Humpherys wrote:
> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com> 
> wrote:
>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott 
>> <labbott@fedoraproject.org> wrote:
> 
> [...]
> 
>>> +Example:
>>> +
>>> +       ion {
>>> +               compatbile = "linux,ion";
>>> +               #address-cells = <1>;
>>> +               #size-cells = <0>;
>>> +
>>> +               ion-system-heap {
>>> +                       linux,ion-heap-id = <0>;
>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>> +                       linux,ion-heap-name = "system";
>> 
>> How does this vary across platforms? Is all of this being pushed down
>> to DT, because there is no coordination of this at the kernel ABI
>> level across platforms. In other words, why can't heap 0 be hardcoded
>> as system heap in the driver. It seems to me any 1 of these 3
>> properties could be used to derive the other 2.
> 
> The heap-id<->heap-type mapping isn't necessarily 1:1.  As Laura
> indicated elsewhere on this thread, a given heap might need to be
> contiguous on one platform but not on another.  In that case you just
> swap out the heap-type here and there's no need for userspace to 
> change.
> 
> The heap-name, OTOH, could be derived from the heap-id, which is what 
> we
> hackishly do here [1] and here[2].

By the way, since we agreed that heap id and heap type mappings
are not 1:1 - we have a problem with the current API.

In userspace we currently have this:

int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask,
               unsigned int flags, ion_user_handle_t *handle);

We do not specify here what TYPE of heap we want the allocation to come 
from.
This may lead to very unpleasant stuff when porting from one platfrom to 
another.

But, manual heap id control is VERY neat, since it allows to cover a lot 
of
platform-specific cases, where allocating memory from certain heaps can
yield performance boost.

In other words - maybe we should specify both suitable heap types and 
heap ids?

> [1]
> https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n53
> [2]
> https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n398
> 
> 
> -Mitch

-- 
Regards,
Andrew

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Andrew]

On 2015-10-12 21:39, Mitchel Humpherys wrote:
> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com> 
> wrote:
>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott 
>> <labbott@fedoraproject.org> wrote:
> 
> [...]
> 
>>> +Example:
>>> +
>>> +       ion {
>>> +               compatbile = "linux,ion";
>>> +               #address-cells = <1>;
>>> +               #size-cells = <0>;
>>> +
>>> +               ion-system-heap {
>>> +                       linux,ion-heap-id = <0>;
>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>> +                       linux,ion-heap-name = "system";
>> 
>> How does this vary across platforms? Is all of this being pushed down
>> to DT, because there is no coordination of this at the kernel ABI
>> level across platforms. In other words, why can't heap 0 be hardcoded
>> as system heap in the driver. It seems to me any 1 of these 3
>> properties could be used to derive the other 2.
> 
> The heap-id<->heap-type mapping isn't necessarily 1:1.  As Laura
> indicated elsewhere on this thread, a given heap might need to be
> contiguous on one platform but not on another.  In that case you just
> swap out the heap-type here and there's no need for userspace to 
> change.
> 
> The heap-name, OTOH, could be derived from the heap-id, which is what 
> we
> hackishly do here [1] and here[2].

By the way, since we agreed that heap id and heap type mappings
are not 1:1 - we have a problem with the current API.

In userspace we currently have this:

int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask,
               unsigned int flags, ion_user_handle_t *handle);

We do not specify here what TYPE of heap we want the allocation to come 
from.
This may lead to very unpleasant stuff when porting from one platfrom to 
another.

But, manual heap id control is VERY neat, since it allows to cover a lot 
of
platform-specific cases, where allocating memory from certain heaps can
yield performance boost.

In other words - maybe we should specify both suitable heap types and 
heap ids?

> [1]
> https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n53
> [2]
> https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n398
> 
> 
> -Mitch

-- 
Regards,
Andrew

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Mitchel Humpherys]

On Tue, Oct 13 2015 at 11:14:23 AM, Andrew <andrew@ncrmnt.org> wrote:
> On 2015-10-12 21:39, Mitchel Humpherys wrote:
>> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com>
>> wrote:
>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org>
>>> wrote:
>>
>> [...]
>>
>>>> +Example:
>>>> +
>>>> +       ion {
>>>> +               compatbile = "linux,ion";
>>>> +               #address-cells = <1>;
>>>> +               #size-cells = <0>;
>>>> +
>>>> +               ion-system-heap {
>>>> +                       linux,ion-heap-id = <0>;
>>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>> +                       linux,ion-heap-name = "system";
>>>
>>> How does this vary across platforms? Is all of this being pushed down
>>> to DT, because there is no coordination of this at the kernel ABI
>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>> as system heap in the driver. It seems to me any 1 of these 3
>>> properties could be used to derive the other 2.
>>
>> The heap-id<->heap-type mapping isn't necessarily 1:1.  As Laura
>> indicated elsewhere on this thread, a given heap might need to be
>> contiguous on one platform but not on another.  In that case you just
>> swap out the heap-type here and there's no need for userspace to change.
>>
>> The heap-name, OTOH, could be derived from the heap-id, which is what we
>> hackishly do here [1] and here[2].
>
> By the way, since we agreed that heap id and heap type mappings
> are not 1:1 - we have a problem with the current API.
>
> In userspace we currently have this:
>
> int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask,
>               unsigned int flags, ion_user_handle_t *handle);
>
> We do not specify here what TYPE of heap we want the allocation to come
> from.
> This may lead to very unpleasant stuff when porting from one platfrom to
> another.

What "unpleasant stuff" are you referring to, exactly?  Abstracting the
heap type away from userspace has actually made our lives easier since
userspace doesn't need to know anything about the properties of the
underlying platform.  It just asks for a buffer from the "camera" heap,
for example.  On some platforms that's contiguous, on others it's not.


-Mitch

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Mitchel Humpherys]

On Tue, Oct 13 2015 at 11:14:23 AM, Andrew <andrew@ncrmnt.org> wrote:
> On 2015-10-12 21:39, Mitchel Humpherys wrote:
>> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com>
>> wrote:
>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org>
>>> wrote:
>>
>> [...]
>>
>>>> +Example:
>>>> +
>>>> +       ion {
>>>> +               compatbile = "linux,ion";
>>>> +               #address-cells = <1>;
>>>> +               #size-cells = <0>;
>>>> +
>>>> +               ion-system-heap {
>>>> +                       linux,ion-heap-id = <0>;
>>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>> +                       linux,ion-heap-name = "system";
>>>
>>> How does this vary across platforms? Is all of this being pushed down
>>> to DT, because there is no coordination of this at the kernel ABI
>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>> as system heap in the driver. It seems to me any 1 of these 3
>>> properties could be used to derive the other 2.
>>
>> The heap-id<->heap-type mapping isn't necessarily 1:1.  As Laura
>> indicated elsewhere on this thread, a given heap might need to be
>> contiguous on one platform but not on another.  In that case you just
>> swap out the heap-type here and there's no need for userspace to change.
>>
>> The heap-name, OTOH, could be derived from the heap-id, which is what we
>> hackishly do here [1] and here[2].
>
> By the way, since we agreed that heap id and heap type mappings
> are not 1:1 - we have a problem with the current API.
>
> In userspace we currently have this:
>
> int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask,
>               unsigned int flags, ion_user_handle_t *handle);
>
> We do not specify here what TYPE of heap we want the allocation to come
> from.
> This may lead to very unpleasant stuff when porting from one platfrom to
> another.

What "unpleasant stuff" are you referring to, exactly?  Abstracting the
heap type away from userspace has actually made our lives easier since
userspace doesn't need to know anything about the properties of the
underlying platform.  It just asks for a buffer from the "camera" heap,
for example.  On some platforms that's contiguous, on others it's not.


-Mitch

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Mitchel Humpherys]

On Tue, Oct 13 2015 at 11:14:23 AM, Andrew <andrew@ncrmnt.org> wrote:
> On 2015-10-12 21:39, Mitchel Humpherys wrote:
>> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com>
>> wrote:
>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org>
>>> wrote:
>>
>> [...]
>>
>>>> +Example:
>>>> +
>>>> +       ion {
>>>> +               compatbile = "linux,ion";
>>>> +               #address-cells = <1>;
>>>> +               #size-cells = <0>;
>>>> +
>>>> +               ion-system-heap {
>>>> +                       linux,ion-heap-id = <0>;
>>>> +                       linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>> +                       linux,ion-heap-name = "system";
>>>
>>> How does this vary across platforms? Is all of this being pushed down
>>> to DT, because there is no coordination of this at the kernel ABI
>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>> as system heap in the driver. It seems to me any 1 of these 3
>>> properties could be used to derive the other 2.
>>
>> The heap-id<->heap-type mapping isn't necessarily 1:1.  As Laura
>> indicated elsewhere on this thread, a given heap might need to be
>> contiguous on one platform but not on another.  In that case you just
>> swap out the heap-type here and there's no need for userspace to change.
>>
>> The heap-name, OTOH, could be derived from the heap-id, which is what we
>> hackishly do here [1] and here[2].
>
> By the way, since we agreed that heap id and heap type mappings
> are not 1:1 - we have a problem with the current API.
>
> In userspace we currently have this:
>
> int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask,
>               unsigned int flags, ion_user_handle_t *handle);
>
> We do not specify here what TYPE of heap we want the allocation to come
> from.
> This may lead to very unpleasant stuff when porting from one platfrom to
> another.

What "unpleasant stuff" are you referring to, exactly?  Abstracting the
heap type away from userspace has actually made our lives easier since
userspace doesn't need to know anything about the properties of the
underlying platform.  It just asks for a buffer from the "camera" heap,
for example.  On some platforms that's contiguous, on others it's not.


-Mitch

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[andrew]

20 октября 2015 г., 19:34, "Mitchel Humpherys" <mitchelh@codeaurora.org> написал:
> On Tue, Oct 13 2015 at 11:14:23 AM, Andrew <andrew@ncrmnt.org> wrote:
> 
>> On 2015-10-12 21:39, Mitchel Humpherys wrote:
>>> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com>
>>> wrote:
>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org>
>>>> wrote:
>>> 
>>> [...]
>>> 
>>>>> +Example:
>>>>> +
>>>>> + ion {
>>>>> + compatbile = "linux,ion";
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <0>;
>>>>> +
>>>>> + ion-system-heap {
>>>>> + linux,ion-heap-id = <0>;
>>>>> + linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>>> + linux,ion-heap-name = "system";
>>>> 
>>>> How does this vary across platforms? Is all of this being pushed down
>>>> to DT, because there is no coordination of this at the kernel ABI
>>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>>> as system heap in the driver. It seems to me any 1 of these 3
>>>> properties could be used to derive the other 2.
>>> 
>>> The heap-id<->heap-type mapping isn't necessarily 1:1. As Laura
>>> indicated elsewhere on this thread, a given heap might need to be
>>> contiguous on one platform but not on another. In that case you just
>>> swap out the heap-type here and there's no need for userspace to change.
>>> 
>>> The heap-name, OTOH, could be derived from the heap-id, which is what we
>>> hackishly do here [1] and here[2].
>> 
>> By the way, since we agreed that heap id and heap type mappings
>> are not 1:1 - we have a problem with the current API.
>> 
>> In userspace we currently have this:
>> 
>> int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask,
>> unsigned int flags, ion_user_handle_t *handle);
>> 
>> We do not specify here what TYPE of heap we want the allocation to come
>> from.
>> This may lead to very unpleasant stuff when porting from one platfrom to
>> another.

Okay, I may be totally missing some point here then.

> What "unpleasant stuff" are you referring to, exactly? 

It's not really clear for me how (and at where - kernel or userspace) 
we should properly sort out cases when the next device the pipeline 
introduces some constraints on the buffer it can use. 

For instance: camera can save data into a non-contiguous buffer, but the 
image processing hardware (that may or may not be involved) expects the 
buffer to be contiguous.

> Abstracting the
> heap type away from userspace has actually made our lives easier since
> userspace doesn't need to know anything about the properties of the
> underlying platform. It just asks for a buffer from the "camera" heap,
> for example. On some platforms that's contiguous, on others it's not.
> 
> -Mitch
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project

Regards, 
Andrew

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[andrew]

20 октября 2015 г., 19:34, "Mitchel Humpherys" <mitchelh@codeaurora.org> написал:
> On Tue, Oct 13 2015 at 11:14:23 AM, Andrew <andrew@ncrmnt.org> wrote:
> 
>> On 2015-10-12 21:39, Mitchel Humpherys wrote:
>>> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com>
>>> wrote:
>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org>
>>>> wrote:
>>> 
>>> [...]
>>> 
>>>>> +Example:
>>>>> +
>>>>> + ion {
>>>>> + compatbile = "linux,ion";
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <0>;
>>>>> +
>>>>> + ion-system-heap {
>>>>> + linux,ion-heap-id = <0>;
>>>>> + linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>>> + linux,ion-heap-name = "system";
>>>> 
>>>> How does this vary across platforms? Is all of this being pushed down
>>>> to DT, because there is no coordination of this at the kernel ABI
>>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>>> as system heap in the driver. It seems to me any 1 of these 3
>>>> properties could be used to derive the other 2.
>>> 
>>> The heap-id<->heap-type mapping isn't necessarily 1:1. As Laura
>>> indicated elsewhere on this thread, a given heap might need to be
>>> contiguous on one platform but not on another. In that case you just
>>> swap out the heap-type here and there's no need for userspace to change.
>>> 
>>> The heap-name, OTOH, could be derived from the heap-id, which is what we
>>> hackishly do here [1] and here[2].
>> 
>> By the way, since we agreed that heap id and heap type mappings
>> are not 1:1 - we have a problem with the current API.
>> 
>> In userspace we currently have this:
>> 
>> int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask,
>> unsigned int flags, ion_user_handle_t *handle);
>> 
>> We do not specify here what TYPE of heap we want the allocation to come
>> from.
>> This may lead to very unpleasant stuff when porting from one platfrom to
>> another.

Okay, I may be totally missing some point here then.

> What "unpleasant stuff" are you referring to, exactly? 

It's not really clear for me how (and at where - kernel or userspace) 
we should properly sort out cases when the next device the pipeline 
introduces some constraints on the buffer it can use. 

For instance: camera can save data into a non-contiguous buffer, but the 
image processing hardware (that may or may not be involved) expects the 
buffer to be contiguous.

> Abstracting the
> heap type away from userspace has actually made our lives easier since
> userspace doesn't need to know anything about the properties of the
> underlying platform. It just asks for a buffer from the "camera" heap,
> for example. On some platforms that's contiguous, on others it's not.
> 
> -Mitch
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project

Regards, 
Andrew
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[andrew at ncrmnt.org]

20 ??????? 2015 ?., 19:34, "Mitchel Humpherys" <mitchelh@codeaurora.org> ???????:
> On Tue, Oct 13 2015 at 11:14:23 AM, Andrew <andrew@ncrmnt.org> wrote:
> 
>> On 2015-10-12 21:39, Mitchel Humpherys wrote:
>>> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com>
>>> wrote:
>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org>
>>>> wrote:
>>> 
>>> [...]
>>> 
>>>>> +Example:
>>>>> +
>>>>> + ion {
>>>>> + compatbile = "linux,ion";
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <0>;
>>>>> +
>>>>> + ion-system-heap {
>>>>> + linux,ion-heap-id = <0>;
>>>>> + linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>>> + linux,ion-heap-name = "system";
>>>> 
>>>> How does this vary across platforms? Is all of this being pushed down
>>>> to DT, because there is no coordination of this at the kernel ABI
>>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>>> as system heap in the driver. It seems to me any 1 of these 3
>>>> properties could be used to derive the other 2.
>>> 
>>> The heap-id<->heap-type mapping isn't necessarily 1:1. As Laura
>>> indicated elsewhere on this thread, a given heap might need to be
>>> contiguous on one platform but not on another. In that case you just
>>> swap out the heap-type here and there's no need for userspace to change.
>>> 
>>> The heap-name, OTOH, could be derived from the heap-id, which is what we
>>> hackishly do here [1] and here[2].
>> 
>> By the way, since we agreed that heap id and heap type mappings
>> are not 1:1 - we have a problem with the current API.
>> 
>> In userspace we currently have this:
>> 
>> int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask,
>> unsigned int flags, ion_user_handle_t *handle);
>> 
>> We do not specify here what TYPE of heap we want the allocation to come
>> from.
>> This may lead to very unpleasant stuff when porting from one platfrom to
>> another.

Okay, I may be totally missing some point here then.

> What "unpleasant stuff" are you referring to, exactly? 

It's not really clear for me how (and at where - kernel or userspace) 
we should properly sort out cases when the next device the pipeline 
introduces some constraints on the buffer it can use. 

For instance: camera can save data into a non-contiguous buffer, but the 
image processing hardware (that may or may not be involved) expects the 
buffer to be contiguous.

> Abstracting the
> heap type away from userspace has actually made our lives easier since
> userspace doesn't need to know anything about the properties of the
> underlying platform. It just asks for a buffer from the "camera" heap,
> for example. On some platforms that's contiguous, on others it's not.
> 
> -Mitch
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project

Regards, 
Andrew

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

On 10/22/15 3:36 AM, andrew@ncrmnt.org wrote:
> 20 октября 2015 г., 19:34, "Mitchel Humpherys" <mitchelh@codeaurora.org> написал:
>> On Tue, Oct 13 2015 at 11:14:23 AM, Andrew <andrew@ncrmnt.org> wrote:
>>
>>> On 2015-10-12 21:39, Mitchel Humpherys wrote:
>>>> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com>
>>>> wrote:
>>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org>
>>>>> wrote:
>>>>
>>>> [...]
>>>>
>>>>>> +Example:
>>>>>> +
>>>>>> + ion {
>>>>>> + compatbile = "linux,ion";
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> +
>>>>>> + ion-system-heap {
>>>>>> + linux,ion-heap-id = <0>;
>>>>>> + linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>>>> + linux,ion-heap-name = "system";
>>>>>
>>>>> How does this vary across platforms? Is all of this being pushed down
>>>>> to DT, because there is no coordination of this at the kernel ABI
>>>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>>>> as system heap in the driver. It seems to me any 1 of these 3
>>>>> properties could be used to derive the other 2.
>>>>
>>>> The heap-id<->heap-type mapping isn't necessarily 1:1. As Laura
>>>> indicated elsewhere on this thread, a given heap might need to be
>>>> contiguous on one platform but not on another. In that case you just
>>>> swap out the heap-type here and there's no need for userspace to change.
>>>>
>>>> The heap-name, OTOH, could be derived from the heap-id, which is what we
>>>> hackishly do here [1] and here[2].
>>>
>>> By the way, since we agreed that heap id and heap type mappings
>>> are not 1:1 - we have a problem with the current API.
>>>
>>> In userspace we currently have this:
>>>
>>> int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask,
>>> unsigned int flags, ion_user_handle_t *handle);
>>>
>>> We do not specify here what TYPE of heap we want the allocation to come
>>> from.
>>> This may lead to very unpleasant stuff when porting from one platfrom to
>>> another.
>
> Okay, I may be totally missing some point here then.
>
>> What "unpleasant stuff" are you referring to, exactly?
>
> It's not really clear for me how (and at where - kernel or userspace)
> we should properly sort out cases when the next device the pipeline
> introduces some constraints on the buffer it can use.
>
> For instance: camera can save data into a non-contiguous buffer, but the
> image processing hardware (that may or may not be involved) expects the
> buffer to be contiguous.
>

You've just hit on one of the open problems. There isn't a good answer
right now for how that is supposed to work. Sumit was working on
cenalloc as an answer to some of that. I think we've decided that
may become more of a long term theoretical problem to solve rather
than a pressing practical problem. These days IOMMUs and the like are
much more common across the entire system so it's becoming rarer to
have a case where some hardware can have discontiguous buffers but
some cannot. This isn't to say it's not a problem that needs to be
solved, but we're focusing on other efforts of Ion right now.

In general though we're working off the assumption that the
kernel knows the constraints and if userspace is requesting memory from
a particular heap the kernel will allocate the correct memory. This
means that it's up to the kernel to set up the heaps correctly for
a particular platform (once again, an open problem).

Thanks,
Laura

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

On 10/22/15 3:36 AM, andrew@ncrmnt.org wrote:
> 20 октября 2015 г., 19:34, "Mitchel Humpherys" <mitchelh@codeaurora.org> написал:
>> On Tue, Oct 13 2015 at 11:14:23 AM, Andrew <andrew@ncrmnt.org> wrote:
>>
>>> On 2015-10-12 21:39, Mitchel Humpherys wrote:
>>>> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com>
>>>> wrote:
>>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org>
>>>>> wrote:
>>>>
>>>> [...]
>>>>
>>>>>> +Example:
>>>>>> +
>>>>>> + ion {
>>>>>> + compatbile = "linux,ion";
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> +
>>>>>> + ion-system-heap {
>>>>>> + linux,ion-heap-id = <0>;
>>>>>> + linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>>>> + linux,ion-heap-name = "system";
>>>>>
>>>>> How does this vary across platforms? Is all of this being pushed down
>>>>> to DT, because there is no coordination of this at the kernel ABI
>>>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>>>> as system heap in the driver. It seems to me any 1 of these 3
>>>>> properties could be used to derive the other 2.
>>>>
>>>> The heap-id<->heap-type mapping isn't necessarily 1:1. As Laura
>>>> indicated elsewhere on this thread, a given heap might need to be
>>>> contiguous on one platform but not on another. In that case you just
>>>> swap out the heap-type here and there's no need for userspace to change.
>>>>
>>>> The heap-name, OTOH, could be derived from the heap-id, which is what we
>>>> hackishly do here [1] and here[2].
>>>
>>> By the way, since we agreed that heap id and heap type mappings
>>> are not 1:1 - we have a problem with the current API.
>>>
>>> In userspace we currently have this:
>>>
>>> int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask,
>>> unsigned int flags, ion_user_handle_t *handle);
>>>
>>> We do not specify here what TYPE of heap we want the allocation to come
>>> from.
>>> This may lead to very unpleasant stuff when porting from one platfrom to
>>> another.
>
> Okay, I may be totally missing some point here then.
>
>> What "unpleasant stuff" are you referring to, exactly?
>
> It's not really clear for me how (and at where - kernel or userspace)
> we should properly sort out cases when the next device the pipeline
> introduces some constraints on the buffer it can use.
>
> For instance: camera can save data into a non-contiguous buffer, but the
> image processing hardware (that may or may not be involved) expects the
> buffer to be contiguous.
>

You've just hit on one of the open problems. There isn't a good answer
right now for how that is supposed to work. Sumit was working on
cenalloc as an answer to some of that. I think we've decided that
may become more of a long term theoretical problem to solve rather
than a pressing practical problem. These days IOMMUs and the like are
much more common across the entire system so it's becoming rarer to
have a case where some hardware can have discontiguous buffers but
some cannot. This isn't to say it's not a problem that needs to be
solved, but we're focusing on other efforts of Ion right now.

In general though we're working off the assumption that the
kernel knows the constraints and if userspace is requesting memory from
a particular heap the kernel will allocate the correct memory. This
means that it's up to the kernel to set up the heaps correctly for
a particular platform (once again, an open problem).

Thanks,
Laura


_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

On 10/22/15 3:36 AM, andrew at ncrmnt.org wrote:
> 20 ??????? 2015 ?., 19:34, "Mitchel Humpherys" <mitchelh@codeaurora.org> ???????:
>> On Tue, Oct 13 2015 at 11:14:23 AM, Andrew <andrew@ncrmnt.org> wrote:
>>
>>> On 2015-10-12 21:39, Mitchel Humpherys wrote:
>>>> On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring <robherring2@gmail.com>
>>>> wrote:
>>>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labbott@fedoraproject.org>
>>>>> wrote:
>>>>
>>>> [...]
>>>>
>>>>>> +Example:
>>>>>> +
>>>>>> + ion {
>>>>>> + compatbile = "linux,ion";
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> +
>>>>>> + ion-system-heap {
>>>>>> + linux,ion-heap-id = <0>;
>>>>>> + linux,ion-heap-type = <ION_SYSTEM_HEAP_TYPE>;
>>>>>> + linux,ion-heap-name = "system";
>>>>>
>>>>> How does this vary across platforms? Is all of this being pushed down
>>>>> to DT, because there is no coordination of this at the kernel ABI
>>>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>>>> as system heap in the driver. It seems to me any 1 of these 3
>>>>> properties could be used to derive the other 2.
>>>>
>>>> The heap-id<->heap-type mapping isn't necessarily 1:1. As Laura
>>>> indicated elsewhere on this thread, a given heap might need to be
>>>> contiguous on one platform but not on another. In that case you just
>>>> swap out the heap-type here and there's no need for userspace to change.
>>>>
>>>> The heap-name, OTOH, could be derived from the heap-id, which is what we
>>>> hackishly do here [1] and here[2].
>>>
>>> By the way, since we agreed that heap id and heap type mappings
>>> are not 1:1 - we have a problem with the current API.
>>>
>>> In userspace we currently have this:
>>>
>>> int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask,
>>> unsigned int flags, ion_user_handle_t *handle);
>>>
>>> We do not specify here what TYPE of heap we want the allocation to come
>>> from.
>>> This may lead to very unpleasant stuff when porting from one platfrom to
>>> another.
>
> Okay, I may be totally missing some point here then.
>
>> What "unpleasant stuff" are you referring to, exactly?
>
> It's not really clear for me how (and at where - kernel or userspace)
> we should properly sort out cases when the next device the pipeline
> introduces some constraints on the buffer it can use.
>
> For instance: camera can save data into a non-contiguous buffer, but the
> image processing hardware (that may or may not be involved) expects the
> buffer to be contiguous.
>

You've just hit on one of the open problems. There isn't a good answer
right now for how that is supposed to work. Sumit was working on
cenalloc as an answer to some of that. I think we've decided that
may become more of a long term theoretical problem to solve rather
than a pressing practical problem. These days IOMMUs and the like are
much more common across the entire system so it's becoming rarer to
have a case where some hardware can have discontiguous buffers but
some cannot. This isn't to say it's not a problem that needs to be
solved, but we're focusing on other efforts of Ion right now.

In general though we're working off the assumption that the
kernel knows the constraints and if userspace is requesting memory from
a particular heap the kernel will allocate the correct memory. This
means that it's up to the kernel to set up the heaps correctly for
a particular platform (once again, an open problem).

Thanks,
Laura