[PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Maxime Ripard]

Hi,

We've had for quite some time to hack around in our drivers to take into
account the fact that our DMA accesses are not done through the parent
node, but through another bus with a different mapping than the CPU for the
RAM (0 instead of 0x40000000 for most SoCs).

After some discussion after the submission of a camera device suffering of
the same hacks, I've decided to put together a serie that introduce a
special interconnect name called "dma" that that allows to express the DMA
relationship between a master and its bus, even if they are not direct
parents in the DT.

Let me know what you think,
Maxime

Changes from v4:
  - Fixed the commit logs that had some leftovers from earlier versions
  - Removed spurious whitespaces
  - Added tags
  - Rebased on next

Changes from v3:
  - Rebased on top of current next
  - Use a function pointer instead of the parent device node to fix the
    recursive cases
  - Fix the usage of the device_node index in __of_get_dma_parent
  - Refer to the DT Specification for dma-ranges in the MBUS binding
  - Used dma-mem as the property instead of dma

Changes from v2:
  - Rewrite commit logs still mentionning dma-parent
  - Removed dma-parent-cells left over in the binding example
  - Removed dma-parent still being mentionned in comments

Changes from v1:
  - Change to use the now merged interconnect bindings
  - Move the DMA parent retrieval logic to its own function
  - Rebase on top of 5.0

Maxime Ripard (7):
  dt-bindings: interconnect: Add a dma interconnect name
  dt-bindings: bus: Add binding for the Allwinner MBUS controller
  of: address: Retrieve a parent through a callback in __of_translate_address
  of: address: Add support for the parent DMA bus
  drm/sun4i: Rely on dma interconnect for our RAM offset
  clk: sunxi-ng: sun5i: Export the MBUS clock
  ARM: dts: sun5i: Add the MBUS controller

 Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt      | 36 ++++++-
 Documentation/devicetree/bindings/interconnect/interconnect.txt |  4 +-
 arch/arm/boot/dts/sun5i.dtsi                                    | 13 ++-
 drivers/clk/sunxi-ng/ccu-sun5i.h                                |  4 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c                           | 28 +++--
 drivers/of/address.c                                            | 40 +++++--
 include/dt-bindings/clock/sun5i-ccu.h                           |  2 +-
 7 files changed, 109 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt

base-commit: e3ecb83ee707a3b2a4d12e19509ecbda7f793cc2
-- 
git-series 0.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Maxime Ripard]

Hi,

We've had for quite some time to hack around in our drivers to take into
account the fact that our DMA accesses are not done through the parent
node, but through another bus with a different mapping than the CPU for the
RAM (0 instead of 0x40000000 for most SoCs).

After some discussion after the submission of a camera device suffering of
the same hacks, I've decided to put together a serie that introduce a
special interconnect name called "dma" that that allows to express the DMA
relationship between a master and its bus, even if they are not direct
parents in the DT.

Let me know what you think,
Maxime

Changes from v4:
  - Fixed the commit logs that had some leftovers from earlier versions
  - Removed spurious whitespaces
  - Added tags
  - Rebased on next

Changes from v3:
  - Rebased on top of current next
  - Use a function pointer instead of the parent device node to fix the
    recursive cases
  - Fix the usage of the device_node index in __of_get_dma_parent
  - Refer to the DT Specification for dma-ranges in the MBUS binding
  - Used dma-mem as the property instead of dma

Changes from v2:
  - Rewrite commit logs still mentionning dma-parent
  - Removed dma-parent-cells left over in the binding example
  - Removed dma-parent still being mentionned in comments

Changes from v1:
  - Change to use the now merged interconnect bindings
  - Move the DMA parent retrieval logic to its own function
  - Rebase on top of 5.0

Maxime Ripard (7):
  dt-bindings: interconnect: Add a dma interconnect name
  dt-bindings: bus: Add binding for the Allwinner MBUS controller
  of: address: Retrieve a parent through a callback in __of_translate_address
  of: address: Add support for the parent DMA bus
  drm/sun4i: Rely on dma interconnect for our RAM offset
  clk: sunxi-ng: sun5i: Export the MBUS clock
  ARM: dts: sun5i: Add the MBUS controller

 Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt      | 36 ++++++-
 Documentation/devicetree/bindings/interconnect/interconnect.txt |  4 +-
 arch/arm/boot/dts/sun5i.dtsi                                    | 13 ++-
 drivers/clk/sunxi-ng/ccu-sun5i.h                                |  4 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c                           | 28 +++--
 drivers/of/address.c                                            | 40 +++++--
 include/dt-bindings/clock/sun5i-ccu.h                           |  2 +-
 7 files changed, 109 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt

base-commit: e3ecb83ee707a3b2a4d12e19509ecbda7f793cc2
-- 
git-series 0.9.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v5 1/7] dt-bindings: interconnect: Add a dma interconnect name

[Maxime Ripard]

The current DT bindings assume that the DMA will be performed by the
devices through their parent DT node, and rely on that assumption for the
address translation using dma-ranges.

However, some SoCs have devices that will perform DMA through another bus,
with separate address translation rules. We therefore need to express that
relationship, through the special interconnect name "dma-mem".

Acked-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 Documentation/devicetree/bindings/interconnect/interconnect.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt
index 5a3c575b387a..6f5d23a605b7 100644
--- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -51,6 +51,10 @@ interconnect-names : List of interconnect path name strings sorted in the same
 		     interconnect-names to match interconnect paths with interconnect
 		     specifier pairs.
 
+                     Reserved interconnect names:
+			 * dma-mem: Path from the device to the main memory of
+			            the system
+
 Example:
 
 	sdhci@7864000 {
-- 
git-series 0.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 1/7] dt-bindings: interconnect: Add a dma interconnect name

[Maxime Ripard]

The current DT bindings assume that the DMA will be performed by the
devices through their parent DT node, and rely on that assumption for the
address translation using dma-ranges.

However, some SoCs have devices that will perform DMA through another bus,
with separate address translation rules. We therefore need to express that
relationship, through the special interconnect name "dma-mem".

Acked-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 Documentation/devicetree/bindings/interconnect/interconnect.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt
index 5a3c575b387a..6f5d23a605b7 100644
--- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -51,6 +51,10 @@ interconnect-names : List of interconnect path name strings sorted in the same
 		     interconnect-names to match interconnect paths with interconnect
 		     specifier pairs.
 
+                     Reserved interconnect names:
+			 * dma-mem: Path from the device to the main memory of
+			            the system
+
 Example:
 
 	sdhci@7864000 {
-- 
git-series 0.9.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v5 2/7] dt-bindings: bus: Add binding for the Allwinner MBUS controller

[Maxime Ripard]

The MBUS controller drives the MBUS that other devices in the SoC will
use to perform DMA. It also has a register interface that allows to
monitor and control the bandwidth and priorities for masters on that
bus.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt | 36 +++++++-
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt

diff --git a/Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt b/Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt
new file mode 100644
index 000000000000..1464a4713553
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt
@@ -0,0 +1,36 @@
+Allwinner Memory Bus (MBUS) controller
+
+The MBUS controller drives the MBUS that other devices in the SoC will
+use to perform DMA. It also has a register interface that allows to
+monitor and control the bandwidth and priorities for masters on that
+bus.
+
+Required properties:
+ - compatible: Must be one of:
+	- allwinner,sun5i-a13-mbus
+ - reg: Offset and length of the register set for the controller
+ - clocks: phandle to the clock driving the controller
+ - dma-ranges: See section 2.3.9 of the DeviceTree Specification
+ - #interconnect-cells: Must be one, with the argument being the MBUS
+   port ID
+
+Each device having to perform their DMA through the MBUS must have the
+interconnects and interconnect-names properties set to the MBUS
+controller and with "dma-mem" as the interconnect name.
+
+Example:
+
+mbus: dram-controller@1c01000 {
+	compatible = "allwinner,sun5i-a13-mbus";
+	reg = <0x01c01000 0x1000>;
+	clocks = <&ccu CLK_MBUS>;
+	dma-ranges = <0x00000000 0x40000000 0x20000000>;
+	#interconnect-cells = <1>;
+};
+
+fe0: display-frontend@1e00000 {
+	compatible = "allwinner,sun5i-a13-display-frontend";
+	...
+	interconnects = <&mbus 19>;
+	interconnect-names = "dma-mem";
+};
-- 
git-series 0.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 2/7] dt-bindings: bus: Add binding for the Allwinner MBUS controller

[Maxime Ripard]

The MBUS controller drives the MBUS that other devices in the SoC will
use to perform DMA. It also has a register interface that allows to
monitor and control the bandwidth and priorities for masters on that
bus.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt | 36 +++++++-
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt

diff --git a/Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt b/Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt
new file mode 100644
index 000000000000..1464a4713553
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt
@@ -0,0 +1,36 @@
+Allwinner Memory Bus (MBUS) controller
+
+The MBUS controller drives the MBUS that other devices in the SoC will
+use to perform DMA. It also has a register interface that allows to
+monitor and control the bandwidth and priorities for masters on that
+bus.
+
+Required properties:
+ - compatible: Must be one of:
+	- allwinner,sun5i-a13-mbus
+ - reg: Offset and length of the register set for the controller
+ - clocks: phandle to the clock driving the controller
+ - dma-ranges: See section 2.3.9 of the DeviceTree Specification
+ - #interconnect-cells: Must be one, with the argument being the MBUS
+   port ID
+
+Each device having to perform their DMA through the MBUS must have the
+interconnects and interconnect-names properties set to the MBUS
+controller and with "dma-mem" as the interconnect name.
+
+Example:
+
+mbus: dram-controller@1c01000 {
+	compatible = "allwinner,sun5i-a13-mbus";
+	reg = <0x01c01000 0x1000>;
+	clocks = <&ccu CLK_MBUS>;
+	dma-ranges = <0x00000000 0x40000000 0x20000000>;
+	#interconnect-cells = <1>;
+};
+
+fe0: display-frontend@1e00000 {
+	compatible = "allwinner,sun5i-a13-display-frontend";
+	...
+	interconnects = <&mbus 19>;
+	interconnect-names = "dma-mem";
+};
-- 
git-series 0.9.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v5 3/7] of: address: Retrieve a parent through a callback in __of_translate_address

[Maxime Ripard]

The __of_translate_address function is used to translate the device tree
addresses to physical addresses using the various ranges property to create
the offset.

However, it's shared between the CPU addresses (based on the ranges
property) and the DMA addresses (based on dma-ranges). Since we're going to
add support for a DMA parent node that is not the DT parent node, we need
to change the logic a bit to have a callback function that will retrieve
the parent node we should use.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 drivers/of/address.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 2270373b30ab..5359a80c4e8c 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -569,6 +569,7 @@ static int of_translate_one(struct device_node *parent, struct of_bus *bus,
  * relative to that node.
  */
 static u64 __of_translate_address(struct device_node *dev,
+				  struct device_node *(*get_parent)(const struct device_node *),
 				  const __be32 *in_addr, const char *rprop,
 				  struct device_node **host)
 {
@@ -585,7 +586,7 @@ static u64 __of_translate_address(struct device_node *dev,
 
 	*host = NULL;
 	/* Get parent & match bus type */
-	parent = of_get_parent(dev);
+	parent = get_parent(dev);
 	if (parent == NULL)
 		goto bail;
 	bus = of_match_bus(parent);
@@ -609,7 +610,7 @@ static u64 __of_translate_address(struct device_node *dev,
 		/* Switch to parent bus */
 		of_node_put(dev);
 		dev = parent;
-		parent = of_get_parent(dev);
+		parent = get_parent(dev);
 
 		/* If root, we have finished */
 		if (parent == NULL) {
@@ -665,7 +666,8 @@ u64 of_translate_address(struct device_node *dev, const __be32 *in_addr)
 	struct device_node *host;
 	u64 ret;
 
-	ret = __of_translate_address(dev, in_addr, "ranges", &host);
+	ret = __of_translate_address(dev, of_get_parent,
+				     in_addr, "ranges", &host);
 	if (host) {
 		of_node_put(host);
 		return OF_BAD_ADDR;
@@ -680,7 +682,8 @@ u64 of_translate_dma_address(struct device_node *dev, const __be32 *in_addr)
 	struct device_node *host;
 	u64 ret;
 
-	ret = __of_translate_address(dev, in_addr, "dma-ranges", &host);
+	ret = __of_translate_address(dev, of_get_parent,
+				     in_addr, "dma-ranges", &host);
 
 	if (host) {
 		of_node_put(host);
@@ -736,7 +739,8 @@ static u64 of_translate_ioport(struct device_node *dev, const __be32 *in_addr,
 	unsigned long port;
 	struct device_node *host;
 
-	taddr = __of_translate_address(dev, in_addr, "ranges", &host);
+	taddr = __of_translate_address(dev, of_get_parent,
+				       in_addr, "ranges", &host);
 	if (host) {
 		/* host-specific port access */
 		port = logic_pio_trans_hwaddr(&host->fwnode, taddr, size);
-- 
git-series 0.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 3/7] of: address: Retrieve a parent through a callback in __of_translate_address

[Maxime Ripard]

The __of_translate_address function is used to translate the device tree
addresses to physical addresses using the various ranges property to create
the offset.

However, it's shared between the CPU addresses (based on the ranges
property) and the DMA addresses (based on dma-ranges). Since we're going to
add support for a DMA parent node that is not the DT parent node, we need
to change the logic a bit to have a callback function that will retrieve
the parent node we should use.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 drivers/of/address.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 2270373b30ab..5359a80c4e8c 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -569,6 +569,7 @@ static int of_translate_one(struct device_node *parent, struct of_bus *bus,
  * relative to that node.
  */
 static u64 __of_translate_address(struct device_node *dev,
+				  struct device_node *(*get_parent)(const struct device_node *),
 				  const __be32 *in_addr, const char *rprop,
 				  struct device_node **host)
 {
@@ -585,7 +586,7 @@ static u64 __of_translate_address(struct device_node *dev,
 
 	*host = NULL;
 	/* Get parent & match bus type */
-	parent = of_get_parent(dev);
+	parent = get_parent(dev);
 	if (parent == NULL)
 		goto bail;
 	bus = of_match_bus(parent);
@@ -609,7 +610,7 @@ static u64 __of_translate_address(struct device_node *dev,
 		/* Switch to parent bus */
 		of_node_put(dev);
 		dev = parent;
-		parent = of_get_parent(dev);
+		parent = get_parent(dev);
 
 		/* If root, we have finished */
 		if (parent == NULL) {
@@ -665,7 +666,8 @@ u64 of_translate_address(struct device_node *dev, const __be32 *in_addr)
 	struct device_node *host;
 	u64 ret;
 
-	ret = __of_translate_address(dev, in_addr, "ranges", &host);
+	ret = __of_translate_address(dev, of_get_parent,
+				     in_addr, "ranges", &host);
 	if (host) {
 		of_node_put(host);
 		return OF_BAD_ADDR;
@@ -680,7 +682,8 @@ u64 of_translate_dma_address(struct device_node *dev, const __be32 *in_addr)
 	struct device_node *host;
 	u64 ret;
 
-	ret = __of_translate_address(dev, in_addr, "dma-ranges", &host);
+	ret = __of_translate_address(dev, of_get_parent,
+				     in_addr, "dma-ranges", &host);
 
 	if (host) {
 		of_node_put(host);
@@ -736,7 +739,8 @@ static u64 of_translate_ioport(struct device_node *dev, const __be32 *in_addr,
 	unsigned long port;
 	struct device_node *host;
 
-	taddr = __of_translate_address(dev, in_addr, "ranges", &host);
+	taddr = __of_translate_address(dev, of_get_parent,
+				       in_addr, "ranges", &host);
 	if (host) {
 		/* host-specific port access */
 		port = logic_pio_trans_hwaddr(&host->fwnode, taddr, size);
-- 
git-series 0.9.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v5 4/7] of: address: Add support for the parent DMA bus

[Maxime Ripard]

Some SoCs have devices that are using a separate bus from the main bus to
perform DMA.

These buses might have some restrictions and/or different mapping than from
the CPU side, so we'd need to express those using the usual dma-ranges, but
using a different DT node than the node's parent.

Now that the generic interconnect bindings are available, we can model an
interconnect with the reserved name "dma-mem" for those use-cases.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 drivers/of/address.c | 28 ++++++++++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5359a80c4e8c..978427a9d5e6 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -677,12 +677,30 @@ u64 of_translate_address(struct device_node *dev, const __be32 *in_addr)
 }
 EXPORT_SYMBOL(of_translate_address);
 
+static struct device_node *__of_get_dma_parent(const struct device_node *np)
+{
+	struct of_phandle_args args;
+	int ret, index;
+
+	index = of_property_match_string(np, "interconnect-names", "dma-mem");
+	if (index < 0)
+		return of_get_parent(np);
+
+	ret = of_parse_phandle_with_args(np, "interconnects",
+					 "#interconnect-cells",
+					 index, &args);
+	if (ret < 0)
+		return of_get_parent(np);
+
+	return of_node_get(args.np);
+}
+
 u64 of_translate_dma_address(struct device_node *dev, const __be32 *in_addr)
 {
 	struct device_node *host;
 	u64 ret;
 
-	ret = __of_translate_address(dev, of_get_parent,
+	ret = __of_translate_address(dev, __of_get_dma_parent,
 				     in_addr, "dma-ranges", &host);
 
 	if (host) {
@@ -912,9 +930,15 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
 		return -EINVAL;
 
 	while (1) {
+		struct device_node *parent;
+
 		naddr = of_n_addr_cells(node);
 		nsize = of_n_size_cells(node);
-		node = of_get_next_parent(node);
+
+		parent = __of_get_dma_parent(node);
+		of_node_put(node);
+
+		node = parent;
 		if (!node)
 			break;
 
-- 
git-series 0.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 4/7] of: address: Add support for the parent DMA bus

[Maxime Ripard]

Some SoCs have devices that are using a separate bus from the main bus to
perform DMA.

These buses might have some restrictions and/or different mapping than from
the CPU side, so we'd need to express those using the usual dma-ranges, but
using a different DT node than the node's parent.

Now that the generic interconnect bindings are available, we can model an
interconnect with the reserved name "dma-mem" for those use-cases.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 drivers/of/address.c | 28 ++++++++++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5359a80c4e8c..978427a9d5e6 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -677,12 +677,30 @@ u64 of_translate_address(struct device_node *dev, const __be32 *in_addr)
 }
 EXPORT_SYMBOL(of_translate_address);
 
+static struct device_node *__of_get_dma_parent(const struct device_node *np)
+{
+	struct of_phandle_args args;
+	int ret, index;
+
+	index = of_property_match_string(np, "interconnect-names", "dma-mem");
+	if (index < 0)
+		return of_get_parent(np);
+
+	ret = of_parse_phandle_with_args(np, "interconnects",
+					 "#interconnect-cells",
+					 index, &args);
+	if (ret < 0)
+		return of_get_parent(np);
+
+	return of_node_get(args.np);
+}
+
 u64 of_translate_dma_address(struct device_node *dev, const __be32 *in_addr)
 {
 	struct device_node *host;
 	u64 ret;
 
-	ret = __of_translate_address(dev, of_get_parent,
+	ret = __of_translate_address(dev, __of_get_dma_parent,
 				     in_addr, "dma-ranges", &host);
 
 	if (host) {
@@ -912,9 +930,15 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
 		return -EINVAL;
 
 	while (1) {
+		struct device_node *parent;
+
 		naddr = of_n_addr_cells(node);
 		nsize = of_n_size_cells(node);
-		node = of_get_next_parent(node);
+
+		parent = __of_get_dma_parent(node);
+		of_node_put(node);
+
+		node = parent;
 		if (!node)
 			break;
 
-- 
git-series 0.9.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v5 5/7] drm/sun4i: Rely on dma interconnect for our RAM offset

[Maxime Ripard]

Now that we can express our DMA topology, rely on those property instead of
hardcoding an offset from the dma_addr_t which wasn't really great.

We still need to add some code to deal with the old DT that would lack that
property, but we move the offset to the DRM device dma_pfn_offset to be
able to rely on just the dma_addr_t associated to the GEM object.

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 28 +++++++++++++++++++++-------
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index ee59da4a0172..4e5922c89d7b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -361,13 +361,6 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
 	paddr = drm_fb_cma_get_gem_addr(fb, state, 0);
 	DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
 
-	/*
-	 * backend DMA accesses DRAM directly, bypassing the system
-	 * bus. As such, the address range is different and the buffer
-	 * address needs to be corrected.
-	 */
-	paddr -= PHYS_OFFSET;
-
 	if (fb->format->is_yuv)
 		return sun4i_backend_update_yuv_buffer(backend, fb, paddr);
 
@@ -803,6 +796,27 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
 	dev_set_drvdata(dev, backend);
 	spin_lock_init(&backend->frontend_lock);
 
+	if (of_find_property(dev->of_node, "interconnects", NULL)) {
+		/*
+		 * This assume we have the same DMA constraints for all our the
+		 * devices in our pipeline (all the backends, but also the
+		 * frontends). This sounds bad, but it has always been the case
+		 * for us, and DRM doesn't do per-device allocation either, so
+		 * we would need to fix DRM first...
+		 */
+		ret = of_dma_configure(drm->dev, dev->of_node, true);
+		if (ret)
+			return ret;
+	} else {
+		/*
+		 * If we don't have the interconnect property, most likely
+		 * because of an old DT, we need to set the DMA offset by hand
+		 * on our device since the RAM mapping is at 0 for the DMA bus,
+		 * unlike the CPU.
+		 */
+		drm->dev->dma_pfn_offset = PHYS_PFN_OFFSET;
+	}
+
 	backend->engine.node = dev->of_node;
 	backend->engine.ops = &sun4i_backend_engine_ops;
 	backend->engine.id = sun4i_backend_of_get_id(dev->of_node);
-- 
git-series 0.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 5/7] drm/sun4i: Rely on dma interconnect for our RAM offset

[Maxime Ripard]

Now that we can express our DMA topology, rely on those property instead of
hardcoding an offset from the dma_addr_t which wasn't really great.

We still need to add some code to deal with the old DT that would lack that
property, but we move the offset to the DRM device dma_pfn_offset to be
able to rely on just the dma_addr_t associated to the GEM object.

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 28 +++++++++++++++++++++-------
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index ee59da4a0172..4e5922c89d7b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -361,13 +361,6 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
 	paddr = drm_fb_cma_get_gem_addr(fb, state, 0);
 	DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
 
-	/*
-	 * backend DMA accesses DRAM directly, bypassing the system
-	 * bus. As such, the address range is different and the buffer
-	 * address needs to be corrected.
-	 */
-	paddr -= PHYS_OFFSET;
-
 	if (fb->format->is_yuv)
 		return sun4i_backend_update_yuv_buffer(backend, fb, paddr);
 
@@ -803,6 +796,27 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
 	dev_set_drvdata(dev, backend);
 	spin_lock_init(&backend->frontend_lock);
 
+	if (of_find_property(dev->of_node, "interconnects", NULL)) {
+		/*
+		 * This assume we have the same DMA constraints for all our the
+		 * devices in our pipeline (all the backends, but also the
+		 * frontends). This sounds bad, but it has always been the case
+		 * for us, and DRM doesn't do per-device allocation either, so
+		 * we would need to fix DRM first...
+		 */
+		ret = of_dma_configure(drm->dev, dev->of_node, true);
+		if (ret)
+			return ret;
+	} else {
+		/*
+		 * If we don't have the interconnect property, most likely
+		 * because of an old DT, we need to set the DMA offset by hand
+		 * on our device since the RAM mapping is at 0 for the DMA bus,
+		 * unlike the CPU.
+		 */
+		drm->dev->dma_pfn_offset = PHYS_PFN_OFFSET;
+	}
+
 	backend->engine.node = dev->of_node;
 	backend->engine.ops = &sun4i_backend_engine_ops;
 	backend->engine.id = sun4i_backend_of_get_id(dev->of_node);
-- 
git-series 0.9.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v5 6/7] clk: sunxi-ng: sun5i: Export the MBUS clock

[Maxime Ripard]

The MBUS clock is used by the MBUS controller, so let's export it so that
we can use it in our DT node.

Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 drivers/clk/sunxi-ng/ccu-sun5i.h      | 4 ----
 include/dt-bindings/clock/sun5i-ccu.h | 2 +-
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.h b/drivers/clk/sunxi-ng/ccu-sun5i.h
index 93a275fbd9a9..b66abd4fd0bf 100644
--- a/drivers/clk/sunxi-ng/ccu-sun5i.h
+++ b/drivers/clk/sunxi-ng/ccu-sun5i.h
@@ -60,10 +60,6 @@
 
 /* The rest of the module clocks are exported */
 
-#define CLK_MBUS		99
-
-/* And finally the IEP clock */
-
 #define CLK_NUMBER		(CLK_IEP + 1)
 
 #endif /* _CCU_SUN5I_H_ */
diff --git a/include/dt-bindings/clock/sun5i-ccu.h b/include/dt-bindings/clock/sun5i-ccu.h
index 81f34d477aeb..2e6b9ddcc24e 100644
--- a/include/dt-bindings/clock/sun5i-ccu.h
+++ b/include/dt-bindings/clock/sun5i-ccu.h
@@ -100,7 +100,7 @@
 #define CLK_AVS			96
 #define CLK_HDMI		97
 #define CLK_GPU			98
-
+#define CLK_MBUS		99
 #define CLK_IEP			100
 
 #endif /* _DT_BINDINGS_CLK_SUN5I_H_ */
-- 
git-series 0.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 6/7] clk: sunxi-ng: sun5i: Export the MBUS clock

[Maxime Ripard]

The MBUS clock is used by the MBUS controller, so let's export it so that
we can use it in our DT node.

Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 drivers/clk/sunxi-ng/ccu-sun5i.h      | 4 ----
 include/dt-bindings/clock/sun5i-ccu.h | 2 +-
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.h b/drivers/clk/sunxi-ng/ccu-sun5i.h
index 93a275fbd9a9..b66abd4fd0bf 100644
--- a/drivers/clk/sunxi-ng/ccu-sun5i.h
+++ b/drivers/clk/sunxi-ng/ccu-sun5i.h
@@ -60,10 +60,6 @@
 
 /* The rest of the module clocks are exported */
 
-#define CLK_MBUS		99
-
-/* And finally the IEP clock */
-
 #define CLK_NUMBER		(CLK_IEP + 1)
 
 #endif /* _CCU_SUN5I_H_ */
diff --git a/include/dt-bindings/clock/sun5i-ccu.h b/include/dt-bindings/clock/sun5i-ccu.h
index 81f34d477aeb..2e6b9ddcc24e 100644
--- a/include/dt-bindings/clock/sun5i-ccu.h
+++ b/include/dt-bindings/clock/sun5i-ccu.h
@@ -100,7 +100,7 @@
 #define CLK_AVS			96
 #define CLK_HDMI		97
 #define CLK_GPU			98
-
+#define CLK_MBUS		99
 #define CLK_IEP			100
 
 #endif /* _DT_BINDINGS_CLK_SUN5I_H_ */
-- 
git-series 0.9.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v5 7/7] ARM: dts: sun5i: Add the MBUS controller

[Maxime Ripard]

The MBUS (and its associated controller) is the bus in the Allwinner SoCs
that DMA devices use in the system to access the memory.

Among other things (and depending on the SoC generation), it can also
enforce priorities or report bandwidth usages on a per-master basis.

One of the most notable thing is that instead of having the same mapping
for the RAM than the CPU, it maps it at address 0, which means we'll have
to do address translation thanks to the dma-ranges property.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 arch/arm/boot/dts/sun5i.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index f69ab288678b..fb4e55484b1a 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -127,6 +127,7 @@
 		compatible = "simple-bus";
 		#address-cells = <1>;
 		#size-cells = <1>;
+		dma-ranges;
 		ranges;
 
 		system-control@1c00000 {
@@ -181,6 +182,14 @@
 			};
 		};
 
+		mbus: dram-controller@1c01000 {
+			compatible = "allwinner,sun5i-a13-mbus";
+			reg = <0x01c01000 0x1000>;
+			clocks = <&ccu CLK_MBUS>;
+			dma-ranges = <0x00000000 0x40000000 0x20000000>;
+			#interconnect-cells = <1>;
+		};
+
 		dma: dma-controller@1c02000 {
 			compatible = "allwinner,sun4i-a10-dma";
 			reg = <0x01c02000 0x1000>;
@@ -723,6 +732,8 @@
 			clock-names = "ahb", "mod",
 				      "ram";
 			resets = <&ccu RST_DE_FE>;
+			interconnects = <&mbus 19>;
+			interconnect-names = "dma-mem";
 			status = "disabled";
 
 			ports {
@@ -748,6 +759,8 @@
 			clock-names = "ahb", "mod",
 				      "ram";
 			resets = <&ccu RST_DE_BE>;
+			interconnects = <&mbus 18>;
+			interconnect-names = "dma-mem";
 			status = "disabled";
 
 			assigned-clocks = <&ccu CLK_DE_BE>;
-- 
git-series 0.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 7/7] ARM: dts: sun5i: Add the MBUS controller

[Maxime Ripard]

The MBUS (and its associated controller) is the bus in the Allwinner SoCs
that DMA devices use in the system to access the memory.

Among other things (and depending on the SoC generation), it can also
enforce priorities or report bandwidth usages on a per-master basis.

One of the most notable thing is that instead of having the same mapping
for the RAM than the CPU, it maps it at address 0, which means we'll have
to do address translation thanks to the dma-ranges property.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 arch/arm/boot/dts/sun5i.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index f69ab288678b..fb4e55484b1a 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -127,6 +127,7 @@
 		compatible = "simple-bus";
 		#address-cells = <1>;
 		#size-cells = <1>;
+		dma-ranges;
 		ranges;
 
 		system-control@1c00000 {
@@ -181,6 +182,14 @@
 			};
 		};
 
+		mbus: dram-controller@1c01000 {
+			compatible = "allwinner,sun5i-a13-mbus";
+			reg = <0x01c01000 0x1000>;
+			clocks = <&ccu CLK_MBUS>;
+			dma-ranges = <0x00000000 0x40000000 0x20000000>;
+			#interconnect-cells = <1>;
+		};
+
 		dma: dma-controller@1c02000 {
 			compatible = "allwinner,sun4i-a10-dma";
 			reg = <0x01c02000 0x1000>;
@@ -723,6 +732,8 @@
 			clock-names = "ahb", "mod",
 				      "ram";
 			resets = <&ccu RST_DE_FE>;
+			interconnects = <&mbus 19>;
+			interconnect-names = "dma-mem";
 			status = "disabled";
 
 			ports {
@@ -748,6 +759,8 @@
 			clock-names = "ahb", "mod",
 				      "ram";
 			resets = <&ccu RST_DE_BE>;
+			interconnects = <&mbus 18>;
+			interconnect-names = "dma-mem";
 			status = "disabled";
 
 			assigned-clocks = <&ccu CLK_DE_BE>;
-- 
git-series 0.9.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Rob Herring]

On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> Hi,
> 
> We've had for quite some time to hack around in our drivers to take into
> account the fact that our DMA accesses are not done through the parent
> node, but through another bus with a different mapping than the CPU for the
> RAM (0 instead of 0x40000000 for most SoCs).
> 
> After some discussion after the submission of a camera device suffering of
> the same hacks, I've decided to put together a serie that introduce a
> special interconnect name called "dma" that that allows to express the DMA
> relationship between a master and its bus, even if they are not direct
> parents in the DT.
> 
> Let me know what you think,
> Maxime

LGTM.

How do you propose merging this? I can take 1-5, and 6 and 7 thru 
arm-soc?

Rob

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Rob Herring]

On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> Hi,
> 
> We've had for quite some time to hack around in our drivers to take into
> account the fact that our DMA accesses are not done through the parent
> node, but through another bus with a different mapping than the CPU for the
> RAM (0 instead of 0x40000000 for most SoCs).
> 
> After some discussion after the submission of a camera device suffering of
> the same hacks, I've decided to put together a serie that introduce a
> special interconnect name called "dma" that that allows to express the DMA
> relationship between a master and its bus, even if they are not direct
> parents in the DT.
> 
> Let me know what you think,
> Maxime

LGTM.

How do you propose merging this? I can take 1-5, and 6 and 7 thru 
arm-soc?

Rob


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1070 bytes --]

On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > We've had for quite some time to hack around in our drivers to take into
> > account the fact that our DMA accesses are not done through the parent
> > node, but through another bus with a different mapping than the CPU for the
> > RAM (0 instead of 0x40000000 for most SoCs).
> >
> > After some discussion after the submission of a camera device suffering of
> > the same hacks, I've decided to put together a serie that introduce a
> > special interconnect name called "dma" that that allows to express the DMA
> > relationship between a master and its bus, even if they are not direct
> > parents in the DT.
> >
> > Let me know what you think,
> > Maxime
>
> LGTM.
>
> How do you propose merging this? I can take 1-5, and 6 and 7 thru
> arm-soc?

You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
arm-soc

Thanks!
Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1070 bytes --]

On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > We've had for quite some time to hack around in our drivers to take into
> > account the fact that our DMA accesses are not done through the parent
> > node, but through another bus with a different mapping than the CPU for the
> > RAM (0 instead of 0x40000000 for most SoCs).
> >
> > After some discussion after the submission of a camera device suffering of
> > the same hacks, I've decided to put together a serie that introduce a
> > special interconnect name called "dma" that that allows to express the DMA
> > relationship between a master and its bus, even if they are not direct
> > parents in the DT.
> >
> > Let me know what you think,
> > Maxime
>
> LGTM.
>
> How do you propose merging this? I can take 1-5, and 6 and 7 thru
> arm-soc?

You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
arm-soc

Thanks!
Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Chen-Yu Tsai]

On Mon, Apr 8, 2019 at 4:11 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > Hi,
> > >
> > > We've had for quite some time to hack around in our drivers to take into
> > > account the fact that our DMA accesses are not done through the parent
> > > node, but through another bus with a different mapping than the CPU for the
> > > RAM (0 instead of 0x40000000 for most SoCs).
> > >
> > > After some discussion after the submission of a camera device suffering of
> > > the same hacks, I've decided to put together a serie that introduce a
> > > special interconnect name called "dma" that that allows to express the DMA
> > > relationship between a master and its bus, even if they are not direct
> > > parents in the DT.
> > >
> > > Let me know what you think,
> > > Maxime
> >
> > LGTM.
> >
> > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > arm-soc?
>
> You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> arm-soc

Wouldn't there be some runtime dependency between 3, 4, and 5?

ChenYu
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Chen-Yu Tsai]

On Mon, Apr 8, 2019 at 4:11 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > Hi,
> > >
> > > We've had for quite some time to hack around in our drivers to take into
> > > account the fact that our DMA accesses are not done through the parent
> > > node, but through another bus with a different mapping than the CPU for the
> > > RAM (0 instead of 0x40000000 for most SoCs).
> > >
> > > After some discussion after the submission of a camera device suffering of
> > > the same hacks, I've decided to put together a serie that introduce a
> > > special interconnect name called "dma" that that allows to express the DMA
> > > relationship between a master and its bus, even if they are not direct
> > > parents in the DT.
> > >
> > > Let me know what you think,
> > > Maxime
> >
> > LGTM.
> >
> > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > arm-soc?
>
> You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> arm-soc

Wouldn't there be some runtime dependency between 3, 4, and 5?

ChenYu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1619 bytes --]

On Mon, Apr 08, 2019 at 04:14:53PM +0800, Chen-Yu Tsai wrote:
> On Mon, Apr 8, 2019 at 4:11 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > We've had for quite some time to hack around in our drivers to take into
> > > > account the fact that our DMA accesses are not done through the parent
> > > > node, but through another bus with a different mapping than the CPU for the
> > > > RAM (0 instead of 0x40000000 for most SoCs).
> > > >
> > > > After some discussion after the submission of a camera device suffering of
> > > > the same hacks, I've decided to put together a serie that introduce a
> > > > special interconnect name called "dma" that that allows to express the DMA
> > > > relationship between a master and its bus, even if they are not direct
> > > > parents in the DT.
> > > >
> > > > Let me know what you think,
> > > > Maxime
> > >
> > > LGTM.
> > >
> > > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > > arm-soc?
> >
> > You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> > arm-soc
>
> Wouldn't there be some runtime dependency between 3, 4, and 5?

What issue did you have in mind?

I guess the only issue would be if we have the new DT properties, but
not the new core code. But that seems pretty unlikely, since each of
the trees will work independently, and next should have all of them.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1619 bytes --]

On Mon, Apr 08, 2019 at 04:14:53PM +0800, Chen-Yu Tsai wrote:
> On Mon, Apr 8, 2019 at 4:11 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > We've had for quite some time to hack around in our drivers to take into
> > > > account the fact that our DMA accesses are not done through the parent
> > > > node, but through another bus with a different mapping than the CPU for the
> > > > RAM (0 instead of 0x40000000 for most SoCs).
> > > >
> > > > After some discussion after the submission of a camera device suffering of
> > > > the same hacks, I've decided to put together a serie that introduce a
> > > > special interconnect name called "dma" that that allows to express the DMA
> > > > relationship between a master and its bus, even if they are not direct
> > > > parents in the DT.
> > > >
> > > > Let me know what you think,
> > > > Maxime
> > >
> > > LGTM.
> > >
> > > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > > arm-soc?
> >
> > You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> > arm-soc
>
> Wouldn't there be some runtime dependency between 3, 4, and 5?

What issue did you have in mind?

I guess the only issue would be if we have the new DT properties, but
not the new core code. But that seems pretty unlikely, since each of
the trees will work independently, and next should have all of them.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Chen-Yu Tsai]

On Mon, Apr 8, 2019 at 4:21 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Mon, Apr 08, 2019 at 04:14:53PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Apr 8, 2019 at 4:11 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > > > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > > > Hi,
> > > > >
> > > > > We've had for quite some time to hack around in our drivers to take into
> > > > > account the fact that our DMA accesses are not done through the parent
> > > > > node, but through another bus with a different mapping than the CPU for the
> > > > > RAM (0 instead of 0x40000000 for most SoCs).
> > > > >
> > > > > After some discussion after the submission of a camera device suffering of
> > > > > the same hacks, I've decided to put together a serie that introduce a
> > > > > special interconnect name called "dma" that that allows to express the DMA
> > > > > relationship between a master and its bus, even if they are not direct
> > > > > parents in the DT.
> > > > >
> > > > > Let me know what you think,
> > > > > Maxime
> > > >
> > > > LGTM.
> > > >
> > > > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > > > arm-soc?
> > >
> > > You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> > > arm-soc
> >
> > Wouldn't there be some runtime dependency between 3, 4, and 5?
>
> What issue did you have in mind?
>
> I guess the only issue would be if we have the new DT properties, but
> not the new core code. But that seems pretty unlikely, since each of
> the trees will work independently, and next should have all of them.

I got it wrong. Even in your case since the interconnect property is
ignored, and the driver would just fall back to using the fixed offset.

Sorry for the noise.

ChenYu
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Chen-Yu Tsai]

On Mon, Apr 8, 2019 at 4:21 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Mon, Apr 08, 2019 at 04:14:53PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Apr 8, 2019 at 4:11 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > > > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > > > Hi,
> > > > >
> > > > > We've had for quite some time to hack around in our drivers to take into
> > > > > account the fact that our DMA accesses are not done through the parent
> > > > > node, but through another bus with a different mapping than the CPU for the
> > > > > RAM (0 instead of 0x40000000 for most SoCs).
> > > > >
> > > > > After some discussion after the submission of a camera device suffering of
> > > > > the same hacks, I've decided to put together a serie that introduce a
> > > > > special interconnect name called "dma" that that allows to express the DMA
> > > > > relationship between a master and its bus, even if they are not direct
> > > > > parents in the DT.
> > > > >
> > > > > Let me know what you think,
> > > > > Maxime
> > > >
> > > > LGTM.
> > > >
> > > > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > > > arm-soc?
> > >
> > > You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> > > arm-soc
> >
> > Wouldn't there be some runtime dependency between 3, 4, and 5?
>
> What issue did you have in mind?
>
> I guess the only issue would be if we have the new DT properties, but
> not the new core code. But that seems pretty unlikely, since each of
> the trees will work independently, and next should have all of them.

I got it wrong. Even in your case since the interconnect property is
ignored, and the driver would just fall back to using the fixed offset.

Sorry for the noise.

ChenYu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Rob Herring]

On Mon, Apr 08, 2019 at 10:11:26AM +0200, Maxime Ripard wrote:
> On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > Hi,
> > >
> > > We've had for quite some time to hack around in our drivers to take into
> > > account the fact that our DMA accesses are not done through the parent
> > > node, but through another bus with a different mapping than the CPU for the
> > > RAM (0 instead of 0x40000000 for most SoCs).
> > >
> > > After some discussion after the submission of a camera device suffering of
> > > the same hacks, I've decided to put together a serie that introduce a
> > > special interconnect name called "dma" that that allows to express the DMA
> > > relationship between a master and its bus, even if they are not direct
> > > parents in the DT.
> > >
> > > Let me know what you think,
> > > Maxime
> >
> > LGTM.
> >
> > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > arm-soc?
> 
> You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> arm-soc

Done.

Rob

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Rob Herring]

On Mon, Apr 08, 2019 at 10:11:26AM +0200, Maxime Ripard wrote:
> On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > Hi,
> > >
> > > We've had for quite some time to hack around in our drivers to take into
> > > account the fact that our DMA accesses are not done through the parent
> > > node, but through another bus with a different mapping than the CPU for the
> > > RAM (0 instead of 0x40000000 for most SoCs).
> > >
> > > After some discussion after the submission of a camera device suffering of
> > > the same hacks, I've decided to put together a serie that introduce a
> > > special interconnect name called "dma" that that allows to express the DMA
> > > relationship between a master and its bus, even if they are not direct
> > > parents in the DT.
> > >
> > > Let me know what you think,
> > > Maxime
> >
> > LGTM.
> >
> > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > arm-soc?
> 
> You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> arm-soc

Done.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1326 bytes --]

On Wed, Apr 10, 2019 at 09:01:28AM -0500, Rob Herring wrote:
> On Mon, Apr 08, 2019 at 10:11:26AM +0200, Maxime Ripard wrote:
> > On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > We've had for quite some time to hack around in our drivers to take into
> > > > account the fact that our DMA accesses are not done through the parent
> > > > node, but through another bus with a different mapping than the CPU for the
> > > > RAM (0 instead of 0x40000000 for most SoCs).
> > > >
> > > > After some discussion after the submission of a camera device suffering of
> > > > the same hacks, I've decided to put together a serie that introduce a
> > > > special interconnect name called "dma" that that allows to express the DMA
> > > > relationship between a master and its bus, even if they are not direct
> > > > parents in the DT.
> > > >
> > > > Let me know what you think,
> > > > Maxime
> > >
> > > LGTM.
> > >
> > > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > > arm-soc?
> >
> > You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> > arm-soc
>
> Done.

Thanks!

Applied 5, 6 and 7

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1326 bytes --]

On Wed, Apr 10, 2019 at 09:01:28AM -0500, Rob Herring wrote:
> On Mon, Apr 08, 2019 at 10:11:26AM +0200, Maxime Ripard wrote:
> > On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > We've had for quite some time to hack around in our drivers to take into
> > > > account the fact that our DMA accesses are not done through the parent
> > > > node, but through another bus with a different mapping than the CPU for the
> > > > RAM (0 instead of 0x40000000 for most SoCs).
> > > >
> > > > After some discussion after the submission of a camera device suffering of
> > > > the same hacks, I've decided to put together a serie that introduce a
> > > > special interconnect name called "dma" that that allows to express the DMA
> > > > relationship between a master and its bus, even if they are not direct
> > > > parents in the DT.
> > > >
> > > > Let me know what you think,
> > > > Maxime
> > >
> > > LGTM.
> > >
> > > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > > arm-soc?
> >
> > You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> > arm-soc
>
> Done.

Thanks!

Applied 5, 6 and 7

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel