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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
