[PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models.

[PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models.

[Jon Medhurst]

List the required properties used to describe ARM's FVP models.

Signed-off-by: Jon Medhurst <tixy@linaro.org>
---
 Documentation/devicetree/bindings/arm/arm-boards | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
index ab318a5..4639a9b 100644
--- a/Documentation/devicetree/bindings/arm/arm-boards
+++ b/Documentation/devicetree/bindings/arm/arm-boards
@@ -234,3 +234,24 @@ Example:
 	};
 
 };
+
+ARM Fixed Virtual Platforms (FVP)
+---------------------------------
+FVPs are simulated platforms produced by ARM to aid software development without
+the requirement for actual hardware. They come in several families, each of
+which (usually) contain variants for different configurations of simulated
+hardware. These are documented in the Fixed Virtual Platforms FVP Reference
+Guide (reference number ARM DUI0837H).
+
+Required properties (in root node):
+- compatible value:
+	compatible = "arm,<family>,<variant>", "arm,<family>";
+  where <family> is one of:
+  - "fvp-base" for the Base FVP
+  - "fvp-ve" for the VE FVP
+  and <variant> is the part of the model's executable filename with the family
+  name omitted, converted to lower case, and with non-alphanumeric characters
+  replaced with '-'. E.g. the Base FVP that has two AEMv8 CPU clusters has an
+  executable file called FVP_Base_AEMv8A-AEMv8A, so the compatible value for
+  this would be:
+	compatible = "arm,fvp-base,aemv8a-aemv8a", "arm,fvp-base";
-- 
2.1.4

[PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model

[Jon Medhurst]

Fixed Virtual Platform (FVP) Base models are simulations of systems
that resemble Versatile Express or Juno hardware.

This adds a device-tree for the model variant that has two clusters of
Architecture Envelope Model (AEM) v8-A CPUs. The peripheral devices that
are common to all variants of Base models have been placed in a separate
file (fvp-base.dtsi) to facilitate creating device-trees for other
models.

It is desirable to use simulations for code testing purposes and so it
is beneficial to include nodes for things that are timing and power
consumption related, even when these don't otherwise have relevance or
accuracy. Where these have been included here (e.g. idle-states) entries
have been copied from real hardware platforms such as Juno.

Signed-off-by: Jon Medhurst <tixy@linaro.org>
---
 arch/arm64/boot/dts/arm/Makefile                   |   1 +
 arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts | 221 +++++++++++++++++
 arch/arm64/boot/dts/arm/fvp-base.dtsi              | 267 +++++++++++++++++++++
 3 files changed, 489 insertions(+)

diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
index 75cc2aa..7531001 100644
--- a/arch/arm64/boot/dts/arm/Makefile
+++ b/arch/arm64/boot/dts/arm/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb foundation-v8-gicv3.dtb
+dtb-$(CONFIG_ARCH_VEXPRESS) += fvp-base-aemv8a-aemv8a.dtb
 dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb juno-r2.dtb
 dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
 dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2f-1xv7-ca53x2.dtb
diff --git a/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts b/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts
new file mode 100644
index 0000000..2acfd26
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts
@@ -0,0 +1,221 @@
+/*
+ * ARM Ltd. Fixed Virtual Platform (FVP) Base model with dual cluster
+ * Architecture Envelope Model (AEM) v8-A CPUs
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	compatible = "arm,fvp-base,aemv8a-aemv8a", "arm,fvp-base", "arm,vexpress";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	chosen { };
+
+	aliases {
+		serial0 = &bp_serial0;
+		serial1 = &bp_serial1;
+		serial2 = &bp_serial2;
+		serial3 = &bp_serial3;
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&CPU0_0>;
+				};
+				core1 {
+					cpu = <&CPU0_1>;
+				};
+				core2 {
+					cpu = <&CPU0_2>;
+				};
+				core3 {
+					cpu = <&CPU0_3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&CPU1_0>;
+				};
+				core1 {
+					cpu = <&CPU1_1>;
+				};
+				core2 {
+					cpu = <&CPU1_2>;
+				};
+				core3 {
+					cpu = <&CPU1_3>;
+				};
+			};
+		};
+
+		idle-states {
+			entry-method = "arm,psci";
+
+			CPU_SLEEP_0: cpu-sleep-0 {
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				local-timer-stop;
+				entry-latency-us = <300>;
+				exit-latency-us = <1200>;
+				min-residency-us = <2000>;
+			};
+
+			CLUSTER_SLEEP_0: cluster-sleep-0 {
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x1010000>;
+				local-timer-stop;
+				entry-latency-us = <300>;
+				exit-latency-us = <1200>;
+				min-residency-us = <2500>;
+			};
+		};
+
+		CPU0_0: cpu@0 {
+			compatible = "arm,armv8";
+			reg = <0x0 0x0>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&CLUSTER0_L2>;
+			cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+		};
+
+		CPU0_1: cpu@1 {
+			compatible = "arm,armv8";
+			reg = <0x0 0x1>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&CLUSTER0_L2>;
+			cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+		};
+
+		CPU0_2: cpu@2 {
+			compatible = "arm,armv8";
+			reg = <0x0 0x2>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&CLUSTER0_L2>;
+			cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+		};
+
+		CPU0_3: cpu@3 {
+			compatible = "arm,armv8";
+			reg = <0x0 0x3>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&CLUSTER0_L2>;
+			cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+		};
+
+		CPU1_0: cpu@100 {
+			compatible = "arm,armv8";
+			reg = <0x0 0x100>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&CLUSTER1_L2>;
+			cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+		};
+
+		CPU1_1: cpu@101 {
+			compatible = "arm,armv8";
+			reg = <0x0 0x101>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&CLUSTER1_L2>;
+			cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+		};
+
+		CPU1_2: cpu@102 {
+			compatible = "arm,armv8";
+			reg = <0x0 0x102>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&CLUSTER1_L2>;
+			cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+		};
+
+		CPU1_3: cpu@103 {
+			compatible = "arm,armv8";
+			reg = <0x0 0x103>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&CLUSTER1_L2>;
+			cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+		};
+
+		CLUSTER0_L2: l2-cache0 {
+			compatible = "cache";
+		};
+
+		CLUSTER1_L2: l2-cache1 {
+			compatible = "cache";
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
+		clock-frequency = <100000000>;
+	};
+
+	pmu {
+		compatible = "arm,armv8-pmuv3";
+		interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&CPU0_0>,
+				     <&CPU0_1>,
+				     <&CPU0_2>,
+				     <&CPU0_3>,
+				     <&CPU1_0>,
+				     <&CPU1_1>,
+				     <&CPU1_2>,
+				     <&CPU1_3>;
+	};
+
+	gic: interrupt-controller@2f000000 {
+		compatible = "arm,gic-v3";
+		#interrupt-cells = <3>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		interrupt-controller;
+		reg =	<0x0 0x2f000000 0x0 0x10000>,
+			<0x0 0x2f100000 0x0 0x100000>,
+			<0x0 0x2c000000 0x0 0x2000>,
+			<0x0 0x2c010000 0x0 0x2000>,
+			<0x0 0x2c02f000 0x0 0x2000>;
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+		its: its@2f020000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			#msi-cells = <1>;
+			reg = <0x0 0x2f020000 0x0 0x20000>;
+		};
+	};
+
+	#include "fvp-base.dtsi"
+};
diff --git a/arch/arm64/boot/dts/arm/fvp-base.dtsi b/arch/arm64/boot/dts/arm/fvp-base.dtsi
new file mode 100644
index 0000000..ea3f170
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/fvp-base.dtsi
@@ -0,0 +1,267 @@
+	bp_clock35mhz: clock35mhz {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <35000000>;
+		clock-output-names = "bp:clock35mhz";
+	};
+
+	bp_clock24mhz: clock24mhz {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24000000>;
+		clock-output-names = "bp:clock24mhz";
+	};
+
+	flash@8000000 {
+		compatible = "arm,vexpress-flash", "cfi-flash";
+		reg = <0x0 0x08000000 0x0 0x04000000>,
+		      <0x0 0x0C000000 0x0 0x04000000>;
+		bank-width = <4>;
+	};
+
+	bp_video_ram: vram@18000000 {
+		compatible = "arm,vexpress-vram";
+		reg = <0x0 0x18000000 0x0 0x00800000>;
+	};
+
+	ethernet@1a000000 {
+		compatible = "smsc,lan91c111";
+		reg = <0x0 0x1a000000 0x0 0x10000>;
+		interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	bp_sysreg: sysreg@1c010000 {
+		compatible = "arm,vexpress-sysreg";
+		reg = <0x0 0x1c010000 0x0 0x1000>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	mcc {
+		compatible = "arm,vexpress,config-bus";
+		arm,vexpress,config-bridge = <&bp_sysreg>;
+
+		bp_oscclk1: oscclk1 {
+			compatible = "arm,vexpress-osc";
+			arm,vexpress-sysreg,func = <1 1>;
+			freq-range = <23750000 63500000>;
+			#clock-cells = <0>;
+			clock-output-names = "bp:oscclk1";
+		};
+
+		muxfpga {
+			compatible = "arm,vexpress-muxfpga";
+			arm,vexpress-sysreg,func = <7 0>;
+		};
+
+		shutdown {
+			compatible = "arm,vexpress-shutdown";
+			arm,vexpress-sysreg,func = <8 0>;
+		};
+
+		reboot {
+			compatible = "arm,vexpress-reboot";
+			arm,vexpress-sysreg,func = <9 0>;
+		};
+	};
+
+	sysctl_refclk: sysctl-refclk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1000000>;
+		clock-output-names = "sysctl:refclk";
+	};
+
+	sysctl_timclk: sysctl-timclk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
+		clock-output-names = "sysctl:timclk";
+	};
+
+	bp_sysctl: sysctl@1c020000 {
+		compatible = "arm,sp810", "arm,primecell";
+		reg = <0x0 0x1c020000 0x0 0x1000>;
+		clocks = <&sysctl_refclk>, <&sysctl_timclk>, <&bp_clock35mhz>;
+		clock-names = "refclk", "timclk", "apb_pclk";
+		#clock-cells = <1>;
+		clock-output-names = "timerclken0", "timerclken1", "timerclken2", "timerclken3";
+		assigned-clocks = <&bp_sysctl 0>, <&bp_sysctl 1>, <&bp_sysctl 3>, <&bp_sysctl 3>;
+		assigned-clock-parents = <&sysctl_timclk>, <&sysctl_timclk>, <&sysctl_timclk>, <&sysctl_timclk>;
+	};
+
+	aaci@1c040000 {
+		compatible = "arm,pl041", "arm,primecell";
+		reg = <0x0 0x1c040000 0x0 0x1000>;
+		interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&bp_clock24mhz>;
+		clock-names = "apb_pclk";
+	};
+
+	bp_fixed_3v3: bp-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
+	mmci@1c050000 {
+		compatible = "arm,pl180", "arm,primecell";
+		reg = <0x0 0x1c050000 0x0 0x1000>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+		cd-gpios = <&bp_sysreg 0 0>;
+		wp-gpios = <&bp_sysreg 1 0>;
+		max-frequency = <12000000>;
+		vmmc-supply = <&bp_fixed_3v3>;
+		clocks = <&bp_clock24mhz>, <&bp_clock24mhz>;
+		clock-names = "mclk", "apb_pclk";
+	};
+
+	kmi@1c060000 {
+		compatible = "arm,pl050", "arm,primecell";
+		reg = <0x0 0x1c060000 0x0 0x1000>;
+		interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&bp_clock24mhz>, <&bp_clock24mhz>;
+		clock-names = "KMIREFCLK", "apb_pclk";
+	};
+
+	kmi@1c070000 {
+		compatible = "arm,pl050", "arm,primecell";
+		reg = <0x0 0x1c070000 0x0 0x1000>;
+		interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&bp_clock24mhz>, <&bp_clock24mhz>;
+		clock-names = "KMIREFCLK", "apb_pclk";
+	};
+
+	bp_serial0: uart@1c090000 {
+		compatible = "arm,pl011", "arm,primecell";
+		reg = <0x0 0x1c090000 0x0 0x1000>;
+		interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&bp_clock24mhz>, <&bp_clock24mhz>;
+		clock-names = "uartclk", "apb_pclk";
+	};
+
+	bp_serial1: uart@1c0a0000 {
+		compatible = "arm,pl011", "arm,primecell";
+		reg = <0x0 0x1c0a0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&bp_clock24mhz>, <&bp_clock24mhz>;
+		clock-names = "uartclk", "apb_pclk";
+	};
+
+	bp_serial2: uart@1c0b0000 {
+		compatible = "arm,pl011", "arm,primecell";
+		reg = <0x0 0x1c0b0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&bp_clock24mhz>, <&bp_clock24mhz>;
+		clock-names = "uartclk", "apb_pclk";
+	};
+
+	bp_serial3: uart@1c0c0000 {
+		compatible = "arm,pl011", "arm,primecell";
+		reg = <0x0 0x1c0c0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&bp_clock24mhz>, <&bp_clock24mhz>;
+		clock-names = "uartclk", "apb_pclk";
+	};
+
+	wdt@1c0f0000 {
+		compatible = "arm,sp805", "arm,primecell";
+		reg = <0x0 0x1c0f0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&bp_clock24mhz>, <&bp_clock24mhz>;
+		clock-names = "wdogclk", "apb_pclk";
+	};
+
+	bp_timer01: timer@1c110000 {
+		compatible = "arm,sp804", "arm,primecell";
+		reg = <0x0 0x1c110000 0x0 0x1000>;
+		interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&bp_sysctl 0>, <&bp_sysctl 1>, <&bp_clock35mhz>;
+		clock-names = "timclken1", "timclken2", "apb_pclk";
+	};
+
+	bp_timer23: timer@1c120000 {
+		compatible = "arm,sp804", "arm,primecell";
+		reg = <0x0 0x1c120000 0x0 0x1000>;
+		interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&bp_sysctl 2>, <&bp_sysctl 3>, <&bp_clock35mhz>;
+		clock-names = "timclken1", "timclken2", "apb_pclk";
+	};
+
+	virtio_block@1c0130000 {
+		compatible = "virtio,mmio";
+		reg = <0x0 0x1c130000 0x0 0x200>;
+		interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	rtc@1c170000 {
+		compatible = "arm,pl031", "arm,primecell";
+		reg = <0x0 0x1c170000 0x0 0x1000>;
+		interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&bp_clock24mhz>;
+		clock-names = "apb_pclk";
+	};
+
+	clcd@1c1f0000 {
+		compatible = "arm,pl111", "arm,primecell";
+		reg = <0x0 0x1c1f0000 0x0 0x1000>;
+		interrupt-names = "combined";
+		interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&bp_oscclk1>, <&bp_clock24mhz>;
+		clock-names = "clcdclk", "apb_pclk";
+		arm,pl11x,framebuffer = <0x18000000 0x00180000>;
+		memory-region = <&bp_video_ram>;
+		max-memory-bandwidth = <130000000>; /* 16bpp @ 63.5MHz */
+
+		port {
+			bp_clcd_pads: endpoint {
+				remote-endpoint = <&bp_clcd_panel>;
+				arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+			};
+		};
+
+		panel {
+			compatible = "panel-dpi";
+
+			port {
+				bp_clcd_panel: endpoint {
+					remote-endpoint = <&bp_clcd_pads>;
+				};
+			};
+
+			panel-timing {
+				clock-frequency = <63500127>;
+				hactive = <1024>;
+				hback-porch = <152>;
+				hfront-porch = <48>;
+				hsync-len = <104>;
+				vactive = <768>;
+				vback-porch = <23>;
+				vfront-porch = <3>;
+				vsync-len = <4>;
+			};
+		};
+	};
+
+	timer@2a810000 {
+		compatible = "arm,armv7-timer-mem";
+		reg = <0x0 0x2a810000 0x0 0x1000>;
+		clock-frequency = <50000000>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		frame@2a830000 {
+			frame-number = <1>;
+			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0x0 0x2a830000 0x0 0x1000>;
+		};
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0x00000000 0x80000000 0 0x80000000>,
+		      <0x00000008 0x80000000 0 0x80000000>;
+	};
-- 
2.1.4

Re: [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model

[Mark Rutland]

Hi,

On Mon, Jun 20, 2016 at 01:13:16PM +0100, Jon Medhurst wrote:
> Fixed Virtual Platform (FVP) Base models are simulations of systems
> that resemble Versatile Express or Juno hardware.
> 
> This adds a device-tree for the model variant that has two clusters of
> Architecture Envelope Model (AEM) v8-A CPUs. The peripheral devices that
> are common to all variants of Base models have been placed in a separate
> file (fvp-base.dtsi) to facilitate creating device-trees for other
> models.
> 
> It is desirable to use simulations for code testing purposes and so it
> is beneficial to include nodes for things that are timing and power
> consumption related, even when these don't otherwise have relevance or
> accuracy. Where these have been included here (e.g. idle-states) entries
> have been copied from real hardware platforms such as Juno.

Which firmware are you using, and what precisely does it do w.r.t.
those idle states? Judging by the FVP ATF pm code [1], those state IDs
aren't valid (though perhaps the comment is wrong, or I've misunderstood
something).

People use the FVPs with a variety of FW and bootloaders, so I'm not
keen on putting anything FW or bootloader specific into the canonical
FVP DT files.

> Signed-off-by: Jon Medhurst <tixy@linaro.org>
> ---
>  arch/arm64/boot/dts/arm/Makefile                   |   1 +
>  arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts | 221 +++++++++++++++++
>  arch/arm64/boot/dts/arm/fvp-base.dtsi              | 267 +++++++++++++++++++++
>  3 files changed, 489 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> index 75cc2aa..7531001 100644
> --- a/arch/arm64/boot/dts/arm/Makefile
> +++ b/arch/arm64/boot/dts/arm/Makefile
> @@ -1,4 +1,5 @@
>  dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb foundation-v8-gicv3.dtb
> +dtb-$(CONFIG_ARCH_VEXPRESS) += fvp-base-aemv8a-aemv8a.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb juno-r2.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2f-1xv7-ca53x2.dtb
> diff --git a/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts b/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts
> new file mode 100644
> index 0000000..2acfd26
> --- /dev/null
> +++ b/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts
> @@ -0,0 +1,221 @@
> +/*
> + * ARM Ltd. Fixed Virtual Platform (FVP) Base model with dual cluster
> + * Architecture Envelope Model (AEM) v8-A CPUs
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	compatible = "arm,fvp-base,aemv8a-aemv8a", "arm,fvp-base", "arm,vexpress";
> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	chosen { };

Please add stdout-path, e.g.

	stdout-path = "serial0:115200";

> +
> +	aliases {
> +		serial0 = &bp_serial0;
> +		serial1 = &bp_serial1;
> +		serial2 = &bp_serial2;
> +		serial3 = &bp_serial3;
> +	};

[...]

> +		idle-states {
> +			entry-method = "arm,psci";
> +
> +			CPU_SLEEP_0: cpu-sleep-0 {
> +				compatible = "arm,idle-state";
> +				arm,psci-suspend-param = <0x0010000>;
> +				local-timer-stop;
> +				entry-latency-us = <300>;
> +				exit-latency-us = <1200>;
> +				min-residency-us = <2000>;
> +			};
> +
> +			CLUSTER_SLEEP_0: cluster-sleep-0 {
> +				compatible = "arm,idle-state";
> +				arm,psci-suspend-param = <0x1010000>;
> +				local-timer-stop;
> +				entry-latency-us = <300>;
> +				exit-latency-us = <1200>;
> +				min-residency-us = <2500>;
> +			};
> +		};

[...]

> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
> +			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
> +			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
> +			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;

The cpumask shouldn't be there (it's not valid for GICv3).

> +		clock-frequency = <100000000>;

FW should program CNTFRQ correctly, so we should drop the
clock-frequency property. We should never have had it in the first place
for the original RTSM DT.

Thanks,
Mark.

[1] https://github.com/ARM-software/arm-trusted-firmware/commit/6355f2347aec8bf6ad74867c2b0c996e10546ad4#L53

Re: [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model

[Jon Medhurst (Tixy)]

On Mon, 2016-06-20 at 13:39 +0100, Mark Rutland wrote:
> Hi,
> 
> On Mon, Jun 20, 2016 at 01:13:16PM +0100, Jon Medhurst wrote:
> > Fixed Virtual Platform (FVP) Base models are simulations of systems
> > that resemble Versatile Express or Juno hardware.
> > 
> > This adds a device-tree for the model variant that has two clusters of
> > Architecture Envelope Model (AEM) v8-A CPUs. The peripheral devices that
> > are common to all variants of Base models have been placed in a separate
> > file (fvp-base.dtsi) to facilitate creating device-trees for other
> > models.
> > 
> > It is desirable to use simulations for code testing purposes and so it
> > is beneficial to include nodes for things that are timing and power
> > consumption related, even when these don't otherwise have relevance or
> > accuracy. Where these have been included here (e.g. idle-states) entries
> > have been copied from real hardware platforms such as Juno.
> 
> Which firmware are you using,

ARM Trusted Firmware

>  and what precisely does it do w.r.t.
> those idle states?

I don't know, will check. Those states are also in the ARM TF
device-tree for the Base FVP [2] but I admit I didn't verify they were
correct. (Unlike real 'hardware' dt nodes, for which I methodically went
through documentation and LISA files to check and fix).

[2] https://github.com/ARM-software/arm-trusted-firmware/blob/master/fdts/fvp-base-gicv3-psci.dts

>  Judging by the FVP ATF pm code [1], those state IDs
> aren't valid (though perhaps the comment is wrong, or I've misunderstood
> something).

I'm not sure which comment you are referring to, that link [1] doesn't
seem to anchor to a particular source line in my web browser, and I
don't spot anything relevant scanning by eye.

> People use the FVPs with a variety of FW and bootloaders, so I'm not
> keen on putting anything FW or bootloader specific into the canonical
> FVP DT files.

I can agree about bootloaders, but would anyone be using FVP's without
ARM Trusted firmware? And if they aren't using using that, can we still
assume a PSCI capable firmware for things like CPU enable-method? I'm
asking to get an idea where the line is as I have changes for Foundation
model too. Also, want something to say to the people who asked me to
'upstream the FVP DTs' as I expect they think people are using the One
True Way which involves ARM's Trusted Firmware and other sacred tomes
passed down to them ;-)

I'll fix your other comment on the DT, so snipping email here.

> [1] https://github.com/ARM-software/arm-trusted-firmware/commit/6355f2347aec8bf6ad74867c2b0c996e10546ad4#L53 

-- 
Tixy

Re: [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model

[Mark Rutland]

On Mon, Jun 20, 2016 at 03:34:37PM +0100, Jon Medhurst (Tixy) wrote:
> On Mon, 2016-06-20 at 13:39 +0100, Mark Rutland wrote:
> > Hi,
> > 
> > On Mon, Jun 20, 2016 at 01:13:16PM +0100, Jon Medhurst wrote:
> > > Fixed Virtual Platform (FVP) Base models are simulations of systems
> > > that resemble Versatile Express or Juno hardware.
> > > 
> > > This adds a device-tree for the model variant that has two clusters of
> > > Architecture Envelope Model (AEM) v8-A CPUs. The peripheral devices that
> > > are common to all variants of Base models have been placed in a separate
> > > file (fvp-base.dtsi) to facilitate creating device-trees for other
> > > models.
> > > 
> > > It is desirable to use simulations for code testing purposes and so it
> > > is beneficial to include nodes for things that are timing and power
> > > consumption related, even when these don't otherwise have relevance or
> > > accuracy. Where these have been included here (e.g. idle-states) entries
> > > have been copied from real hardware platforms such as Juno.
> > 
> > Which firmware are you using,
> 
> ARM Trusted Firmware
> 
> >  and what precisely does it do w.r.t.
> > those idle states?
> 
> I don't know, will check. Those states are also in the ARM TF
> device-tree for the Base FVP [2] but I admit I didn't verify they were
> correct. (Unlike real 'hardware' dt nodes, for which I methodically went
> through documentation and LISA files to check and fix).
> 
> [2] https://github.com/ARM-software/arm-trusted-firmware/blob/master/fdts/fvp-base-gicv3-psci.dts
> 
> >  Judging by the FVP ATF pm code [1], those state IDs
> > aren't valid (though perhaps the comment is wrong, or I've misunderstood
> > something).
> 
> I'm not sure which comment you are referring to, that link [1] doesn't
> seem to anchor to a particular source line in my web browser, and I
> don't spot anything relevant scanning by eye.

Aargh, the web interface appears to have given me a duff URL. Let's try
again [3]. ;)

The comments note state-ids 0x01, 0x02, and 0x22, which don't appear to
match the DT. It might be that I've just misunderstood, but it could be
that every attempt to idle simply fails if we're passing the wrong
state-ids, and that's somewhat sub-optimal.

I'm not sure if there's a simple diagnostic for that. Lorenzo, any idea
if/how we can detect when the FW rejects an idle state it doesn't
recognise?

> > People use the FVPs with a variety of FW and bootloaders, so I'm not
> > keen on putting anything FW or bootloader specific into the canonical
> > FVP DT files.
> 
> I can agree about bootloaders, but would anyone be using FVP's without
> ARM Trusted firmware?

Yes. I know of several people just using the bootwrapper [4], with
custom DTs.

> And if they aren't using using that, can we still assume a PSCI
> capable firmware for things like CPU enable-method?

I was counting that under "FW or bootloader specific", so no.

> I'm asking to get an idea where the line is as I have changes for
> Foundation model too. Also, want something to say to the people who
> asked me to 'upstream the FVP DTs' as I expect they think people are
> using the One True Way which involves ARM's Trusted Firmware and other
> sacred tomes passed down to them ;-)

Ideally, the Base stuff is meant to be all fixed, so we should be able
to support the default configuration.

To handle different FWs and bootloaders, I think we should have a DT
without the enable-method, PSCI node, and idle states, for the default
FVP Base configuration.

We can *also* have a DT for the default FVP Base + ATF configuration (so
long as clearly named as such), with the appropriate nodes and
properties.

> I'll fix your other comment on the DT, so snipping email here.

Sure, cheers!

Thanks,
Mark.

> > [1] https://github.com/ARM-software/arm-trusted-firmware/commit/6355f2347aec8bf6ad74867c2b0c996e10546ad4#L53 

[3] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/plat/arm/board/fvp/fvp_pm.c#L53
[4] https://git.kernel.org/cgit/linux/kernel/git/cmarinas/boot-wrapper-aarch64.git/
--
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 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models.

[Rob Herring]

On Mon, Jun 20, 2016 at 01:13:15PM +0100, Jon Medhurst wrote:
> List the required properties used to describe ARM's FVP models.
> 
> Signed-off-by: Jon Medhurst <tixy-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/arm/arm-boards | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
> index ab318a5..4639a9b 100644
> --- a/Documentation/devicetree/bindings/arm/arm-boards
> +++ b/Documentation/devicetree/bindings/arm/arm-boards
> @@ -234,3 +234,24 @@ Example:
>  	};
>  
>  };
> +
> +ARM Fixed Virtual Platforms (FVP)
> +---------------------------------
> +FVPs are simulated platforms produced by ARM to aid software development without
> +the requirement for actual hardware. They come in several families, each of
> +which (usually) contain variants for different configurations of simulated
> +hardware. These are documented in the Fixed Virtual Platforms FVP Reference
> +Guide (reference number ARM DUI0837H).
> +
> +Required properties (in root node):
> +- compatible value:
> +	compatible = "arm,<family>,<variant>", "arm,<family>";
> +  where <family> is one of:
> +  - "fvp-base" for the Base FVP
> +  - "fvp-ve" for the VE FVP
> +  and <variant> is the part of the model's executable filename with the family
> +  name omitted, converted to lower case, and with non-alphanumeric characters
> +  replaced with '-'. E.g. the Base FVP that has two AEMv8 CPU clusters has an
> +  executable file called FVP_Base_AEMv8A-AEMv8A, so the compatible value for

Naming conventions of the exe aren't going to change?

> +  this would be:
> +	compatible = "arm,fvp-base,aemv8a-aemv8a", "arm,fvp-base";
> -- 
> 2.1.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models.

[Jon Medhurst (Tixy)]

On Tue, 2016-06-21 at 08:22 -0500, Rob Herring wrote:
> > +Required properties (in root node):
> > +- compatible value:
> > +     compatible = "arm,<family>,<variant>", "arm,<family>";
> > +  where <family> is one of:
> > +  - "fvp-base" for the Base FVP
> > +  - "fvp-ve" for the VE FVP
> > +  and <variant> is the part of the model's executable filename with
> the family
> > +  name omitted, converted to lower case, and with non-alphanumeric
> characters
> > +  replaced with '-'. E.g. the Base FVP that has two AEMv8 CPU
> clusters has an
> > +  executable file called FVP_Base_AEMv8A-AEMv8A, so the compatible
> value for
> 
> Naming conventions of the exe aren't going to change?

Almost certainly will at some point, as will the very name Fixed Virtual
Platform, what 'families' ARM produce and their naming, and the
configuration of the 'hardware' compiled into the models.

These are software models, so can be changed easily at the whim of
marketing, or current perceived requirements from engineers and
managers. So generally, it's a moving target, that doesn't fit nicely
into the needs producing device-trees.

-- 
Tixy

Re: [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model

[Jon Medhurst (Tixy)]

On Mon, 2016-06-20 at 15:55 +0100, Mark Rutland wrote:
> On Mon, Jun 20, 2016 at 03:34:37PM +0100, Jon Medhurst (Tixy) wrote:
> > On Mon, 2016-06-20 at 13:39 +0100, Mark Rutland wrote:
> > > Hi,
> > > 
> > > On Mon, Jun 20, 2016 at 01:13:16PM +0100, Jon Medhurst wrote:
> > > > Fixed Virtual Platform (FVP) Base models are simulations of systems
> > > > that resemble Versatile Express or Juno hardware.
> > > > 
> > > > This adds a device-tree for the model variant that has two clusters of
> > > > Architecture Envelope Model (AEM) v8-A CPUs. The peripheral devices that
> > > > are common to all variants of Base models have been placed in a separate
> > > > file (fvp-base.dtsi) to facilitate creating device-trees for other
> > > > models.
> > > > 
> > > > It is desirable to use simulations for code testing purposes and so it
> > > > is beneficial to include nodes for things that are timing and power
> > > > consumption related, even when these don't otherwise have relevance or
> > > > accuracy. Where these have been included here (e.g. idle-states) entries
> > > > have been copied from real hardware platforms such as Juno.
> > > 
> > > Which firmware are you using,
> > 
> > ARM Trusted Firmware
> > 
> > >  and what precisely does it do w.r.t.
> > > those idle states?
> > 
> > I don't know, will check. Those states are also in the ARM TF
> > device-tree for the Base FVP [2] but I admit I didn't verify they were
> > correct. (Unlike real 'hardware' dt nodes, for which I methodically went
> > through documentation and LISA files to check and fix).
> > 
> > [2] https://github.com/ARM-software/arm-trusted-firmware/blob/master/fdts/fvp-base-gicv3-psci.dts
> > 
> > >  Judging by the FVP ATF pm code [1], those state IDs
> > > aren't valid (though perhaps the comment is wrong, or I've misunderstood
> > > something).
> > 
> > I'm not sure which comment you are referring to, that link [1] doesn't
> > seem to anchor to a particular source line in my web browser, and I
> > don't spot anything relevant scanning by eye.
> 
> Aargh, the web interface appears to have given me a duff URL. Let's try
> again [3]. ;)
> 
> The comments note state-ids 0x01, 0x02, and 0x22, which don't appear to
> match the DT. It might be that I've just misunderstood

That function is only compiled when ARM_RECOM_STATE_ID_ENC is true,
which it isn't when I build TF using "make PLAT=fvp ...." so I think
it's a red herring.

When I boot the FVP with my posted device-tree, the core run state icons
on the CLCD window behave as you would expect for CPUs and whole
clusters powering off/on as CPU's activity changes. So idle _looks_ like
it's working OK.

I also put printfs in ATF's psci_cpu_suspend() function and I can see
the values specified in device-tree being passed in and the code
behaving sensibly. From how it cracks the power_state value [4] it
certainly looks like the numbers have the following meanings:

top byte = 0..3 for the 'level' of the power state
top-but-one byte = 0/1 for Standby/Powerdown

For FVP [5], the level appears to be 0=CPU, 1=Cluster.
This matches what's in the device-tree I posted, where we have
0x00010000 for CPU sleep, and 0x01010000 for cluster sleep.

All of which is a long way of saying that I believe the values that the
firmware guys and Linaro have been using for the past year or two are
correct ;-)

> [3] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/plat/arm/board/fvp/fvp_pm.c#L53

[4] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/include/bl31/services/psci.h#L100
[5] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/plat/arm/board/fvp/fvp_pm.c#L195

-- 
Tixy

Re: [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models.

[Rob Herring]

On Tue, Jun 21, 2016 at 02:38:32PM +0100, Jon Medhurst (Tixy) wrote:
> On Tue, 2016-06-21 at 08:22 -0500, Rob Herring wrote:
> > > +Required properties (in root node):
> > > +- compatible value:
> > > +     compatible = "arm,<family>,<variant>", "arm,<family>";
> > > +  where <family> is one of:
> > > +  - "fvp-base" for the Base FVP
> > > +  - "fvp-ve" for the VE FVP
> > > +  and <variant> is the part of the model's executable filename with
> > the family
> > > +  name omitted, converted to lower case, and with non-alphanumeric
> > characters
> > > +  replaced with '-'. E.g. the Base FVP that has two AEMv8 CPU
> > clusters has an
> > > +  executable file called FVP_Base_AEMv8A-AEMv8A, so the compatible
> > value for
> > 
> > Naming conventions of the exe aren't going to change?
> 
> Almost certainly will at some point, as will the very name Fixed Virtual
> Platform, what 'families' ARM produce and their naming, and the
> configuration of the 'hardware' compiled into the models.
> 
> These are software models, so can be changed easily at the whim of
> marketing, or current perceived requirements from engineers and
> managers. So generally, it's a moving target, that doesn't fit nicely
> into the needs producing device-trees.

Then do we even need to specify something so specific? The kernel 
probably doesn't even care. Are you going to upstream new strings 
everytime there's a new one (that's public)?

We've had models supported upstream for a long time. What's changed now?

Rob

Re: [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models.

[Jon Medhurst (Tixy)]

On Tue, 2016-06-21 at 16:33 -0500, Rob Herring wrote:
> On Tue, Jun 21, 2016 at 02:38:32PM +0100, Jon Medhurst (Tixy) wrote:
> > On Tue, 2016-06-21 at 08:22 -0500, Rob Herring wrote:
> > > > +Required properties (in root node):
> > > > +- compatible value:
> > > > +     compatible = "arm,<family>,<variant>", "arm,<family>";
> > > > +  where <family> is one of:
> > > > +  - "fvp-base" for the Base FVP
> > > > +  - "fvp-ve" for the VE FVP
> > > > +  and <variant> is the part of the model's executable filename with
> > > the family
> > > > +  name omitted, converted to lower case, and with non-alphanumeric
> > > characters
> > > > +  replaced with '-'. E.g. the Base FVP that has two AEMv8 CPU
> > > clusters has an
> > > > +  executable file called FVP_Base_AEMv8A-AEMv8A, so the compatible
> > > value for
> > > 
> > > Naming conventions of the exe aren't going to change?
> > 
> > Almost certainly will at some point, as will the very name Fixed Virtual
> > Platform, what 'families' ARM produce and their naming, and the
> > configuration of the 'hardware' compiled into the models.
> > 
> > These are software models, so can be changed easily at the whim of
> > marketing, or current perceived requirements from engineers and
> > managers. So generally, it's a moving target, that doesn't fit nicely
> > into the needs producing device-trees.
> 
> Then do we even need to specify something so specific? The kernel 
> probably doesn't even care.

Well, it would certainly be easier if we could just use a simple
'arm,fvp' for compatible and model name and not worry about the 100 or
so current variants. (Some are 32-bit, some 64-bit with just about every
current ARM CPU represented, plus various peripheral sets with regard to
display, iommu, dma, etc.


>  Are you going to upstream new strings 
> everytime there's a new one (that's public)?

I've only been asked to upstream a device-tree for the one that ARM
targets in its 'platform release' [1]. Note, all 100+ models are equally
'public' in the sense that they are available to people are pay (like
real hardware supported by Linux).

[1] https://community.arm.com/docs/DOC-10803)

> 
> We've had models supported upstream for a long time. What's changed now?

ARM's software releases are targeting a different model.

-- 
Tixy

Re: [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model

[Mark Rutland]

On Tue, Jun 21, 2016 at 07:01:27PM +0100, Jon Medhurst (Tixy) wrote:
> On Mon, 2016-06-20 at 15:55 +0100, Mark Rutland wrote:
> > On Mon, Jun 20, 2016 at 03:34:37PM +0100, Jon Medhurst (Tixy) wrote:
> > > On Mon, 2016-06-20 at 13:39 +0100, Mark Rutland wrote:
> > > > Hi,
> > > > 
> > > > On Mon, Jun 20, 2016 at 01:13:16PM +0100, Jon Medhurst wrote:
> > > > > Fixed Virtual Platform (FVP) Base models are simulations of systems
> > > > > that resemble Versatile Express or Juno hardware.
> > > > > 
> > > > > This adds a device-tree for the model variant that has two clusters of
> > > > > Architecture Envelope Model (AEM) v8-A CPUs. The peripheral devices that
> > > > > are common to all variants of Base models have been placed in a separate
> > > > > file (fvp-base.dtsi) to facilitate creating device-trees for other
> > > > > models.
> > > > > 
> > > > > It is desirable to use simulations for code testing purposes and so it
> > > > > is beneficial to include nodes for things that are timing and power
> > > > > consumption related, even when these don't otherwise have relevance or
> > > > > accuracy. Where these have been included here (e.g. idle-states) entries
> > > > > have been copied from real hardware platforms such as Juno.
> > > > 
> > > > Which firmware are you using,
> > > 
> > > ARM Trusted Firmware
> > > 
> > > >  and what precisely does it do w.r.t.
> > > > those idle states?
> > > 
> > > I don't know, will check. Those states are also in the ARM TF
> > > device-tree for the Base FVP [2] but I admit I didn't verify they were
> > > correct. (Unlike real 'hardware' dt nodes, for which I methodically went
> > > through documentation and LISA files to check and fix).
> > > 
> > > [2] https://github.com/ARM-software/arm-trusted-firmware/blob/master/fdts/fvp-base-gicv3-psci.dts
> > > 
> > > >  Judging by the FVP ATF pm code [1], those state IDs
> > > > aren't valid (though perhaps the comment is wrong, or I've misunderstood
> > > > something).
> > > 
> > > I'm not sure which comment you are referring to, that link [1] doesn't
> > > seem to anchor to a particular source line in my web browser, and I
> > > don't spot anything relevant scanning by eye.
> > 
> > Aargh, the web interface appears to have given me a duff URL. Let's try
> > again [3]. ;)
> > 
> > The comments note state-ids 0x01, 0x02, and 0x22, which don't appear to
> > match the DT. It might be that I've just misunderstood
> 
> That function is only compiled when ARM_RECOM_STATE_ID_ENC is true,
> which it isn't when I build TF using "make PLAT=fvp ...." so I think
> it's a red herring.

Ah,ok.

> When I boot the FVP with my posted device-tree, the core run state icons
> on the CLCD window behave as you would expect for CPUs and whole
> clusters powering off/on as CPU's activity changes. So idle _looks_ like
> it's working OK.
> 
> I also put printfs in ATF's psci_cpu_suspend() function and I can see
> the values specified in device-tree being passed in and the code
> behaving sensibly. From how it cracks the power_state value [4] it
> certainly looks like the numbers have the following meanings:
> 
> top byte = 0..3 for the 'level' of the power state
> top-but-one byte = 0/1 for Standby/Powerdown
> 
> For FVP [5], the level appears to be 0=CPU, 1=Cluster.
> This matches what's in the device-tree I posted, where we have
> 0x00010000 for CPU sleep, and 0x01010000 for cluster sleep.
> 
> All of which is a long way of saying that I believe the values that the
> firmware guys and Linaro have been using for the past year or two are
> correct ;-)

Great, thanks for digging into that, and apologies for the noise!

Thanks,
Mark.

> 
> > [3] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/plat/arm/board/fvp/fvp_pm.c#L53
> 
> [4] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/include/bl31/services/psci.h#L100
> [5] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/plat/arm/board/fvp/fvp_pm.c#L195
> 
> -- 
> Tixy
> 
--
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