"Alastair D'Silva" <alastair@xxxxxxxxxxx> writes: >> -----Original Message----- >> From: Dan Williams <dan.j.williams@xxxxxxxxx> >> >> On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva <alastair@xxxxxxxxxxx> >> wrote: >> > >> > This series adds support for OpenCAPI Persistent Memory devices on >> > bare metal (arch/powernv), exposing them as nvdimms so that we can >> > make use of the existing infrastructure. There already exists a driver >> > for the same devices abstracted through PowerVM (arch/pseries): >> > arch/powerpc/platforms/pseries/papr_scm.c >> > >> > These devices are connected via OpenCAPI, and present as LPC (lowest >> coherence point) memory to the system, practically, that means that >> memory on these cards could be treated as conventional, cache-coherent >> memory. >> > >> > Since the devices are connected via OpenCAPI, they are not enumerated >> via ACPI. Instead, OpenCAPI links present as pseudo-PCI bridges, with >> devices below them. >> > >> > This series introduces a driver that exposes the memory on these cards as >> nvdimms, with each card getting it's own bus. This is somewhat complicated >> by the fact that the cards do not have out of band persistent storage for >> metadata, so 1 SECTION_SIZE's (see SPARSEMEM) worth of storage is carved >> out of the top of the card storage to implement the ndctl_config_* calls. >> >> Is it really tied to section-size? Can't that change based on the configured >> page-size? It's not clear to me why that would be the choice, but I'll dig into >> the implementation. >> > > I had tried using PAGE_SIZE, but ran into problems carving off just 1 page and handing it to the kernel, while leaving the rest as pmem. That was a while ago though, so maybe I should retry it. > >> > The driver is not responsible for configuring the NPU (NVLink Processing >> Unit) BARs to map the LPC memory from the card into the system's physical >> address space, instead, it requests this to be done via OPAL calls (typically >> implemented by Skiboot). >> >> Are OPAL calls similar to ACPI DSMs? I.e. methods for the OS to invoke >> platform firmware services? What's Skiboot? >> > > Yes, OPAL is the interface to firmware for POWER. Skiboot is the open-source (and only) implementation of OPAL. https://github.com/open-power/skiboot In particular the tokens for calls are defined here: https://github.com/open-power/skiboot/blob/master/include/opal-api.h#L220 And you can grep for the token to find the implementation: https://github.com/open-power/skiboot/blob/master/hw/npu2-opencapi.c#L2328 cheers
