devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: "Jon Medhurst (Tixy)"
	<tixy-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model
Date: Mon, 20 Jun 2016 15:55:35 +0100	[thread overview]
Message-ID: <20160620145535.GC9246@leverpostej> (raw)
In-Reply-To: <1466433277.2833.33.camel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

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, but it could be
that every attempt to idle simply fails if we're passing the wrong
state-ids, and that's somewhat sub-optimal.

I'm not sure if there's a simple diagnostic for that. Lorenzo, any idea
if/how we can detect when the FW rejects an idle state it doesn't
recognise?

> > People use the FVPs with a variety of FW and bootloaders, so I'm not
> > keen on putting anything FW or bootloader specific into the canonical
> > FVP DT files.
> 
> I can agree about bootloaders, but would anyone be using FVP's without
> ARM Trusted firmware?

Yes. I know of several people just using the bootwrapper [4], with
custom DTs.

> And if they aren't using using that, can we still assume a PSCI
> capable firmware for things like CPU enable-method?

I was counting that under "FW or bootloader specific", so no.

> I'm asking to get an idea where the line is as I have changes for
> Foundation model too. Also, want something to say to the people who
> asked me to 'upstream the FVP DTs' as I expect they think people are
> using the One True Way which involves ARM's Trusted Firmware and other
> sacred tomes passed down to them ;-)

Ideally, the Base stuff is meant to be all fixed, so we should be able
to support the default configuration.

To handle different FWs and bootloaders, I think we should have a DT
without the enable-method, PSCI node, and idle states, for the default
FVP Base configuration.

We can *also* have a DT for the default FVP Base + ATF configuration (so
long as clearly named as such), with the appropriate nodes and
properties.

> I'll fix your other comment on the DT, so snipping email here.

Sure, cheers!

Thanks,
Mark.

> > [1] https://github.com/ARM-software/arm-trusted-firmware/commit/6355f2347aec8bf6ad74867c2b0c996e10546ad4#L53 

[3] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/plat/arm/board/fvp/fvp_pm.c#L53
[4] https://git.kernel.org/cgit/linux/kernel/git/cmarinas/boot-wrapper-aarch64.git/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2016-06-20 14:55 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)
     [not found]       ` <1466433277.2833.33.camel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-06-20 14:55         ` Mark Rutland [this message]
2016-06-21 18:01           ` Jon Medhurst (Tixy)
     [not found]             ` <1466532087.2856.66.camel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-06-22  9:35               ` Mark Rutland
     [not found] ` <1466424796-13769-1-git-send-email-tixy-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
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=20160620145535.GC9246@leverpostej \
    --to=mark.rutland-5wv7dgnigg8@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=sudeep.holla-5wv7dgnIgG8@public.gmane.org \
    --cc=tixy-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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).