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:
> > Hi,
> >
> > On Wed, Dec 10, 2014 at 10:50:01AM +0000, Eddie Huang wrote:
> > > 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
>
> >
> > > + };
> > > +
> > > + memory {
> >
> > Nit: should be memory@40000000 (and you'll need to add device_type =
> > "memory").
> >
> > > + 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@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.
>
> > > +
> > > +#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
>
> > > +
> > > + 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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
