arm64: renesas: Add support for R Car H3e 2G-and M3e-2G

Document the compatible values for the R-Car H3e-2G (R8A779M1) and M3e-2G (R8A779M3) SoCs. These are different gradings of the R-Car H3 ES3.0 (R8A77951) and M3-W+ (R8A77961) SoCs.

All R-Car Gen3e on-SoC devices are identical to the devices on the corresponding R-Car Gen3 SoCs, and thus just use the compatible values for the latter. The root compatible properties do gain an additional value, to sort out integration issues if they ever arise.

Document the use of these SoCs on the Salvator-XS and ULCB (with and without Kingfisher) development boards.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 .../devicetree/bindings/arm/renesas.yaml      | 50 +++++++++++++++----
 1 file changed, 39 insertions(+), 11 deletions(-)

Documentation/devicetree/bindings/arm/renesas.yaml +39 -11

index 5fd0696a9f91f383..a01dd064bf16632a 100644
@@ -238,17 +238,29 @@ properties:
           - const: renesas,r8a77961
 
       - description: Kingfisher (SBEV-RCAR-KF-M03)
-        items:
-          - const: shimafuji,kingfisher
-          - enum:
-              - renesas,h3ulcb
-              - renesas,m3ulcb
-              - renesas,m3nulcb
-          - enum:
-              - renesas,r8a7795
-              - renesas,r8a7796
-              - renesas,r8a77961
-              - renesas,r8a77965
+        oneOf:
+          - items:
+              - const: shimafuji,kingfisher
+              - enum:
+                  - renesas,h3ulcb
+                  - renesas,m3ulcb
+                  - renesas,m3nulcb
+              - enum:
+                  - renesas,r8a7795
+                  - renesas,r8a7796
+                  - renesas,r8a77961
+                  - renesas,r8a77965
+          - items:
+              - const: shimafuji,kingfisher
+              - enum:
+                  - renesas,h3ulcb
+                  - renesas,m3ulcb
+              - enum:
+                  - renesas,r8a779m1
+                  - renesas,r8a779m3
+              - enum:
+                  - renesas,r8a7795
+                  - renesas,r8a77961
 
       - description: R-Car M3-N (R8A77965)
         items:

@@ -296,6 +308,22 @@ properties:
           - const: renesas,falcon-cpu
           - const: renesas,r8a779a0
 
+      - description: R-Car H3e-2G (R8A779M1)
+        items:
+          - enum:
+              - renesas,h3ulcb      # H3ULCB (R-Car Starter Kit Premier)
+              - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+          - const: renesas,r8a779m1
+          - const: renesas,r8a7795
+
+      - description: R-Car M3e-2G (R8A779M3)
+        items:
+          - enum:
+              - renesas,m3ulcb      # M3ULCB (R-Car Starter Kit Pro)
+              - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+          - const: renesas,r8a779m3
+          - const: renesas,r8a77961
+
       - description: RZ/N1D (R9A06G032)
         items:
           - enum:

Quoted 9 lines · Geert Uytterhoeven

Document the compatible values for the R-Car H3e-2G (R8A779M1) and M3e-2G (R8A779M3) SoCs. These are different gradings of the R-Car H3 ES3.0 (R8A77951) and M3-W+ (R8A77961) SoCs.

All R-Car Gen3e on-SoC devices are identical to the devices on the corresponding R-Car Gen3 SoCs, and thus just use the compatible values for the latter. The root compatible properties do gain an additional value, to sort out integration issues if they ever arise.

Quoted 4 lines

Document the use of these SoCs on the Salvator-XS and ULCB (with and without Kingfisher) development boards.

Signed-off-by Geert Uytterhoeven <[email protected]>

Reviewed-by Laurent Pinchart <[email protected]>

I however wonder if we haven't messed up the board compatible strings somehow (unrelated to this patch). Aren't compatible strings supposed to be ordered from most specific to most generic, with a more specific compatible string being a strict subset of a more generic string ? Looking at, for example,

        compatible = "renesas,salvator-xs", "renesas,r8a779m1", "renesas,r8a7795";

the rule is upheld by renesas,r8a779m1 being a subset of the more generic renesas,r8a7795, but that's not the case for renesas,salvator-xs.

Quoted 58 lines

Documentation/devicetree/bindings/arm/renesas.yaml +34 -11

@@ -238,17 +238,29 @@ properties:
           - const: renesas,r8a77961
 
       - description: Kingfisher (SBEV-RCAR-KF-M03)
-        items:
-          - const: shimafuji,kingfisher
-          - enum:
-              - renesas,h3ulcb
-              - renesas,m3ulcb
-              - renesas,m3nulcb
-          - enum:
-              - renesas,r8a7795
-              - renesas,r8a7796
-              - renesas,r8a77961
-              - renesas,r8a77965
+        oneOf:
+          - items:
+              - const: shimafuji,kingfisher
+              - enum:
+                  - renesas,h3ulcb
+                  - renesas,m3ulcb
+                  - renesas,m3nulcb
+              - enum:
+                  - renesas,r8a7795
+                  - renesas,r8a7796
+                  - renesas,r8a77961
+                  - renesas,r8a77965
+          - items:
+              - const: shimafuji,kingfisher
+              - enum:
+                  - renesas,h3ulcb
+                  - renesas,m3ulcb
+              - enum:
+                  - renesas,r8a779m1
+                  - renesas,r8a779m3
+              - enum:
+                  - renesas,r8a7795
+                  - renesas,r8a77961
 
       - description: R-Car M3-N (R8A77965)
         items:

@@ -296,6 +308,22 @@ properties:
           - const: renesas,falcon-cpu
           - const: renesas,r8a779a0
 
+      - description: R-Car H3e-2G (R8A779M1)
+        items:
+          - enum:
+              - renesas,h3ulcb      # H3ULCB (R-Car Starter Kit Premier)
+              - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+          - const: renesas,r8a779m1
+          - const: renesas,r8a7795
+
+      - description: R-Car M3e-2G (R8A779M3)
+        items:
+          - enum:

Documentation/devicetree/bindings/arm/renesas.yaml properties: · line 329

Quoted 8 lines

Documentation/devicetree/bindings/arm/renesas.yaml +5 -0

+              - renesas,m3ulcb      # M3ULCB (R-Car Starter Kit Pro)
+              - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+          - const: renesas,r8a779m3
+          - const: renesas,r8a77961
+
       - description: RZ/N1D (R9A06G032)
         items:
           - enum:

Quoted 10 lines · Laurent Pinchart

Quoted 9 lines · Geert Uytterhoeven

Document the compatible values for the R-Car H3e-2G (R8A779M1) and M3e-2G (R8A779M3) SoCs. These are different gradings of the R-Car H3 ES3.0 (R8A77951) and M3-W+ (R8A77961) SoCs.

All R-Car Gen3e on-SoC devices are identical to the devices on the corresponding R-Car Gen3 SoCs, and thus just use the compatible values for the latter. The root compatible properties do gain an additional value, to sort out integration issues if they ever arise.

Quoted 6 lines

Quoted 4 lines

Document the use of these SoCs on the Salvator-XS and ULCB (with and without Kingfisher) development boards.

Signed-off-by Geert Uytterhoeven <[email protected]>

Reviewed-by Laurent Pinchart <[email protected]>

Thanks!

Quoted 11 lines

I however wonder if we haven't messed up the board compatible strings somehow (unrelated to this patch). Aren't compatible strings supposed to be ordered from most specific to most generic, with a more specific compatible string being a strict subset of a more generic string ? Looking at, for example,

        compatible = "renesas,salvator-xs", "renesas,r8a779m1", "renesas,r8a7795";

the rule is upheld by renesas,r8a779m1 being a subset of the more generic renesas,r8a7795, but that's not the case for renesas,salvator-xs.

That's a very interesting comment. Originally, we had lists like:

    compatible = "renesas,koelsch", "renesas,r8a7791";

with the Koelsch board indeed being a specialization of an R-Car M2-W-based system. Later, we reused that system for the Salvator-X board with an R-Car H3 SiP:

    compatible = "renesas,salvator-x", "renesas,r8a7795";

That scheme became "broken" with the introduction of the R-Car M3-W SiP, which was also mounted on a Salvator-X board, leading to:

    compatible = "renesas,salvator-x", "renesas,r8a7796";

Note that we did have a similar case for R-Car M2-W and R-Car M2-N on the Koelsch resp. Gose boards: from the schematics (I haven't seen a Gose), it looks identical to Koelsch, with parts not supported by R-Car M2-N (like the second SDRAM bank) marked "Do not stuff". But in this case the boards were assigned different names, thus leading to different compatible values.

With Salvator-X(S), it was easier to support multiple SoCs, as they are mounted on SiPs, with differences like the different number of memory channels hidden in the SiP, and handled at a different level (these days memory layout information flows from ATF to U-Boot to the DTB passed to the kernel).

Would you feel more comfortable if we had introduced more board-specific compatible values, like "renesas,r8a7796-salvator-x", and had used

    compatible = "renesas,r8a7795-salvator-x", "renesas,salvator-x",

"renesas,r8a7795";

or

    compatible = "renesas,r8a7795-salvator-x", "renesas,r8a7795";

?

If the need ever arises, Linux can still identify the exact combination by checking for both the board- and the SoC-specific values. So far we didn't have that need for Salvator-X(S) yet (we do have board-specific checks in arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c).

Quoted 66 lines

Quoted 66 lines

Documentation/devicetree/bindings/arm/renesas.yaml +39 -11

@@ -238,17 +238,29 @@ properties:
           - const: renesas,r8a77961
 
       - description: Kingfisher (SBEV-RCAR-KF-M03)
-        items:
-          - const: shimafuji,kingfisher
-          - enum:
-              - renesas,h3ulcb
-              - renesas,m3ulcb
-              - renesas,m3nulcb
-          - enum:
-              - renesas,r8a7795
-              - renesas,r8a7796
-              - renesas,r8a77961
-              - renesas,r8a77965
+        oneOf:
+          - items:
+              - const: shimafuji,kingfisher
+              - enum:
+                  - renesas,h3ulcb
+                  - renesas,m3ulcb
+                  - renesas,m3nulcb
+              - enum:
+                  - renesas,r8a7795
+                  - renesas,r8a7796
+                  - renesas,r8a77961
+                  - renesas,r8a77965
+          - items:
+              - const: shimafuji,kingfisher
+              - enum:
+                  - renesas,h3ulcb
+                  - renesas,m3ulcb
+              - enum:
+                  - renesas,r8a779m1
+                  - renesas,r8a779m3
+              - enum:
+                  - renesas,r8a7795
+                  - renesas,r8a77961
 
       - description: R-Car M3-N (R8A77965)
         items:

@@ -296,6 +308,22 @@ properties:
           - const: renesas,falcon-cpu
           - const: renesas,r8a779a0
 
+      - description: R-Car H3e-2G (R8A779M1)
+        items:
+          - enum:
+              - renesas,h3ulcb      # H3ULCB (R-Car Starter Kit Premier)
+              - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+          - const: renesas,r8a779m1
+          - const: renesas,r8a7795
+
+      - description: R-Car M3e-2G (R8A779M3)
+        items:
+          - enum:
+              - renesas,m3ulcb      # M3ULCB (R-Car Starter Kit Pro)
+              - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+          - const: renesas,r8a779m3
+          - const: renesas,r8a77961
+
       - description: RZ/N1D (R9A06G032)
         items:
           - enum:

Document the compatible values for the R-Car H3e-2G (R8A779M1) and M3e-2G (R8A779M3) SoCs. These are different gradings of the R-Car H3 ES3.0 (R8A77951) and M3-W+ (R8A77961) SoCs.

All R-Car Gen3e on-SoC devices are identical to the devices on the corresponding R-Car Gen3 SoCs, and thus just use the compatible values for the latter. The root compatible properties do gain an additional value, to sort out integration issues if they ever arise.

Document the use of these SoCs on the Salvator-XS and ULCB (with and without Kingfisher) development boards.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 .../devicetree/bindings/arm/renesas.yaml      | 50 +++++++++++++++----
 1 file changed, 39 insertions(+), 11 deletions(-)

From: Geert Uytterhoeven, Sent: Thursday, June 10, 2021 6:37 PM

Document the compatible values for the R-Car H3e-2G (R8A779M1) and M3e-2G (R8A779M3) SoCs. These are different gradings of the R-Car H3 ES3.0 (R8A77951) and M3-W+ (R8A77961) SoCs.

All R-Car Gen3e on-SoC devices are identical to the devices on the corresponding R-Car Gen3 SoCs, and thus just use the compatible values for the latter. The root compatible properties do gain an additional value, to sort out integration issues if they ever arise.

Document the use of these SoCs on the Salvator-XS and ULCB (with and without Kingfisher) development boards.

Signed-off-by Geert Uytterhoeven <[email protected]>

Add support for identifying the R-Car H3e-2G (R8A779M1) and R-Car M3e-2G (R8A779M3) SoCs.

As these are different gradings of the already supported R-Car H3 ES3.0 (R8A77951) and M3-W+ (R8A77961) SoCs, support for them is enabled through the existing ARCH_R8A77951 and ARCH_R8A77961 configuration symbols.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
Question: Should we drop fam_rcar_gen3e and soc_rcar_[hm]3e, and just
use the existing soc_rcar_h3 and soc_rcar_m3_w?

---
 drivers/soc/renesas/Kconfig       |  2 ++
 drivers/soc/renesas/renesas-soc.c | 19 +++++++++++++++++++
 2 files changed, 21 insertions(+)

drivers/soc/renesas/Kconfig +2 -0

index 4fe0247189a615b0..089c7c50e3ca4c3b 100644
@@ -213,6 +213,7 @@ config ARCH_R8A77951
 	help
 	  This enables support for the Renesas R-Car H3 SoC (revisions 2.0 and
 	  later).
+	  This includes different gradings like R-Car H3e-2G.
 
 config ARCH_R8A77965
 	bool "ARM64 Platform support for R-Car M3-N"

@@ -234,6 +235,7 @@ config ARCH_R8A77961
 	select SYSC_R8A77961
 	help
 	  This enables support for the Renesas R-Car M3-W+ SoC.
+	  This includes different gradings like R-Car M3e-2G.
 
 config ARCH_R8A77980
 	bool "ARM64 Platform support for R-Car V3H"

drivers/soc/renesas/renesas-soc.c +19 -0

index 0f8eff4a641a21b7..2851fd9c44ce8e3f 100644
@@ -33,6 +33,11 @@ static const struct renesas_family fam_rcar_gen3 __initconst __maybe_unused = {
 	.reg	= 0xfff00044,		/* PRR (Product Register) */
 };
 
+static const struct renesas_family fam_rcar_gen3e __initconst __maybe_unused = {
+	.name	= "R-Car Gen3e",
+	.reg	= 0xfff00044,		/* PRR (Product Register) */
+};
+
 static const struct renesas_family fam_rmobile __initconst __maybe_unused = {
 	.name	= "R-Mobile",
 	.reg	= 0xe600101c,		/* CCCR (Common Chip Code Register) */

@@ -205,6 +210,16 @@ static const struct renesas_soc soc_rcar_v3u __initconst __maybe_unused = {
 	.id	= 0x59,
 };
 
+static const struct renesas_soc soc_rcar_h3e __initconst __maybe_unused = {
+	.family	= &fam_rcar_gen3e,
+	.id	= 0x4f,
+};
+
+static const struct renesas_soc soc_rcar_m3e __initconst __maybe_unused = {
+	.family	= &fam_rcar_gen3e,
+	.id	= 0x52,
+};
+
 static const struct renesas_soc soc_shmobile_ag5 __initconst __maybe_unused = {
 	.family	= &fam_shmobile,
 	.id	= 0x37,

@@ -275,11 +290,15 @@ static const struct of_device_id renesas_socs[] __initconst = {
 #if defined(CONFIG_ARCH_R8A77950) || defined(CONFIG_ARCH_R8A77951)
 	{ .compatible = "renesas,r8a7795",	.data = &soc_rcar_h3 },
 #endif
+#ifdef CONFIG_ARCH_R8A77951
+	{ .compatible = "renesas,r8a779m1",	.data = &soc_rcar_h3e },
+#endif
 #ifdef CONFIG_ARCH_R8A77960
 	{ .compatible = "renesas,r8a7796",	.data = &soc_rcar_m3_w },
 #endif
 #ifdef CONFIG_ARCH_R8A77961
 	{ .compatible = "renesas,r8a77961",	.data = &soc_rcar_m3_w },
+	{ .compatible = "renesas,r8a779m3",	.data = &soc_rcar_m3e },
 #endif
 #ifdef CONFIG_ARCH_R8A77965
 	{ .compatible = "renesas,r8a77965",	.data = &soc_rcar_m3_n },

From: Laurent Pinchart, Sent: Tuesday, June 15, 2021 3:31 AM

Hi Geert,

Thank you for the patch.

Quoted 8 lines · Geert Uytterhoeven

Add support for identifying the R-Car H3e-2G (R8A779M1) and R-Car M3e-2G (R8A779M3) SoCs.

As these are different gradings of the already supported R-Car H3 ES3.0 (R8A77951) and M3-W+ (R8A77961) SoCs, support for them is enabled through the existing ARCH_R8A77951 and ARCH_R8A77961 configuration symbols.

Quoted 4 lines

Signed-off-by Geert Uytterhoeven <[email protected]>

---
Question: Should we drop fam_rcar_gen3e and soc_rcar_[hm]3e, and just
use the existing soc_rcar_h3 and soc_rcar_m3_w?

I'd vote for that, as there's no functional difference in the code below between fam_rcar_gen3e and fam_rcar_gen3.

As R-Car H3 ES1.x (R8A77950) and R-Car ES2.0+ (R8A77951) use the same compatible value, the pin control driver relies on soc_device_match() with soc_id = "r8a7795" and the (non)matching of revision = "ES1.*" to match with and distinguish between the two SoC variants. The corresponding entries in the normal of_match_table are present only to make the optional sanity checks work.

The R-Car H3e-2G (R8A779M1) SoC is a different grading of the R-Car H3 ES3.0 (R8A77951) SoC. It uses the same compatible values for individual devices, but has an additional compatible value for the root node. When running on an R-Car H3e-2G SoC, soc_device_match() with soc_id = "r8a7795" does not return a match. Hence the pin control driver falls back to the normal of_match_table, and, as the R8A77950 entry is listed first, incorrectly uses the sub-driver for R-Car H3 ES1.x.

Fix this by moving the entry for R8A77951 before the entry for R8A77950.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 drivers/pinctrl/renesas/core.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

drivers/pinctrl/renesas/core.c +9 -5

index 5ccc49b387f17eb9..9adb97065704270d 100644
@@ -571,17 +571,21 @@ static const struct of_device_id sh_pfc_of_table[] = {
 		.data = &r8a7794_pinmux_info,
 	},
 #endif
-/* Both r8a7795 entries must be present to make sanity checks work */
-#ifdef CONFIG_PINCTRL_PFC_R8A77950
+/*
+ * Both r8a7795 entries must be present to make sanity checks work, but only
+ * the first entry is actually used, for R-Car H3e.
+ * R-Car H3 ES1.x and ES2.0+ are matched using soc_device_match() instead.
+ */
+#ifdef CONFIG_PINCTRL_PFC_R8A77951
 	{
 		.compatible = "renesas,pfc-r8a7795",
-		.data = &r8a77950_pinmux_info,
+		.data = &r8a77951_pinmux_info,
 	},
 #endif
-#ifdef CONFIG_PINCTRL_PFC_R8A77951
+#ifdef CONFIG_PINCTRL_PFC_R8A77950
 	{
 		.compatible = "renesas,pfc-r8a7795",
-		.data = &r8a77951_pinmux_info,
+		.data = &r8a77950_pinmux_info,
 	},
 #endif
 #ifdef CONFIG_PINCTRL_PFC_R8A77960

Quoted 15 lines · Geert Uytterhoeven

As R-Car H3 ES1.x (R8A77950) and R-Car ES2.0+ (R8A77951) use the same compatible value, the pin control driver relies on soc_device_match() with soc_id = "r8a7795" and the (non)matching of revision = "ES1.*" to match with and distinguish between the two SoC variants. The corresponding entries in the normal of_match_table are present only to make the optional sanity checks work.

The R-Car H3e-2G (R8A779M1) SoC is a different grading of the R-Car H3 ES3.0 (R8A77951) SoC. It uses the same compatible values for individual devices, but has an additional compatible value for the root node. When running on an R-Car H3e-2G SoC, soc_device_match() with soc_id = "r8a7795" does not return a match. Hence the pin control driver falls back to the normal of_match_table, and, as the R8A77950 entry is listed first, incorrectly uses the sub-driver for R-Car H3 ES1.x.

Quoted 3 lines

Fix this by moving the entry for R8A77951 before the entry for R8A77950.

Signed-off-by Geert Uytterhoeven <[email protected]>

Reviewed-by Laurent Pinchart <[email protected]>

I wonder if this means we could drop the second entry in the quirks array, in sh_pfc_quirk_match().

Quoted 21 lines

drivers/pinctrl/renesas/core.c +7 -4

@@ -571,17 +571,21 @@ static const struct of_device_id sh_pfc_of_table[] = {
              .data = &r8a7794_pinmux_info,
      },
 #endif
-/* Both r8a7795 entries must be present to make sanity checks work */
-#ifdef CONFIG_PINCTRL_PFC_R8A77950
+/*
+ * Both r8a7795 entries must be present to make sanity checks work, but only
+ * the first entry is actually used, for R-Car H3e.
+ * R-Car H3 ES1.x and ES2.0+ are matched using soc_device_match() instead.
+ */
+#ifdef CONFIG_PINCTRL_PFC_R8A77951
      {
              .compatible = "renesas,pfc-r8a7795",
-             .data = &r8a77950_pinmux_info,
+             .data = &r8a77951_pinmux_info,
      },
 #endif
-#ifdef CONFIG_PINCTRL_PFC_R8A77951

drivers/pinctrl/renesas/core.c static const struct of_device_id sh_pfc_of_table[] = { · line 591

Quoted 8 lines

drivers/pinctrl/renesas/core.c +2 -1

+#ifdef CONFIG_PINCTRL_PFC_R8A77950
      {
              .compatible = "renesas,pfc-r8a7795",
-             .data = &r8a77951_pinmux_info,
+             .data = &r8a77950_pinmux_info,
      },
 #endif
 #ifdef CONFIG_PINCTRL_PFC_R8A77960

From: Geert Uytterhoeven, Sent: Thursday, June 10, 2021 6:37 PM

As R-Car H3 ES1.x (R8A77950) and R-Car ES2.0+ (R8A77951) use the same compatible value, the pin control driver relies on soc_device_match() with soc_id = "r8a7795" and the (non)matching of revision = "ES1.*" to match with and distinguish between the two SoC variants. The corresponding entries in the normal of_match_table are present only to make the optional sanity checks work.

The R-Car H3e-2G (R8A779M1) SoC is a different grading of the R-Car H3 ES3.0 (R8A77951) SoC. It uses the same compatible values for individual devices, but has an additional compatible value for the root node. When running on an R-Car H3e-2G SoC, soc_device_match() with soc_id = "r8a7795" does not return a match. Hence the pin control driver falls back to the normal of_match_table, and, as the R8A77950 entry is listed first, incorrectly uses the sub-driver for R-Car H3 ES1.x.

Fix this by moving the entry for R8A77951 before the entry for R8A77950.

Signed-off-by Geert Uytterhoeven <[email protected]>

Add support for the R-Car H3e-2G (R8A779M1) and M3e-2G (R8A779M3) SoCs. These are different gradings of the R-Car H3 ES3.0 (R8A77951) and M3-W+ (R8A77961) SoCs, and thus subject to the same quirks.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 drivers/mmc/host/renesas_sdhi_core.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/mmc/host/renesas_sdhi_core.c +0 -0

index b719eda6b8619453..0478c9d58b965392 100644

drivers/mmc/host/renesas_sdhi_core.c +0 -0

 	{ /* Sentinel. */ },
 };
 

Quoted 5 lines · Geert Uytterhoeven

Add support for the R-Car H3e-2G (R8A779M1) and M3e-2G (R8A779M3) SoCs. These are different gradings of the R-Car H3 ES3.0 (R8A77951) and M3-W+ (R8A77961) SoCs, and thus subject to the same quirks.

Signed-off-by Geert Uytterhoeven <[email protected]>

drivers/mmc/host/renesas_sdhi_core.c static const struct soc_device_attribute sdhi_quirks_match[] = { · line 947

Quoted 8 lines

drivers/mmc/host/renesas_sdhi_core.c +2 -0

@@ -943,6 +943,8 @@ static const struct soc_device_attribute sdhi_quirks_match[]  = {
      { .soc_id = "r8a77965", .data = &sdhi_quirks_r8a77965 },
      { .soc_id = "r8a77980", .data = &sdhi_quirks_nohs400 },
      { .soc_id = "r8a77990", .data = &sdhi_quirks_r8a77990 },
+     { .soc_id = "r8a779m1", .data = &sdhi_quirks_bad_taps2367 },
+     { .soc_id = "r8a779m3", .data = &sdhi_quirks_bad_taps1357 },

Could we reuse the entries for H3 and M3 instead, by dropping the "ES3.*" revision ?

From: Geert Uytterhoeven, Sent: Tuesday, June 15, 2021 4:32 AM

Hi Laurent,

Quoted 7 lines · Laurent Pinchart

Quoted 5 lines · Geert Uytterhoeven

Add support for the R-Car H3e-2G (R8A779M1) and M3e-2G (R8A779M3) SoCs. These are different gradings of the R-Car H3 ES3.0 (R8A77951) and M3-W+ (R8A77961) SoCs, and thus subject to the same quirks.

Signed-off-by Geert Uytterhoeven <[email protected]>

Quoted 11 lines

drivers/mmc/host/renesas_sdhi_core.c static const struct soc_device_attribute sdhi_quirks_match[] = { · line 947

Quoted 8 lines

drivers/mmc/host/renesas_sdhi_core.c +2 -0

@@ -943,6 +943,8 @@ static const struct soc_device_attribute sdhi_quirks_match[]  = {
      { .soc_id = "r8a77965", .data = &sdhi_quirks_r8a77965 },
      { .soc_id = "r8a77980", .data = &sdhi_quirks_nohs400 },
      { .soc_id = "r8a77990", .data = &sdhi_quirks_r8a77990 },
+     { .soc_id = "r8a779m1", .data = &sdhi_quirks_bad_taps2367 },
+     { .soc_id = "r8a779m3", .data = &sdhi_quirks_bad_taps1357 },

Could we reuse the entries for H3 and M3 instead, by dropping the "ES3.*" revision ?

We cannot reuse the H3 ES3.0 entry, as soc_device_match() works differently than of_machine_is_compatible(): the former doesn't consider "r8a779m1" and "r8a7795" equivalent, the latter does. Same for M3-W+ (no explicit ES3.0 there) and M3e-2G.

It's a pity we still don't have a "quirk-free" SDHI version on H3 and M3-W class SoCs (waiting for ES4.0?), as that would allow us to just match on "renesas,sdhi-r8a7795" resp. "renesas,sdhi-r8a77961" through the driver's .of_match_table[] instead, which would work for H3e-2G and M3e-2G, too.

Quoted 17 lines

Quoted 11 lines

drivers/mmc/host/renesas_sdhi_core.c static const struct soc_device_attribute sdhi_quirks_match[] = { · line 947

Quoted 8 lines

drivers/mmc/host/renesas_sdhi_core.c +2 -0

@@ -943,6 +943,8 @@ static const struct soc_device_attribute sdhi_quirks_match[]  = {
      { .soc_id = "r8a77965", .data = &sdhi_quirks_r8a77965 },
      { .soc_id = "r8a77980", .data = &sdhi_quirks_nohs400 },
      { .soc_id = "r8a77990", .data = &sdhi_quirks_r8a77990 },
+     { .soc_id = "r8a779m1", .data = &sdhi_quirks_bad_taps2367 },
+     { .soc_id = "r8a779m3", .data = &sdhi_quirks_bad_taps1357 },

Could we reuse the entries for H3 and M3 instead, by dropping the "ES3.*" revision ?

We cannot reuse the H3 ES3.0 entry, as soc_device_match() works differently than of_machine_is_compatible(): the former doesn't consider "r8a779m1" and "r8a7795" equivalent, the latter does. Same for M3-W+ (no explicit ES3.0 there) and M3e-2G.

Quoted 5 lines

It's a pity we still don't have a "quirk-free" SDHI version on H3 and M3-W class SoCs (waiting for ES4.0?), as that would allow us to just match on "renesas,sdhi-r8a7795" resp. "renesas,sdhi-r8a77961" through the driver's .of_match_table[] instead, which would work for H3e-2G and M3e-2G, too.

Perhaps, ES4.0 will not be released. So, we can refactor the driver's .of_match_table[] now. I investigated this a little, and it seems we need many renesas_sdhi_of_data for each SoC instead of of_rcar_gen3_compatible. But, I guess such modification is better than adding sdhi_quirks_match entries.

Wolfram-san, what do you thinks?

From: Wolfram Sang, Sent: Thursday, June 24, 2021 3:15 PM

Hi all,

Quoted 29 lines

Quoted 17 lines

Quoted 11 lines

drivers/mmc/host/renesas_sdhi_core.c static const struct soc_device_attribute sdhi_quirks_match[] = { · line 947

Quoted 8 lines

drivers/mmc/host/renesas_sdhi_core.c +2 -0

@@ -943,6 +943,8 @@ static const struct soc_device_attribute sdhi_quirks_match[]  = {
      { .soc_id = "r8a77965", .data = &sdhi_quirks_r8a77965 },
      { .soc_id = "r8a77980", .data = &sdhi_quirks_nohs400 },
      { .soc_id = "r8a77990", .data = &sdhi_quirks_r8a77990 },
+     { .soc_id = "r8a779m1", .data = &sdhi_quirks_bad_taps2367 },
+     { .soc_id = "r8a779m3", .data = &sdhi_quirks_bad_taps1357 },

Could we reuse the entries for H3 and M3 instead, by dropping the "ES3.*" revision ?

We cannot reuse the H3 ES3.0 entry, as soc_device_match() works differently than of_machine_is_compatible(): the former doesn't consider "r8a779m1" and "r8a7795" equivalent, the latter does. Same for M3-W+ (no explicit ES3.0 there) and M3e-2G.

Quoted 5 lines

It's a pity we still don't have a "quirk-free" SDHI version on H3 and M3-W class SoCs (waiting for ES4.0?), as that would allow us to just match on "renesas,sdhi-r8a7795" resp. "renesas,sdhi-r8a77961" through the driver's .of_match_table[] instead, which would work for H3e-2G and M3e-2G, too.

Perhaps, ES4.0 will not be released. So, we can refactor the driver's .of_match_table[] now. I investigated this a little, and it seems we need many renesas_sdhi_of_data for each SoC instead of of_rcar_gen3_compatible. But, I guess such modification is better than adding sdhi_quirks_match entries.

Quoted 1 line

Wolfram-san, what do you thinks?

I don't fully understand how the refactoring should look like? Is it moving 'struct renesas_sdhi_quirks' to renesas_sdhi_internal_dmac.c and merge it there with renesas_sdhi_of_data? Is it really better to copy this struct per SoC? Most of the data is the same.

Thanks,

Wolfram

Quoted 5 lines

I don't fully understand how the refactoring should look like? Is it moving 'struct renesas_sdhi_quirks' to renesas_sdhi_internal_dmac.c and merge it there with renesas_sdhi_of_data? Is it really better to copy this struct per SoC? Most of the data is the same.

I also have the same concern. But, I guess we can refactor the renesas_sdhi_of_data like below to avoid increasing data size:

struct renesas_sdhi_of_data_with_quirks {
	const struct renesas_sdhi_of_data *of_data;
	const struct renesas_sdhi_quirks *quirks;
};

And then, we can keep of_rcar_gen3_compatible and we can add each SoC's renesas_sdhi_of_data_with_quirks and set it to the .data.

From: Wolfram Sang, Sent: Friday, June 25, 2021 12:20 AM

Quoted 13 lines

Quoted 4 lines

I don't fully understand how the refactoring should look like? Is it moving 'struct renesas_sdhi_quirks' to renesas_sdhi_internal_dmac.c and merge it there with renesas_sdhi_of_data? Is it really better to copy this struct per SoC? Most of the data is the same.

I also have the same concern. But, I guess we can refactor the renesas_sdhi_of_data like below to avoid increasing data size:

struct renesas_sdhi_of_data_with_quirks {
	const struct renesas_sdhi_of_data *of_data;
	const struct renesas_sdhi_quirks *quirks;
};

Quoted 3 lines

And then, we can keep of_rcar_gen3_compatible and we can add each SoC's renesas_sdhi_of_data_with_quirks and set it to the .data.

That sounds like a reasonable approach to me. This would also allow us to merge the quirks from sdhi_core with the quirks from sdhi_internal_dmac.

Add support for the Renesas R-Car H3e-2G (R8A779M1) SoC, which is a different grading of the R-Car H3 ES3.0 (R8A77951) SoC.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 arch/arm64/boot/dts/renesas/r8a779m1.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a779m1.dtsi

arch/arm64/boot/dts/renesas/r8a779m1.dtsi new file +1 -0

new file mode 100644
index 0000000000000000..0e9b04469b83c661
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0 or MIT)

arch/arm64/boot/dts/renesas/r8a779m1.dtsi new file +1 -0

+};

From: Geert Uytterhoeven, Sent: Thursday, June 10, 2021 6:37 PM

Add support for the Renesas R-Car H3e-2G (R8A779M1) SoC, which is a different grading of the R-Car H3 ES3.0 (R8A77951) SoC.

Signed-off-by Geert Uytterhoeven <[email protected]>

From: Geert Uytterhoeven, Sent: Thursday, June 10, 2021 6:37 PM

Add support for the Renesas R-Car M3e-2G (R8A779M3) SoC, which is a different grading of the R-Car M3-W+ (R8A77961) SoC.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 arch/arm64/boot/dts/renesas/r8a779m3.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a779m3.dtsi

arch/arm64/boot/dts/renesas/r8a779m3.dtsi new file +12 -1

new file mode 100644
index 0000000000000000..65bb6188ccf5470a
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0 or MIT)
+/*
+ * Device Tree Source for the R-Car M3e-2G (R8A779M3) SoC
+ *
+ * Copyright (C) 2021 Glider bv
+ */
+
+#include "r8a77961.dtsi"
+
+/ {
+	compatible = "renesas,r8a779m3", "renesas,r8a77961";
+};
--

2.25.1

Add support for the Renesas Salvator-X 2nd version development board equipped with an R-Car H3e-2G SiP.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 arch/arm64/boot/dts/renesas/Makefile          |  2 +
 .../boot/dts/renesas/r8a779m1-salvator-xs.dts | 53 +++++++++++++++++++
 2 files changed, 55 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a779m1-salvator-xs.dts

arch/arm64/boot/dts/renesas/Makefile +0 -0

index f2de2fa0c8b890fb..5a689a1d10821f1d 100644

arch/arm64/boot/dts/renesas/r8a779m1-salvator-xs.dts new file +53 -0

new file mode 100644
index 0000000000000000..084b75b046802339
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: (GPL-2.0 or MIT)
+/*
+ * Device Tree Source for the Salvator-X 2nd version board with R-Car H3e-2G
+ *
+ * Copyright (C) 2021 Glider bv
+ *
+ * Based on r8a77951-salvator-xs.dts
+ * Copyright (C) 2015-2017 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+#include "r8a779m1.dtsi"
+#include "salvator-xs.dtsi"
+
+/ {
+	model = "Renesas Salvator-X 2nd version board based on r8a779m1";
+	compatible = "renesas,salvator-xs", "renesas,r8a779m1",
+		     "renesas,r8a7795";
+
+	memory@48000000 {
+		device_type = "memory";
+		/* first 128MB is reserved for secure area. */
+		reg = <0x0 0x48000000 0x0 0x38000000>;
+	};
+
+	memory@500000000 {
+		device_type = "memory";
+		reg = <0x5 0x00000000 0x0 0x40000000>;
+	};
+
+	memory@600000000 {
+		device_type = "memory";
+		reg = <0x6 0x00000000 0x0 0x40000000>;
+	};
+
+	memory@700000000 {
+		device_type = "memory";
+		reg = <0x7 0x00000000 0x0 0x40000000>;
+	};
+};
+
+&du {
+	clocks = <&cpg CPG_MOD 724>,
+		 <&cpg CPG_MOD 723>,
+		 <&cpg CPG_MOD 722>,
+		 <&cpg CPG_MOD 721>,
+		 <&versaclock6 1>,
+		 <&x21_clk>,
+		 <&x22_clk>,
+		 <&versaclock6 2>;
+	clock-names = "du.0", "du.1", "du.2", "du.3",
+		      "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
+};

Quoted 10 lines · Geert Uytterhoeven

Add support for the Renesas Salvator-X 2nd version development board equipped with an R-Car H3e-2G SiP.

Signed-off-by Geert Uytterhoeven <[email protected]>

arch/arm64/boot/dts/renesas/Makefile +0 -0

@@ -62,3 +62,5 @@ dtb-$(CONFIG_ARCH_R8A77990) += r8a77990-ebisu.dtb
 dtb-$(CONFIG_ARCH_R8A77995) += r8a77995-draak.dtb
 

arch/arm64/boot/dts/renesas/Makefile dtb-$(CONFIG_ARCH_R8A77990) += r8a77990-ebisu.dtb · line 66

Quoted 3 lines

arch/arm64/boot/dts/renesas/Makefile +2 -0

 dtb-$(CONFIG_ARCH_R8A779A0) += r8a779a0-falcon.dtb
+
+dtb-$(CONFIG_ARCH_R8A77951) += r8a779m1-salvator-xs.dtb

How about preserving the alphabetical order of the Kconfig symbols ?

Reviewed-by Laurent Pinchart <[email protected]>

From: Geert Uytterhoeven, Sent: Tuesday, June 15, 2021 4:34 AM

Hi Laurent,

Quoted 11 lines · Laurent Pinchart

Quoted 10 lines · Geert Uytterhoeven

Add support for the Renesas Salvator-X 2nd version development board equipped with an R-Car H3e-2G SiP.

Signed-off-by Geert Uytterhoeven <[email protected]>

arch/arm64/boot/dts/renesas/Makefile +0 -0

@@ -62,3 +62,5 @@ dtb-$(CONFIG_ARCH_R8A77990) += r8a77990-ebisu.dtb
 dtb-$(CONFIG_ARCH_R8A77995) += r8a77995-draak.dtb
 

Quoted 5 lines

arch/arm64/boot/dts/renesas/Makefile dtb-$(CONFIG_ARCH_R8A77990) += r8a77990-ebisu.dtb · line 66

Quoted 3 lines

arch/arm64/boot/dts/renesas/Makefile +2 -0

 dtb-$(CONFIG_ARCH_R8A779A0) += r8a779a0-falcon.dtb
+
+dtb-$(CONFIG_ARCH_R8A77951) += r8a779m1-salvator-xs.dtb

How about preserving the alphabetical order of the Kconfig symbols ?

At the expense of breaking alphabetical order of the DTB file names?

I agree both make sense. Do we need a vote? ;-)

Add support for the Renesas R-Car Starter Kit Premier equipped with an R-Car H3e-2G SiP.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 arch/arm64/boot/dts/renesas/Makefile          |  1 +
 arch/arm64/boot/dts/renesas/r8a779m1-ulcb.dts | 54 +++++++++++++++++++
 2 files changed, 55 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a779m1-ulcb.dts

arch/arm64/boot/dts/renesas/Makefile +1 -0

index 5a689a1d10821f1d..2a9119c8651815eb 100644
@@ -64,3 +64,4 @@ dtb-$(CONFIG_ARCH_R8A77995) += r8a77995-draak.dtb
 dtb-$(CONFIG_ARCH_R8A779A0) += r8a779a0-falcon.dtb
 
 dtb-$(CONFIG_ARCH_R8A77951) += r8a779m1-salvator-xs.dtb
+dtb-$(CONFIG_ARCH_R8A77951) += r8a779m1-ulcb.dtb

arch/arm64/boot/dts/renesas/r8a779m1-ulcb.dts new file +54 -0

new file mode 100644
index 0000000000000000..e294b6bda28c68c8
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: (GPL-2.0 or MIT)
+/*
+ * Device Tree Source for the H3ULCB (R-Car Starter Kit Premier) with R-Car H3e-2G
+ *
+ * Copyright (C) 2021 Glider bv
+ *
+ * Based on r8a77951-ulcb.dts
+ *
+ * Copyright (C) 2016 Renesas Electronics Corp.
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ */
+
+/dts-v1/;
+#include "r8a779m1.dtsi"
+#include "ulcb.dtsi"
+
+/ {
+	model = "Renesas H3ULCB board based on r8a779m1";
+	compatible = "renesas,h3ulcb", "renesas,r8a779m1", "renesas,r8a7795";
+
+	memory@48000000 {
+		device_type = "memory";
+		/* first 128MB is reserved for secure area. */
+		reg = <0x0 0x48000000 0x0 0x38000000>;
+	};
+
+	memory@500000000 {
+		device_type = "memory";
+		reg = <0x5 0x00000000 0x0 0x40000000>;
+	};
+
+	memory@600000000 {
+		device_type = "memory";
+		reg = <0x6 0x00000000 0x0 0x40000000>;
+	};
+
+	memory@700000000 {
+		device_type = "memory";
+		reg = <0x7 0x00000000 0x0 0x40000000>;
+	};
+};
+
+&du {
+	clocks = <&cpg CPG_MOD 724>,
+		 <&cpg CPG_MOD 723>,
+		 <&cpg CPG_MOD 722>,
+		 <&cpg CPG_MOD 721>,
+		 <&versaclock5 1>,
+		 <&versaclock5 3>,
+		 <&versaclock5 4>,
+		 <&versaclock5 2>;
+	clock-names = "du.0", "du.1", "du.2", "du.3",
+		      "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
+};

Signature · 1 line

2.25.1

Add support for the Renesas R-Car Starter Kit Premier and Kingfisher combo equipped with an R-Car H3e-2G SiP.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 arch/arm64/boot/dts/renesas/Makefile          |  1 +
 .../boot/dts/renesas/r8a779m1-ulcb-kf.dts     | 19 +++++++++++++++++++
 2 files changed, 20 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a779m1-ulcb-kf.dts

arch/arm64/boot/dts/renesas/Makefile +1 -0

index 2a9119c8651815eb..4fa0d56602684faf 100644
@@ -65,3 +65,4 @@ dtb-$(CONFIG_ARCH_R8A779A0) += r8a779a0-falcon.dtb
 
 dtb-$(CONFIG_ARCH_R8A77951) += r8a779m1-salvator-xs.dtb
 dtb-$(CONFIG_ARCH_R8A77951) += r8a779m1-ulcb.dtb
+dtb-$(CONFIG_ARCH_R8A77951) += r8a779m1-ulcb-kf.dtb

arch/arm64/boot/dts/renesas/r8a779m1-ulcb-kf.dts new file +19 -0

new file mode 100644
index 0000000000000000..0baebc5c58b06a34
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: (GPL-2.0 or MIT)
+/*
+ * Device Tree Source for the H3ULCB Kingfisher board with R-Car H3e-2G
+ *
+ * Copyright (C) 2021 Glider bv
+ *
+ * Based on r8a77951-ulcb-kf.dts
+ * Copyright (C) 2017 Renesas Electronics Corp.
+ * Copyright (C) 2017 Cogent Embedded, Inc.
+ */
+
+#include "r8a779m1-ulcb.dts"
+#include "ulcb-kf.dtsi"
+
+/ {
+	model = "Renesas H3ULCB Kingfisher board based on r8a779m1";
+	compatible = "shimafuji,kingfisher", "renesas,h3ulcb",
+		     "renesas,r8a779m1", "renesas,r8a7795";
+};

Add support for the Renesas Salvator-X 2nd version development board equipped with an R-Car M3e-2G SiP.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 arch/arm64/boot/dts/renesas/Makefile          |  2 +
 .../boot/dts/renesas/r8a779m3-salvator-xs.dts | 46 +++++++++++++++++++
 2 files changed, 48 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a779m3-salvator-xs.dts

arch/arm64/boot/dts/renesas/Makefile +0 -0

index 4fa0d56602684faf..6a1061824a9f29f0 100644

arch/arm64/boot/dts/renesas/r8a779m3-salvator-xs.dts new file +46 -0

new file mode 100644
index 0000000000000000..4ab26fd7233d62fc
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: (GPL-2.0 or MIT)
+/*
+ * Device Tree Source for the Salvator-X 2nd version board with R-Car M3e-2G
+ *
+ * Copyright (C) 2021 Glider bv
+ *
+ * Based on r8a77961-salvator-xs.dts
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+#include "r8a779m3.dtsi"
+#include "salvator-xs.dtsi"
+
+/ {
+	model = "Renesas Salvator-X 2nd version board based on r8a779m3";
+	compatible = "renesas,salvator-xs", "renesas,r8a779m3",
+		     "renesas,r8a77961";
+
+	memory@48000000 {
+		device_type = "memory";
+		/* first 128MB is reserved for secure area. */
+		reg = <0x0 0x48000000 0x0 0x78000000>;
+	};
+
+	memory@480000000 {
+		device_type = "memory";
+		reg = <0x4 0x80000000 0x0 0x80000000>;
+	};
+
+	memory@600000000 {
+		device_type = "memory";
+		reg = <0x6 0x00000000 0x1 0x00000000>;
+	};
+};
+
+&du {
+	clocks = <&cpg CPG_MOD 724>,
+		 <&cpg CPG_MOD 723>,
+		 <&cpg CPG_MOD 722>,
+		 <&versaclock6 1>,
+		 <&x21_clk>,
+		 <&versaclock6 2>;
+	clock-names = "du.0", "du.1", "du.2",
+		      "dclkin.0", "dclkin.1", "dclkin.2";
+};

Add support for the Renesas R-Car Starter Kit Pro equipped with an R-Car M3e-2G SiP.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 arch/arm64/boot/dts/renesas/Makefile          |  1 +
 arch/arm64/boot/dts/renesas/r8a779m3-ulcb.dts | 45 +++++++++++++++++++
 2 files changed, 46 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a779m3-ulcb.dts

arch/arm64/boot/dts/renesas/Makefile +1 -0

index 6a1061824a9f29f0..f29dd27692ba4a66 100644
@@ -68,3 +68,4 @@ dtb-$(CONFIG_ARCH_R8A77951) += r8a779m1-ulcb.dtb
 dtb-$(CONFIG_ARCH_R8A77951) += r8a779m1-ulcb-kf.dtb
 
 dtb-$(CONFIG_ARCH_R8A77961) += r8a779m3-salvator-xs.dtb
+dtb-$(CONFIG_ARCH_R8A77961) += r8a779m3-ulcb.dtb

arch/arm64/boot/dts/renesas/r8a779m3-ulcb.dts new file +45 -0

new file mode 100644
index 0000000000000000..8f215a0b771b7c30
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: (GPL-2.0 or MIT)
+/*
+ * Device Tree Source for the M3ULCB (R-Car Starter Kit Pro) with R-Car M3e-2G
+ *
+ * Copyright (C) 2021 Glider bv
+ *
+ * Based on r8a77961-ulcb.dts
+ * Copyright (C) 2020 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+#include "r8a779m3.dtsi"
+#include "ulcb.dtsi"
+
+/ {
+	model = "Renesas M3ULCB board based on r8a779m3";
+	compatible = "renesas,m3ulcb", "renesas,r8a779m3", "renesas,r8a77961";
+
+	memory@48000000 {
+		device_type = "memory";
+		/* first 128MB is reserved for secure area. */
+		reg = <0x0 0x48000000 0x0 0x78000000>;
+	};
+
+	memory@480000000 {
+		device_type = "memory";
+		reg = <0x4 0x80000000 0x0 0x80000000>;
+	};
+
+	memory@600000000 {
+		device_type = "memory";
+		reg = <0x6 0x00000000 0x1 0x00000000>;
+	};
+};
+
+&du {
+	clocks = <&cpg CPG_MOD 724>,
+		 <&cpg CPG_MOD 723>,
+		 <&cpg CPG_MOD 722>,
+		 <&versaclock5 1>,
+		 <&versaclock5 3>,
+		 <&versaclock5 2>;
+	clock-names = "du.0", "du.1", "du.2",
+		      "dclkin.0", "dclkin.1", "dclkin.2";
+};

Add support for the Renesas R-Car Starter Kit Pro and Kingfisher combo equipped with an R-Car M3e-2G SiP.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 arch/arm64/boot/dts/renesas/Makefile           |  1 +
 .../boot/dts/renesas/r8a779m3-ulcb-kf.dts      | 18 ++++++++++++++++++
 2 files changed, 19 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a779m3-ulcb-kf.dts

arch/arm64/boot/dts/renesas/Makefile +1 -0

index f29dd27692ba4a66..5c73eb7baeadc8c4 100644
@@ -69,3 +69,4 @@ dtb-$(CONFIG_ARCH_R8A77951) += r8a779m1-ulcb-kf.dtb
 
 dtb-$(CONFIG_ARCH_R8A77961) += r8a779m3-salvator-xs.dtb
 dtb-$(CONFIG_ARCH_R8A77961) += r8a779m3-ulcb.dtb
+dtb-$(CONFIG_ARCH_R8A77961) += r8a779m3-ulcb-kf.dtb

arch/arm64/boot/dts/renesas/r8a779m3-ulcb-kf.dts new file +18 -0

new file mode 100644
index 0000000000000000..6bacee1d2ef5c857
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: (GPL-2.0 or MIT)
+/*
+ * Device Tree Source for the M3ULCB Kingfisher board with R-Car M3e-2G
+ *
+ * Copyright (C) 2021 Glider bv
+ *
+ * Based on r8a77961-ulcb-kf.dts
+ * Copyright (C) 2020 Eugeniu Rosca <[email protected]>
+ */
+
+#include "r8a779m3-ulcb.dts"
+#include "ulcb-kf.dtsi"
+
+/ {
+	model = "Renesas M3ULCB Kingfisher board based on r8a779m3";
+	compatible = "shimafuji,kingfisher", "renesas,m3ulcb",
+		     "renesas,r8a779m3", "renesas,r8a77961";
+};

From: Geert Uytterhoeven, Sent: Thursday, June 10, 2021 6:37 PM

Add a preliminary operating point for running the Cortex-A57 CPU cores on R-Car H3e-2G at 2 GHz.

The opp-microvolt value depends on a future update of the Electrical Characteristics for R-Car H3e-2G.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 arch/arm64/boot/dts/renesas/r8a779m1.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

arch/arm64/boot/dts/renesas/r8a779m1.dtsi +0 -0

index 0e9b04469b83c661..01b4e787e5749219 100644

arch/arm64/boot/dts/renesas/r8a779m1.dtsi +4 -1

+		clock-latency-ns = <300000>;
+		turbo-mode;
+	};
+};
--

2.25.1

From: Geert Uytterhoeven, Sent: Thursday, June 10, 2021 6:37 PM

Add a preliminary operating point for running the Cortex-A57 CPU cores on R-Car M3e-2G at 2 GHz.

The opp-microvolt value depends on a future update of the Electrical Characteristics for R-Car M3e-2G.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 arch/arm64/boot/dts/renesas/r8a779m3.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

arch/arm64/boot/dts/renesas/r8a779m3.dtsi +0 -0

index 65bb6188ccf5470a..fa5e8ffdf7343739 100644

arch/arm64/boot/dts/renesas/r8a779m3.dtsi +4 -1

+		clock-latency-ns = <300000>;
+		turbo-mode;
+	};
+};
--

2.25.1