[PATCH v8 0/9] RZN1 DMA support

[PATCH v8 0/9] RZN1 DMA support

[Miquel Raynal]

Hello,

Here is a first series bringing DMA support to RZN1 platforms. Soon a
second series will come with changes made to the UART controller
driver, in order to interact with the RZN1 DMA controller.

Stephen acked the sysctrl patch (in the clk driver) but somehow I feel
like it would be good to have this patch applied on both sides
(dmaengine and clk) because more changes will depend on the addition of
this helper, that are not related to DMA at all. I'll let you folks
figure out what is best.

Cheers,
Miquèl

Changes in v8:
* Collected more tags.
* Moved the Makefile line adding the dmamux driver to the bottom of the
  file.
* Reversed the logic in a ternary operation as suggested by Andy.
* Changed a bit the naming of a #define as suggested by Andy.

Changes in v7:
* This time, really added Stephen's Acks (sorry for the error).
* Moved an error check to get rid of one mutex_unlock/lock call as
  suggested by Ilpo.
* Split the patch adding the dmamux driver as advised by Vinod. One
  patch introduces the dmamux driver, the other populates the children
  of the system controller. As the original patch got acked by Stephen
  Boyd, I moved his tag to the patch touching the clock controller only.

Changes in v6:
* Added Stephen's acks.
* Fixed an extra newline added in the middle of nowhere.
* Rebased on top of v5.18-rc1.

Changes in v5:
* Used gotos in rzn1_dmamux_route_allocate().
* Changed the prefix to "dmaengine:".
* Dropped the partial transfers fix.
* Added Rob's acks.

Changes in v4:
* Freed "map" in the error path of the dmamux driver.
* Improved a bit the style as requested by Prabhakar.
* Dropped a __maybe_unused.
* Reorder the includes.
* Added a dependency on ARCH_RZN1.
* Added Rob's Ack.
* Added a reg property to the dmamux binding file.
* Referenced the dmamux binding from the system controller file.
* Called of_platform_populate from the end of the system controller
  (clock) driver probe in order to probe the dmamux if it was
  populated.
* Added DMA properties to all the relevant UARTs.

Changes in v3:
* Added Reviewed-by tags.
* Exported the set_dmamux* symbol properly.
* Dropped a useless check in the probe and moved the sysctrl_priv
  assignation to the end of the probe.
* Renamed the dmamux driver
* Added a couple of missing MODULE_ macros in the dmamux driver.
* Decided to use a regular platform init call instead of the
  arch_initcall() initially proposed.
* s/%d/%u/ in printk's when appropriate.
* Used a hardcoded value instead of dmamux->dmac_requests when
  appropriate.
* Changed the variable name "master" to "dmac_idx" to be more
  descriptive.
* Dropped most of the of_* calls in favor of #define's.
* Fixed a typo.
* Exported two symbols from 8250_dma.c.

Changes in v2:
* Clarified that the 'fix' regarding non aligned reads would only apply
  to the DEV_TO_MEM case.
* Fix the DMA controller compatible string (copy-paste error).
* s/syscon/sysctrl/ as advised by Geert.
* Disabled irqs when taking the spinlock from the clocks driver.
* Moved the DMAMUX offset inside the driver.
* Removed extra commas.
* Improved the style as suggested by Andy.
* Removed a dupplicated check against the device node presence.
* Reduced the number of lines of code by using dev_err_probe().
* Created a Kconfig symbol for DMAMUX to fix the two robot reports
  received and be sure there was no useless overhead with other
  platforms.
* Exported the serial8250_{tx,rx}_dma() symbols.

Miquel Raynal (9):
  dt-bindings: dmaengine: Introduce RZN1 dmamux bindings
  dt-bindings: clock: r9a06g032-sysctrl: Reference the DMAMUX subnode
  dt-bindings: dmaengine: Introduce RZN1 DMA compatible
  soc: renesas: rzn1-sysc: Export function to set dmamux
  dmaengine: dw: dmamux: Introduce RZN1 DMA router support
  clk: renesas: r9a06g032: Probe possible children
  dmaengine: dw: Add RZN1 compatible
  ARM: dts: r9a06g032: Add the two DMA nodes
  ARM: dts: r9a06g032: Describe the DMA router

 .../clock/renesas,r9a06g032-sysctrl.yaml      |  11 ++
 .../bindings/dma/renesas,rzn1-dmamux.yaml     |  51 ++++++
 .../bindings/dma/snps,dma-spear1340.yaml      |   8 +-
 MAINTAINERS                                   |   1 +
 arch/arm/boot/dts/r9a06g032.dtsi              |  40 +++++
 drivers/clk/renesas/r9a06g032-clocks.c        |  36 +++-
 drivers/dma/dw/Kconfig                        |   9 +
 drivers/dma/dw/Makefile                       |   2 +
 drivers/dma/dw/platform.c                     |   1 +
 drivers/dma/dw/rzn1-dmamux.c                  | 157 ++++++++++++++++++
 include/linux/soc/renesas/r9a06g032-sysctrl.h |  11 ++
 11 files changed, 325 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml
 create mode 100644 drivers/dma/dw/rzn1-dmamux.c
 create mode 100644 include/linux/soc/renesas/r9a06g032-sysctrl.h

-- 
2.27.0

[PATCH v8 1/9] dt-bindings: dmaengine: Introduce RZN1 dmamux bindings

[Miquel Raynal]

The Renesas RZN1 DMA IP is based on a DW core, with eg. an additional
dmamux register located in the system control area which can take up to
32 requests (16 per DMA controller). Each DMA channel can be wired to
two different peripherals.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 .../bindings/dma/renesas,rzn1-dmamux.yaml     | 51 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 2 files changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml

diff --git a/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml b/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml
new file mode 100644
index 000000000000..d83013b0dd74
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/renesas,rzn1-dmamux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/N1 DMA mux
+
+maintainers:
+  - Miquel Raynal <miquel.raynal@bootlin.com>
+
+allOf:
+  - $ref: "dma-router.yaml#"
+
+properties:
+  compatible:
+    const: renesas,rzn1-dmamux
+
+  reg:
+    maxItems: 1
+    description: DMA mux first register offset within the system control parent.
+
+  '#dma-cells':
+    const: 6
+    description:
+      The first four cells are dedicated to the master DMA controller. The fifth
+      cell gives the DMA mux bit index that must be set starting from 0. The
+      sixth cell gives the binary value that must be written there, ie. 0 or 1.
+
+  dma-masters:
+    minItems: 1
+    maxItems: 2
+
+  dma-requests:
+    const: 32
+
+required:
+  - reg
+  - dma-requests
+
+additionalProperties: false
+
+examples:
+  - |
+    dma-router@a0 {
+      compatible = "renesas,rzn1-dmamux";
+      reg = <0xa0 4>;
+      #dma-cells = <6>;
+      dma-masters = <&dma0 &dma1>;
+      dma-requests = <32>;
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index fd768d43e048..120d3ae57a4b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19040,6 +19040,7 @@ SYNOPSYS DESIGNWARE DMAC DRIVER
 M:	Viresh Kumar <vireshk@kernel.org>
 R:	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
 S:	Maintained
+F:	Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml
 F:	Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
 F:	drivers/dma/dw/
 F:	include/dt-bindings/dma/dw-dmac.h
-- 
2.27.0

[PATCH v8 2/9] dt-bindings: clock: r9a06g032-sysctrl: Reference the DMAMUX subnode

[Miquel Raynal]

This system controller contains several registers that have nothing to
do with the clock handling, like the DMA mux register. Describe this
part of the system controller as a subnode.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Stephen Boyd <sboyd@kernel.org>
---
 .../bindings/clock/renesas,r9a06g032-sysctrl.yaml     | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml
index 25dbb0fac065..95bf485c6cec 100644
--- a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml
@@ -39,6 +39,17 @@ properties:
   '#power-domain-cells':
     const: 0
 
+  '#address-cells':
+    const: 1
+
+  '#size-cells':
+    const: 1
+
+patternProperties:
+  "^dma-router@[a-f0-9]+$":
+    type: object
+    $ref: "../dma/renesas,rzn1-dmamux.yaml#"
+
 required:
   - compatible
   - reg
-- 
2.27.0

[PATCH v8 3/9] dt-bindings: dmaengine: Introduce RZN1 DMA compatible

[Miquel Raynal]

Just like for the NAND controller that is also on this SoC, let's
provide a SoC generic and a more specific couple of compatibles for the
DMA controller.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../devicetree/bindings/dma/snps,dma-spear1340.yaml       | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
index 6b35089ac017..c13649bf7f19 100644
--- a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
+++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
@@ -15,7 +15,13 @@ allOf:
 
 properties:
   compatible:
-    const: snps,dma-spear1340
+    oneOf:
+      - const: snps,dma-spear1340
+      - items:
+          - enum:
+              - renesas,r9a06g032-dma
+          - const: renesas,rzn1-dma
+
 
   "#dma-cells":
     minimum: 3
-- 
2.27.0

[PATCH v8 4/9] soc: renesas: rzn1-sysc: Export function to set dmamux

[Miquel Raynal]

The dmamux register is located within the system controller.

Without syscon, we need an extra helper in order to give write access to
this register to a dmamux driver.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
---
 drivers/clk/renesas/r9a06g032-clocks.c        | 35 ++++++++++++++++++-
 include/linux/soc/renesas/r9a06g032-sysctrl.h | 11 ++++++
 2 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/soc/renesas/r9a06g032-sysctrl.h

diff --git a/drivers/clk/renesas/r9a06g032-clocks.c b/drivers/clk/renesas/r9a06g032-clocks.c
index c99942f0e4d4..052d99059981 100644
--- a/drivers/clk/renesas/r9a06g032-clocks.c
+++ b/drivers/clk/renesas/r9a06g032-clocks.c
@@ -20,9 +20,12 @@
 #include <linux/pm_clock.h>
 #include <linux/pm_domain.h>
 #include <linux/slab.h>
+#include <linux/soc/renesas/r9a06g032-sysctrl.h>
 #include <linux/spinlock.h>
 #include <dt-bindings/clock/r9a06g032-sysctrl.h>
 
+#define R9A06G032_SYSCTRL_DMAMUX 0xA0
+
 struct r9a06g032_gate {
 	u16 gate, reset, ready, midle,
 		scon, mirack, mistat;
@@ -315,6 +318,30 @@ struct r9a06g032_priv {
 	void __iomem *reg;
 };
 
+static struct r9a06g032_priv *sysctrl_priv;
+
+/* Exported helper to access the DMAMUX register */
+int r9a06g032_sysctrl_set_dmamux(u32 mask, u32 val)
+{
+	unsigned long flags;
+	u32 dmamux;
+
+	if (!sysctrl_priv)
+		return -EPROBE_DEFER;
+
+	spin_lock_irqsave(&sysctrl_priv->lock, flags);
+
+	dmamux = readl(sysctrl_priv->reg + R9A06G032_SYSCTRL_DMAMUX);
+	dmamux &= ~mask;
+	dmamux |= val & mask;
+	writel(dmamux, sysctrl_priv->reg + R9A06G032_SYSCTRL_DMAMUX);
+
+	spin_unlock_irqrestore(&sysctrl_priv->lock, flags);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(r9a06g032_sysctrl_set_dmamux);
+
 /* register/bit pairs are encoded as an uint16_t */
 static void
 clk_rdesc_set(struct r9a06g032_priv *clocks,
@@ -963,7 +990,13 @@ static int __init r9a06g032_clocks_probe(struct platform_device *pdev)
 	if (error)
 		return error;
 
-	return r9a06g032_add_clk_domain(dev);
+	error = r9a06g032_add_clk_domain(dev);
+	if (error)
+		return error;
+
+	sysctrl_priv = clocks;
+
+	return 0;
 }
 
 static const struct of_device_id r9a06g032_match[] = {
diff --git a/include/linux/soc/renesas/r9a06g032-sysctrl.h b/include/linux/soc/renesas/r9a06g032-sysctrl.h
new file mode 100644
index 000000000000..066dfb15cbdd
--- /dev/null
+++ b/include/linux/soc/renesas/r9a06g032-sysctrl.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __LINUX_SOC_RENESAS_R9A06G032_SYSCTRL_H__
+#define __LINUX_SOC_RENESAS_R9A06G032_SYSCTRL_H__
+
+#ifdef CONFIG_CLK_R9A06G032
+int r9a06g032_sysctrl_set_dmamux(u32 mask, u32 val);
+#else
+static inline int r9a06g032_sysctrl_set_dmamux(u32 mask, u32 val) { return -ENODEV; }
+#endif
+
+#endif /* __LINUX_SOC_RENESAS_R9A06G032_SYSCTRL_H__ */
-- 
2.27.0

[PATCH v8 5/9] dmaengine: dw: dmamux: Introduce RZN1 DMA router support

[Miquel Raynal]

The Renesas RZN1 DMA IP is based on a DW core, with eg. an additional
dmamux register located in the system control area which can take up to
32 requests (16 per DMA controller). Each DMA channel can be wired to
two different peripherals.

We need two additional information from the 'dmas' property: the channel
(bit in the dmamux register) that must be accessed and the value of the
mux for this channel.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/dma/dw/Kconfig       |   9 ++
 drivers/dma/dw/Makefile      |   2 +
 drivers/dma/dw/rzn1-dmamux.c | 157 +++++++++++++++++++++++++++++++++++
 3 files changed, 168 insertions(+)
 create mode 100644 drivers/dma/dw/rzn1-dmamux.c

diff --git a/drivers/dma/dw/Kconfig b/drivers/dma/dw/Kconfig
index db25f9b7778c..a9828ddd6d06 100644
--- a/drivers/dma/dw/Kconfig
+++ b/drivers/dma/dw/Kconfig
@@ -16,6 +16,15 @@ config DW_DMAC
 	  Support the Synopsys DesignWare AHB DMA controller. This
 	  can be integrated in chips such as the Intel Cherrytrail.
 
+config RZN1_DMAMUX
+	tristate "Renesas RZ/N1 DMAMUX driver"
+	depends on DW_DMAC
+	depends on ARCH_RZN1 || COMPILE_TEST
+	help
+	  Support the Renesas RZ/N1 DMAMUX which is located in front of
+	  the Synopsys DesignWare AHB DMA controller located on Renesas
+	  SoCs.
+
 config DW_DMAC_PCI
 	tristate "Synopsys DesignWare AHB DMA PCI driver"
 	depends on PCI
diff --git a/drivers/dma/dw/Makefile b/drivers/dma/dw/Makefile
index a6f358ad8591..e1796015f213 100644
--- a/drivers/dma/dw/Makefile
+++ b/drivers/dma/dw/Makefile
@@ -9,3 +9,5 @@ dw_dmac-$(CONFIG_OF)		+= of.o
 
 obj-$(CONFIG_DW_DMAC_PCI)	+= dw_dmac_pci.o
 dw_dmac_pci-y			:= pci.o
+
+obj-$(CONFIG_RZN1_DMAMUX)	+= rzn1-dmamux.o
diff --git a/drivers/dma/dw/rzn1-dmamux.c b/drivers/dma/dw/rzn1-dmamux.c
new file mode 100644
index 000000000000..5f878a55158f
--- /dev/null
+++ b/drivers/dma/dw/rzn1-dmamux.c
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Schneider-Electric
+ * Author: Miquel Raynal <miquel.raynal@bootlin.com
+ * Based on TI crossbar driver written by Peter Ujfalusi <peter.ujfalusi@ti.com>
+ */
+#include <linux/of_device.h>
+#include <linux/of_dma.h>
+#include <linux/slab.h>
+#include <linux/soc/renesas/r9a06g032-sysctrl.h>
+
+#define RZN1_DMAMUX_LINES 64
+#define RZN1_DMAMUX_MAX_LINES 16
+
+struct rzn1_dmamux_data {
+	struct dma_router dmarouter;
+	u32 used_chans;
+	struct mutex lock;
+};
+
+struct rzn1_dmamux_map {
+	unsigned int req_idx;
+};
+
+static void rzn1_dmamux_free(struct device *dev, void *route_data)
+{
+	struct rzn1_dmamux_data *dmamux = dev_get_drvdata(dev);
+	struct rzn1_dmamux_map *map = route_data;
+
+	dev_dbg(dev, "Unmapping DMAMUX request %u\n", map->req_idx);
+
+	mutex_lock(&dmamux->lock);
+	dmamux->used_chans &= ~BIT(map->req_idx);
+	mutex_unlock(&dmamux->lock);
+
+	kfree(map);
+}
+
+static void *rzn1_dmamux_route_allocate(struct of_phandle_args *dma_spec,
+					struct of_dma *ofdma)
+{
+	struct platform_device *pdev = of_find_device_by_node(ofdma->of_node);
+	struct rzn1_dmamux_data *dmamux = platform_get_drvdata(pdev);
+	struct rzn1_dmamux_map *map;
+	unsigned int dmac_idx, chan, val;
+	u32 mask;
+	int ret;
+
+	if (dma_spec->args_count != 6)
+		return ERR_PTR(-EINVAL);
+
+	map = kzalloc(sizeof(*map), GFP_KERNEL);
+	if (!map)
+		return ERR_PTR(-ENOMEM);
+
+	chan = dma_spec->args[0];
+	map->req_idx = dma_spec->args[4];
+	val = dma_spec->args[5];
+	dma_spec->args_count -= 2;
+
+	if (chan >= RZN1_DMAMUX_MAX_LINES) {
+		dev_err(&pdev->dev, "Invalid DMA request line: %u\n", chan);
+		ret = -EINVAL;
+		goto free_map;
+	}
+
+	if (map->req_idx >= RZN1_DMAMUX_LINES ||
+	    (map->req_idx % RZN1_DMAMUX_MAX_LINES) != chan) {
+		dev_err(&pdev->dev, "Invalid MUX request line: %u\n", map->req_idx);
+		ret = -EINVAL;
+		goto free_map;
+	}
+
+	dmac_idx = map->req_idx >= RZN1_DMAMUX_MAX_LINES ? 1 : 0;
+	dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", dmac_idx);
+	if (!dma_spec->np) {
+		dev_err(&pdev->dev, "Can't get DMA master\n");
+		ret = -EINVAL;
+		goto free_map;
+	}
+
+	dev_dbg(&pdev->dev, "Mapping DMAMUX request %u to DMAC%u request %u\n",
+		map->req_idx, dmac_idx, chan);
+
+	mask = BIT(map->req_idx);
+	mutex_lock(&dmamux->lock);
+	dmamux->used_chans |= mask;
+	ret = r9a06g032_sysctrl_set_dmamux(mask, val ? mask : 0);
+	if (ret)
+		goto release_chan_and_unlock;
+
+	mutex_unlock(&dmamux->lock);
+
+	return map;
+
+release_chan_and_unlock:
+	dmamux->used_chans &= ~mask;
+	mutex_unlock(&dmamux->lock);
+free_map:
+	kfree(map);
+
+	return ERR_PTR(ret);
+}
+
+static const struct of_device_id rzn1_dmac_match[] = {
+	{ .compatible = "renesas,rzn1-dma" },
+	{}
+};
+
+static int rzn1_dmamux_probe(struct platform_device *pdev)
+{
+	struct device_node *mux_node = pdev->dev.of_node;
+	const struct of_device_id *match;
+	struct device_node *dmac_node;
+	struct rzn1_dmamux_data *dmamux;
+
+	dmamux = devm_kzalloc(&pdev->dev, sizeof(*dmamux), GFP_KERNEL);
+	if (!dmamux)
+		return -ENOMEM;
+
+	mutex_init(&dmamux->lock);
+
+	dmac_node = of_parse_phandle(mux_node, "dma-masters", 0);
+	if (!dmac_node)
+		return dev_err_probe(&pdev->dev, -ENODEV, "Can't get DMA master node\n");
+
+	match = of_match_node(rzn1_dmac_match, dmac_node);
+	of_node_put(dmac_node);
+	if (!match)
+		return dev_err_probe(&pdev->dev, -EINVAL, "DMA master is not supported\n");
+
+	dmamux->dmarouter.dev = &pdev->dev;
+	dmamux->dmarouter.route_free = rzn1_dmamux_free;
+
+	platform_set_drvdata(pdev, dmamux);
+
+	return of_dma_router_register(mux_node, rzn1_dmamux_route_allocate,
+				      &dmamux->dmarouter);
+}
+
+static const struct of_device_id rzn1_dmamux_match[] = {
+	{ .compatible = "renesas,rzn1-dmamux" },
+	{}
+};
+
+static struct platform_driver rzn1_dmamux_driver = {
+	.driver = {
+		.name = "renesas,rzn1-dmamux",
+		.of_match_table = rzn1_dmamux_match,
+	},
+	.probe	= rzn1_dmamux_probe,
+};
+module_platform_driver(rzn1_dmamux_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com");
+MODULE_DESCRIPTION("Renesas RZ/N1 DMAMUX driver");
-- 
2.27.0

[PATCH v8 6/9] clk: renesas: r9a06g032: Probe possible children

[Miquel Raynal]

The clock controller device on r9a06g032 takes all the memory range that
is described as being a system controller. This range contains many
different (unrelated?) registers besides the ones belonging to the clock
controller, that can necessitate to be accessed from other peripherals.

For instance, the dmamux registers are there. The dmamux "device" will
be described as a child node of the clock/system controller node, which
means we need the top device driver (the clock controller driver in this
case) to populate its children manually.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
---
 drivers/clk/renesas/r9a06g032-clocks.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/renesas/r9a06g032-clocks.c b/drivers/clk/renesas/r9a06g032-clocks.c
index 052d99059981..1df56d7ab3e1 100644
--- a/drivers/clk/renesas/r9a06g032-clocks.c
+++ b/drivers/clk/renesas/r9a06g032-clocks.c
@@ -16,6 +16,7 @@
 #include <linux/math64.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
+#include <linux/of_platform.h>
 #include <linux/platform_device.h>
 #include <linux/pm_clock.h>
 #include <linux/pm_domain.h>
@@ -996,7 +997,7 @@ static int __init r9a06g032_clocks_probe(struct platform_device *pdev)
 
 	sysctrl_priv = clocks;
 
-	return 0;
+	return of_platform_populate(np, NULL, NULL, dev);
 }
 
 static const struct of_device_id r9a06g032_match[] = {
-- 
2.27.0

[PATCH v8 7/9] dmaengine: dw: Add RZN1 compatible

[Miquel Raynal]

The Renesas RZN1 DMA IP is very close to the original DW DMA IP, a DMA
router has been introduced to handle the wiring options that have been
added.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/dma/dw/platform.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 246118955877..47f2292dba98 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -137,6 +137,7 @@ static void dw_shutdown(struct platform_device *pdev)
 #ifdef CONFIG_OF
 static const struct of_device_id dw_dma_of_id_table[] = {
 	{ .compatible = "snps,dma-spear1340", .data = &dw_dma_chip_pdata },
+	{ .compatible = "renesas,rzn1-dma", .data = &dw_dma_chip_pdata },
 	{}
 };
 MODULE_DEVICE_TABLE(of, dw_dma_of_id_table);
-- 
2.27.0

[PATCH v8 8/9] ARM: dts: r9a06g032: Add the two DMA nodes

[Miquel Raynal]

Describe the two DMA controllers available on this SoC.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm/boot/dts/r9a06g032.dtsi | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
index 636a6ab31c58..839580ec21ee 100644
--- a/arch/arm/boot/dts/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -200,6 +200,36 @@ nand_controller: nand-controller@40102000 {
 			status = "disabled";
 		};
 
+		dma0: dma-controller@40104000 {
+			compatible = "renesas,r9a06g032-dma", "renesas,rzn1-dma";
+			reg = <0x40104000 0x1000>;
+			interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "hclk";
+			clocks = <&sysctrl R9A06G032_HCLK_DMA0>;
+			dma-channels = <8>;
+			dma-requests = <16>;
+			dma-masters = <1>;
+			#dma-cells = <3>;
+			block_size = <0xfff>;
+			data_width = <3>;
+			status = "disabled";
+		};
+
+		dma1: dma-controller@40105000 {
+			compatible = "renesas,r9a06g032-dma", "renesas,rzn1-dma";
+			reg = <0x40105000 0x1000>;
+			interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "hclk";
+			clocks = <&sysctrl R9A06G032_HCLK_DMA1>;
+			dma-channels = <8>;
+			dma-requests = <16>;
+			dma-masters = <1>;
+			#dma-cells = <3>;
+			block_size = <0xfff>;
+			data_width = <3>;
+			status = "disabled";
+		};
+
 		gic: interrupt-controller@44101000 {
 			compatible = "arm,gic-400", "arm,cortex-a7-gic";
 			interrupt-controller;
-- 
2.27.0

[PATCH v8 9/9] ARM: dts: r9a06g032: Describe the DMA router

[Miquel Raynal]

There is a dmamux on this SoC which allows picking two different sources
for a single DMA request.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 arch/arm/boot/dts/r9a06g032.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
index 839580ec21ee..c854aa4cfa77 100644
--- a/arch/arm/boot/dts/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -91,6 +91,16 @@ sysctrl: system-controller@4000c000 {
 			clocks = <&ext_mclk>, <&ext_rtc_clk>,
 					<&ext_jtag_clk>, <&ext_rgmii_ref>;
 			clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			dmamux: dma-router@a0 {
+				compatible = "renesas,rzn1-dmamux";
+				reg = <0xa0 4>;
+				#dma-cells = <6>;
+				dma-requests = <32>;
+				dma-masters = <&dma0 &dma1>;
+			};
 		};
 
 		uart0: serial@40060000 {
-- 
2.27.0

Re: [PATCH v8 0/9] RZN1 DMA support

[Stephen Boyd]

Quoting Miquel Raynal (2022-04-06 09:18:47)
> Hello,
> 
> Here is a first series bringing DMA support to RZN1 platforms. Soon a
> second series will come with changes made to the UART controller
> driver, in order to interact with the RZN1 DMA controller.
> 
> Stephen acked the sysctrl patch (in the clk driver) but somehow I feel
> like it would be good to have this patch applied on both sides
> (dmaengine and clk) because more changes will depend on the addition of
> this helper, that are not related to DMA at all. I'll let you folks
> figure out what is best.

Are you sending more patches in the next 7 weeks or so that will touch
the same area? If so, then it sounds like I'll need to take the clk
patch through clk tree. I don't know what is best because I don't have
the information about what everyone plans to do in that file.

Re: [PATCH v8 0/9] RZN1 DMA support

[Miquel Raynal]

Hi Stephen,

sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700:

> Quoting Miquel Raynal (2022-04-06 09:18:47)
> > Hello,
> > 
> > Here is a first series bringing DMA support to RZN1 platforms. Soon a
> > second series will come with changes made to the UART controller
> > driver, in order to interact with the RZN1 DMA controller.
> > 
> > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel
> > like it would be good to have this patch applied on both sides
> > (dmaengine and clk) because more changes will depend on the addition of
> > this helper, that are not related to DMA at all. I'll let you folks
> > figure out what is best.  
> 
> Are you sending more patches in the next 7 weeks or so that will touch
> the same area? If so, then it sounds like I'll need to take the clk
> patch through clk tree. I don't know what is best because I don't have
> the information about what everyone plans to do in that file.

This series brings DMA support and needs to access the dmamux registers
that are in the sysctrl area.

I've sent an RTC series which needs to access this area as well, but
it is not fully ready yet as it was advised to go for a reset
controller in this case. The reset controller would be registered by
the clock driver, so yes it would touch the same file.

Finally, there is an USB series that is coming soon, I don't know if
it will be ready for merge for 5.19, but it needs to access a specific
register in this area as well (h2mode).

So provided that we are able to contribute this reset driver quickly
enough, I would argue that it is safer to merge the clk changes in the
clk tree.

Thanks,
Miquèl

Re: [PATCH v8 5/9] dmaengine: dw: dmamux: Introduce RZN1 DMA router support

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 2596 bytes --]

On Wed, 6 Apr 2022, Miquel Raynal wrote:

> The Renesas RZN1 DMA IP is based on a DW core, with eg. an additional
> dmamux register located in the system control area which can take up to
> 32 requests (16 per DMA controller). Each DMA channel can be wired to
> two different peripherals.
> 
> We need two additional information from the 'dmas' property: the channel
> (bit in the dmamux register) that must be accessed and the value of the
> mux for this channel.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---

> +static void *rzn1_dmamux_route_allocate(struct of_phandle_args *dma_spec,
> +					struct of_dma *ofdma)
> +{
> +	struct platform_device *pdev = of_find_device_by_node(ofdma->of_node);
> +	struct rzn1_dmamux_data *dmamux = platform_get_drvdata(pdev);
> +	struct rzn1_dmamux_map *map;
> +	unsigned int dmac_idx, chan, val;
> +	u32 mask;
> +	int ret;
> +
> +	if (dma_spec->args_count != 6)
> +		return ERR_PTR(-EINVAL);
> +
> +	map = kzalloc(sizeof(*map), GFP_KERNEL);
> +	if (!map)
> +		return ERR_PTR(-ENOMEM);
> +
> +	chan = dma_spec->args[0];
> +	map->req_idx = dma_spec->args[4];
> +	val = dma_spec->args[5];
> +	dma_spec->args_count -= 2;
> +
> +	if (chan >= RZN1_DMAMUX_MAX_LINES) {
> +		dev_err(&pdev->dev, "Invalid DMA request line: %u\n", chan);
> +		ret = -EINVAL;
> +		goto free_map;
> +	}
> +
> +	if (map->req_idx >= RZN1_DMAMUX_LINES ||
> +	    (map->req_idx % RZN1_DMAMUX_MAX_LINES) != chan) {
> +		dev_err(&pdev->dev, "Invalid MUX request line: %u\n", map->req_idx);
> +		ret = -EINVAL;
> +		goto free_map;
> +	}
> +
> +	dmac_idx = map->req_idx >= RZN1_DMAMUX_MAX_LINES ? 1 : 0;
> +	dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", dmac_idx);
> +	if (!dma_spec->np) {
> +		dev_err(&pdev->dev, "Can't get DMA master\n");
> +		ret = -EINVAL;
> +		goto free_map;
> +	}
> +
> +	dev_dbg(&pdev->dev, "Mapping DMAMUX request %u to DMAC%u request %u\n",
> +		map->req_idx, dmac_idx, chan);
> +
> +	mask = BIT(map->req_idx);
> +	mutex_lock(&dmamux->lock);
> +	dmamux->used_chans |= mask;
> +	ret = r9a06g032_sysctrl_set_dmamux(mask, val ? mask : 0);
> +	if (ret)
> +		goto release_chan_and_unlock;
> +
> +	mutex_unlock(&dmamux->lock);
> +
> +	return map;
> +
> +release_chan_and_unlock:
> +	dmamux->used_chans &= ~mask;

Now that I check this again, I'm not sure why dmamux->used_chans |= mask; 
couldn't be done after r9a06g032_sysctrl_set_dmamux() call so this 
rollback of it wouldn't be necessary.

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>



-- 
 i.

Re: [PATCH v8 5/9] dmaengine: dw: dmamux: Introduce RZN1 DMA router support

[Andy Shevchenko]

On Fri, Apr 08, 2022 at 12:55:47PM +0300, Ilpo Järvinen wrote:
> On Wed, 6 Apr 2022, Miquel Raynal wrote:
> 
> > The Renesas RZN1 DMA IP is based on a DW core, with eg. an additional
> > dmamux register located in the system control area which can take up to
> > 32 requests (16 per DMA controller). Each DMA channel can be wired to
> > two different peripherals.
> > 
> > We need two additional information from the 'dmas' property: the channel
> > (bit in the dmamux register) that must be accessed and the value of the
> > mux for this channel.

> > +	mask = BIT(map->req_idx);
> > +	mutex_lock(&dmamux->lock);
> > +	dmamux->used_chans |= mask;
> > +	ret = r9a06g032_sysctrl_set_dmamux(mask, val ? mask : 0);
> > +	if (ret)
> > +		goto release_chan_and_unlock;
> > +
> > +	mutex_unlock(&dmamux->lock);
> > +
> > +	return map;
> > +
> > +release_chan_and_unlock:
> > +	dmamux->used_chans &= ~mask;
> 
> Now that I check this again, I'm not sure why dmamux->used_chans |= mask; 
> couldn't be done after r9a06g032_sysctrl_set_dmamux() call so this 
> rollback of it wouldn't be necessary.

I would still need the mutex unlock which I believe is down path there under
some other label. Hence you are proposing something like

	mask = BIT(map->req_idx);

	mutex_lock(&dmamux->lock);
	ret = r9a06g032_sysctrl_set_dmamux(mask, val ? mask : 0);
	if (ret)
		goto err_unlock; // or whatever label is

	dmamux->used_chans |= mask;
	mutex_unlock(&dmamux->lock);

	return map;

Is that correct? If so, I don't see impediments either.

> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v8 5/9] dmaengine: dw: dmamux: Introduce RZN1 DMA router support

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

On Fri, 8 Apr 2022, Andy Shevchenko wrote:

> On Fri, Apr 08, 2022 at 12:55:47PM +0300, Ilpo Järvinen wrote:
> > On Wed, 6 Apr 2022, Miquel Raynal wrote:
> > 
> > > The Renesas RZN1 DMA IP is based on a DW core, with eg. an additional
> > > dmamux register located in the system control area which can take up to
> > > 32 requests (16 per DMA controller). Each DMA channel can be wired to
> > > two different peripherals.
> > > 
> > > We need two additional information from the 'dmas' property: the channel
> > > (bit in the dmamux register) that must be accessed and the value of the
> > > mux for this channel.
> 
> > > +	mask = BIT(map->req_idx);
> > > +	mutex_lock(&dmamux->lock);
> > > +	dmamux->used_chans |= mask;
> > > +	ret = r9a06g032_sysctrl_set_dmamux(mask, val ? mask : 0);
> > > +	if (ret)
> > > +		goto release_chan_and_unlock;
> > > +
> > > +	mutex_unlock(&dmamux->lock);
> > > +
> > > +	return map;
> > > +
> > > +release_chan_and_unlock:
> > > +	dmamux->used_chans &= ~mask;
> > 
> > Now that I check this again, I'm not sure why dmamux->used_chans |= mask; 
> > couldn't be done after r9a06g032_sysctrl_set_dmamux() call so this 
> > rollback of it wouldn't be necessary.
> 
> I would still need the mutex unlock which I believe is down path there under
> some other label. Hence you are proposing something like
> 
> 	mask = BIT(map->req_idx);
> 
> 	mutex_lock(&dmamux->lock);
> 	ret = r9a06g032_sysctrl_set_dmamux(mask, val ? mask : 0);
> 	if (ret)
> 		goto err_unlock; // or whatever label is
> 
> 	dmamux->used_chans |= mask;
> 	mutex_unlock(&dmamux->lock);
> 
> 	return map;
> 
> Is that correct? If so, I don't see impediments either.

Yes, and yes, the mutex still has to be unlocked on that error path.

> > Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

-- 
 i.

Re: [PATCH v8 5/9] dmaengine: dw: dmamux: Introduce RZN1 DMA router support

[Vinod Koul]

On 06-04-22, 18:18, Miquel Raynal wrote:
> The Renesas RZN1 DMA IP is based on a DW core, with eg. an additional
> dmamux register located in the system control area which can take up to
> 32 requests (16 per DMA controller). Each DMA channel can be wired to
> two different peripherals.
> 
> We need two additional information from the 'dmas' property: the channel
> (bit in the dmamux register) that must be accessed and the value of the
> mux for this channel.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  drivers/dma/dw/Kconfig       |   9 ++
>  drivers/dma/dw/Makefile      |   2 +
>  drivers/dma/dw/rzn1-dmamux.c | 157 +++++++++++++++++++++++++++++++++++
>  3 files changed, 168 insertions(+)
>  create mode 100644 drivers/dma/dw/rzn1-dmamux.c
> 
> diff --git a/drivers/dma/dw/Kconfig b/drivers/dma/dw/Kconfig
> index db25f9b7778c..a9828ddd6d06 100644
> --- a/drivers/dma/dw/Kconfig
> +++ b/drivers/dma/dw/Kconfig
> @@ -16,6 +16,15 @@ config DW_DMAC
>  	  Support the Synopsys DesignWare AHB DMA controller. This
>  	  can be integrated in chips such as the Intel Cherrytrail.
>  
> +config RZN1_DMAMUX
> +	tristate "Renesas RZ/N1 DMAMUX driver"
> +	depends on DW_DMAC
> +	depends on ARCH_RZN1 || COMPILE_TEST
> +	help
> +	  Support the Renesas RZ/N1 DMAMUX which is located in front of
> +	  the Synopsys DesignWare AHB DMA controller located on Renesas
> +	  SoCs.
> +
>  config DW_DMAC_PCI
>  	tristate "Synopsys DesignWare AHB DMA PCI driver"
>  	depends on PCI
> diff --git a/drivers/dma/dw/Makefile b/drivers/dma/dw/Makefile
> index a6f358ad8591..e1796015f213 100644
> --- a/drivers/dma/dw/Makefile
> +++ b/drivers/dma/dw/Makefile
> @@ -9,3 +9,5 @@ dw_dmac-$(CONFIG_OF)		+= of.o
>  
>  obj-$(CONFIG_DW_DMAC_PCI)	+= dw_dmac_pci.o
>  dw_dmac_pci-y			:= pci.o
> +
> +obj-$(CONFIG_RZN1_DMAMUX)	+= rzn1-dmamux.o
> diff --git a/drivers/dma/dw/rzn1-dmamux.c b/drivers/dma/dw/rzn1-dmamux.c
> new file mode 100644
> index 000000000000..5f878a55158f
> --- /dev/null
> +++ b/drivers/dma/dw/rzn1-dmamux.c
> @@ -0,0 +1,157 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022 Schneider-Electric
> + * Author: Miquel Raynal <miquel.raynal@bootlin.com
> + * Based on TI crossbar driver written by Peter Ujfalusi <peter.ujfalusi@ti.com>
> + */
> +#include <linux/of_device.h>
> +#include <linux/of_dma.h>
> +#include <linux/slab.h>
> +#include <linux/soc/renesas/r9a06g032-sysctrl.h>
> +
> +#define RZN1_DMAMUX_LINES 64
> +#define RZN1_DMAMUX_MAX_LINES 16
> +
> +struct rzn1_dmamux_data {
> +	struct dma_router dmarouter;
> +	u32 used_chans;
> +	struct mutex lock;
> +};
> +
> +struct rzn1_dmamux_map {
> +	unsigned int req_idx;
> +};
> +
> +static void rzn1_dmamux_free(struct device *dev, void *route_data)
> +{
> +	struct rzn1_dmamux_data *dmamux = dev_get_drvdata(dev);
> +	struct rzn1_dmamux_map *map = route_data;
> +
> +	dev_dbg(dev, "Unmapping DMAMUX request %u\n", map->req_idx);
> +
> +	mutex_lock(&dmamux->lock);
> +	dmamux->used_chans &= ~BIT(map->req_idx);
> +	mutex_unlock(&dmamux->lock);

Why not use idr or bitmap for this. Hint: former does locking as well

> +
> +	kfree(map);
> +}
> +
> +static void *rzn1_dmamux_route_allocate(struct of_phandle_args *dma_spec,
> +					struct of_dma *ofdma)
> +{
> +	struct platform_device *pdev = of_find_device_by_node(ofdma->of_node);
> +	struct rzn1_dmamux_data *dmamux = platform_get_drvdata(pdev);
> +	struct rzn1_dmamux_map *map;
> +	unsigned int dmac_idx, chan, val;
> +	u32 mask;
> +	int ret;
> +
> +	if (dma_spec->args_count != 6)

magic

> +		return ERR_PTR(-EINVAL);
> +
> +	map = kzalloc(sizeof(*map), GFP_KERNEL);
> +	if (!map)
> +		return ERR_PTR(-ENOMEM);
> +
> +	chan = dma_spec->args[0];
> +	map->req_idx = dma_spec->args[4];
> +	val = dma_spec->args[5];
> +	dma_spec->args_count -= 2;
> +
> +	if (chan >= RZN1_DMAMUX_MAX_LINES) {
> +		dev_err(&pdev->dev, "Invalid DMA request line: %u\n", chan);
> +		ret = -EINVAL;
> +		goto free_map;
> +	}
> +
> +	if (map->req_idx >= RZN1_DMAMUX_LINES ||
> +	    (map->req_idx % RZN1_DMAMUX_MAX_LINES) != chan) {
> +		dev_err(&pdev->dev, "Invalid MUX request line: %u\n", map->req_idx);
> +		ret = -EINVAL;
> +		goto free_map;
> +	}
> +
> +	dmac_idx = map->req_idx >= RZN1_DMAMUX_MAX_LINES ? 1 : 0;
> +	dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", dmac_idx);
> +	if (!dma_spec->np) {
> +		dev_err(&pdev->dev, "Can't get DMA master\n");
> +		ret = -EINVAL;
> +		goto free_map;
> +	}
> +
> +	dev_dbg(&pdev->dev, "Mapping DMAMUX request %u to DMAC%u request %u\n",
> +		map->req_idx, dmac_idx, chan);
> +
> +	mask = BIT(map->req_idx);
> +	mutex_lock(&dmamux->lock);
> +	dmamux->used_chans |= mask;
> +	ret = r9a06g032_sysctrl_set_dmamux(mask, val ? mask : 0);

I guess due to this it would be merged by whosoever merges this api.
Please mention this in cover letter and how you propose this should be
merged

-- 
~Vinod

Re: [PATCH v8 0/9] RZN1 DMA support

[Geert Uytterhoeven]

Hi Miquel,

On Thu, Apr 7, 2022 at 10:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700:
> > Quoting Miquel Raynal (2022-04-06 09:18:47)
> > > Here is a first series bringing DMA support to RZN1 platforms. Soon a
> > > second series will come with changes made to the UART controller
> > > driver, in order to interact with the RZN1 DMA controller.
> > >
> > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel
> > > like it would be good to have this patch applied on both sides
> > > (dmaengine and clk) because more changes will depend on the addition of
> > > this helper, that are not related to DMA at all. I'll let you folks
> > > figure out what is best.
> >
> > Are you sending more patches in the next 7 weeks or so that will touch
> > the same area? If so, then it sounds like I'll need to take the clk
> > patch through clk tree. I don't know what is best because I don't have
> > the information about what everyone plans to do in that file.
>
> This series brings DMA support and needs to access the dmamux registers
> that are in the sysctrl area.
>
> I've sent an RTC series which needs to access this area as well, but
> it is not fully ready yet as it was advised to go for a reset
> controller in this case. The reset controller would be registered by
> the clock driver, so yes it would touch the same file.
>
> Finally, there is an USB series that is coming soon, I don't know if
> it will be ready for merge for 5.19, but it needs to access a specific
> register in this area as well (h2mode).
>
> So provided that we are able to contribute this reset driver quickly
> enough, I would argue that it is safer to merge the clk changes in the
> clk tree.

The clk tree or the renesas-clk tree? ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v8 0/9] RZN1 DMA support

[Miquel Raynal]

Hi Geert,

geert@linux-m68k.org wrote on Mon, 11 Apr 2022 17:09:50 +0200:

> Hi Miquel,
> 
> On Thu, Apr 7, 2022 at 10:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700:  
> > > Quoting Miquel Raynal (2022-04-06 09:18:47)  
> > > > Here is a first series bringing DMA support to RZN1 platforms. Soon a
> > > > second series will come with changes made to the UART controller
> > > > driver, in order to interact with the RZN1 DMA controller.
> > > >
> > > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel
> > > > like it would be good to have this patch applied on both sides
> > > > (dmaengine and clk) because more changes will depend on the addition of
> > > > this helper, that are not related to DMA at all. I'll let you folks
> > > > figure out what is best.  
> > >
> > > Are you sending more patches in the next 7 weeks or so that will touch
> > > the same area? If so, then it sounds like I'll need to take the clk
> > > patch through clk tree. I don't know what is best because I don't have
> > > the information about what everyone plans to do in that file.  
> >
> > This series brings DMA support and needs to access the dmamux registers
> > that are in the sysctrl area.
> >
> > I've sent an RTC series which needs to access this area as well, but
> > it is not fully ready yet as it was advised to go for a reset
> > controller in this case. The reset controller would be registered by
> > the clock driver, so yes it would touch the same file.
> >
> > Finally, there is an USB series that is coming soon, I don't know if
> > it will be ready for merge for 5.19, but it needs to access a specific
> > register in this area as well (h2mode).
> >
> > So provided that we are able to contribute this reset driver quickly
> > enough, I would argue that it is safer to merge the clk changes in the
> > clk tree.  
> 
> The clk tree or the renesas-clk tree? ;-)

Actually I forgot about this tree, would you mind to merge *all* the
patches that depend on the sysctrl changes in the renesas/renesas-clk
tree? This also stands for the UART and RTC for instance. Otherwise
you'll need to set up immutable branches and share them with the
dmaengine, serial and rtc trees. I'm fine either way, it's just much
less work in the first situation IMHO.

Thanks,
Miquèl

Re: [PATCH v8 0/9] RZN1 DMA support

[Geert Uytterhoeven]

Hi Miquel,

On Tue, Apr 12, 2022 at 9:32 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> geert@linux-m68k.org wrote on Mon, 11 Apr 2022 17:09:50 +0200:
> > On Thu, Apr 7, 2022 at 10:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700:
> > > > Quoting Miquel Raynal (2022-04-06 09:18:47)
> > > > > Here is a first series bringing DMA support to RZN1 platforms. Soon a
> > > > > second series will come with changes made to the UART controller
> > > > > driver, in order to interact with the RZN1 DMA controller.
> > > > >
> > > > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel
> > > > > like it would be good to have this patch applied on both sides
> > > > > (dmaengine and clk) because more changes will depend on the addition of
> > > > > this helper, that are not related to DMA at all. I'll let you folks
> > > > > figure out what is best.
> > > >
> > > > Are you sending more patches in the next 7 weeks or so that will touch
> > > > the same area? If so, then it sounds like I'll need to take the clk
> > > > patch through clk tree. I don't know what is best because I don't have
> > > > the information about what everyone plans to do in that file.
> > >
> > > This series brings DMA support and needs to access the dmamux registers
> > > that are in the sysctrl area.
> > >
> > > I've sent an RTC series which needs to access this area as well, but
> > > it is not fully ready yet as it was advised to go for a reset
> > > controller in this case. The reset controller would be registered by
> > > the clock driver, so yes it would touch the same file.
> > >
> > > Finally, there is an USB series that is coming soon, I don't know if
> > > it will be ready for merge for 5.19, but it needs to access a specific
> > > register in this area as well (h2mode).
> > >
> > > So provided that we are able to contribute this reset driver quickly
> > > enough, I would argue that it is safer to merge the clk changes in the
> > > clk tree.
> >
> > The clk tree or the renesas-clk tree? ;-)
>
> Actually I forgot about this tree, would you mind to merge *all* the
> patches that depend on the sysctrl changes in the renesas/renesas-clk
> tree? This also stands for the UART and RTC for instance. Otherwise
> you'll need to set up immutable branches and share them with the
> dmaengine, serial and rtc trees. I'm fine either way, it's just much
> less work in the first situation IMHO.

Sure, I can do that, given acks from the DMA, UART, and RTC
maintainers.

So far I've been rather terse in giving feedback on these series,
as I'm in wait-and-see mode w.r.t. what else you've planned for the
sysctrl DT node[1] and clock/sys controller code...

[1] Did I say I'm not that fond of child nodes? But for the dmamux,
    it looks like a good solution to handle this.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v8 0/9] RZN1 DMA support

[Miquel Raynal]

Hi Geert,

geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:37:22 +0200:

> Hi Miquel,
> 
> On Tue, Apr 12, 2022 at 9:32 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > geert@linux-m68k.org wrote on Mon, 11 Apr 2022 17:09:50 +0200:  
> > > On Thu, Apr 7, 2022 at 10:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700:  
> > > > > Quoting Miquel Raynal (2022-04-06 09:18:47)  
> > > > > > Here is a first series bringing DMA support to RZN1 platforms. Soon a
> > > > > > second series will come with changes made to the UART controller
> > > > > > driver, in order to interact with the RZN1 DMA controller.
> > > > > >
> > > > > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel
> > > > > > like it would be good to have this patch applied on both sides
> > > > > > (dmaengine and clk) because more changes will depend on the addition of
> > > > > > this helper, that are not related to DMA at all. I'll let you folks
> > > > > > figure out what is best.  
> > > > >
> > > > > Are you sending more patches in the next 7 weeks or so that will touch
> > > > > the same area? If so, then it sounds like I'll need to take the clk
> > > > > patch through clk tree. I don't know what is best because I don't have
> > > > > the information about what everyone plans to do in that file.  
> > > >
> > > > This series brings DMA support and needs to access the dmamux registers
> > > > that are in the sysctrl area.
> > > >
> > > > I've sent an RTC series which needs to access this area as well, but
> > > > it is not fully ready yet as it was advised to go for a reset
> > > > controller in this case. The reset controller would be registered by
> > > > the clock driver, so yes it would touch the same file.
> > > >
> > > > Finally, there is an USB series that is coming soon, I don't know if
> > > > it will be ready for merge for 5.19, but it needs to access a specific
> > > > register in this area as well (h2mode).
> > > >
> > > > So provided that we are able to contribute this reset driver quickly
> > > > enough, I would argue that it is safer to merge the clk changes in the
> > > > clk tree.  
> > >
> > > The clk tree or the renesas-clk tree? ;-)  
> >
> > Actually I forgot about this tree, would you mind to merge *all* the
> > patches that depend on the sysctrl changes in the renesas/renesas-clk
> > tree? This also stands for the UART and RTC for instance. Otherwise
> > you'll need to set up immutable branches and share them with the
> > dmaengine, serial and rtc trees. I'm fine either way, it's just much
> > less work in the first situation IMHO.  
> 
> Sure, I can do that, given acks from the DMA, UART, and RTC
> maintainers.

Ok, I'll say so in the cover letter of the v9.

> So far I've been rather terse in giving feedback on these series,
> as I'm in wait-and-see mode w.r.t. what else you've planned for the
> sysctrl DT node[1] and clock/sys controller code...
> 
> [1] Did I say I'm not that fond of child nodes? But for the dmamux,
>     it looks like a good solution to handle this.

O:-)

I plan in the coming days to write a proper reset controller driver
that will be queried by the rtc driver (as proposed by Alexandre).
Which means I'll have to declare this reset controller as a child of
the systrl node. If you disagree with it, you may jump-in, see this
thread :

	Subject: Re: [PATCH 2/7] soc: renesas: rzn1-sysc: Export a
		 function to  enable/disable the RTC
	Date: Wed, 6 Apr 2022 10:32:31 +0200

Thanks,
Miquèl

Re: [PATCH v8 0/9] RZN1 DMA support

[Geert Uytterhoeven]

Hi Miquel,

On Tue, Apr 12, 2022 at 9:43 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:37:22 +0200:
> > On Tue, Apr 12, 2022 at 9:32 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > geert@linux-m68k.org wrote on Mon, 11 Apr 2022 17:09:50 +0200:
> > > > On Thu, Apr 7, 2022 at 10:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700:
> > > > > > Quoting Miquel Raynal (2022-04-06 09:18:47)
> > > > > > > Here is a first series bringing DMA support to RZN1 platforms. Soon a
> > > > > > > second series will come with changes made to the UART controller
> > > > > > > driver, in order to interact with the RZN1 DMA controller.
> > > > > > >
> > > > > > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel
> > > > > > > like it would be good to have this patch applied on both sides
> > > > > > > (dmaengine and clk) because more changes will depend on the addition of
> > > > > > > this helper, that are not related to DMA at all. I'll let you folks
> > > > > > > figure out what is best.
> > > > > >
> > > > > > Are you sending more patches in the next 7 weeks or so that will touch
> > > > > > the same area? If so, then it sounds like I'll need to take the clk
> > > > > > patch through clk tree. I don't know what is best because I don't have
> > > > > > the information about what everyone plans to do in that file.
> > > > >
> > > > > This series brings DMA support and needs to access the dmamux registers
> > > > > that are in the sysctrl area.
> > > > >
> > > > > I've sent an RTC series which needs to access this area as well, but
> > > > > it is not fully ready yet as it was advised to go for a reset
> > > > > controller in this case. The reset controller would be registered by
> > > > > the clock driver, so yes it would touch the same file.
> > > > >
> > > > > Finally, there is an USB series that is coming soon, I don't know if
> > > > > it will be ready for merge for 5.19, but it needs to access a specific
> > > > > register in this area as well (h2mode).
> > > > >
> > > > > So provided that we are able to contribute this reset driver quickly
> > > > > enough, I would argue that it is safer to merge the clk changes in the
> > > > > clk tree.
> > > >
> > > > The clk tree or the renesas-clk tree? ;-)
> > >
> > > Actually I forgot about this tree, would you mind to merge *all* the
> > > patches that depend on the sysctrl changes in the renesas/renesas-clk
> > > tree? This also stands for the UART and RTC for instance. Otherwise
> > > you'll need to set up immutable branches and share them with the
> > > dmaengine, serial and rtc trees. I'm fine either way, it's just much
> > > less work in the first situation IMHO.
> >
> > Sure, I can do that, given acks from the DMA, UART, and RTC
> > maintainers.
>
> Ok, I'll say so in the cover letter of the v9.
>
> > So far I've been rather terse in giving feedback on these series,
> > as I'm in wait-and-see mode w.r.t. what else you've planned for the
> > sysctrl DT node[1] and clock/sys controller code...
> >
> > [1] Did I say I'm not that fond of child nodes? But for the dmamux,
> >     it looks like a good solution to handle this.
>
> O:-)
>
> I plan in the coming days to write a proper reset controller driver
> that will be queried by the rtc driver (as proposed by Alexandre).

OK.

> Which means I'll have to declare this reset controller as a child of
> the systrl node. If you disagree with it, you may jump-in, see this
> thread :
>
>         Subject: Re: [PATCH 2/7] soc: renesas: rzn1-sysc: Export a
>                  function to  enable/disable the RTC
>         Date: Wed, 6 Apr 2022 10:32:31 +0200

But do you need a child node for that? All(most all) other Renesas
clock drivers provide reset functionality, and none of them use a
child node for that.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v8 0/9] RZN1 DMA support

[Miquel Raynal]

Hi Geert,

geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:52:25 +0200:

> Hi Miquel,
> 
> On Tue, Apr 12, 2022 at 9:43 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:37:22 +0200:  
> > > On Tue, Apr 12, 2022 at 9:32 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > geert@linux-m68k.org wrote on Mon, 11 Apr 2022 17:09:50 +0200:  
> > > > > On Thu, Apr 7, 2022 at 10:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > > > sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700:  
> > > > > > > Quoting Miquel Raynal (2022-04-06 09:18:47)  
> > > > > > > > Here is a first series bringing DMA support to RZN1 platforms. Soon a
> > > > > > > > second series will come with changes made to the UART controller
> > > > > > > > driver, in order to interact with the RZN1 DMA controller.
> > > > > > > >
> > > > > > > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel
> > > > > > > > like it would be good to have this patch applied on both sides
> > > > > > > > (dmaengine and clk) because more changes will depend on the addition of
> > > > > > > > this helper, that are not related to DMA at all. I'll let you folks
> > > > > > > > figure out what is best.  
> > > > > > >
> > > > > > > Are you sending more patches in the next 7 weeks or so that will touch
> > > > > > > the same area? If so, then it sounds like I'll need to take the clk
> > > > > > > patch through clk tree. I don't know what is best because I don't have
> > > > > > > the information about what everyone plans to do in that file.  
> > > > > >
> > > > > > This series brings DMA support and needs to access the dmamux registers
> > > > > > that are in the sysctrl area.
> > > > > >
> > > > > > I've sent an RTC series which needs to access this area as well, but
> > > > > > it is not fully ready yet as it was advised to go for a reset
> > > > > > controller in this case. The reset controller would be registered by
> > > > > > the clock driver, so yes it would touch the same file.
> > > > > >
> > > > > > Finally, there is an USB series that is coming soon, I don't know if
> > > > > > it will be ready for merge for 5.19, but it needs to access a specific
> > > > > > register in this area as well (h2mode).
> > > > > >
> > > > > > So provided that we are able to contribute this reset driver quickly
> > > > > > enough, I would argue that it is safer to merge the clk changes in the
> > > > > > clk tree.  
> > > > >
> > > > > The clk tree or the renesas-clk tree? ;-)  
> > > >
> > > > Actually I forgot about this tree, would you mind to merge *all* the
> > > > patches that depend on the sysctrl changes in the renesas/renesas-clk
> > > > tree? This also stands for the UART and RTC for instance. Otherwise
> > > > you'll need to set up immutable branches and share them with the
> > > > dmaengine, serial and rtc trees. I'm fine either way, it's just much
> > > > less work in the first situation IMHO.  
> > >
> > > Sure, I can do that, given acks from the DMA, UART, and RTC
> > > maintainers.  
> >
> > Ok, I'll say so in the cover letter of the v9.
> >  
> > > So far I've been rather terse in giving feedback on these series,
> > > as I'm in wait-and-see mode w.r.t. what else you've planned for the
> > > sysctrl DT node[1] and clock/sys controller code...
> > >
> > > [1] Did I say I'm not that fond of child nodes? But for the dmamux,
> > >     it looks like a good solution to handle this.  
> >
> > O:-)
> >
> > I plan in the coming days to write a proper reset controller driver
> > that will be queried by the rtc driver (as proposed by Alexandre).  
> 
> OK.
> 
> > Which means I'll have to declare this reset controller as a child of
> > the systrl node. If you disagree with it, you may jump-in, see this
> > thread :
> >
> >         Subject: Re: [PATCH 2/7] soc: renesas: rzn1-sysc: Export a
> >                  function to  enable/disable the RTC
> >         Date: Wed, 6 Apr 2022 10:32:31 +0200  
> 
> But do you need a child node for that? All(most all) other Renesas
> clock drivers provide reset functionality, and none of them use a
> child node for that.

How do you "request" the reset handle from the consumer driver if it's
not described in the DT? Do you have examples to share?

Thanks,
Miquèl

Re: [PATCH v8 0/9] RZN1 DMA support

[Geert Uytterhoeven]

Hi Miquel,

On Tue, Apr 12, 2022 at 10:03 AM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
> geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:52:25 +0200:
> > On Tue, Apr 12, 2022 at 9:43 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:37:22 +0200:
> > > > So far I've been rather terse in giving feedback on these series,
> > > > as I'm in wait-and-see mode w.r.t. what else you've planned for the
> > > > sysctrl DT node[1] and clock/sys controller code...
> > > >
> > > > [1] Did I say I'm not that fond of child nodes? But for the dmamux,
> > > >     it looks like a good solution to handle this.
> > >
> > > O:-)
> > >
> > > I plan in the coming days to write a proper reset controller driver
> > > that will be queried by the rtc driver (as proposed by Alexandre).
> >
> > OK.
> >
> > > Which means I'll have to declare this reset controller as a child of
> > > the systrl node. If you disagree with it, you may jump-in, see this
> > > thread :
> > >
> > >         Subject: Re: [PATCH 2/7] soc: renesas: rzn1-sysc: Export a
> > >                  function to  enable/disable the RTC
> > >         Date: Wed, 6 Apr 2022 10:32:31 +0200
> >
> > But do you need a child node for that? All(most all) other Renesas
> > clock drivers provide reset functionality, and none of them use a
> > child node for that.
>
> How do you "request" the reset handle from the consumer driver if it's
> not described in the DT? Do you have examples to share?

I didn't say it does not need to be described in DT ;-)

Just add "#reset-cells = <1>" to the sysctrl node, and nodes can
start referring to it using "resets = <&sysctrl N>".
Currently, the sysctrl node is already a clock and power-domain provider.

Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml
shows an R-Car CPG/MSSR node providing clock, power-domain, and
reset functionalities.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v8 0/9] RZN1 DMA support

[Miquel Raynal]

Hi Geert,

geert@linux-m68k.org wrote on Tue, 12 Apr 2022 10:12:41 +0200:

> Hi Miquel,
> 
> On Tue, Apr 12, 2022 at 10:03 AM Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
> > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:52:25 +0200:  
> > > On Tue, Apr 12, 2022 at 9:43 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:37:22 +0200:  
> > > > > So far I've been rather terse in giving feedback on these series,
> > > > > as I'm in wait-and-see mode w.r.t. what else you've planned for the
> > > > > sysctrl DT node[1] and clock/sys controller code...
> > > > >
> > > > > [1] Did I say I'm not that fond of child nodes? But for the dmamux,
> > > > >     it looks like a good solution to handle this.  
> > > >
> > > > O:-)
> > > >
> > > > I plan in the coming days to write a proper reset controller driver
> > > > that will be queried by the rtc driver (as proposed by Alexandre).  
> > >
> > > OK.
> > >  
> > > > Which means I'll have to declare this reset controller as a child of
> > > > the systrl node. If you disagree with it, you may jump-in, see this
> > > > thread :
> > > >
> > > >         Subject: Re: [PATCH 2/7] soc: renesas: rzn1-sysc: Export a
> > > >                  function to  enable/disable the RTC
> > > >         Date: Wed, 6 Apr 2022 10:32:31 +0200  
> > >
> > > But do you need a child node for that? All(most all) other Renesas
> > > clock drivers provide reset functionality, and none of them use a
> > > child node for that.  
> >
> > How do you "request" the reset handle from the consumer driver if it's
> > not described in the DT? Do you have examples to share?  
> 
> I didn't say it does not need to be described in DT ;-)
> 
> Just add "#reset-cells = <1>" to the sysctrl node, and nodes can
> start referring to it using "resets = <&sysctrl N>".
> Currently, the sysctrl node is already a clock and power-domain provider.
> 
> Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml
> shows an R-Car CPG/MSSR node providing clock, power-domain, and
> reset functionalities.

Ok, works for me ;)

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds


Thanks,
Miquèl

Re: [PATCH v8 5/9] dmaengine: dw: dmamux: Introduce RZN1 DMA router support

[Miquel Raynal]

Hi Vinod,


> > +static void rzn1_dmamux_free(struct device *dev, void *route_data)
> > +{
> > +	struct rzn1_dmamux_data *dmamux = dev_get_drvdata(dev);
> > +	struct rzn1_dmamux_map *map = route_data;
> > +
> > +	dev_dbg(dev, "Unmapping DMAMUX request %u\n", map->req_idx);
> > +
> > +	mutex_lock(&dmamux->lock);
> > +	dmamux->used_chans &= ~BIT(map->req_idx);
> > +	mutex_unlock(&dmamux->lock);  
> 
> Why not use idr or bitmap for this. Hint: former does locking as well

I've changed the code to use a proper bitmap.

> 
> > +
> > +	kfree(map);
> > +}
> > +
> > +static void *rzn1_dmamux_route_allocate(struct of_phandle_args *dma_spec,
> > +					struct of_dma *ofdma)
> > +{
> > +	struct platform_device *pdev = of_find_device_by_node(ofdma->of_node);
> > +	struct rzn1_dmamux_data *dmamux = platform_get_drvdata(pdev);
> > +	struct rzn1_dmamux_map *map;
> > +	unsigned int dmac_idx, chan, val;
> > +	u32 mask;
> > +	int ret;
> > +
> > +	if (dma_spec->args_count != 6)  
> 
> magic

Defined.

> 
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	map = kzalloc(sizeof(*map), GFP_KERNEL);
> > +	if (!map)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	chan = dma_spec->args[0];
> > +	map->req_idx = dma_spec->args[4];
> > +	val = dma_spec->args[5];
> > +	dma_spec->args_count -= 2;
> > +

[...]

> > +	dev_dbg(&pdev->dev, "Mapping DMAMUX request %u to DMAC%u request %u\n",
> > +		map->req_idx, dmac_idx, chan);
> > +
> > +	mask = BIT(map->req_idx);
> > +	mutex_lock(&dmamux->lock);
> > +	dmamux->used_chans |= mask;
> > +	ret = r9a06g032_sysctrl_set_dmamux(mask, val ? mask : 0);  
> 
> I guess due to this it would be merged by whosoever merges this api.
> Please mention this in cover letter and how you propose this should be
> merged

Yes, the cover letter mentions this issue, but since then Geert
proposed to take everything through the renesas trees, which I agree
with. I will send a v9 and if you agree with it please provide your Ack
so that Geert can take it.

Thanks,
Miquèl

Re: [PATCH v8 5/9] dmaengine: dw: dmamux: Introduce RZN1 DMA router support

[Miquel Raynal]

Hi Ilpo, Andy,

ilpo.jarvinen@linux.intel.com wrote on Fri, 8 Apr 2022 15:38:48 +0300
(EEST):

> On Fri, 8 Apr 2022, Andy Shevchenko wrote:
> 
> > On Fri, Apr 08, 2022 at 12:55:47PM +0300, Ilpo Järvinen wrote:  
> > > On Wed, 6 Apr 2022, Miquel Raynal wrote:
> > >   
> > > > The Renesas RZN1 DMA IP is based on a DW core, with eg. an additional
> > > > dmamux register located in the system control area which can take up to
> > > > 32 requests (16 per DMA controller). Each DMA channel can be wired to
> > > > two different peripherals.
> > > > 
> > > > We need two additional information from the 'dmas' property: the channel
> > > > (bit in the dmamux register) that must be accessed and the value of the
> > > > mux for this channel.  
> >   
> > > > +	mask = BIT(map->req_idx);
> > > > +	mutex_lock(&dmamux->lock);
> > > > +	dmamux->used_chans |= mask;
> > > > +	ret = r9a06g032_sysctrl_set_dmamux(mask, val ? mask : 0);
> > > > +	if (ret)
> > > > +		goto release_chan_and_unlock;
> > > > +
> > > > +	mutex_unlock(&dmamux->lock);
> > > > +
> > > > +	return map;
> > > > +
> > > > +release_chan_and_unlock:
> > > > +	dmamux->used_chans &= ~mask;  
> > > 
> > > Now that I check this again, I'm not sure why dmamux->used_chans |= mask; 
> > > couldn't be done after r9a06g032_sysctrl_set_dmamux() call so this 
> > > rollback of it wouldn't be necessary.  
> > 
> > I would still need the mutex unlock which I believe is down path there under
> > some other label. Hence you are proposing something like
> > 
> > 	mask = BIT(map->req_idx);
> > 
> > 	mutex_lock(&dmamux->lock);
> > 	ret = r9a06g032_sysctrl_set_dmamux(mask, val ? mask : 0);
> > 	if (ret)
> > 		goto err_unlock; // or whatever label is
> > 
> > 	dmamux->used_chans |= mask;
> > 	mutex_unlock(&dmamux->lock);
> > 
> > 	return map;
> > 
> > Is that correct? If so, I don't see impediments either.  
> 
> Yes, and yes, the mutex still has to be unlocked on that error path.
> 
> > > Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>  

I've done the modification, thanks for your feedback.

Thanks,
Miquèl

Re: [PATCH v8 0/9] RZN1 DMA support

[Miquel Raynal]

Hi Geert,

geert@linux-m68k.org wrote on Tue, 12 Apr 2022 10:12:41 +0200:

> Hi Miquel,
> 
> On Tue, Apr 12, 2022 at 10:03 AM Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
> > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:52:25 +0200:  
> > > On Tue, Apr 12, 2022 at 9:43 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:37:22 +0200:  
> > > > > So far I've been rather terse in giving feedback on these series,
> > > > > as I'm in wait-and-see mode w.r.t. what else you've planned for the
> > > > > sysctrl DT node[1] and clock/sys controller code...
> > > > >
> > > > > [1] Did I say I'm not that fond of child nodes? But for the dmamux,
> > > > >     it looks like a good solution to handle this.  
> > > >
> > > > O:-)
> > > >
> > > > I plan in the coming days to write a proper reset controller driver
> > > > that will be queried by the rtc driver (as proposed by Alexandre).  
> > >
> > > OK.
> > >  
> > > > Which means I'll have to declare this reset controller as a child of
> > > > the systrl node. If you disagree with it, you may jump-in, see this
> > > > thread :
> > > >
> > > >         Subject: Re: [PATCH 2/7] soc: renesas: rzn1-sysc: Export a
> > > >                  function to  enable/disable the RTC
> > > >         Date: Wed, 6 Apr 2022 10:32:31 +0200  
> > >
> > > But do you need a child node for that? All(most all) other Renesas
> > > clock drivers provide reset functionality, and none of them use a
> > > child node for that.  
> >
> > How do you "request" the reset handle from the consumer driver if it's
> > not described in the DT? Do you have examples to share?  
> 
> I didn't say it does not need to be described in DT ;-)
> 
> Just add "#reset-cells = <1>" to the sysctrl node, and nodes can
> start referring to it using "resets = <&sysctrl N>".
> Currently, the sysctrl node is already a clock and power-domain provider.
> 
> Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml
> shows an R-Car CPG/MSSR node providing clock, power-domain, and
> reset functionalities.

While working on implementing a reset controller driver, I realized
that almost all the clocks had a reset, which was already managed by the
driver as part of a number of additional possible signals (gate
reset, gate master idle, gate ready...). So I actually figured out
that my issue originated from an incomplete description of the RTC clock
gate, which I fulfilled. Now it works without the need for an additional
exported symbol.

Thanks,
Miquèl