| Message ID | 20230630035547.80329-1-joel@jms.id.au (mailing list archive) |
|---|---|
| Headers | show |
| Series | ppc/pnv: Extend "quad" model for p10 | expand |
On Fri Jun 30, 2023 at 1:55 PM AEST, Joel Stanley wrote: > The quad model implements the EC xscoms for the p9 machine, reusing the > same model for p10 which isn't quite correct. This series adds a PnvQuad > class and subclasses it for P9 and P10. Implement the core thread state > xscom as an example. I expect more function to be implemented in future > patches. > > There's one outstanding question. Skiboot has this for the p10 scom: > > #define P10_EC_CORE_THREAD_STATE 0x412 > > However the read that comes is for 0x28412. I suspect the upper 0x28000 > are addressing bits, so we're really reporting the core thread state for > the given core. Should the model instead wired so one is created for > each chiplet? Or should we report the value for all possible cores, like > the P9 code does for P9X_EX_NCU_SPEC_BAR? > > switch (offset) { > case P9X_EX_NCU_SPEC_BAR: > case P9X_EX_NCU_SPEC_BAR + 0x400: /* Second EX */ Yes you're right, 0x28000 is addressing within the quad. The 0x2 selects core/cache/NCU/etc and the 8 is a one-hot encoding to select the core. So this access should actually be redirected to the pnv core scoms. I think to make that work, those regions have to be a subregion of the quad, right now they seem to overlap (the sizes are a bit wrong too, they end up overlapping). 0x412 is then a register in a particular core's "PC" unit. I assume PC is probably 0x800 or 0x1000 in size. The quad itself has a QME engine, so you might address that with the quad registers. IIRC the actual topology is something like EQ +--- EX +--- ECL2 +--- EC | +--- L3 +--- L2 +--- QME +--- NCU +--- maybe some scom and sensor stuff No point modeling all that of course, just per-core and per-quad regions like it already has for now. But if for example we wanted to model some registers in the L2, it would not be contiguous with the core addresses so we'd have to add it. Thanks, Nick > > Joel Stanley (4): > ppc/pnv: quad xscom callbacks are P9 specific > ppc/pnv: Subclass quad xscom callbacks > ppc/pnv: Add P10 quad ops > ppc/pnv: Return zero for core thread state xscom > > include/hw/ppc/pnv_core.h | 12 +++- > hw/ppc/pnv.c | 11 ++-- > hw/ppc/pnv_core.c | 114 +++++++++++++++++++++++++++++++------- > 3 files changed, 113 insertions(+), 24 deletions(-)
The quad model implements the EC xscoms for the p9 machine, reusing the same model for p10 which isn't quite correct. This series adds a PnvQuad class and subclasses it for P9 and P10. Implement the core thread state xscom as an example. I expect more function to be implemented in future patches. There's one outstanding question. Skiboot has this for the p10 scom: #define P10_EC_CORE_THREAD_STATE 0x412 However the read that comes is for 0x28412. I suspect the upper 0x28000 are addressing bits, so we're really reporting the core thread state for the given core. Should the model instead wired so one is created for each chiplet? Or should we report the value for all possible cores, like the P9 code does for P9X_EX_NCU_SPEC_BAR? switch (offset) { case P9X_EX_NCU_SPEC_BAR: case P9X_EX_NCU_SPEC_BAR + 0x400: /* Second EX */ Joel Stanley (4): ppc/pnv: quad xscom callbacks are P9 specific ppc/pnv: Subclass quad xscom callbacks ppc/pnv: Add P10 quad ops ppc/pnv: Return zero for core thread state xscom include/hw/ppc/pnv_core.h | 12 +++- hw/ppc/pnv.c | 11 ++-- hw/ppc/pnv_core.c | 114 +++++++++++++++++++++++++++++++------- 3 files changed, 113 insertions(+), 24 deletions(-)