[Skiboot] [PATCH v9 00/10] Initial OpenCAPI 3.0 Support for P9

[Stewart Smith]

Andrew Donnellan <andrew.donnellan at au1.ibm.com> writes:
> This series implements OpenCAPI support for P9.
>
> The series is divided as follows:
>
>  - Patches 1-3: general refactoring
>
>    Add various structs and fields we'll need later.
>
>  - Patch 4: setting up the NPU
>
>    At present, we're doing NPU configuration separately from the existing
>    NVLink code. At a later point, we intend to rework this to make it
>    possible to support both NVLink and OpenCAPI links on the same NPU.
>
>  - Patches 5-6: training links and creating OpenCAPI PHBs
>
>    Unlike NVLink, which presents a single PHB to represent the entire NPU,
>    we present a single PHB per device/link. This is necessary due to
>    limitations in MMIO window allocation. Unfortunately this makes the
>    structures we share with NVLink a little more complex, oh well.
>
>  - Patch 7: OPAL API calls
>
>    We define three new API calls for handling the Shared Process Area and
>    setting OpenCAPI TL template capabilities.
>
>  - Patch 8: platform support
>
>    See below.
>
>  - Patches 9-10: device tree documentation
>
> Notable limitations:
>
>  - We only support the zaius platform for now. We'll be adding ZZ after a bit
>    more testing booting ZZs with hostboot rather than BML. Witherspoon
>    support will come at a later point (our testing shows it's mostly
>    working now!)
>
>  - No mixing of OpenCAPI and NVLink devices on the same NPU. This will come in a
>    later series. The only platform this currently impacts is Witherspoon.
>
>  - No support for link ganging - there are also no OpenCAPI devices that support
>    link ganging yet, so this will come when we get to it...
>
>  - Link information is hardcoded per platform, and we don't have any form of
>    presence detection apart from failing to train the link. Eventually, this
>    will be detected via I2C once Hostboot adds the relevant link info to HDAT.
>
>  - No LPC memory - this will come in a later patch once we've done a bit more
>    testing internally.
>
>  - No link reset functionality - this will come in a later patch.
>
> This series has been tested on a Zaius. I've also tested it on a
> GPU-equipped Witherspoon to ensure it doesn't break NVLink.
>
> Thanks to everyone who's helped us with this, especially to Alistair Popple for
> his advice on NVLink, and to the OpenCAPI hardware teams in Austin and
> Rochester who provided us with a lot of vital assistance.
>
> Comments welcome!

Is "merged to master as of bd6194f5a8647e2e8671a76f7af65244fa0d30e7" a
suitable comment?

i.e. I think we're okay to have this upstream now.

We may want to think about how we deal with OPAL APIs for things that
are in development (should we hide things behind a nvram setting until
we're sure they're okay?)

As it is today, all p9 systems that could support this aren't going to
go out with anything earlier than skiboot 6.0 (which is a couple of
months away), so we're probably okay... but it's something to think
about.

You have any thoughts?

-- 
Stewart Smith
OPAL Architect, IBM.