From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model
Date: Wed, 22 Jun 2016 10:35:49 +0100 [thread overview]
Message-ID: <20160622093549.GA25837@leverpostej> (raw)
In-Reply-To: <1466532087.2856.66.camel@linaro.org>
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
>
next prev parent reply other threads:[~2016-06-22 9:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 12:13 [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models Jon Medhurst
2016-06-20 12:13 ` [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model Jon Medhurst
2016-06-20 12:39 ` Mark Rutland
2016-06-20 14:34 ` Jon Medhurst (Tixy)
2016-06-20 14:55 ` Mark Rutland
2016-06-21 18:01 ` Jon Medhurst (Tixy)
2016-06-22 9:35 ` Mark Rutland [this message]
2016-06-21 13:22 ` [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models Rob Herring
2016-06-21 13:38 ` Jon Medhurst (Tixy)
2016-06-21 21:33 ` Rob Herring
2016-06-22 8:43 ` Jon Medhurst (Tixy)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160622093549.GA25837@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).