[PATCH v2 00/07] ARM: shmobile: APMU DT support via SMP Enable method V2

[PATCH v2 00/07] ARM: shmobile: APMU DT support via SMP Enable method V2

[Magnus Damm]

ARM: shmobile: APMU DT support via SMP Enable method V2

[PATCH v2 01/07] devicetree: bindings: Renesas APMU and SMP Enable method
[PATCH v2 02/07] ARM: shmobile: Add APMU DT support via Enable method
[PATCH v2 03/07] ARM: shmobile: Add APMU nodes to r8a7790 DTSI
[PATCH v2 04/07] ARM: shmobile: Add APMU nodes to r8a7791 DTSI
[PATCH v2 05/07] ARM: shmobile: Add function to prioritize DT SMP
[PATCH v2 06/07] ARM: shmobile: Prioritize r8a7790 DT APMU support
[PATCH v2 07/07] ARM: shmobile: Prioritize r8a7791 DT APMU support

These patches add DT support for the APMU hardware commonly found in
Renesas R-Car Gen2 SoCs. Without these patches the APMU gets configured
through data expressed in C, and with this series applied it is possible
to describe the APMU configuration in DT and let the enable method point
out that the APMU should be used.

Patch 1 and 2 are Documenting and adding DT support to the APMU driver
together with enabling use of the enable-method way to describe that
the APMU hardware is needed for SMP operation.

Patch 3 and 4 are related to r8a7790/r8a7791 support that get a DTSI update
to describe the APMU hardware. To avoid breaking support for older DTBs out
in the wild these patches keep the older existing C code APMU configuration
as-is. Patch 5-7 make sure that during run-time, if the APMU is installed
via the DT enable-method then it will not be overriden by older non-DT
configuration.

I suggest making APMU DT configuration mandatory for SMP operation on
newer SoCs and that we keep the old APMU support code in place for a
good number of kernel releases or until we can identify a couple of major
reasons good enough to force a DTB update on the end users.

In the future r8a7793 and r8a7794 support may be added by using code
similar to patch 3 and 4 but without any C-based SMP code and fallback.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

Written against renesas-drivers-2015-08-18-v4.2-rc7
 
 Documentation/devicetree/bindings/arm/cpus.txt           |    1 
 Documentation/devicetree/bindings/power/renesas,apmu.txt |   31 ++++
 arch/arm/boot/dts/r8a7790.dtsi                           |   13 ++
 arch/arm/boot/dts/r8a7791.dtsi                           |    7 +
 arch/arm/mach-shmobile/common.h                          |    1 
 arch/arm/mach-shmobile/platsmp-apmu.c                    |   89 +++++++++++++-
 arch/arm/mach-shmobile/platsmp.c                         |    7 +
 arch/arm/mach-shmobile/setup-r8a7790.c                   |    1 
 arch/arm/mach-shmobile/setup-r8a7791.c                   |    1 
 9 files changed, 147 insertions(+), 4 deletions(-)

[PATCH v2 01/07] devicetree: bindings: Renesas APMU and SMP Enable method

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Add DT binding documentation for the APMU hardware and add "renesas,apmu"
to the list of enable methods for the ARM cpus.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 Changes since V1:
 - None

 Documentation/devicetree/bindings/arm/cpus.txt           |    1 
 Documentation/devicetree/bindings/power/renesas,apmu.txt |   31 ++++++++++++++
 2 files changed, 32 insertions(+)

--- 0001/Documentation/devicetree/bindings/arm/cpus.txt
+++ work/Documentation/devicetree/bindings/arm/cpus.txt	2015-05-20 21:55:51.912366518 +0900
@@ -197,6 +197,7 @@ nodes to be present and contain the prop
 			    "qcom,gcc-msm8660"
 			    "qcom,kpss-acc-v1"
 			    "qcom,kpss-acc-v2"
+			    "renesas,apmu"
 			    "rockchip,rk3066-smp"
 
 	- cpu-release-addr
--- /dev/null
+++ work/Documentation/devicetree/bindings/power/renesas,apmu.txt	2015-05-20 22:39:34.872366518 +0900
@@ -0,0 +1,31 @@
+DT bindings for the Renesas Advanced Power Management Unit
+
+Renesas R-Car line of SoCs utilize one or more APMU hardware units
+for CPU core power domain control including SMP boot and CPU Hotplug.
+
+Required properties:
+
+- compatible: Should be "renesas,apmu-<soctype>", "renesas,apmu" as fallback.
+	      Examples with soctypes are:
+		- "renesas,apmu-r8a7790" (R-Car H2)
+		- "renesas,apmu-r8a7791" (R-Car M2-W)
+		- "renesas,apmu-r8a7792" (R-Car V2H)
+		- "renesas,apmu-r8a7793" (R-Car M2-N)
+		- "renesas,apmu-r8a7794" (R-Car E2)
+
+- reg: Base address and length of the I/O registers used by the APMU.
+
+- cpus: This node contains a list of CPU cores, which should match the order
+  of CPU cores used by the WUPCR and PSTR registers in the Advanced Power
+  Management Until section of the device's datasheet.
+
+
+Example:
+
+This shows the r8a7791 APMU that can control CPU0 and CPU1.
+
+	apmu@e6152000 {
+		compatible = "renesas,apmu-r8a7791", "renesas,apmu";
+		reg = <0 0xe6152000 0 0x188>;
+		cpus = <&cpu0 &cpu1>;
+	};

[PATCH v2 02/07] ARM: shmobile: Add APMU DT support via Enable method

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Allow DT configuration of the APMU hardware in the case when the APMU is
pointed out in the DTB via the enable-method. The ability to configure
the APMU via C code is still kept intact to prevent DTB breakage for older
SoCs that do not rely on the enable-method for SMP support.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 Changes since V1:
 - Adjusted to use .cpu_can_disable instead of .cpu_disable

 arch/arm/mach-shmobile/platsmp-apmu.c |   89 +++++++++++++++++++++++++++++++--
 1 file changed, 85 insertions(+), 4 deletions(-)

--- 0001/arch/arm/mach-shmobile/platsmp-apmu.c
+++ work/arch/arm/mach-shmobile/platsmp-apmu.c	2015-08-23 15:33:57.742366518 +0900
@@ -24,6 +24,7 @@
 #include <asm/suspend.h>
 #include "common.h"
 #include "platsmp-apmu.h"
+#include "rcar-gen2.h"
 
 static struct {
 	void __iomem *iomem;
@@ -117,15 +118,64 @@ static void apmu_parse_cfg(void (*fn)(st
 	}
 }
 
-void __init shmobile_smp_apmu_prepare_cpus(unsigned int max_cpus,
-					   struct rcar_apmu_config *apmu_config,
-					   int num)
+static const struct of_device_id apmu_ids[] = {
+	{ .compatible = "renesas,apmu" },
+	{ /*sentinel*/ }
+};
+
+static void apmu_parse_dt(void (*fn)(struct resource *res, int cpu, int bit))
+{
+	struct device_node *np_apmu, *np_cpu;
+	struct resource res;
+	u32 id;
+	int bit, index;
+	bool is_allowed;
+
+	for_each_matching_node(np_apmu, apmu_ids) {
+		/* only enable the cluster that includes the boot CPU */
+		is_allowed = false;
+		for (bit = 0; bit < CONFIG_NR_CPUS; bit++) {
+			np_cpu = of_parse_phandle(np_apmu, "cpus", bit);
+			if (np_cpu) {
+				if (!of_property_read_u32(np_cpu, "reg", &id)) {
+					if (id == cpu_logical_map(0))
+						is_allowed = true;
+				}
+				of_node_put(np_cpu);
+			}
+		}
+		if (!is_allowed)
+			continue;
+
+		for (bit = 0; bit < CONFIG_NR_CPUS; bit++) {
+			np_cpu = of_parse_phandle(np_apmu, "cpus", bit);
+			if (np_cpu) {
+				if (!of_property_read_u32(np_cpu, "reg", &id)) {
+					index = get_logical_index(id);
+					if ((index >= 0) &&
+					    !of_address_to_resource(np_apmu,
+								    0, &res))
+						fn(&res, index, bit);
+				}
+				of_node_put(np_cpu);
+			}
+		}
+		of_node_put(np_apmu);
+	}
+}
+
+static void __init shmobile_smp_apmu_setup_boot(void)
 {
 	/* install boot code shared by all CPUs */
 	shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
 	shmobile_boot_arg = MPIDR_HWID_BITMASK;
+}
 
-	/* perform per-cpu setup */
+void __init shmobile_smp_apmu_prepare_cpus(unsigned int max_cpus,
+					   struct rcar_apmu_config *apmu_config,
+					   int num)
+{
+	shmobile_smp_apmu_setup_boot();
 	apmu_parse_cfg(apmu_init_cpu, apmu_config, num);
 }
 
@@ -236,3 +286,34 @@ void __init shmobile_smp_apmu_suspend_in
 	shmobile_suspend_ops.enter = shmobile_smp_apmu_enter_suspend;
 }
 #endif
+
+static void __init shmobile_smp_apmu_prepare_cpus_dt(unsigned int max_cpus)
+{
+	shmobile_smp_apmu_setup_boot();
+	apmu_parse_dt(apmu_init_cpu);
+	rcar_gen2_pm_init();
+}
+
+static int shmobile_smp_apmu_boot_secondary_md21(unsigned int cpu,
+						 struct task_struct *idle)
+{
+	/* Error out when hardware debug mode is enabled */
+	if (rcar_gen2_read_mode_pins() & BIT(21)) {
+		pr_warn("Unable to boot CPU%u when MD21 is set\n", cpu);
+		return -ENOTSUPP;
+	}
+
+	return shmobile_smp_apmu_boot_secondary(cpu, idle);
+}
+
+static struct smp_operations apmu_smp_ops __initdata = {
+	.smp_prepare_cpus	= shmobile_smp_apmu_prepare_cpus_dt,
+	.smp_boot_secondary	= shmobile_smp_apmu_boot_secondary_md21,
+#ifdef CONFIG_HOTPLUG_CPU
+	.cpu_can_disable	= shmobile_smp_cpu_can_disable,
+	.cpu_die		= shmobile_smp_apmu_cpu_die,
+	.cpu_kill		= shmobile_smp_apmu_cpu_kill,
+#endif
+};
+
+CPU_METHOD_OF_DECLARE(shmobile_smp_apmu, "renesas,apmu", &apmu_smp_ops);

[PATCH v2 03/07] ARM: shmobile: Add APMU nodes to r8a7790 DTSI

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Add an APMU DT node for the r8a7790 SoC and use the enable-method to
point out that the APMU should be used for SMP support.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 Changes from V1:
 - New patch

 arch/arm/boot/dts/r8a7790.dtsi |   13 +++++++++++++
 1 file changed, 13 insertions(+)

--- 0001/arch/arm/boot/dts/r8a7790.dtsi
+++ work/arch/arm/boot/dts/r8a7790.dtsi	2015-08-23 15:51:24.132366518 +0900
@@ -43,6 +43,7 @@
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
+		enable-method = "renesas,apmu";
 
 		cpu0: cpu@0 {
 			device_type = "cpu";
@@ -112,6 +113,18 @@
 		};
 	};
 
+	apmu@e6151000 {
+		compatible = "renesas,apmu-r8a7790", "renesas,apmu";
+		reg = <0 0xe6151000 0 0x188>;
+		cpus = <&cpu4 &cpu5 &cpu6 &cpu7>;
+	};
+
+	apmu@e6152000 {
+		compatible = "renesas,apmu-r8a7790", "renesas,apmu";
+		reg = <0 0xe6152000 0 0x188>;
+		cpus = <&cpu0 &cpu1 &cpu2 &cpu3>;
+	};
+
 	gic: interrupt-controller@f1001000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;

[PATCH v2 04/07] ARM: shmobile: Add APMU nodes to r8a7791 DTSI

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Add an APMU DT node for the r8a7791 SoC and use the enable-method to
point out that the APMU should be used for SMP support.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 Changes from V1:
 - None

 arch/arm/boot/dts/r8a7791.dtsi |    7 +++++++
 1 file changed, 7 insertions(+)

--- 0001/arch/arm/boot/dts/r8a7791.dtsi
+++ work/arch/arm/boot/dts/r8a7791.dtsi	2015-08-23 15:42:10.522366518 +0900
@@ -42,6 +42,7 @@
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
+		enable-method = "renesas,apmu";
 
 		cpu0: cpu@0 {
 			device_type = "cpu";
@@ -69,6 +70,12 @@
 		};
 	};
 
+	apmu@e6152000 {
+		compatible = "renesas,apmu-r8a7791", "renesas,apmu";
+		reg = <0 0xe6152000 0 0x188>;
+		cpus = <&cpu0 &cpu1>;
+	};
+
 	gic: interrupt-controller@f1001000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;

[PATCH v2 05/07] ARM: shmobile: Add function to prioritize DT SMP

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Add a function to check if other DT based method is available, and
if so return false to not hook up smp_ops from the machine vector.

This results in that DT-based SMP support has priority over older
C-based smp_ops code, and in case DT-based SMP support code does not
exist in the DTB then the old smp_ops code will still work as-is.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 Changes since V1:
 - Reworked r8a7791-specific version to become reusable function.

 arch/arm/mach-shmobile/common.h  |    1 +
 arch/arm/mach-shmobile/platsmp.c |    7 +++++++
 2 files changed, 8 insertions(+)

--- 0001/arch/arm/mach-shmobile/common.h
+++ work/arch/arm/mach-shmobile/common.h	2015-08-23 15:26:18.722366518 +0900
@@ -11,6 +11,7 @@ extern void shmobile_smp_sleep(void);
 extern void shmobile_smp_hook(unsigned int cpu, unsigned long fn,
 			      unsigned long arg);
 extern bool shmobile_smp_cpu_can_disable(unsigned int cpu);
+extern bool shmobile_smp_init_fallback_ops(void);
 extern void shmobile_boot_scu(void);
 extern void shmobile_smp_scu_prepare_cpus(unsigned int max_cpus);
 extern void shmobile_smp_scu_cpu_die(unsigned int cpu);
--- 0001/arch/arm/mach-shmobile/platsmp.c
+++ work/arch/arm/mach-shmobile/platsmp.c	2015-08-23 15:26:13.692366518 +0900
@@ -36,3 +36,10 @@ bool shmobile_smp_cpu_can_disable(unsign
 	return true; /* Hotplug of any CPU is supported */
 }
 #endif
+
+bool __init shmobile_smp_init_fallback_ops(void)
+{
+	/* fallback on PSCI/smp_ops if no other DT based method is detected */
+	return platform_can_secondary_boot() ? true : false;
+}
+

[PATCH v2 06/07] ARM: shmobile: Prioritize r8a7790 DT APMU support

[Magnus Damm]

From: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>

Adjust the r8a7790 SoC support code to not configure any non-DT SMP code
in case the DT-based enable-method has been installed already.

Signed-off-by: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
---

 Changes since V1:
 - New patch.

 arch/arm/mach-shmobile/setup-r8a7790.c |    1 +
 1 file changed, 1 insertion(+)

--- 0001/arch/arm/mach-shmobile/setup-r8a7790.c
+++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2015-08-23 15:44:29.102366518 +0900
@@ -28,6 +28,7 @@ static const char * const r8a7790_boards
 };
 
 DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
+	.smp_init	= shmobile_smp_init_fallback_ops,
 	.smp		= smp_ops(r8a7790_smp_ops),
 	.init_early	= shmobile_init_delay,
 	.init_time	= rcar_gen2_timer_init,
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 07/07] ARM: shmobile: Prioritize r8a7791 DT APMU support

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Adjust the r8a7791 SoC support code to not configure any non-DT SMP code
in case the DT-based enable-method has been installed already.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 Changes since V1:
 - Broke out bits from former r8a7791-specific patch.

 arch/arm/mach-shmobile/setup-r8a7791.c |    1 +
 1 file changed, 1 insertion(+)

--- 0001/arch/arm/mach-shmobile/setup-r8a7791.c
+++ work/arch/arm/mach-shmobile/setup-r8a7791.c	2015-08-23 15:46:53.002366518 +0900
@@ -29,6 +29,7 @@ static const char *const r8a7791_boards_
 };
 
 DT_MACHINE_START(R8A7791_DT, "Generic R8A7791 (Flattened Device Tree)")
+	.smp_init	= shmobile_smp_init_fallback_ops,
 	.smp		= smp_ops(r8a7791_smp_ops),
 	.init_early	= shmobile_init_delay,
 	.init_time	= rcar_gen2_timer_init,

Re: [PATCH v2 01/07] devicetree: bindings: Renesas APMU and SMP Enable method

[Geert Uytterhoeven]

Hi Magnus,

On Sun, Aug 23, 2015 at 9:24 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> Add DT binding documentation for the APMU hardware and add "renesas,apmu"
> to the list of enable methods for the ARM cpus.

Thanks!

> --- /dev/null
> +++ work/Documentation/devicetree/bindings/power/renesas,apmu.txt       2015-05-20 22:39:34.872366518 +0900
> @@ -0,0 +1,31 @@

> +- cpus: This node contains a list of CPU cores, which should match the order
> +  of CPU cores used by the WUPCR and PSTR registers in the Advanced Power
> +  Management Until section of the device's datasheet.

s/Until/Unit/

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 01/07] devicetree: bindings: Renesas APMU and SMP Enable method

[Laurent Pinchart]

Hi Magnus,

Thank you for the patch.

On Sunday 23 August 2015 16:24:39 Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
> 
> Add DT binding documentation for the APMU hardware and add "renesas,apmu"
> to the list of enable methods for the ARM cpus.
> 
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> ---
> 
>  Changes since V1:
>  - None
> 
>  Documentation/devicetree/bindings/arm/cpus.txt           |    1
>  Documentation/devicetree/bindings/power/renesas,apmu.txt |   31 +++++++++++
>  2 files changed, 32 insertions(+)
> 
> --- 0001/Documentation/devicetree/bindings/arm/cpus.txt
> +++ work/Documentation/devicetree/bindings/arm/cpus.txt	2015-05-20
> 21:55:51.912366518 +0900 @@ -197,6 +197,7 @@ nodes to be present and
> contain the prop
>  			    "qcom,gcc-msm8660"
>  			    "qcom,kpss-acc-v1"
>  			    "qcom,kpss-acc-v2"
> +			    "renesas,apmu"
>  			    "rockchip,rk3066-smp"
> 
>  	- cpu-release-addr
> --- /dev/null
> +++ work/Documentation/devicetree/bindings/power/renesas,apmu.txt	
2015-05-20
> 22:39:34.872366518 +0900 @@ -0,0 +1,31 @@
> +DT bindings for the Renesas Advanced Power Management Unit
> +
> +Renesas R-Car line of SoCs utilize one or more APMU hardware units
> +for CPU core power domain control including SMP boot and CPU Hotplug.
> +
> +Required properties:
> +
> +- compatible: Should be "renesas,apmu-<soctype>", "renesas,apmu" as
> fallback.
> +	      Examples with soctypes are:
> +		- "renesas,apmu-r8a7790" (R-Car H2)
> +		- "renesas,apmu-r8a7791" (R-Car M2-W)
> +		- "renesas,apmu-r8a7792" (R-Car V2H)
> +		- "renesas,apmu-r8a7793" (R-Car M2-N)
> +		- "renesas,apmu-r8a7794" (R-Car E2)
> +
> +- reg: Base address and length of the I/O registers used by the APMU.
> +
> +- cpus: This node contains a list of CPU cores, which should match the
> order
> +  of CPU cores used by the WUPCR and PSTR registers in the Advanced Power
> +  Management Until section of the device's datasheet.
> +
> +
> +Example:
> +
> +This shows the r8a7791 APMU that can control CPU0 and CPU1.
> +
> +	apmu@e6152000 {
> +		compatible = "renesas,apmu-r8a7791", "renesas,apmu";
> +		reg = <0 0xe6152000 0 0x188>;

Are the CA7 and CA15 APMUs identical ? If not you won't be able to instantiate 
two APMU nodes, and it might be better to span the whole registers range of 
both CA7 and CA15.

> +		cpus = <&cpu0 &cpu1>;
> +	};

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 03/07] ARM: shmobile: Add APMU nodes to r8a7790 DTSI

[Laurent Pinchart]

Hi Magnus,

Thank you for the patch.

On Sunday 23 August 2015 16:25:00 Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
> 
> Add an APMU DT node for the r8a7790 SoC and use the enable-method to
> point out that the APMU should be used for SMP support.
> 
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> ---
> 
>  Changes from V1:
>  - New patch
> 
>  arch/arm/boot/dts/r8a7790.dtsi |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> --- 0001/arch/arm/boot/dts/r8a7790.dtsi
> +++ work/arch/arm/boot/dts/r8a7790.dtsi	2015-08-23 15:51:24.132366518 +0900
> @@ -43,6 +43,7 @@
>  	cpus {
>  		#address-cells = <1>;
>  		#size-cells = <0>;
> +		enable-method = "renesas,apmu";
> 
>  		cpu0: cpu@0 {
>  			device_type = "cpu";
> @@ -112,6 +113,18 @@
>  		};
>  	};
> 
> +	apmu@e6151000 {
> +		compatible = "renesas,apmu-r8a7790", "renesas,apmu";
> +		reg = <0 0xe6151000 0 0x188>;
> +		cpus = <&cpu4 &cpu5 &cpu6 &cpu7>;
> +	};
> +
> +	apmu@e6152000 {
> +		compatible = "renesas,apmu-r8a7790", "renesas,apmu";
> +		reg = <0 0xe6152000 0 0x188>;
> +		cpus = <&cpu0 &cpu1 &cpu2 &cpu3>;
> +	};

I wonder whether those two nodes shouldn't be moved inside the CPG node as it 
seems that the APMU is part of the CPG IP core. We can delay that though, as 
the Gen3 DTS will need to be refactored anyway.

> +
>  	gic: interrupt-controller@f1001000 {
>  		compatible = "arm,gic-400";
>  		#interrupt-cells = <3>;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 00/07] ARM: shmobile: APMU DT support via SMP Enable method V2

[Simon Horman]

Hi Magnus,

On Sun, Aug 23, 2015 at 04:24:27PM +0900, Magnus Damm wrote:
> ARM: shmobile: APMU DT support via SMP Enable method V2
> 
> [PATCH v2 01/07] devicetree: bindings: Renesas APMU and SMP Enable method
> [PATCH v2 02/07] ARM: shmobile: Add APMU DT support via Enable method
> [PATCH v2 03/07] ARM: shmobile: Add APMU nodes to r8a7790 DTSI
> [PATCH v2 04/07] ARM: shmobile: Add APMU nodes to r8a7791 DTSI
> [PATCH v2 05/07] ARM: shmobile: Add function to prioritize DT SMP
> [PATCH v2 06/07] ARM: shmobile: Prioritize r8a7790 DT APMU support
> [PATCH v2 07/07] ARM: shmobile: Prioritize r8a7791 DT APMU support
> 
> These patches add DT support for the APMU hardware commonly found in
> Renesas R-Car Gen2 SoCs. Without these patches the APMU gets configured
> through data expressed in C, and with this series applied it is possible
> to describe the APMU configuration in DT and let the enable method point
> out that the APMU should be used.
> 
> Patch 1 and 2 are Documenting and adding DT support to the APMU driver
> together with enabling use of the enable-method way to describe that
> the APMU hardware is needed for SMP operation.
> 
> Patch 3 and 4 are related to r8a7790/r8a7791 support that get a DTSI update
> to describe the APMU hardware. To avoid breaking support for older DTBs out
> in the wild these patches keep the older existing C code APMU configuration
> as-is. Patch 5-7 make sure that during run-time, if the APMU is installed
> via the DT enable-method then it will not be overriden by older non-DT
> configuration.
> 
> I suggest making APMU DT configuration mandatory for SMP operation on
> newer SoCs and that we keep the old APMU support code in place for a
> good number of kernel releases or until we can identify a couple of major
> reasons good enough to force a DTB update on the end users.
> 
> In the future r8a7793 and r8a7794 support may be added by using code
> similar to patch 3 and 4 but without any C-based SMP code and fallback.

Sounds reasonable.

Looking over the review of this series I see only one minor comment
regarding spelling in documentation. I have it in mind to queue up
this series with that problem fixed unless objections are raised
in the near future. Please feel free to convince me otherwise or
repost the series with the spelling error fixed.

Re: [PATCH v2 00/07] ARM: shmobile: APMU DT support via SMP Enable method V2

[Magnus Damm]

Hi Simon,

On Tue, Aug 25, 2015 at 9:49 AM, Simon Horman <horms@verge.net.au> wrote:
> Hi Magnus,
>
> On Sun, Aug 23, 2015 at 04:24:27PM +0900, Magnus Damm wrote:
>> ARM: shmobile: APMU DT support via SMP Enable method V2
>>
>> [PATCH v2 01/07] devicetree: bindings: Renesas APMU and SMP Enable method
>> [PATCH v2 02/07] ARM: shmobile: Add APMU DT support via Enable method
>> [PATCH v2 03/07] ARM: shmobile: Add APMU nodes to r8a7790 DTSI
>> [PATCH v2 04/07] ARM: shmobile: Add APMU nodes to r8a7791 DTSI
>> [PATCH v2 05/07] ARM: shmobile: Add function to prioritize DT SMP
>> [PATCH v2 06/07] ARM: shmobile: Prioritize r8a7790 DT APMU support
>> [PATCH v2 07/07] ARM: shmobile: Prioritize r8a7791 DT APMU support
>>
>> These patches add DT support for the APMU hardware commonly found in
>> Renesas R-Car Gen2 SoCs. Without these patches the APMU gets configured
>> through data expressed in C, and with this series applied it is possible
>> to describe the APMU configuration in DT and let the enable method point
>> out that the APMU should be used.
>>
>> Patch 1 and 2 are Documenting and adding DT support to the APMU driver
>> together with enabling use of the enable-method way to describe that
>> the APMU hardware is needed for SMP operation.
>>
>> Patch 3 and 4 are related to r8a7790/r8a7791 support that get a DTSI update
>> to describe the APMU hardware. To avoid breaking support for older DTBs out
>> in the wild these patches keep the older existing C code APMU configuration
>> as-is. Patch 5-7 make sure that during run-time, if the APMU is installed
>> via the DT enable-method then it will not be overriden by older non-DT
>> configuration.
>>
>> I suggest making APMU DT configuration mandatory for SMP operation on
>> newer SoCs and that we keep the old APMU support code in place for a
>> good number of kernel releases or until we can identify a couple of major
>> reasons good enough to force a DTB update on the end users.
>>
>> In the future r8a7793 and r8a7794 support may be added by using code
>> similar to patch 3 and 4 but without any C-based SMP code and fallback.
>
> Sounds reasonable.
>
> Looking over the review of this series I see only one minor comment
> regarding spelling in documentation. I have it in mind to queue up
> this series with that problem fixed unless objections are raised
> in the near future. Please feel free to convince me otherwise or
> repost the series with the spelling error fixed.

Thanks for your feedback! My plan is to update this series once more
early next month, so no need to pick anything up right now.

I feel that we should discuss with the ARM SoC guys about the reason
why SMP Enable DT binding is needed. From my side it seems enough to
determine the SMP configuration from the SoC part number (and maybe
APMU DT bits) that we already have encoded in DT.

Perhaps discussing that at ELCE would be good?

Best,

/ magnus

Re: [PATCH v2 01/07] devicetree: bindings: Renesas APMU and SMP Enable method

[Magnus Damm]

Hi Laurent,

On Tue, Aug 25, 2015 at 3:25 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Magnus,
>
> Thank you for the patch.
>
> On Sunday 23 August 2015 16:24:39 Magnus Damm wrote:
>> From: Magnus Damm <damm+renesas@opensource.se>
>>
>> Add DT binding documentation for the APMU hardware and add "renesas,apmu"
>> to the list of enable methods for the ARM cpus.
>>
>> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>> ---
>>
>>  Changes since V1:
>>  - None
>>
>>  Documentation/devicetree/bindings/arm/cpus.txt           |    1
>>  Documentation/devicetree/bindings/power/renesas,apmu.txt |   31 +++++++++++
>>  2 files changed, 32 insertions(+)
>>
>> --- 0001/Documentation/devicetree/bindings/arm/cpus.txt
>> +++ work/Documentation/devicetree/bindings/arm/cpus.txt       2015-05-20
>> 21:55:51.912366518 +0900 @@ -197,6 +197,7 @@ nodes to be present and
>> contain the prop
>>                           "qcom,gcc-msm8660"
>>                           "qcom,kpss-acc-v1"
>>                           "qcom,kpss-acc-v2"
>> +                         "renesas,apmu"
>>                           "rockchip,rk3066-smp"
>>
>>       - cpu-release-addr
>> --- /dev/null
>> +++ work/Documentation/devicetree/bindings/power/renesas,apmu.txt
> 2015-05-20
>> 22:39:34.872366518 +0900 @@ -0,0 +1,31 @@
>> +DT bindings for the Renesas Advanced Power Management Unit
>> +
>> +Renesas R-Car line of SoCs utilize one or more APMU hardware units
>> +for CPU core power domain control including SMP boot and CPU Hotplug.
>> +
>> +Required properties:
>> +
>> +- compatible: Should be "renesas,apmu-<soctype>", "renesas,apmu" as
>> fallback.
>> +           Examples with soctypes are:
>> +             - "renesas,apmu-r8a7790" (R-Car H2)
>> +             - "renesas,apmu-r8a7791" (R-Car M2-W)
>> +             - "renesas,apmu-r8a7792" (R-Car V2H)
>> +             - "renesas,apmu-r8a7793" (R-Car M2-N)
>> +             - "renesas,apmu-r8a7794" (R-Car E2)
>> +
>> +- reg: Base address and length of the I/O registers used by the APMU.
>> +
>> +- cpus: This node contains a list of CPU cores, which should match the
>> order
>> +  of CPU cores used by the WUPCR and PSTR registers in the Advanced Power
>> +  Management Until section of the device's datasheet.
>> +
>> +
>> +Example:
>> +
>> +This shows the r8a7791 APMU that can control CPU0 and CPU1.
>> +
>> +     apmu@e6152000 {
>> +             compatible = "renesas,apmu-r8a7791", "renesas,apmu";
>> +             reg = <0 0xe6152000 0 0x188>;
>
> Are the CA7 and CA15 APMUs identical ? If not you won't be able to instantiate
> two APMU nodes, and it might be better to span the whole registers range of
> both CA7 and CA15.

I believe they are identical, but now when you mention it I should
really double check!

Cheers,

/ magnus

Re: [PATCH v2 03/07] ARM: shmobile: Add APMU nodes to r8a7790 DTSI

[Magnus Damm]

Hi Laurent,

On Tue, Aug 25, 2015 at 3:29 AM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> Hi Magnus,
>
> Thank you for the patch.
>
> On Sunday 23 August 2015 16:25:00 Magnus Damm wrote:
>> From: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
>>
>> Add an APMU DT node for the r8a7790 SoC and use the enable-method to
>> point out that the APMU should be used for SMP support.
>>
>> Signed-off-by: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
>> ---
>>
>>  Changes from V1:
>>  - New patch
>>
>>  arch/arm/boot/dts/r8a7790.dtsi |   13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>>
>> --- 0001/arch/arm/boot/dts/r8a7790.dtsi
>> +++ work/arch/arm/boot/dts/r8a7790.dtsi       2015-08-23 15:51:24.132366518 +0900
>> @@ -43,6 +43,7 @@
>>       cpus {
>>               #address-cells = <1>;
>>               #size-cells = <0>;
>> +             enable-method = "renesas,apmu";
>>
>>               cpu0: cpu@0 {
>>                       device_type = "cpu";
>> @@ -112,6 +113,18 @@
>>               };
>>       };
>>
>> +     apmu@e6151000 {
>> +             compatible = "renesas,apmu-r8a7790", "renesas,apmu";
>> +             reg = <0 0xe6151000 0 0x188>;
>> +             cpus = <&cpu4 &cpu5 &cpu6 &cpu7>;
>> +     };
>> +
>> +     apmu@e6152000 {
>> +             compatible = "renesas,apmu-r8a7790", "renesas,apmu";
>> +             reg = <0 0xe6152000 0 0x188>;
>> +             cpus = <&cpu0 &cpu1 &cpu2 &cpu3>;
>> +     };
>
> I wonder whether those two nodes shouldn't be moved inside the CPG node as it
> seems that the APMU is part of the CPG IP core. We can delay that though, as
> the Gen3 DTS will need to be refactored anyway.

Hm, I don't mind reworking things, but with power domain focus I sort
of expected the APMU to be closer to SYSC than the CPG actually...

Thanks,

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

Re: [PATCH v2 03/07] ARM: shmobile: Add APMU nodes to r8a7790 DTSI

[Laurent Pinchart]

Hi Magnus,

On Tuesday 25 August 2015 13:13:46 Magnus Damm wrote:
> On Tue, Aug 25, 2015 at 3:29 AM, Laurent Pinchart wrote:
> > On Sunday 23 August 2015 16:25:00 Magnus Damm wrote:
> >> From: Magnus Damm <damm+renesas@opensource.se>
> >> 
> >> Add an APMU DT node for the r8a7790 SoC and use the enable-method to
> >> point out that the APMU should be used for SMP support.
> >> 
> >> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> >> ---
> >> 
> >>  Changes from V1:
> >>  - New patch
> >>  
> >>  arch/arm/boot/dts/r8a7790.dtsi |   13 +++++++++++++
> >>  1 file changed, 13 insertions(+)
> >> 
> >> --- 0001/arch/arm/boot/dts/r8a7790.dtsi
> >> +++ work/arch/arm/boot/dts/r8a7790.dtsi       2015-08-23
> >> 15:51:24.132366518 +0900 @@ -43,6 +43,7 @@
> >>       cpus {
> >>               #address-cells = <1>;
> >>               #size-cells = <0>;
> >> +             enable-method = "renesas,apmu";
> >> 
> >>               cpu0: cpu@0 {
> >>                       device_type = "cpu";
> >> @@ -112,6 +113,18 @@
> >>               };
> >>       };
> >> 
> >> +     apmu@e6151000 {
> >> +             compatible = "renesas,apmu-r8a7790", "renesas,apmu";
> >> +             reg = <0 0xe6151000 0 0x188>;
> >> +             cpus = <&cpu4 &cpu5 &cpu6 &cpu7>;
> >> +     };
> >> +
> >> +     apmu@e6152000 {
> >> +             compatible = "renesas,apmu-r8a7790", "renesas,apmu";
> >> +             reg = <0 0xe6152000 0 0x188>;
> >> +             cpus = <&cpu0 &cpu1 &cpu2 &cpu3>;
> >> +     };
> > 
> > I wonder whether those two nodes shouldn't be moved inside the CPG node as
> > it seems that the APMU is part of the CPG IP core. We can delay that
> > though, as the Gen3 DTS will need to be refactored anyway.
> 
> Hm, I don't mind reworking things, but with power domain focus I sort
> of expected the APMU to be closer to SYSC than the CPG actually...

So did I, but the APMU is in the CPG address range, and is documented in the 
datasheet in the same section as the CPG (7. for CPG, 7A. for MSTP and 7B. for 
APMU). Don't ask me why :-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 01/07] devicetree: bindings: Renesas APMU and SMP Enable method

[Geert Uytterhoeven]

Hi Magnus, Laurent,

On Tue, Aug 25, 2015 at 6:11 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> On Tue, Aug 25, 2015 at 3:25 AM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>>> --- /dev/null
>>> +++ work/Documentation/devicetree/bindings/power/renesas,apmu.txt
>> 2015-05-20
>>> 22:39:34.872366518 +0900 @@ -0,0 +1,31 @@
>>> +DT bindings for the Renesas Advanced Power Management Unit
>>> +
>>> +Renesas R-Car line of SoCs utilize one or more APMU hardware units
>>> +for CPU core power domain control including SMP boot and CPU Hotplug.
>>> +
>>> +Required properties:
>>> +
>>> +- compatible: Should be "renesas,apmu-<soctype>", "renesas,apmu" as
>>> fallback.
>>> +           Examples with soctypes are:
>>> +             - "renesas,apmu-r8a7790" (R-Car H2)
>>> +             - "renesas,apmu-r8a7791" (R-Car M2-W)
>>> +             - "renesas,apmu-r8a7792" (R-Car V2H)
>>> +             - "renesas,apmu-r8a7793" (R-Car M2-N)
>>> +             - "renesas,apmu-r8a7794" (R-Car E2)
>>> +
>>> +- reg: Base address and length of the I/O registers used by the APMU.
>>> +
>>> +- cpus: This node contains a list of CPU cores, which should match the
>>> order
>>> +  of CPU cores used by the WUPCR and PSTR registers in the Advanced Power
>>> +  Management Until section of the device's datasheet.
>>> +
>>> +
>>> +Example:
>>> +
>>> +This shows the r8a7791 APMU that can control CPU0 and CPU1.
>>> +
>>> +     apmu@e6152000 {
>>> +             compatible = "renesas,apmu-r8a7791", "renesas,apmu";
>>> +             reg = <0 0xe6152000 0 0x188>;
>>
>> Are the CA7 and CA15 APMUs identical ? If not you won't be able to instantiate
>> two APMU nodes, and it might be better to span the whole registers range of
>> both CA7 and CA15.

That complicates the (alternative solution to the) "cpus" property.
Now you have two of them, in two separate nodes, for CA15 vs. CA7 on H2,
and CA57 vs. CA53 on H3.

You can merge the nodes, but you can't easily merge the "cpus" property,
as they relate to two different registers.

> I believe they are identical, but now when you mention it I should

I was also under the impression they're identical...

> really double check!

Let's wait and see...

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 00/07] ARM: shmobile: APMU DT support via SMP Enable method V2

[Simon Horman]

[resending as vegr rejected the previous attempt]

On 25 August 2015 at 13:09, Magnus Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Hi Simon,
>
> On Tue, Aug 25, 2015 at 9:49 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> > Hi Magnus,
> >
> > On Sun, Aug 23, 2015 at 04:24:27PM +0900, Magnus Damm wrote:
> >> ARM: shmobile: APMU DT support via SMP Enable method V2
> >>
> >> [PATCH v2 01/07] devicetree: bindings: Renesas APMU and SMP Enable
> method
> >> [PATCH v2 02/07] ARM: shmobile: Add APMU DT support via Enable method
> >> [PATCH v2 03/07] ARM: shmobile: Add APMU nodes to r8a7790 DTSI
> >> [PATCH v2 04/07] ARM: shmobile: Add APMU nodes to r8a7791 DTSI
> >> [PATCH v2 05/07] ARM: shmobile: Add function to prioritize DT SMP
> >> [PATCH v2 06/07] ARM: shmobile: Prioritize r8a7790 DT APMU support
> >> [PATCH v2 07/07] ARM: shmobile: Prioritize r8a7791 DT APMU support
> >>
> >> These patches add DT support for the APMU hardware commonly found in
> >> Renesas R-Car Gen2 SoCs. Without these patches the APMU gets configured
> >> through data expressed in C, and with this series applied it is possible
> >> to describe the APMU configuration in DT and let the enable method point
> >> out that the APMU should be used.
> >>
> >> Patch 1 and 2 are Documenting and adding DT support to the APMU driver
> >> together with enabling use of the enable-method way to describe that
> >> the APMU hardware is needed for SMP operation.
> >>
> >> Patch 3 and 4 are related to r8a7790/r8a7791 support that get a DTSI
> update
> >> to describe the APMU hardware. To avoid breaking support for older DTBs
> out
> >> in the wild these patches keep the older existing C code APMU
> configuration
> >> as-is. Patch 5-7 make sure that during run-time, if the APMU is
> installed
> >> via the DT enable-method then it will not be overriden by older non-DT
> >> configuration.
> >>
> >> I suggest making APMU DT configuration mandatory for SMP operation on
> >> newer SoCs and that we keep the old APMU support code in place for a
> >> good number of kernel releases or until we can identify a couple of
> major
> >> reasons good enough to force a DTB update on the end users.
> >>
> >> In the future r8a7793 and r8a7794 support may be added by using code
> >> similar to patch 3 and 4 but without any C-based SMP code and fallback.
> >
> > Sounds reasonable.
> >
> > Looking over the review of this series I see only one minor comment
> > regarding spelling in documentation. I have it in mind to queue up
> > this series with that problem fixed unless objections are raised
> > in the near future. Please feel free to convince me otherwise or
> > repost the series with the spelling error fixed.
>
> Thanks for your feedback! My plan is to update this series once more
> early next month, so no need to pick anything up right now.
>

Thanks, I will immediately do nothing.


> I feel that we should discuss with the ARM SoC guys about the reason
> why SMP Enable DT binding is needed. From my side it seems enough to
> determine the SMP configuration from the SoC part number (and maybe
> APMU DT bits) that we already have encoded in DT.
>
> Perhaps discussing that at ELCE would be good?
>
> Best,
>
> / magnus
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html