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

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:

quoted

On Mon, Jun 20, 2016 at 03:34:37PM +0100, Jon Medhurst (Tixy) wrote:

quoted

On Mon, 2016-06-20 at 13:39 +0100, Mark Rutland wrote:

quoted

Hi,

On Mon, Jun 20, 2016 at 01:13:16PM +0100, Jon Medhurst wrote:

quoted

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

quoted

 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

quoted

 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.

quoted

[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