qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Prerna Saxena <prerna@linux.vnet.ibm.com>
Cc: "Alexey Kardashevisky" <aik@au1.ibm.com>,
	qemu-ppc <qemu-ppc@nongnu.org>,
	"Andreas Färber" <afaerber@suse.de>,
	"Anthony Liguori" <anthony@codemonkey.ws>,
	QEMU <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] [v3] target-ppc: Enhance CPU nodes of device tree to be PAPR compliant.
Date: Mon, 12 Aug 2013 16:03:24 +1000	[thread overview]
Message-ID: <1376287404.32100.153.camel@pasglop> (raw)
In-Reply-To: <5208669A.7010000@linux.vnet.ibm.com>

On Mon, 2013-08-12 at 10:07 +0530, Prerna Saxena wrote:

 .../...

> I dont know what context lead to this observation.
> However, PAPR mentions the following nomenclature guideline:
> 
> "The value of this property shall be of the form: “PowerPC,<name>”,
> where <name> is the name of the processor chip which may be displayed to
> the user. <name> shall not contain underscores."

This actually comes from the original Open Firmware binding for PowerPC
processors, which PAPR inherits largely from. Thus this naming scheme
should apply to all PowerPC processors when a device-tree is involved.

> I think this name guideline will hold good for all PAPR compliant
> processors.

Also PAPR is not a processor architecture, it's a platform and firmware
architecture, so "PAPR-compliant CPU" has little meaning :-)

Cheers,
Ben.

> > 
> >> @@ -1315,6 +1325,14 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
> >>  
> >>          cpu_model = g_strndup(parent_name,
> >>              strlen(parent_name) - strlen("-" TYPE_POWERPC_CPU));
> >> +
> >> +        for (i = 0; ppc_cpu_aliases[i].model != NULL; i++) {
> >> +            if (strcmp(ppc_cpu_aliases[i].model, cpu_model) == 0) {
> >> +                g_free(cpu_model);
> >> +                cpu_model = g_strndup(ppc_cpu_aliases[i].alias,
> >> +                                strlen(ppc_cpu_aliases[i].alias));
> >> +            }
> >> +        }
> >>      }
> >>  
> >>      /* Prepare the device tree */
> > 
> > This is still fixing up the name in the wrong place: -cpu POWER7_v2.3
> > will not get fixed, only -cpu host or KVM's default.
> > 
> > The solution I had discussed with Alex is the following: When devices
> > need to expose their name to firmware in a special way, we have the
> > DeviceClass::fw_name field. All we have to do is assign it and use it
> > instead of cpu_model if non-NULL, just like we assign DeviceClass::desc.
> > The way to do it would be to extend the family of POWERPC_DEF* macros to
> > specify the additional field on the relevant CPU models.
> > 
> 
> Would this be the same use-case as reflected by: ppc_cpu_aliases.alias ?
> If so, do we really need a separate field to convey the same information ?
> 
> > Therefore my above question: Would it be sufficient to explicitly name
> > POWER7_v2.3 PowerPC,POWER7 etc. and to drop the upper-casing?
> > Or would we also need to name a CPU such as MPC8572E (random Freescale
> > CPU where I don't know the expected fw_name and that is unlikely to
> > occur/work in sPAPR) "PowerPC,MPC8572E" if someone specified it with
> > -cpu MPC8572E?
> > 
> 
> If this is not a PAPR-compliant CPU, I dont think the PAPR naming
> convention is of any good.
> I havent worked with non-PAPR cpus. Is the device tree for such CPUs
> generated by routines in hw/ppc/spapr.c ? Or do they have custom
> routines to generate appropriate device tree nodes ?
> 
> Regards,

  reply	other threads:[~2013-08-12  6:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-08  7:21 [Qemu-devel] [PATCH 0/2] [v3] target-ppc: Enhance CPU nodes of SPAPR-generated device tree Prerna Saxena
2013-08-08  7:24 ` [Qemu-devel] [PATCH 1/2] [v3] target-ppc: Get CPU name to correct reflect its model in the SLOF " Prerna Saxena
2013-08-08  7:26 ` [Qemu-devel] [PATCH 2/2] [v3] target-ppc: Enhance CPU nodes of device tree to be PAPR compliant Prerna Saxena
2013-08-08 10:34   ` Andreas Färber
2013-08-12  4:37     ` Prerna Saxena
2013-08-12  6:03       ` Benjamin Herrenschmidt [this message]
2013-08-12 19:17         ` [Qemu-devel] [Qemu-ppc] " Thomas Huth
2013-08-12 21:22           ` Benjamin Herrenschmidt
2013-08-14 10:18             ` Alexander Graf
2013-08-14 10:31               ` Andreas Färber
2013-08-14 11:04               ` Andreas Färber
  -- strict thread matches above, loose matches on Subject: below --
2013-08-14 11:20 Jacques Mony

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=1376287404.32100.153.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=afaerber@suse.de \
    --cc=aik@au1.ibm.com \
    --cc=anthony@codemonkey.ws \
    --cc=prerna@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.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).