[PATCH v2 0/2] Initial Renesas R-Car remoteproc support

[PATCH v2 0/2] Initial Renesas R-Car remoteproc support

[Julien Massot]

Most of the SoCs in the R-Car gen3 SoC series such as
H3,M3 and E3 have an 'Arm Realtime Core'.
This Realtime core is an Arm Cortex-R7 clocked at 800MHz.
This series adds initial support to load a firmware and start
this remote processor through the remoteproc subsystem.

This series depends on
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20211022122101.66998-1-julien.massot@iot.bzh/
to be able to set the Cortex-R7 boot address.

One of the way to test this driver is to use the zephyr upstream support
for h3ulcb board 'blinky' demo is my favorite testing firmware.

To generate a firmware with the zephyr project.

follow this starting guide
https://docs.zephyrproject.org/2.7.0/getting_started/index.html

Then compile your zephyr demo
west build -b rcar_h3ulcb_cr7 zephyr/samples/basic/blinky \
    -DCONFIG_KERNEL_ENTRY=\"_vector_table\" \
    --build-dir h3-blinky

Then you can use h3-blinky/zephyr/zephyr.elf as a testing
firmware.

Patch 1/2 adds the dt-bindings

Patch 2/2 is a small driver to cover basic remoteproc
usage: loading firmware from filesystem, starting and stopping the
Cortex-r7 processor.

Device tree modifications have been dropped in this patchset version.
Reason is that memory range used by the Cortex-R7 depends on
design choice.
One thing we could do in the future is to add CR7 node
in the different Gen3 SoCs dtsi files such as r8a77951.dtsi, r8a77990.dtsi,
r8a77961.dtsi.. 

Julien Massot (2):
  dt-bindings: remoteproc: Add Renesas R-Car
  remoteproc: Add Renesas rcar driver

 .../remoteproc/renesas,rcar-rproc.yaml        |  65 +++++
 drivers/remoteproc/Kconfig                    |  11 +
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/rcar_rproc.c               | 226 ++++++++++++++++++
 4 files changed, 303 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
 create mode 100644 drivers/remoteproc/rcar_rproc.c

-- 
2.33.1

[PATCH v2 1/2] dt-bindings: remoteproc: Add Renesas R-Car

[Julien Massot]

Renesas R-Car SoCs may contains a Realtime processor.
This patch adds binding for this remote processor.

Signed-off-by: Julien Massot <julien.massot@iot.bzh>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes since v1
- dropped 'status = "okay";' in the sample
- Add Rob's Reviewed-by tag

---
 .../remoteproc/renesas,rcar-rproc.yaml        | 65 +++++++++++++++++++
 1 file changed, 65 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml

diff --git a/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
new file mode 100644
index 000000000000..3fe8d49051e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/remoteproc/renesas,rcar-rproc.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Renesas R-Car remote processor controller bindings
+
+maintainers:
+  - Julien Massot <julien.massot@iot.bzh>
+
+description: |
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Renesas R-Car family chipset.
+  R-Car gen3 family may have a realtime processor, this processor share peripheral
+  and RAM with the host processor with the same address map.
+
+properties:
+  compatible:
+    const: renesas,rcar-cr7
+
+  resets:
+    maxItems: 1
+
+  power-domains:
+    maxItems: 1
+
+  memory-region:
+    description:
+      List of phandles to the reserved memory regions associated with the
+      remoteproc device. This is variable and describes the memories shared with
+      the remote processor (e.g. remoteproc firmware and carveouts, rpmsg
+      vrings, ...).
+      (see ../reserved-memory/reserved-memory.yaml)
+
+required:
+  - compatible
+  - resets
+  - memory-region
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/r8a7795-cpg-mssr.h>
+    #include <dt-bindings/power/r8a7795-sysc.h>
+    reserved-memory {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        cr7_ram: cr7_ram@40040000 {
+            no-map;
+            reg = <0x0 0x40040000 0x0 0x1fc0000>;
+        };
+    };
+
+    cr7_rproc: cr7 {
+        compatible = "renesas,rcar-cr7";
+        memory-region = <&cr7_ram>;
+        power-domains = <&sysc R8A7795_PD_CR7>;
+        resets = <&cpg 222>;
+    };
+
+...
-- 
2.33.1

Re: [PATCH v2 1/2] dt-bindings: remoteproc: Add Renesas R-Car

[Geert Uytterhoeven]

Hi Julien,

Thanks for your patch!

On Tue, Nov 30, 2021 at 11:01 AM Julien Massot <julien.massot@iot.bzh> wrote:
> Renesas R-Car SoCs may contains a Realtime processor.

contain

> This patch adds binding for this remote processor.

bindings

>
> Signed-off-by: Julien Massot <julien.massot@iot.bzh>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> Changes since v1
> - dropped 'status = "okay";' in the sample
> - Add Rob's Reviewed-by tag
>
> ---
>  .../remoteproc/renesas,rcar-rproc.yaml        | 65 +++++++++++++++++++
>  1 file changed, 65 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
> new file mode 100644
> index 000000000000..3fe8d49051e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
> @@ -0,0 +1,65 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/remoteproc/renesas,rcar-rproc.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Renesas R-Car remote processor controller bindings
> +
> +maintainers:
> +  - Julien Massot <julien.massot@iot.bzh>
> +
> +description: |
> +  This document defines the binding for the remoteproc component that loads and

bindings

> +  boots firmwares on the Renesas R-Car family chipset.
> +  R-Car gen3 family may have a realtime processor, this processor share peripheral

shares

> +  and RAM with the host processor with the same address map.
> +
> +properties:
> +  compatible:
> +    const: renesas,rcar-cr7
> +
> +  resets:
> +    maxItems: 1
> +
> +  power-domains:
> +    maxItems: 1
> +
> +  memory-region:
> +    description:
> +      List of phandles to the reserved memory regions associated with the
> +      remoteproc device. This is variable and describes the memories shared with
> +      the remote processor (e.g. remoteproc firmware and carveouts, rpmsg

carve-out

> +      vrings, ...).
> +      (see ../reserved-memory/reserved-memory.yaml)

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

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 v2 1/2] dt-bindings: remoteproc: Add Renesas R-Car

[Julien Massot]

Hi Geert,

On 12/2/21 14:22, Geert Uytterhoeven wrote:
> Hi Julien,
> 
> Thanks for your patch!
> 
> On Tue, Nov 30, 2021 at 11:01 AM Julien Massot <julien.massot@iot.bzh> wrote:
>> Renesas R-Car SoCs may contains a Realtime processor.
> 
> contain
> 
>> This patch adds binding for this remote processor.
> 
> bindings
> 
>>
>> Signed-off-by: Julien Massot <julien.massot@iot.bzh>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>> ---
>> Changes since v1
>> - dropped 'status = "okay";' in the sample
>> - Add Rob's Reviewed-by tag
>>
>> ---
>>   .../remoteproc/renesas,rcar-rproc.yaml        | 65 +++++++++++++++++++
>>   1 file changed, 65 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
>> new file mode 100644
>> index 000000000000..3fe8d49051e6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
>> @@ -0,0 +1,65 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: "http://devicetree.org/schemas/remoteproc/renesas,rcar-rproc.yaml#"
>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
>> +
>> +title: Renesas R-Car remote processor controller bindings
>> +
>> +maintainers:
>> +  - Julien Massot <julien.massot@iot.bzh>
>> +
>> +description: |
>> +  This document defines the binding for the remoteproc component that loads and
> 
> bindings
> 
>> +  boots firmwares on the Renesas R-Car family chipset.
>> +  R-Car gen3 family may have a realtime processor, this processor share peripheral
> 
> shares
> 
>> +  and RAM with the host processor with the same address map.
>> +
>> +properties:
>> +  compatible:
>> +    const: renesas,rcar-cr7
>> +
>> +  resets:
>> +    maxItems: 1
>> +
>> +  power-domains:
>> +    maxItems: 1
>> +
>> +  memory-region:
>> +    description:
>> +      List of phandles to the reserved memory regions associated with the
>> +      remoteproc device. This is variable and describes the memories shared with
>> +      the remote processor (e.g. remoteproc firmware and carveouts, rpmsg
Thanks for fixing all these english mistakes.
Will resend this patch soon.

> 
> carve-out

Will keep 'carveouts' since this term is intensively used in the remoteproc core.

> 
>> +      vrings, ...).
>> +      (see ../reserved-memory/reserved-memory.yaml)
> 
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Regards,

-- 
Julien Massot [IoT.bzh]

[PATCH v2 2/2] remoteproc: Add Renesas rcar driver

[Julien Massot]

Renesas Gen3 platform includes a Cortex-r7 processor.

Both: the application cores (A5x) and the realtime core (CR7)
share access to the RAM and devices with the same address map,
so device addresses are equal to the Linux physical addresses.

In order to initialize this remote processor we need to:
- power on the realtime core
- put the firmware in a ram area
- set the boot address for this firmware (reset vector)
- Deassert the reset

This initial driver allows to start and stop the Cortex R7
processor.

Signed-off-by: Julien Massot <julien.massot@iot.bzh>
---
Change since v1:
- use "%zx" printf specifier for size_t
- drop depends on REMOTEPROC in Kconfig file

---
 drivers/remoteproc/Kconfig      |  11 ++
 drivers/remoteproc/Makefile     |   1 +
 drivers/remoteproc/rcar_rproc.c | 226 ++++++++++++++++++++++++++++++++
 3 files changed, 238 insertions(+)
 create mode 100644 drivers/remoteproc/rcar_rproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index f2e961f998ca..10cde1f9dbe0 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -283,6 +283,17 @@ config QCOM_WCNSS_PIL
 	  verified and booted with the help of the Peripheral Authentication
 	  System (PAS) in TrustZone.
 
+config RCAR_REMOTEPROC
+	tristate "Renesas R-CAR Gen3 remoteproc support"
+	depends on ARCH_RENESAS
+	help
+	  Say y here to support R-Car realtime processor via the
+	  remote processor framework. An elf firmware can be loaded
+	  thanks to sysfs remoteproc entries. The remote processor
+	  can be started and stopped.
+	  This can be either built-in or a loadable module.
+	  If compiled as module (M), the module name is rcar_rproc.
+
 config ST_REMOTEPROC
 	tristate "ST remoteproc support"
 	depends on ARCH_STI
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 0ac256b6c977..5478c7cb9e07 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_QCOM_SYSMON)		+= qcom_sysmon.o
 obj-$(CONFIG_QCOM_WCNSS_PIL)		+= qcom_wcnss_pil.o
 qcom_wcnss_pil-y			+= qcom_wcnss.o
 qcom_wcnss_pil-y			+= qcom_wcnss_iris.o
+obj-$(CONFIG_RCAR_REMOTEPROC)		+= rcar_rproc.o
 obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
 obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
 obj-$(CONFIG_STM32_RPROC)		+= stm32_rproc.o
diff --git a/drivers/remoteproc/rcar_rproc.c b/drivers/remoteproc/rcar_rproc.c
new file mode 100644
index 000000000000..d01bbca41697
--- /dev/null
+++ b/drivers/remoteproc/rcar_rproc.c
@@ -0,0 +1,226 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) IoT.bzh 2021
+ */
+
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/pm_runtime.h>
+#include <linux/remoteproc.h>
+#include <linux/reset.h>
+#include <linux/soc/renesas/rcar-rst.h>
+
+#include "remoteproc_internal.h"
+
+struct rcar_rproc {
+	struct reset_control *rst;
+};
+
+static int rcar_rproc_mem_alloc(struct rproc *rproc,
+				 struct rproc_mem_entry *mem)
+{
+	struct device *dev = &rproc->dev;
+	void *va;
+
+	dev_dbg(dev, "map memory: %pa+%zx\n", &mem->dma, mem->len);
+	va = ioremap_wc(mem->dma, mem->len);
+	if (IS_ERR_OR_NULL(va)) {
+		dev_err(dev, "Unable to map memory region: %pa+%zx\n",
+			&mem->dma, mem->len);
+		return -ENOMEM;
+	}
+
+	/* Update memory entry va */
+	mem->va = va;
+
+	return 0;
+}
+
+static int rcar_rproc_mem_release(struct rproc *rproc,
+				   struct rproc_mem_entry *mem)
+{
+	dev_dbg(&rproc->dev, "unmap memory: %pa\n", &mem->dma);
+	iounmap(mem->va);
+
+	return 0;
+}
+
+static int rcar_rproc_prepare(struct rproc *rproc)
+{
+	struct device *dev = rproc->dev.parent;
+	struct device_node *np = dev->of_node;
+	struct of_phandle_iterator it;
+	struct rproc_mem_entry *mem;
+	struct reserved_mem *rmem;
+	u64 da;
+
+	/* Register associated reserved memory regions */
+	of_phandle_iterator_init(&it, np, "memory-region", NULL, 0);
+	while (of_phandle_iterator_next(&it) == 0) {
+
+		rmem = of_reserved_mem_lookup(it.node);
+		if (!rmem) {
+			dev_err(&rproc->dev,
+				"unable to acquire memory-region\n");
+			return -EINVAL;
+		}
+
+		/* No need to translate pa to da, R-Car use same map */
+		da = rmem->base;
+
+		mem = rproc_mem_entry_init(dev, NULL,
+					   (dma_addr_t)rmem->base,
+					   rmem->size, da,
+					   rcar_rproc_mem_alloc,
+					   rcar_rproc_mem_release,
+					   it.node->name);
+
+		if (!mem)
+			return -ENOMEM;
+
+		rproc_add_carveout(rproc, mem);
+	}
+
+	return 0;
+}
+
+static int rcar_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
+{
+	int ret;
+
+	ret = rproc_elf_load_rsc_table(rproc, fw);
+	if (ret)
+		dev_info(&rproc->dev, "No resource table in elf\n");
+
+	return 0;
+}
+
+static int rcar_rproc_start(struct rproc *rproc)
+{
+	struct rcar_rproc *priv = rproc->priv;
+	int err;
+
+	if (!rproc->bootaddr)
+		return -EINVAL;
+
+	err = rcar_rst_set_rproc_boot_addr(rproc->bootaddr);
+	if (err) {
+		dev_err(&rproc->dev, "failed to set rproc boot addr\n");
+		return err;
+	}
+
+	err = reset_control_deassert(priv->rst);
+	if (err)
+		dev_err(&rproc->dev, "failed to deassert reset\n");
+
+	return err;
+}
+
+static int rcar_rproc_stop(struct rproc *rproc)
+{
+	struct rcar_rproc *priv = rproc->priv;
+	int err;
+
+	err = reset_control_assert(priv->rst);
+	if (err)
+		dev_err(&rproc->dev, "failed to assert reset\n");
+
+	return err;
+}
+
+static struct rproc_ops rcar_rproc_ops = {
+	.prepare	= rcar_rproc_prepare,
+	.start		= rcar_rproc_start,
+	.stop		= rcar_rproc_stop,
+	.load		= rproc_elf_load_segments,
+	.parse_fw	= rcar_rproc_parse_fw,
+	.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
+	.sanity_check	= rproc_elf_sanity_check,
+	.get_boot_addr	= rproc_elf_get_boot_addr,
+
+};
+
+static int rcar_rproc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct rcar_rproc *priv;
+	struct rproc *rproc;
+	int ret;
+
+	rproc = rproc_alloc(dev, np->name, &rcar_rproc_ops,
+			    NULL, sizeof(*priv));
+	if (!rproc)
+		return -ENOMEM;
+
+	priv = rproc->priv;
+
+	priv->rst = devm_reset_control_get_exclusive(dev, NULL);
+	if (IS_ERR(priv->rst)) {
+		ret = PTR_ERR(priv->rst);
+		dev_err(dev, "fail to acquire rproc reset\n");
+		goto free_rproc;
+	}
+
+	pm_runtime_enable(dev);
+	ret = pm_runtime_get_sync(dev);
+	if (ret) {
+		dev_err(dev, "failed to power up\n");
+		goto free_rproc;
+	}
+
+	dev_set_drvdata(dev, rproc);
+
+	/* Manually start the rproc */
+	rproc->auto_boot = false;
+
+	ret = rproc_add(rproc);
+	if (ret) {
+		dev_err(dev, "rproc_add failed\n");
+		goto pm_disable;
+	}
+
+	return 0;
+
+pm_disable:
+	pm_runtime_disable(dev);
+free_rproc:
+	rproc_free(rproc);
+
+	return ret;
+}
+
+static int rcar_rproc_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct rproc *rproc = platform_get_drvdata(pdev);
+
+	rproc_del(rproc);
+	pm_runtime_disable(dev);
+	rproc_free(rproc);
+
+	return 0;
+}
+
+static const struct of_device_id rcar_rproc_of_match[] = {
+	{ .compatible = "renesas,rcar-cr7" },
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, rcar_rproc_of_match);
+
+static struct platform_driver rcar_rproc_driver = {
+	.probe = rcar_rproc_probe,
+	.remove = rcar_rproc_remove,
+	.driver = {
+		.name = "rcar-rproc",
+		.of_match_table = rcar_rproc_of_match,
+	},
+};
+
+module_platform_driver(rcar_rproc_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Renesas Gen3 R-Car remote processor control driver");
+MODULE_AUTHOR("Julien Massot <julien.massot@iot.bzh>");
-- 
2.33.1

Re: [PATCH v2 2/2] remoteproc: Add Renesas rcar driver

[Mathieu Poirier]

On Tue, Nov 30, 2021 at 11:00:49AM +0100, Julien Massot wrote:
> Renesas Gen3 platform includes a Cortex-r7 processor.
> 
> Both: the application cores (A5x) and the realtime core (CR7)
> share access to the RAM and devices with the same address map,
> so device addresses are equal to the Linux physical addresses.
> 
> In order to initialize this remote processor we need to:
> - power on the realtime core
> - put the firmware in a ram area
> - set the boot address for this firmware (reset vector)
> - Deassert the reset
> 
> This initial driver allows to start and stop the Cortex R7
> processor.
> 
> Signed-off-by: Julien Massot <julien.massot@iot.bzh>
> ---
> Change since v1:
> - use "%zx" printf specifier for size_t
> - drop depends on REMOTEPROC in Kconfig file
> 
> ---
>  drivers/remoteproc/Kconfig      |  11 ++
>  drivers/remoteproc/Makefile     |   1 +
>  drivers/remoteproc/rcar_rproc.c | 226 ++++++++++++++++++++++++++++++++
>  3 files changed, 238 insertions(+)
>  create mode 100644 drivers/remoteproc/rcar_rproc.c

Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>

> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index f2e961f998ca..10cde1f9dbe0 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -283,6 +283,17 @@ config QCOM_WCNSS_PIL
>  	  verified and booted with the help of the Peripheral Authentication
>  	  System (PAS) in TrustZone.
>  
> +config RCAR_REMOTEPROC
> +	tristate "Renesas R-CAR Gen3 remoteproc support"
> +	depends on ARCH_RENESAS
> +	help
> +	  Say y here to support R-Car realtime processor via the
> +	  remote processor framework. An elf firmware can be loaded
> +	  thanks to sysfs remoteproc entries. The remote processor
> +	  can be started and stopped.
> +	  This can be either built-in or a loadable module.
> +	  If compiled as module (M), the module name is rcar_rproc.
> +
>  config ST_REMOTEPROC
>  	tristate "ST remoteproc support"
>  	depends on ARCH_STI
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 0ac256b6c977..5478c7cb9e07 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -32,6 +32,7 @@ obj-$(CONFIG_QCOM_SYSMON)		+= qcom_sysmon.o
>  obj-$(CONFIG_QCOM_WCNSS_PIL)		+= qcom_wcnss_pil.o
>  qcom_wcnss_pil-y			+= qcom_wcnss.o
>  qcom_wcnss_pil-y			+= qcom_wcnss_iris.o
> +obj-$(CONFIG_RCAR_REMOTEPROC)		+= rcar_rproc.o
>  obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
>  obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
>  obj-$(CONFIG_STM32_RPROC)		+= stm32_rproc.o
> diff --git a/drivers/remoteproc/rcar_rproc.c b/drivers/remoteproc/rcar_rproc.c
> new file mode 100644
> index 000000000000..d01bbca41697
> --- /dev/null
> +++ b/drivers/remoteproc/rcar_rproc.c
> @@ -0,0 +1,226 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) IoT.bzh 2021
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/remoteproc.h>
> +#include <linux/reset.h>
> +#include <linux/soc/renesas/rcar-rst.h>
> +
> +#include "remoteproc_internal.h"
> +
> +struct rcar_rproc {
> +	struct reset_control *rst;
> +};
> +
> +static int rcar_rproc_mem_alloc(struct rproc *rproc,
> +				 struct rproc_mem_entry *mem)
> +{
> +	struct device *dev = &rproc->dev;
> +	void *va;
> +
> +	dev_dbg(dev, "map memory: %pa+%zx\n", &mem->dma, mem->len);
> +	va = ioremap_wc(mem->dma, mem->len);
> +	if (IS_ERR_OR_NULL(va)) {
> +		dev_err(dev, "Unable to map memory region: %pa+%zx\n",
> +			&mem->dma, mem->len);
> +		return -ENOMEM;
> +	}
> +
> +	/* Update memory entry va */
> +	mem->va = va;
> +
> +	return 0;
> +}
> +
> +static int rcar_rproc_mem_release(struct rproc *rproc,
> +				   struct rproc_mem_entry *mem)
> +{
> +	dev_dbg(&rproc->dev, "unmap memory: %pa\n", &mem->dma);
> +	iounmap(mem->va);
> +
> +	return 0;
> +}
> +
> +static int rcar_rproc_prepare(struct rproc *rproc)
> +{
> +	struct device *dev = rproc->dev.parent;
> +	struct device_node *np = dev->of_node;
> +	struct of_phandle_iterator it;
> +	struct rproc_mem_entry *mem;
> +	struct reserved_mem *rmem;
> +	u64 da;
> +
> +	/* Register associated reserved memory regions */
> +	of_phandle_iterator_init(&it, np, "memory-region", NULL, 0);
> +	while (of_phandle_iterator_next(&it) == 0) {
> +
> +		rmem = of_reserved_mem_lookup(it.node);
> +		if (!rmem) {
> +			dev_err(&rproc->dev,
> +				"unable to acquire memory-region\n");
> +			return -EINVAL;
> +		}
> +
> +		/* No need to translate pa to da, R-Car use same map */
> +		da = rmem->base;
> +
> +		mem = rproc_mem_entry_init(dev, NULL,
> +					   (dma_addr_t)rmem->base,
> +					   rmem->size, da,
> +					   rcar_rproc_mem_alloc,
> +					   rcar_rproc_mem_release,
> +					   it.node->name);
> +
> +		if (!mem)
> +			return -ENOMEM;
> +
> +		rproc_add_carveout(rproc, mem);
> +	}
> +
> +	return 0;
> +}
> +
> +static int rcar_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
> +{
> +	int ret;
> +
> +	ret = rproc_elf_load_rsc_table(rproc, fw);
> +	if (ret)
> +		dev_info(&rproc->dev, "No resource table in elf\n");
> +
> +	return 0;
> +}
> +
> +static int rcar_rproc_start(struct rproc *rproc)
> +{
> +	struct rcar_rproc *priv = rproc->priv;
> +	int err;
> +
> +	if (!rproc->bootaddr)
> +		return -EINVAL;
> +
> +	err = rcar_rst_set_rproc_boot_addr(rproc->bootaddr);
> +	if (err) {
> +		dev_err(&rproc->dev, "failed to set rproc boot addr\n");
> +		return err;
> +	}
> +
> +	err = reset_control_deassert(priv->rst);
> +	if (err)
> +		dev_err(&rproc->dev, "failed to deassert reset\n");
> +
> +	return err;
> +}
> +
> +static int rcar_rproc_stop(struct rproc *rproc)
> +{
> +	struct rcar_rproc *priv = rproc->priv;
> +	int err;
> +
> +	err = reset_control_assert(priv->rst);
> +	if (err)
> +		dev_err(&rproc->dev, "failed to assert reset\n");
> +
> +	return err;
> +}
> +
> +static struct rproc_ops rcar_rproc_ops = {
> +	.prepare	= rcar_rproc_prepare,
> +	.start		= rcar_rproc_start,
> +	.stop		= rcar_rproc_stop,
> +	.load		= rproc_elf_load_segments,
> +	.parse_fw	= rcar_rproc_parse_fw,
> +	.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
> +	.sanity_check	= rproc_elf_sanity_check,
> +	.get_boot_addr	= rproc_elf_get_boot_addr,
> +
> +};
> +
> +static int rcar_rproc_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device_node *np = dev->of_node;
> +	struct rcar_rproc *priv;
> +	struct rproc *rproc;
> +	int ret;
> +
> +	rproc = rproc_alloc(dev, np->name, &rcar_rproc_ops,
> +			    NULL, sizeof(*priv));
> +	if (!rproc)
> +		return -ENOMEM;
> +
> +	priv = rproc->priv;
> +
> +	priv->rst = devm_reset_control_get_exclusive(dev, NULL);
> +	if (IS_ERR(priv->rst)) {
> +		ret = PTR_ERR(priv->rst);
> +		dev_err(dev, "fail to acquire rproc reset\n");
> +		goto free_rproc;
> +	}
> +
> +	pm_runtime_enable(dev);
> +	ret = pm_runtime_get_sync(dev);
> +	if (ret) {
> +		dev_err(dev, "failed to power up\n");
> +		goto free_rproc;
> +	}
> +
> +	dev_set_drvdata(dev, rproc);
> +
> +	/* Manually start the rproc */
> +	rproc->auto_boot = false;
> +
> +	ret = rproc_add(rproc);
> +	if (ret) {
> +		dev_err(dev, "rproc_add failed\n");
> +		goto pm_disable;
> +	}
> +
> +	return 0;
> +
> +pm_disable:
> +	pm_runtime_disable(dev);
> +free_rproc:
> +	rproc_free(rproc);
> +
> +	return ret;
> +}
> +
> +static int rcar_rproc_remove(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct rproc *rproc = platform_get_drvdata(pdev);
> +
> +	rproc_del(rproc);
> +	pm_runtime_disable(dev);
> +	rproc_free(rproc);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id rcar_rproc_of_match[] = {
> +	{ .compatible = "renesas,rcar-cr7" },
> +	{},
> +};
> +
> +MODULE_DEVICE_TABLE(of, rcar_rproc_of_match);
> +
> +static struct platform_driver rcar_rproc_driver = {
> +	.probe = rcar_rproc_probe,
> +	.remove = rcar_rproc_remove,
> +	.driver = {
> +		.name = "rcar-rproc",
> +		.of_match_table = rcar_rproc_of_match,
> +	},
> +};
> +
> +module_platform_driver(rcar_rproc_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Renesas Gen3 R-Car remote processor control driver");
> +MODULE_AUTHOR("Julien Massot <julien.massot@iot.bzh>");
> -- 
> 2.33.1
> 
> 

Re: [PATCH v2 2/2] remoteproc: Add Renesas rcar driver

[Geert Uytterhoeven]

Hi Julien,

Thanks for your patch!

On Tue, Nov 30, 2021 at 11:01 AM Julien Massot <julien.massot@iot.bzh> wrote:
> Renesas Gen3 platform includes a Cortex-r7 processor.
>
> Both: the application cores (A5x) and the realtime core (CR7)
> share access to the RAM and devices with the same address map,
> so device addresses are equal to the Linux physical addresses.
>
> In order to initialize this remote processor we need to:
> - power on the realtime core
> - put the firmware in a ram area

RAM

> - set the boot address for this firmware (reset vector)
> - Deassert the reset
>
> This initial driver allows to start and stop the Cortex R7
> processor.
>
> Signed-off-by: Julien Massot <julien.massot@iot.bzh>

> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -283,6 +283,17 @@ config QCOM_WCNSS_PIL
>           verified and booted with the help of the Peripheral Authentication
>           System (PAS) in TrustZone.
>
> +config RCAR_REMOTEPROC
> +       tristate "Renesas R-CAR Gen3 remoteproc support"

R-Car

> +       depends on ARCH_RENESAS

|| COMPILE_TEST?

> +       help
> +         Say y here to support R-Car realtime processor via the
> +         remote processor framework. An elf firmware can be loaded

ELF

> +         thanks to sysfs remoteproc entries. The remote processor
> +         can be started and stopped.
> +         This can be either built-in or a loadable module.
> +         If compiled as module (M), the module name is rcar_rproc.
> +
>  config ST_REMOTEPROC
>         tristate "ST remoteproc support"
>         depends on ARCH_STI

> --- /dev/null
> +++ b/drivers/remoteproc/rcar_rproc.c

> +static int rcar_rproc_mem_alloc(struct rproc *rproc,
> +                                struct rproc_mem_entry *mem)
> +{
> +       struct device *dev = &rproc->dev;
> +       void *va;
> +
> +       dev_dbg(dev, "map memory: %pa+%zx\n", &mem->dma, mem->len);
> +       va = ioremap_wc(mem->dma, mem->len);
> +       if (IS_ERR_OR_NULL(va)) {

I think ioremap_*() never returns an error code, only NULL for failure.

> +               dev_err(dev, "Unable to map memory region: %pa+%zx\n",
> +                       &mem->dma, mem->len);
> +               return -ENOMEM;
> +       }
> +
> +       /* Update memory entry va */
> +       mem->va = va;
> +
> +       return 0;
> +}

> +static int rcar_rproc_prepare(struct rproc *rproc)
> +{
> +       struct device *dev = rproc->dev.parent;
> +       struct device_node *np = dev->of_node;
> +       struct of_phandle_iterator it;
> +       struct rproc_mem_entry *mem;
> +       struct reserved_mem *rmem;
> +       u64 da;
> +
> +       /* Register associated reserved memory regions */
> +       of_phandle_iterator_init(&it, np, "memory-region", NULL, 0);
> +       while (of_phandle_iterator_next(&it) == 0) {
> +
> +               rmem = of_reserved_mem_lookup(it.node);
> +               if (!rmem) {
> +                       dev_err(&rproc->dev,
> +                               "unable to acquire memory-region\n");
> +                       return -EINVAL;
> +               }
> +
> +               /* No need to translate pa to da, R-Car use same map */
> +               da = rmem->base;
> +
> +               mem = rproc_mem_entry_init(dev, NULL,
> +                                          (dma_addr_t)rmem->base,

Do you need this cast?

> +                                          rmem->size, da,

da is u64, and thus truncated to u32.

> +                                          rcar_rproc_mem_alloc,
> +                                          rcar_rproc_mem_release,
> +                                          it.node->name);
> +
> +               if (!mem)
> +                       return -ENOMEM;
> +
> +               rproc_add_carveout(rproc, mem);
> +       }
> +
> +       return 0;
> +}

> +static int rcar_rproc_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct device_node *np = dev->of_node;
> +       struct rcar_rproc *priv;
> +       struct rproc *rproc;
> +       int ret;
> +
> +       rproc = rproc_alloc(dev, np->name, &rcar_rproc_ops,
> +                           NULL, sizeof(*priv));

devm_rproc_alloc(), to simplify cleanup?

> +       if (!rproc)
> +               return -ENOMEM;
> +
> +       priv = rproc->priv;
> +
> +       priv->rst = devm_reset_control_get_exclusive(dev, NULL);
> +       if (IS_ERR(priv->rst)) {
> +               ret = PTR_ERR(priv->rst);
> +               dev_err(dev, "fail to acquire rproc reset\n");

dev_err_probe() (which handles -EPROBE_DEFER, too)

> +               goto free_rproc;
> +       }
> +
> +       pm_runtime_enable(dev);
> +       ret = pm_runtime_get_sync(dev);
> +       if (ret) {
> +               dev_err(dev, "failed to power up\n");
> +               goto free_rproc;
> +       }
> +
> +       dev_set_drvdata(dev, rproc);
> +
> +       /* Manually start the rproc */
> +       rproc->auto_boot = false;
> +
> +       ret = rproc_add(rproc);

devm_rproc_add()?

> +       if (ret) {
> +               dev_err(dev, "rproc_add failed\n");
> +               goto pm_disable;
> +       }
> +
> +       return 0;
> +
> +pm_disable:
> +       pm_runtime_disable(dev);
> +free_rproc:
> +       rproc_free(rproc);
> +
> +       return ret;
> +}

> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Renesas Gen3 R-Car remote processor control driver");

R-Car Gen3

> +MODULE_AUTHOR("Julien Massot <julien.massot@iot.bzh>");

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 v2 2/2] remoteproc: Add Renesas rcar driver

[Julien Massot]

Hi Geert,
Thanks for taking time to review my patch.

On 12/2/21 14:40, Geert Uytterhoeven wrote:
> Hi Julien,
> 
> Thanks for your patch!
> 
> On Tue, Nov 30, 2021 at 11:01 AM Julien Massot <julien.massot@iot.bzh> wrote:
>> Renesas Gen3 platform includes a Cortex-r7 processor.
>>
>> Both: the application cores (A5x) and the realtime core (CR7)
>> share access to the RAM and devices with the same address map,
>> so device addresses are equal to the Linux physical addresses.
>>
>> In order to initialize this remote processor we need to:
>> - power on the realtime core
>> - put the firmware in a ram area
> 
> RAM
fixed
> 
>> - set the boot address for this firmware (reset vector)
>> - Deassert the reset
>>
>> This initial driver allows to start and stop the Cortex R7
>> processor.
>>
>> Signed-off-by: Julien Massot <julien.massot@iot.bzh>
> 
>> --- a/drivers/remoteproc/Kconfig
>> +++ b/drivers/remoteproc/Kconfig
>> @@ -283,6 +283,17 @@ config QCOM_WCNSS_PIL
>>            verified and booted with the help of the Peripheral Authentication
>>            System (PAS) in TrustZone.
>>
>> +config RCAR_REMOTEPROC
>> +       tristate "Renesas R-CAR Gen3 remoteproc support"
> 
> R-Car
fixed
> 
>> +       depends on ARCH_RENESAS
> 
> || COMPILE_TEST?
COMPILE_TEST has been added to v3

> 
>> +       help
>> +         Say y here to support R-Car realtime processor via the
>> +         remote processor framework. An elf firmware can be loaded
> 
> ELF
ok
> 
>> +         thanks to sysfs remoteproc entries. The remote processor
>> +         can be started and stopped.
>> +         This can be either built-in or a loadable module.
>> +         If compiled as module (M), the module name is rcar_rproc.
>> +
>>   config ST_REMOTEPROC
>>          tristate "ST remoteproc support"
>>          depends on ARCH_STI
> 
>> --- /dev/null
>> +++ b/drivers/remoteproc/rcar_rproc.c
> 
>> +static int rcar_rproc_mem_alloc(struct rproc *rproc,
>> +                                struct rproc_mem_entry *mem)
>> +{
>> +       struct device *dev = &rproc->dev;
>> +       void *va;
>> +
>> +       dev_dbg(dev, "map memory: %pa+%zx\n", &mem->dma, mem->len);
>> +       va = ioremap_wc(mem->dma, mem->len);
>> +       if (IS_ERR_OR_NULL(va)) {
> 
> I think ioremap_*() never returns an error code, only NULL for failure.
Changed to check against NULL.
> 
>> +               dev_err(dev, "Unable to map memory region: %pa+%zx\n",
>> +                       &mem->dma, mem->len);
>> +               return -ENOMEM;
>> +       }
>> +
>> +       /* Update memory entry va */
>> +       mem->va = va;
>> +
>> +       return 0;
>> +}
> 
>> +static int rcar_rproc_prepare(struct rproc *rproc)
>> +{
>> +       struct device *dev = rproc->dev.parent;
>> +       struct device_node *np = dev->of_node;
>> +       struct of_phandle_iterator it;
>> +       struct rproc_mem_entry *mem;
>> +       struct reserved_mem *rmem;
>> +       u64 da;
>> +
>> +       /* Register associated reserved memory regions */
>> +       of_phandle_iterator_init(&it, np, "memory-region", NULL, 0);
>> +       while (of_phandle_iterator_next(&it) == 0) {
>> +
>> +               rmem = of_reserved_mem_lookup(it.node);
>> +               if (!rmem) {
>> +                       dev_err(&rproc->dev,
>> +                               "unable to acquire memory-region\n");
>> +                       return -EINVAL;
>> +               }
>> +
>> +               /* No need to translate pa to da, R-Car use same map */
>> +               da = rmem->base;
>> +
>> +               mem = rproc_mem_entry_init(dev, NULL,
>> +                                          (dma_addr_t)rmem->base,
> 
> Do you need this cast?
Looks like not. removed in v3

> 
>> +                                          rmem->size, da,
> 
> da is u64, and thus truncated to u32.
Ok thats indeed a limitation between the AP cores and the realtime core.
In v3 there is a check for bad input from device tree.

> 
>> +                                          rcar_rproc_mem_alloc,
>> +                                          rcar_rproc_mem_release,
>> +                                          it.node->name);
>> +
>> +               if (!mem)
>> +                       return -ENOMEM;
>> +
>> +               rproc_add_carveout(rproc, mem);
>> +       }
>> +
>> +       return 0;
>> +}
> 
>> +static int rcar_rproc_probe(struct platform_device *pdev)
>> +{
>> +       struct device *dev = &pdev->dev;
>> +       struct device_node *np = dev->of_node;
>> +       struct rcar_rproc *priv;
>> +       struct rproc *rproc;
>> +       int ret;
>> +
>> +       rproc = rproc_alloc(dev, np->name, &rcar_rproc_ops,
>> +                           NULL, sizeof(*priv));
> 
> devm_rproc_alloc(), to simplify cleanup?
Indeed devm_rproc_alloc is used in v3.
> 
>> +       if (!rproc)
>> +               return -ENOMEM;
>> +
>> +       priv = rproc->priv;
>> +
>> +       priv->rst = devm_reset_control_get_exclusive(dev, NULL);
>> +       if (IS_ERR(priv->rst)) {
>> +               ret = PTR_ERR(priv->rst);
>> +               dev_err(dev, "fail to acquire rproc reset\n");
> 
> dev_err_probe() (which handles -EPROBE_DEFER, too)
ok
> 
>> +               goto free_rproc;
>> +       }
>> +
>> +       pm_runtime_enable(dev);
>> +       ret = pm_runtime_get_sync(dev);
>> +       if (ret) {
>> +               dev_err(dev, "failed to power up\n");
>> +               goto free_rproc;
>> +       }
>> +
>> +       dev_set_drvdata(dev, rproc);
>> +
>> +       /* Manually start the rproc */
>> +       rproc->auto_boot = false;
>> +
>> +       ret = rproc_add(rproc);
> 
> devm_rproc_add()?
devm_rproc_add is now used in v3.

> 
>> +       if (ret) {
>> +               dev_err(dev, "rproc_add failed\n");
>> +               goto pm_disable;
>> +       }
>> +
>> +       return 0;
>> +
>> +pm_disable:
>> +       pm_runtime_disable(dev);
>> +free_rproc:
>> +       rproc_free(rproc);
>> +
>> +       return ret;
>> +}
> 
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("Renesas Gen3 R-Car remote processor control driver");
> 
> R-Car Gen3
Ok

All requested changes should be addressed in v3.

Regards,
-- 
Julien Massot [IoT.bzh]

Re: [PATCH v2 0/2] Initial Renesas R-Car remoteproc support

[Mathieu Poirier]

Good morning,

On Tue, Nov 30, 2021 at 11:00:47AM +0100, Julien Massot wrote:
> Most of the SoCs in the R-Car gen3 SoC series such as
> H3,M3 and E3 have an 'Arm Realtime Core'.
> This Realtime core is an Arm Cortex-R7 clocked at 800MHz.
> This series adds initial support to load a firmware and start
> this remote processor through the remoteproc subsystem.
> 
> This series depends on
> https://patchwork.kernel.org/project/linux-renesas-soc/patch/20211022122101.66998-1-julien.massot@iot.bzh/
> to be able to set the Cortex-R7 boot address.

The above depencency is needed for this patchset to compile properly.  Since
Geert has already applied it to his renesas-devel tree we can do two things:

1) Make this set go through Geert's tree.
2) Geert publishes an immutable branch I can pull the dependency from.

I'm good either way, just let me know what you want to do.

Thanks,
Mathieu

> 
> One of the way to test this driver is to use the zephyr upstream support
> for h3ulcb board 'blinky' demo is my favorite testing firmware.
> 
> To generate a firmware with the zephyr project.
> 
> follow this starting guide
> https://docs.zephyrproject.org/2.7.0/getting_started/index.html
> 
> Then compile your zephyr demo
> west build -b rcar_h3ulcb_cr7 zephyr/samples/basic/blinky \
>     -DCONFIG_KERNEL_ENTRY=\"_vector_table\" \
>     --build-dir h3-blinky
> 
> Then you can use h3-blinky/zephyr/zephyr.elf as a testing
> firmware.
> 
> Patch 1/2 adds the dt-bindings
> 
> Patch 2/2 is a small driver to cover basic remoteproc
> usage: loading firmware from filesystem, starting and stopping the
> Cortex-r7 processor.
> 
> Device tree modifications have been dropped in this patchset version.
> Reason is that memory range used by the Cortex-R7 depends on
> design choice.
> One thing we could do in the future is to add CR7 node
> in the different Gen3 SoCs dtsi files such as r8a77951.dtsi, r8a77990.dtsi,
> r8a77961.dtsi.. 
> 
> Julien Massot (2):
>   dt-bindings: remoteproc: Add Renesas R-Car
>   remoteproc: Add Renesas rcar driver
> 
>  .../remoteproc/renesas,rcar-rproc.yaml        |  65 +++++
>  drivers/remoteproc/Kconfig                    |  11 +
>  drivers/remoteproc/Makefile                   |   1 +
>  drivers/remoteproc/rcar_rproc.c               | 226 ++++++++++++++++++
>  4 files changed, 303 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
>  create mode 100644 drivers/remoteproc/rcar_rproc.c
> 
> -- 
> 2.33.1
> 
> 

Re: [PATCH v2 0/2] Initial Renesas R-Car remoteproc support

[Julien Massot]

Hi Geert, Mathieu,

On 12/1/21 17:46, Mathieu Poirier wrote:
> Good morning,
> 
> On Tue, Nov 30, 2021 at 11:00:47AM +0100, Julien Massot wrote:
>> Most of the SoCs in the R-Car gen3 SoC series such as
>> H3,M3 and E3 have an 'Arm Realtime Core'.
>> This Realtime core is an Arm Cortex-R7 clocked at 800MHz.
>> This series adds initial support to load a firmware and start
>> this remote processor through the remoteproc subsystem.
>>
>> This series depends on
>> https://patchwork.kernel.org/project/linux-renesas-soc/patch/20211022122101.66998-1-julien.massot@iot.bzh/
>> to be able to set the Cortex-R7 boot address.
> 
> The above depencency is needed for this patchset to compile properly.  Since
> Geert has already applied it to his renesas-devel tree we can do two things:
> 
> 1) Make this set go through Geert's tree.
> 2) Geert publishes an immutable branch I can pull the dependency from.
> 
> I'm good either way, just let me know what you want to do.
Geert, since you already have the required patch in your tree, it could make sense
if you handle this patchset too ?
Up to your choice.

Regards,

-- 
Julien Massot [IoT.bzh]

Re: [PATCH v2 0/2] Initial Renesas R-Car remoteproc support

[Geert Uytterhoeven]

Hi Mathieu,

On Wed, Dec 1, 2021 at 5:46 PM Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
> On Tue, Nov 30, 2021 at 11:00:47AM +0100, Julien Massot wrote:
> > Most of the SoCs in the R-Car gen3 SoC series such as
> > H3,M3 and E3 have an 'Arm Realtime Core'.
> > This Realtime core is an Arm Cortex-R7 clocked at 800MHz.
> > This series adds initial support to load a firmware and start
> > this remote processor through the remoteproc subsystem.
> >
> > This series depends on
> > https://patchwork.kernel.org/project/linux-renesas-soc/patch/20211022122101.66998-1-julien.massot@iot.bzh/
> > to be able to set the Cortex-R7 boot address.
>
> The above depencency is needed for this patchset to compile properly.  Since
> Geert has already applied it to his renesas-devel tree we can do two things:
>
> 1) Make this set go through Geert's tree.
> 2) Geert publishes an immutable branch I can pull the dependency from.
>
> I'm good either way, just let me know what you want to do.

I prefer you to handle the remoteproc parts.
Please find a pull request for the immutable branch below.
Thanks!

The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:

  Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git
tags/rcar_rst_rproc-tag1

for you to fetch changes up to 4c7924fb905b02323ff6d9d20f370892615dccfa:

  soc: renesas: rcar-rst: Add support to set rproc boot address
(2021-11-15 10:01:10 +0100)

----------------------------------------------------------------
Renesas R-Car Reset Controller remoteproc API

Definition of rcar_rst_set_rproc_boot_addr(), to be consumed by the
Renesas R-Car Gen3 remote processor driver.

----------------------------------------------------------------
Julien Massot (1):
      soc: renesas: rcar-rst: Add support to set rproc boot address

 drivers/soc/renesas/rcar-rst.c       | 43 +++++++++++++++++++++++++++++++++---
 include/linux/soc/renesas/rcar-rst.h |  2 ++
 2 files changed, 42 insertions(+), 3 deletions(-)

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 v2 0/2] Initial Renesas R-Car remoteproc support

[Mathieu Poirier]

On Thu, Dec 02, 2021 at 02:41:57PM +0100, Geert Uytterhoeven wrote:
> Hi Mathieu,
> 
> On Wed, Dec 1, 2021 at 5:46 PM Mathieu Poirier
> <mathieu.poirier@linaro.org> wrote:
> > On Tue, Nov 30, 2021 at 11:00:47AM +0100, Julien Massot wrote:
> > > Most of the SoCs in the R-Car gen3 SoC series such as
> > > H3,M3 and E3 have an 'Arm Realtime Core'.
> > > This Realtime core is an Arm Cortex-R7 clocked at 800MHz.
> > > This series adds initial support to load a firmware and start
> > > this remote processor through the remoteproc subsystem.
> > >
> > > This series depends on
> > > https://patchwork.kernel.org/project/linux-renesas-soc/patch/20211022122101.66998-1-julien.massot@iot.bzh/
> > > to be able to set the Cortex-R7 boot address.
> >
> > The above depencency is needed for this patchset to compile properly.  Since
> > Geert has already applied it to his renesas-devel tree we can do two things:
> >
> > 1) Make this set go through Geert's tree.
> > 2) Geert publishes an immutable branch I can pull the dependency from.
> >
> > I'm good either way, just let me know what you want to do.
> 
> I prefer you to handle the remoteproc parts.
> Please find a pull request for the immutable branch below.
> Thanks!

Perfect - I'll pull from this branch when I receive Julien's final version.

Mathieu

> 
> The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:
> 
>   Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git
> tags/rcar_rst_rproc-tag1
> 
> for you to fetch changes up to 4c7924fb905b02323ff6d9d20f370892615dccfa:
> 
>   soc: renesas: rcar-rst: Add support to set rproc boot address
> (2021-11-15 10:01:10 +0100)
> 
> ----------------------------------------------------------------
> Renesas R-Car Reset Controller remoteproc API
> 
> Definition of rcar_rst_set_rproc_boot_addr(), to be consumed by the
> Renesas R-Car Gen3 remote processor driver.
> 
> ----------------------------------------------------------------
> Julien Massot (1):
>       soc: renesas: rcar-rst: Add support to set rproc boot address
> 
>  drivers/soc/renesas/rcar-rst.c       | 43 +++++++++++++++++++++++++++++++++---
>  include/linux/soc/renesas/rcar-rst.h |  2 ++
>  2 files changed, 42 insertions(+), 3 deletions(-)
> 
> 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