From: David Gibson <david@gibson.dropbear.id.au>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"Cédric Le Goater" <clg@kaod.org>,
qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Andrea Bolognani" <abologna@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge
Date: Wed, 27 Jun 2018 17:28:25 +1000 [thread overview]
Message-ID: <20180627072825.GH14434@umbus.fritz.box> (raw)
In-Reply-To: <1d70c0f9179990cd33d7c82c5190179e60ae4ce3.camel@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]
On Wed, Jun 27, 2018 at 11:38:17AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2018-06-27 at 03:35 +0300, Michael S. Tsirkin wrote:
> >
> > > +
> > > +/* Extract field fname from val */
> > > +#define GETFIELD(fname, val) \
> > > + (((val) & fname##_MASK) >> fname##_LSH)
> > > +
> > > +/* Set field fname of oval to fval
> > > + * NOTE: oval isn't modified, the combined result is returned
> > > + */
> > > +#define SETFIELD(fname, oval, fval) \
> > > + (((oval) & ~fname##_MASK) | \
> > > + ((((typeof(oval))(fval)) << fname##_LSH) & fname##_MASK))
> > > +
> >
> > Pls don't make up macros like these. We can't have each device do it.
>
> So what ? We move the macros in a generic place ? These are MUCH better
> than open-coding the masks & shifts and much less error prone.
There are already deposit32 and deposit64() functions which I think
would cover this.
>
> > > @@ -1031,6 +1110,7 @@ static Property pnv_chip_properties[] = {
> > > DEFINE_PROP_UINT64("ram-size", PnvChip, ram_size, 0),
> > > DEFINE_PROP_UINT32("nr-cores", PnvChip, nr_cores, 1),
> > > DEFINE_PROP_UINT64("cores-mask", PnvChip, cores_mask, 0x0),
> > > + DEFINE_PROP_UINT32("num-phbs", PnvChip, num_phbs, 1),
> > > DEFINE_PROP_END_OF_LIST(),
> > > };
> >
> > How about instanciating each extra phb using -device?
> > Seems better than teaching everyone about platform-specific
> > options.
>
> It's about which PHBs are enabled, not which are instanciated, if I
> understand Cedric changes ...
>
> This aims are implementing the POWER8 chip correctly, it has a fixed
> number of PHBs per-chip at very specific XSCOM addresses, that the
> firwmare knows about.
Yeah, this is a recurring design conflict, which I'm not sure how to
address. Usually instantiating things with -device works better, but
when do we do when that allows more flexibility with hardware
arrangement than is actually possible in the hardware.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-06-27 7:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-26 13:59 [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge Cédric Le Goater
2018-06-26 15:57 ` Andrea Bolognani
2018-06-26 17:02 ` Cédric Le Goater
2018-06-27 10:22 ` Andrea Bolognani
2018-06-27 12:18 ` Cédric Le Goater
2018-06-27 19:48 ` Cédric Le Goater
2018-06-28 3:59 ` David Gibson
2018-06-28 8:00 ` Andrea Bolognani
2018-06-28 10:04 ` Cédric Le Goater
2018-06-28 11:40 ` Andrea Bolognani
2018-06-28 12:20 ` Cédric Le Goater
2018-06-28 13:05 ` Cédric Le Goater
2018-06-28 12:14 ` Benjamin Herrenschmidt
2018-07-02 6:23 ` David Gibson
2018-06-26 22:21 ` Benjamin Herrenschmidt
2018-06-27 0:35 ` Michael S. Tsirkin
2018-06-27 1:38 ` Benjamin Herrenschmidt
2018-06-27 2:39 ` Michael S. Tsirkin
2018-06-27 7:28 ` David Gibson [this message]
2018-06-27 7:46 ` Cédric Le Goater
2018-06-27 8:41 ` Benjamin Herrenschmidt
2018-06-27 10:40 ` Andrea Bolognani
2018-06-27 13:03 ` Cédric Le Goater
2018-06-27 11:51 ` Cédric Le Goater
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=20180627072825.GH14434@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=abologna@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=clg@kaod.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.