On Mon Jul 10, 2023 at 10:25 AM AEST, Joel Stanley wrote:
> On Sat, 8 Jul 2023 at 01:17, Nicholas Piggin <npig...@gmail.com> wrote:
>
> > > --- a/include/hw/ppc/pnv_xscom.h
> > > +++ b/include/hw/ppc/pnv_xscom.h
> > > @@ -127,6 +127,17 @@ struct PnvXScomInterfaceClass {
> > > #define PNV10_XSCOM_EC(proc) \
> > > ((0x2 << 16) | ((1 << (3 - (proc))) << 12))
> > >
> > > +#define PNV10_XSCOM_QME(chiplet) \
> > > + (PNV10_XSCOM_EQ(chiplet) | (0xE << 16))
> > > +
> > > +/*
> > > + * Make the region larger by 0x1000 (instead of starting at an offset)
> > > so the
> > > + * modelled addresses start from 0
> > > + */
> > > +#define PNV10_XSCOM_QME_BASE(core) \
> > > + ((uint64_t) PNV10_XSCOM_QME(PNV10_XSCOM_EQ_CHIPLET(core)))
> > > +#define PNV10_XSCOM_QME_SIZE (0x8000 + 0x1000)
> >
> > I couldn't work out this comment.
>
> I was trying to describe why we have the + 0x1000.
>
> Each core sets a bit in the xscom address space, with the first core
> setting bit 12, second bit 13, etc. So there's actually no registers
> at PNV10_XSCOM_QME_BASE, but so the addressing is easier to follow, I
> chose to start the base where we do, and make the region 0x1000
> bigger.
>
> That was my understanding at least.
Ah okay that does make sense. Because you have the core number in the
address and core number encoding is one-hot, you don't start at zero
or end at 0x4000.
It makes sense after you stare at QME model, but maybe could comment
the scheme briefly there... and now I think about it, I wonder if QME
can actually do broadcast ops to the cores. We don't use that in
skiboot but ISTR it could be done, so size might be 0x10000.
Thanks,
Nick
