arm64: Add L2 cache topology to ARM Ltd boards/models

Hi Arnd/Olof,

Though this patch and commit 5d425c18653731af6 ("arm64: kernel: add support for cpu cache information") which is in -next(via arm64) are dependent to provide desired functionality, then can go indepedently if you think there could be conflicts if this change is taken via arm64. If not, Catalin can pick up with your acks after the review.

Quoted 5 lines · On Wednesday 21 January 2015 12:02:30 Sudeep Holla wrote:

Though this patch and commit 5d425c18653731af6 ("arm64: kernel: add support for cpu cache information") which is in -next(via arm64) are dependent to provide desired functionality, then can go indepedently if you think there could be conflicts if this change is taken via arm64. If not, Catalin can pick up with your acks after the review.

I think it would be better to take this through arm-soc. It's not extremely likely to cause conflicts, but as you say there are no strict dependencies on which goes in first, so there is no harm in merging them separately.

Quoted 8 lines · On Wednesday 21 January 2015 12:02:30 Sudeep Holla wrote:

Hi Arnd/Olof,

Though this patch and commit 5d425c18653731af6 ("arm64: kernel: add support for cpu cache information") which is in -next(via arm64) are dependent to provide desired functionality, then can go indepedently if you think there could be conflicts if this change is taken via arm64. If not, Catalin can pick up with your acks after the review.

I think it would be better to take this through arm-soc. It's not extremely likely to cause conflicts, but as you say there are no strict dependencies on which goes in first, so there is no harm in merging them separately.

Hi Arnd,

Quoted 10 lines · Arnd Bergmann

Quoted 8 lines · On Wednesday 21 January 2015 12:02:30 Sudeep Holla wrote:

Hi Arnd/Olof,

Though this patch and commit 5d425c18653731af6 ("arm64: kernel: add support for cpu cache information") which is in -next(via arm64) are dependent to provide desired functionality, then can go indepedently if you think there could be conflicts if this change is taken via arm64. If not, Catalin can pick up with your acks after the review.

Quoted 5 lines

I think it would be better to take this through arm-soc. It's not extremely likely to cause conflicts, but as you say there are no strict dependencies on which goes in first, so there is no harm in merging them separately.

I think this patch got missed for -rc1. The arm64 architectural support patch for cacheinfo got merged via arm64 tree. It would be good if this is also merged so that cache information can be exposed to the user-space on ARM Ltd boards.

Quoted 19 lines · On Tuesday 24 February 2015 15:14:14 Sudeep Holla wrote:

Hi Arnd,

Quoted 15 lines · Arnd Bergmann

Quoted 8 lines · On Wednesday 21 January 2015 12:02:30 Sudeep Holla wrote:

Hi Arnd/Olof,

Though this patch and commit 5d425c18653731af6 ("arm64: kernel: add support for cpu cache information") which is in -next(via arm64) are dependent to provide desired functionality, then can go indepedently if you think there could be conflicts if this change is taken via arm64. If not, Catalin can pick up with your acks after the review.

I think it would be better to take this through arm-soc. It's not extremely likely to cause conflicts, but as you say there are no strict dependencies on which goes in first, so there is no harm in merging them separately.

Quoted 5 lines

I think this patch got missed for -rc1. The arm64 architectural support patch for cacheinfo got merged via arm64 tree. It would be good if this is also merged so that cache information can be exposed to the user-space on ARM Ltd boards.

Ah, bummer. I've applied this one as a fix for 4.0 because I said we'd take it and dropped the ball on it.

Commit 5d425c18653731af6 ("arm64: kernel: add support for cpu cache information") adds cacheinfo support for ARM64. Since there's no architectural way of detecting the cpus that share particular cache, device tree can be used and the core cacheinfo already supports the same.

This patch adds the L2 cache topology on Juno board, FVP/RTSM and foundation models.

Signed-off-by Sudeep Holla <[email protected]>

Cc Mark Rutland <[email protected]>

Cc Liviu Dudau <[email protected]>

Cc Lorenzo Pieralisi <[email protected]>

---
 arch/arm64/boot/dts/arm/foundation-v8.dts  |  8 ++++++++
 arch/arm64/boot/dts/arm/juno.dts           | 14 ++++++++++++++
 arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts |  8 ++++++++
 3 files changed, 30 insertions(+)

Hi Arnd/Olof,

Though this patch and commit 5d425c18653731af6 ("arm64: kernel: add support for cpu cache information") which is in -next(via arm64) are dependent to provide desired functionality, then can go indepedently if you think there could be conflicts if this change is taken via arm64. If not, Catalin can pick up with your acks after the review.

Regards,
Sudeep

arch/arm64/boot/dts/arm/foundation-v8.dts +8 -0

index 27f32962e55c..4eac8dcea423 100644
@@ -34,6 +34,7 @@
 			reg = <0x0 0x0>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 1 {
 			device_type = "cpu";

@@ -41,6 +42,7 @@
 			reg = <0x0 0x1>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 2 {
 			device_type = "cpu";

@@ -48,6 +50,7 @@
 			reg = <0x0 0x2>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 3 {
 			device_type = "cpu";

@@ -55,6 +58,11 @@
 			reg = <0x0 0x3>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
+		};
+
+		L2_0: l2-cache0 {
+			compatible = "cache";
 		};
 	};
 

arch/arm64/boot/dts/arm/juno.dts +14 -0

index cb3073e4e7a8..15dafbb24426 100644
@@ -39,6 +39,7 @@
 			reg = <0x0 0x0>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A57_L2>;
 		};
 
 		A57_1: cpu at 1 {

@@ -46,6 +47,7 @@
 			reg = <0x0 0x1>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A57_L2>;
 		};
 
 		A53_0: cpu at 100 {

@@ -53,6 +55,7 @@
 			reg = <0x0 0x100>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
 		};
 
 		A53_1: cpu at 101 {

@@ -60,6 +63,7 @@
 			reg = <0x0 0x101>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
 		};
 
 		A53_2: cpu at 102 {

@@ -67,6 +71,7 @@
 			reg = <0x0 0x102>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
 		};
 
 		A53_3: cpu at 103 {

@@ -74,6 +79,15 @@
 			reg = <0x0 0x103>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
+		};
+
+		A57_L2: l2-cache0 {
+			compatible = "cache";
+		};
+
+		A53_L2: l2-cache1 {
+			compatible = "cache";
 		};
 	};
 

arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts +8 -0

index efc59b3baf63..20addabbd127 100644
@@ -37,6 +37,7 @@
 			reg = <0x0 0x0>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 1 {
 			device_type = "cpu";

@@ -44,6 +45,7 @@
 			reg = <0x0 0x1>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 2 {
 			device_type = "cpu";

@@ -51,6 +53,7 @@
 			reg = <0x0 0x2>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 3 {
 			device_type = "cpu";

@@ -58,6 +61,11 @@
 			reg = <0x0 0x3>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
+		};
+
+		L2_0: l2-cache0 {
+			compatible = "cache";
 		};
 	};
 

Signature · 1 line

1.9.1

Quoted 5 lines · Sudeep Holla

Commit 5d425c18653731af6 ("arm64: kernel: add support for cpu cache information") adds cacheinfo support for ARM64. Since there's no architectural way of detecting the cpus that share particular cache, device tree can be used and the core cacheinfo already supports the same.

This still leaves the possibility that misleading information is exposed for systems from other vendors. I've made a quick attempt to Cc the authors of other arm64 dts here.

Given that in the absence of these nodes we can't derive a complete view of the cache hierarchy, shouldn't we only expose the cacheinfo when we have these nodes and can therefore produce correct values?

I can imagine that future dts are likely to appear without these nodes, and I imagine that we won't spot all of those cases. We also have existing DTBs to take into account.

Thanks,
Mark.

Quoted 169 lines

This patch adds the L2 cache topology on Juno board, FVP/RTSM and foundation models.

Signed-off-by Sudeep Holla <[email protected]>

Cc Mark Rutland <[email protected]>

Cc Liviu Dudau <[email protected]>

Cc Lorenzo Pieralisi <[email protected]>

---
 arch/arm64/boot/dts/arm/foundation-v8.dts  |  8 ++++++++
 arch/arm64/boot/dts/arm/juno.dts           | 14 ++++++++++++++
 arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts |  8 ++++++++
 3 files changed, 30 insertions(+)

Hi Arnd/Olof,

Though this patch and commit 5d425c18653731af6 ("arm64: kernel: add support for cpu cache information") which is in -next(via arm64) are dependent to provide desired functionality, then can go indepedently if you think there could be conflicts if this change is taken via arm64. If not, Catalin can pick up with your acks after the review.

Regards,
Sudeep

arch/arm64/boot/dts/arm/foundation-v8.dts +8 -0

index 27f32962e55c..4eac8dcea423 100644
@@ -34,6 +34,7 @@
 			reg = <0x0 0x0>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 1 {
 			device_type = "cpu";

@@ -41,6 +42,7 @@
 			reg = <0x0 0x1>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 2 {
 			device_type = "cpu";

@@ -48,6 +50,7 @@
 			reg = <0x0 0x2>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 3 {
 			device_type = "cpu";

@@ -55,6 +58,11 @@
 			reg = <0x0 0x3>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
+		};
+
+		L2_0: l2-cache0 {
+			compatible = "cache";
 		};
 	};
 

arch/arm64/boot/dts/arm/juno.dts +14 -0

index cb3073e4e7a8..15dafbb24426 100644
@@ -39,6 +39,7 @@
 			reg = <0x0 0x0>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A57_L2>;
 		};
 
 		A57_1: cpu at 1 {

@@ -46,6 +47,7 @@
 			reg = <0x0 0x1>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A57_L2>;
 		};
 
 		A53_0: cpu at 100 {

@@ -53,6 +55,7 @@
 			reg = <0x0 0x100>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
 		};
 
 		A53_1: cpu at 101 {

@@ -60,6 +63,7 @@
 			reg = <0x0 0x101>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
 		};
 
 		A53_2: cpu at 102 {

@@ -67,6 +71,7 @@
 			reg = <0x0 0x102>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
 		};
 
 		A53_3: cpu at 103 {

@@ -74,6 +79,15 @@
 			reg = <0x0 0x103>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
+		};
+
+		A57_L2: l2-cache0 {
+			compatible = "cache";
+		};
+
+		A53_L2: l2-cache1 {
+			compatible = "cache";
 		};
 	};
 

arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts +8 -0

index efc59b3baf63..20addabbd127 100644
@@ -37,6 +37,7 @@
 			reg = <0x0 0x0>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 1 {
 			device_type = "cpu";

@@ -44,6 +45,7 @@
 			reg = <0x0 0x1>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 2 {
 			device_type = "cpu";

@@ -51,6 +53,7 @@
 			reg = <0x0 0x2>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 3 {
 			device_type = "cpu";

@@ -58,6 +61,11 @@
 			reg = <0x0 0x3>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
+		};
+
+		L2_0: l2-cache0 {
+			compatible = "cache";
 		};
 	};
 

Signature · 1 line

1.9.1

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

Hi,

Quoted 11 lines · Mark Rutland

Quoted 5 lines · Sudeep Holla

Commit 5d425c18653731af6 ("arm64: kernel: add support for cpu cache information") adds cacheinfo support for ARM64. Since there's no architectural way of detecting the cpus that share particular cache, device tree can be used and the core cacheinfo already supports the same.

This still leaves the possibility that misleading information is exposed for systems from other vendors. I've made a quick attempt to Cc the authors of other arm64 dts here.

Quoted 3 lines

Given that in the absence of these nodes we can't derive a complete view of the cache hierarchy, shouldn't we only expose the cacheinfo when we have these nodes and can therefore produce correct values?

I'm still rather concerned about exposing misleading cache info in this manner. Is there no way we can limit the exposure of this information to those cases where we actually have the information?

Do we know if/how this will work for ACPI systems?

Thanks,
Mark.

Quoted 181 lines

I can imagine that future dts are likely to appear without these nodes, and I imagine that we won't spot all of those cases. We also have existing DTBs to take into account.

Thanks,
Mark.

Quoted 169 lines

This patch adds the L2 cache topology on Juno board, FVP/RTSM and foundation models.

Signed-off-by Sudeep Holla <[email protected]>

Cc Mark Rutland <[email protected]>

Cc Liviu Dudau <[email protected]>

Cc Lorenzo Pieralisi <[email protected]>

---
 arch/arm64/boot/dts/arm/foundation-v8.dts  |  8 ++++++++
 arch/arm64/boot/dts/arm/juno.dts           | 14 ++++++++++++++
 arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts |  8 ++++++++
 3 files changed, 30 insertions(+)

Hi Arnd/Olof,

Though this patch and commit 5d425c18653731af6 ("arm64: kernel: add support for cpu cache information") which is in -next(via arm64) are dependent to provide desired functionality, then can go indepedently if you think there could be conflicts if this change is taken via arm64. If not, Catalin can pick up with your acks after the review.

Regards,
Sudeep

arch/arm64/boot/dts/arm/foundation-v8.dts +8 -0

index 27f32962e55c..4eac8dcea423 100644
@@ -34,6 +34,7 @@
 			reg = <0x0 0x0>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 1 {
 			device_type = "cpu";

@@ -41,6 +42,7 @@
 			reg = <0x0 0x1>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 2 {
 			device_type = "cpu";

@@ -48,6 +50,7 @@
 			reg = <0x0 0x2>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 3 {
 			device_type = "cpu";

@@ -55,6 +58,11 @@
 			reg = <0x0 0x3>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
+		};
+
+		L2_0: l2-cache0 {
+			compatible = "cache";
 		};
 	};
 

arch/arm64/boot/dts/arm/juno.dts +14 -0

index cb3073e4e7a8..15dafbb24426 100644
@@ -39,6 +39,7 @@
 			reg = <0x0 0x0>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A57_L2>;
 		};
 
 		A57_1: cpu at 1 {

@@ -46,6 +47,7 @@
 			reg = <0x0 0x1>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A57_L2>;
 		};
 
 		A53_0: cpu at 100 {

@@ -53,6 +55,7 @@
 			reg = <0x0 0x100>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
 		};
 
 		A53_1: cpu at 101 {

@@ -60,6 +63,7 @@
 			reg = <0x0 0x101>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
 		};
 
 		A53_2: cpu at 102 {

@@ -67,6 +71,7 @@
 			reg = <0x0 0x102>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
 		};
 
 		A53_3: cpu at 103 {

@@ -74,6 +79,15 @@
 			reg = <0x0 0x103>;
 			device_type = "cpu";
 			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
+		};
+
+		A57_L2: l2-cache0 {
+			compatible = "cache";
+		};
+
+		A53_L2: l2-cache1 {
+			compatible = "cache";
 		};
 	};
 

arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts +8 -0

index efc59b3baf63..20addabbd127 100644
@@ -37,6 +37,7 @@
 			reg = <0x0 0x0>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 1 {
 			device_type = "cpu";

@@ -44,6 +45,7 @@
 			reg = <0x0 0x1>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 2 {
 			device_type = "cpu";

@@ -51,6 +53,7 @@
 			reg = <0x0 0x2>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
 		};
 		cpu at 3 {
 			device_type = "cpu";

@@ -58,6 +61,11 @@
 			reg = <0x0 0x3>;
 			enable-method = "spin-table";
 			cpu-release-addr = <0x0 0x8000fff8>;
+			next-level-cache = <&L2_0>;
+		};
+
+		L2_0: l2-cache0 {
+			compatible = "cache";
 		};
 	};
 

Signature · 1 line

1.9.1

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

Hi,

Quoted 11 lines · Mark Rutland

Quoted 5 lines · Sudeep Holla

Commit 5d425c18653731af6 ("arm64: kernel: add support for cpu cache information") adds cacheinfo support for ARM64. Since there's no architectural way of detecting the cpus that share particular cache, device tree can be used and the core cacheinfo already supports the same.

This still leaves the possibility that misleading information is exposed for systems from other vendors. I've made a quick attempt to Cc the authors of other arm64 dts here.

Quoted 3 lines

Given that in the absence of these nodes we can't derive a complete view of the cache hierarchy, shouldn't we only expose the cacheinfo when we have these nodes and can therefore produce correct values?

I'm still rather concerned about exposing misleading cache info in this manner. Is there no way we can limit the exposure of this information to those cases where we actually have the information?

Do we know if/how this will work for ACPI systems?

Hi Mark,

Quoted 14 lines · Mark Rutland

Hi,

Quoted 11 lines · Mark Rutland

Quoted 5 lines · Sudeep Holla

Commit 5d425c18653731af6 ("arm64: kernel: add support for cpu cache information") adds cacheinfo support for ARM64. Since there's no architectural way of detecting the cpus that share particular cache, device tree can be used and the core cacheinfo already supports the same.

This still leaves the possibility that misleading information is exposed for systems from other vendors. I've made a quick attempt to Cc the authors of other arm64 dts here.

Quoted 8 lines

Quoted 3 lines

Given that in the absence of these nodes we can't derive a complete view of the cache hierarchy, shouldn't we only expose the cacheinfo when we have these nodes and can therefore produce correct values?

I'm still rather concerned about exposing misleading cache info in this manner. Is there no way we can limit the exposure of this information to those cases where we actually have the information?

Yes I have a patch to check all the device nodes in the cache hierarchy before initializing the sysfs. So cacheinfo won't be setup if all the device nodes aren't found(at-least on architecture like ARM/ARM64 which depends on DT). I will post it soon, was waiting for a week so that it's not lost during merge window.

Quoted 2 lines

Do we know if/how this will work for ACPI systems?

It should be similar to DT i.e. the hierarchy must be completely detected through ACPI tables/methods, but I have not thought of implementation specifics yet.