On Fri, Dec 12, 2014 at 08:08:25AM +0000, Eddie Huang wrote:

Hi Mark,

On Thu, 2014-12-11 at 18:02 +0000, Mark Rutland wrote:

quoted

Hi,

On Wed, Dec 10, 2014 at 10:50:01AM +0000, Eddie Huang wrote:

quoted

Add device tree support for MT8173 SoC and evalutaion board based on it.

+/ {
+	model = "mediatek,mt8173-evb";
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;

Do any of these support earlycon?

Not yet

quoted

quoted

+	};
+
+	memory {

Nit: should be memory at 40000000 (and you'll need to add device_type =
"memory").

quoted

+		reg = <0 0x40000000 0 0x40000000>;
+	};

skeleton.dtsi already has /memory node with address-cells=2,
size-cells=1, which will cause build warning if I change to use
memory at 40000000, because we use size-cells=2. I will not include
skeleton.dtsi and follow your suggestion in next version.

That sounds fine to me.

quoted

quoted

+
+#include "skeleton.dtsi"
+
+/ {
+	compatible = "mediatek,mt8173";
+	interrupt-parent = <&sysirq>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpu-map {

This should live under /cpus, as documented in
Documentation/devicetree/bindings/arm/topology.txt.

Got it, fix next version

quoted

quoted

+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};

What are you using as your PSCI 0.2 implementation?

Is it fully compliant? (e.g. are the reset and power off functions
implemented, may CPU0 be hotplugged)?

Given only portions of the GIC seem to be described below, what
exception level is your kernel entered at? Per the spec it should be
EL2, but given the brokenness below with the GIC I'm suspicious.

Currently we only implement CPU boot, no power off, no CPU0 hotplug
either. And enter kernel at EL2. Actually, we run ATF in EL3, then
switch to EL2 to run lk and kernel.

Ok. In the absence of CPU_OFF, this is not yet a conforming PSCI 0.2
implementation, so I'm wary of marking this as PSCI 0.2 until that is
the case. Any attempt to power of CPUs will hit a BUG() in cpu_die(),
and we don't want that.

Is CPU0 hotplug planned?

If not, does your PSCI implementation report CPU0 as
non-hotpluggable via MIGRATE_INFO_TYPE reporting a UP not migratable
trusted OS (and MIGRATE_INFO_UP_CPU reporting CPU0 as the resident CPU)?

Are SYSTEM_OFF and SYSTEM_RESET available?

Thanks,
Mark.