ARM/arm64 : shmobile/renesas: Add L2 cache-controller nodes

Add device nodes for the L2 caches, and link the CPU node to its L2 cache node.

The L2 cache for the Cortex-A57 CPU cores is 2 MiB large (organized as 128 KiB x 16 ways), and requires the following settings:
- Tag RAM latency: 3 cycles,
- Data RAM latency: 4 cycles,
- Data RAM setup: 1 cycles,

The L2 cache for the Cortex-A53 CPU cores is 512 KiB large (organized as 32 KiB x 16 ways).

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

---
What are the DT bindings for Cortex-A57/A53 L2 cache controllers?

v2:
- New.

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

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

index 816400c1bee604db..30063546c7e9bbea 100644
@@ -35,9 +35,24 @@
  			compatible = "arm,cortex-a57", "arm,armv8";

arch/arm64/boot/dts/renesas/r8a7795.dtsi line 45

Quoted 4 lines · Geert Uytterhoeven

arch/arm64/boot/dts/renesas/r8a7795.dtsi +4 -0

+	L2_CA57: cache-controller at 0 {
+		compatible = "cache";
+		arm,data-latency = <4 4 1>;
+		arm,tag-latency = <3 3 3>;

Interesting, only PL2xx/3xx cache controller driver reads this from the DT and configures the controller. The integrated L2 found in A15/A7/A57/A53 needs doesn't make use of these values from the DT.

Quoted 6 lines · Sudeep Holla

Quoted 4 lines · Geert Uytterhoeven

arch/arm64/boot/dts/renesas/r8a7795.dtsi +4 -0

+    L2_CA57: cache-controller at 0 {
+            compatible = "cache";
+            arm,data-latency = <4 4 1>;
+            arm,tag-latency = <3 3 3>;

Quoted 3 lines

Interesting, only PL2xx/3xx cache controller driver reads this from the DT and configures the controller. The integrated L2 found in A15/A7/A57/A53 needs doesn't make use of these values from the DT.

These properties seem to be from l2cc.txt, which really only corresponds to PL210/PL220/PL310 (and variants) and isn't as generic as it sounds.

I don't see that these are necessary at all.

Quoted 11 lines · Mark Rutland

Quoted 9 lines · Sudeep Holla

arch/arm64/boot/dts/renesas/r8a7795.dtsi line 45

Quoted 4 lines · Geert Uytterhoeven

arch/arm64/boot/dts/renesas/r8a7795.dtsi +4 -0

+    L2_CA57: cache-controller at 0 {
+            compatible = "cache";
+            arm,data-latency = <4 4 1>;
+            arm,tag-latency = <3 3 3>;

Interesting, only PL2xx/3xx cache controller driver reads this from the DT and configures the controller. The integrated L2 found in A15/A7/A57/A53 needs doesn't make use of these values from the DT.

Quoted 4 lines

These properties seem to be from l2cc.txt, which really only corresponds to PL210/PL220/PL310 (and variants) and isn't as generic as it sounds.

I don't see that these are necessary at all.

The datasheet does mention the data/tag RAM latencies/setup values, so I put them in DT using the properties I could fine.

Quoted 10 lines · Sudeep Holla

Review

Quoted 4 lines · Geert Uytterhoeven

(quoted diff) +4 -0

+	L2_CA57: cache-controller at 0 {
+		compatible = "cache";
+		arm,data-latency = <4 4 1>;
+		arm,tag-latency = <3 3 3>;

Interesting, only PL2xx/3xx cache controller driver reads this from the DT and configures the controller. The integrated L2 found in A15/A7/A57/A53 needs doesn't make use of these values from the DT.

These properties seem to be from l2cc.txt, which really only corresponds to PL210/PL220/PL310 (and variants) and isn't as generic as it sounds.

I don't see that these are necessary at all.

Quoted 8 lines · Mark Rutland

Quoted 7 lines · Sudeep Holla

Quoted 4 lines · Geert Uytterhoeven

(quoted diff) +4 -0

+    L2_CA57: cache-controller at 0 {
+        compatible = "cache";
+        arm,data-latency = <4 4 1>;
+        arm,tag-latency = <3 3 3>;

Quoted 8 lines

Quoted 3 lines

Interesting, only PL2xx/3xx cache controller driver reads this from the DT and configures the controller. The integrated L2 found in A15/A7/A57/A53 needs doesn't make use of these values from the DT.

These properties seem to be from l2cc.txt, which really only corresponds to PL210/PL220/PL310 (and variants) and isn't as generic as it sounds.

I don't see that these are necessary at all.

What's about a documentation patch like [1], then?

For what is the arm64 dts entry

cpu at 0 {
     ...
     next-level-cache = <&L2_0>;
};

L2_0: l2-cache0 {
     compatible = "cache";
};

good for at all, then?

Best regards

Dirk

[1]

Documentation/devicetree/bindings/arm/l2cc.txt +0 -1

index 06c88a4..f687aed 100644
@@ -1,12 +1,18 @@
  * ARM L2 Cache Controller
 
-ARM cores often have a separate level 2 cache controller. There are

various
+ARM 32-bit cores often have a separate level 2 cache controller. There are various
implementations of the L2 cache controller with compatible programming
models.
Some of the properties that are just prefixed "cache-*" are taken from
section
3.7.3 of the ePAPR v1.1 specification which can be found at:

https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf

-The ARM L2 cache representation in the device tree should be done as follows:
+ARM 64-bit cores (e.g. A15/A7/A57/A53) have an integrated level 2 cache which

Quoted 12 lines · Mark Rutland

Quoted 10 lines · Sudeep Holla

Review

Quoted 4 lines · Geert Uytterhoeven

(quoted diff) +4 -0

+	L2_CA57: cache-controller at 0 {
+		compatible = "cache";
+		arm,data-latency = <4 4 1>;
+		arm,tag-latency = <3 3 3>;

Interesting, only PL2xx/3xx cache controller driver reads this from the DT and configures the controller. The integrated L2 found in A15/A7/A57/A53 needs doesn't make use of these values from the DT.

Quoted 4 lines

These properties seem to be from l2cc.txt, which really only corresponds to PL210/PL220/PL310 (and variants) and isn't as generic as it sounds.

I don't see that these are necessary at all.

What's about a documentation patch like [1], then?

For what is the arm64 dts entry

cpu at 0 {
	...
	next-level-cache = <&L2_0>;
};

L2_0: l2-cache0 {
	compatible = "cache";
};

good for at all, then?

[1]

Documentation/devicetree/bindings/arm/l2cc.txt +0 -1

index 06c88a4..f687aed 100644
@@ -1,12 +1,18 @@
 * ARM L2 Cache Controller
 
-ARM cores often have a separate level 2 cache controller. There are

various
+ARM 32-bit cores often have a separate level 2 cache controller. There are various
implementations of the L2 cache controller with compatible
programming models.
Some of the properties that are just prefixed "cache-*" are taken
from section
3.7.3 of the ePAPR v1.1 specification which can be found at:

https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf

-The ARM L2 cache representation in the device tree should be done as follows:
+ARM 64-bit cores (e.g. A15/A7/A57/A53) have an integrated level 2 cache which

Documentation/devicetree/bindings/arm/l2cc.txt +5 -0

+doesn't make use of any values from the kernel device tree. There is no
+L2 cache configuration done in the kernel. The L2 cache is assumed to be
+preconfigured by early secure boot code.
+
+The ARM L2 cache representation for 32-bit cores in the device tree

should be done
+as follows:

Required properties:

Quoted 19 lines · Dirk Behme

Quoted 16 lines · Mark Rutland

Quoted 10 lines · Sudeep Holla

Review

Quoted 4 lines · Geert Uytterhoeven

(quoted diff) +4 -0

+	L2_CA57: cache-controller at 0 {
+		compatible = "cache";
+		arm,data-latency = <4 4 1>;
+		arm,tag-latency = <3 3 3>;

Interesting, only PL2xx/3xx cache controller driver reads this from the DT and configures the controller. The integrated L2 found in A15/A7/A57/A53 needs doesn't make use of these values from the DT.

These properties seem to be from l2cc.txt, which really only corresponds to PL210/PL220/PL310 (and variants) and isn't as generic as it sounds.

I don't see that these are necessary at all.

Quoted 1 line

What's about a documentation patch like [1], then?

I think it would be better to s/l2cc/l2x0/, and to make it clear that the document only applies to the variants listed above.

If ePAPR doesn't cover the other cases, we should document those separately.

Quoted 11 lines

For what is the arm64 dts entry

cpu at 0 {
	...
	next-level-cache = <&L2_0>;
};

L2_0: l2-cache0 {
	compatible = "cache";
};

Quoted 1 line

good for at all, then?

With the other properties from ePAPR you can acquire information on the geometry of the cache, which cannot be acquired from architected registers.

On 08.12.2015 20:16, Mark Rutland wrote:

Quoted 4 lines

With the other properties from ePAPR you can acquire information on the geometry of the cache, which cannot be acquired from architected registers.

Just for my understanding: Yes, if other properties from ePAPR like geometry of the cache are added to the device tree l2 cache entries then it makes sense to have them.

But an "empty" entry like the one given in the example above doesn't make much sense and could be removed without loosing any functionality?

It looks to me that most of the L2 entries we have in arch/arm64/boot/dts are such "empty" entries.

Quoted 11 lines

Quoted 11 lines

For what is the arm64 dts entry

cpu at 0 {
	...
	next-level-cache = <&L2_0>;
};

L2_0: l2-cache0 {
	compatible = "cache";
};

Quoted 5 lines

Quoted 1 line

good for at all, then?

With the other properties from ePAPR you can acquire information on the geometry of the cache, which cannot be acquired from architected registers.

Just for my understanding: Yes, if other properties from ePAPR like geometry of the cache are added to the device tree l2 cache entries then it makes sense to have them.

But an "empty" entry like the one given in the example above doesn't make much sense and could be removed without loosing any functionality?

It looks to me that most of the L2 entries we have in arch/arm64/boot/dts are such "empty" entries.

Is this understanding correct?

Quoted 22 lines · Dirk Behme

Quoted 11 lines

Quoted 11 lines

For what is the arm64 dts entry

cpu at 0 {
	...
	next-level-cache = <&L2_0>;
};

L2_0: l2-cache0 {
	compatible = "cache";
};

Quoted 5 lines

Quoted 1 line

good for at all, then?

With the other properties from ePAPR you can acquire information on the geometry of the cache, which cannot be acquired from architected registers.

Just for my understanding: Yes, if other properties from ePAPR like geometry of the cache are added to the device tree l2 cache entries then it makes sense to have them.

Quoted 8 lines

But an "empty" entry like the one given in the example above doesn't make much sense and could be removed without loosing any functionality?

It looks to me that most of the L2 entries we have in arch/arm64/boot/dts are such "empty" entries.

Is this understanding correct?

You are mostly correct, just missing some history.

It was previously (erroneously) assumed that the cache geometry could be derived from architected registers used for set/way maintenance. However, we knew that this did not describe how those caches were linked to each other (e.g. which CPU shared with level x cache). So the description in DT was required to provide that.

Now, we all know that the geometry is necessary too. Those DTs should be fixed.

Sudeep, do you know what's happening on that front?

Hi Simon, Magnus,

This patch series adds the missing L2 cache-controller nodes to the DTSes for various Renesas ARM-based SoCs, and links the CPU nodes to them.

For R-Mobile APE6 (r8a73a4), the L2 cache-controllers are also linked to the respective (already existing) SYSC Power Domains. Fortunately these Power Domains were never powered down, as they are parents of the Power Domains containing CPU cores. This may change in the future.

For R-Car Gen2 and Gen3 (r8a779x), this serves as a preparatory step for adding SYSC Power Domain support later.

Question for the ARM/DT people: What are the DT bindings for Cortex-A15/A7/A57/A53 L2 cache controllers?
Everybody just seems to use "cache" for the compatible values...

Patches 2-5 were extracted from series "[PATCH/RFC 00/15]
ARM: shmobile: R-Car: Add SYSC PM Domain DT Support",
(http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348742.html)
and received some fixes. You can find more detailed changelogs in the individual patches).

This has been tested on r8a73a4/ape6evm, r8a7791/koelsch, and r8a7795/salvator-x.

Thanks!

Geert Uytterhoeven (6):
ARM: shmobile: r8a73a4 dtsi: Add L2 cache-controller nodes
ARM: shmobile: r8a7790 dtsi: Add L2 cache-controller nodes
ARM: shmobile: r8a7791 dtsi: Add L2 cache-controller node
ARM: shmobile: r8a7793 dtsi: Add L2 cache-controller node
ARM: shmobile: r8a7794 dtsi: Add L2 cache-controller node
arm64: renesas: r8a7795: Add L2 cache-controller nodes

 arch/arm/boot/dts/r8a73a4.dtsi           | 19 +++++++++++++++++++
 arch/arm/boot/dts/r8a7790.dtsi           | 22 ++++++++++++++++++++++
 arch/arm/boot/dts/r8a7791.dtsi           | 10 ++++++++++
 arch/arm/boot/dts/r8a7793.dtsi           |  9 +++++++++
 arch/arm/boot/dts/r8a7794.dtsi           |  8 ++++++++
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 15 +++++++++++++++
 6 files changed, 83 insertions(+)

Signature · 12 lines

1.9.1

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

Quoted 22 lines · Geert Uytterhoeven

This patch series adds the missing L2 cache-controller nodes to the DTSes for various Renesas ARM-based SoCs, and links the CPU nodes to them.

For R-Mobile APE6 (r8a73a4), the L2 cache-controllers are also linked to the respective (already existing) SYSC Power Domains. Fortunately these Power Domains were never powered down, as they are parents of the Power Domains containing CPU cores. This may change in the future.

For R-Car Gen2 and Gen3 (r8a779x), this serves as a preparatory step for adding SYSC Power Domain support later.

Question for the ARM/DT people: What are the DT bindings for Cortex-A15/A7/A57/A53 L2 cache controllers?
Everybody just seems to use "cache" for the compatible values...

Patches 2-5 were extracted from series "[PATCH/RFC 00/15]
ARM: shmobile: R-Car: Add SYSC PM Domain DT Support",
(http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348742.html)
and received some fixes. You can find more detailed changelogs in the individual patches).

Quoted 2 lines

This has been tested on r8a73a4/ape6evm, r8a7791/koelsch, and r8a7795/salvator-x.

Sorry for loosing track of this until now.

It seems to me that the Gen-2 changes could be applied, is that correct?

It also seems to me that there was inconclusive discussion regarding the r8a7795 change, is that also correct.