Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1166617ybb; Wed, 1 Apr 2020 17:22:24 -0700 (PDT) X-Google-Smtp-Source: APiQypLhcdjdyMJFcAICx6BGhf38MLEKeNDEBZEwOK1JAYgUFg+7xb8af8Ikn0oDVWIOkpg8LAZT X-Received: by 2002:a9d:c69:: with SMTP id 96mr410277otr.77.1585786944444; Wed, 01 Apr 2020 17:22:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585786944; cv=none; d=google.com; s=arc-20160816; b=HvIAo5jLXeuEYSJ5d2f4IUJk9Z3KIgPdgkkNAnq3l4FQPiNZ16aFoovU8QYX7ZqoIw vwolc246Uxgzrc3DyYS0H2Roc5lmyMhJj1fHTRHD2Xa0uCXFEamezVtDU35gP4QjfVwP zrgYn6RIgEFrQx0Yp91bpbRgZfzu896KkjMffmNxAftwNlrPcI12gRBhTAhjGIe4+iL4 f8qBNhpCm96Jo4a1/gmEwDzxkdaLZAS9tz5D1nayGWtD6PfNIBGe9rZ0oDozmGr2bgsA uE5KvsPEMNhr/wGxDYwJuoed6hujYvv4a8DOXLiShXqUA9vMiyXJV+nhye3STWonagAJ aGgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Cy8vIQz2yaGK0zk3nTridT+PraSHoSgW6yCapUf+4BA=; b=Q3oaHgdf2PYcdKe5ePdUbcES8HQ9nn1ZWp0gy5vXx+KLo+bjE5xHqvf6pbVBdqETvi wpf/K4o9Mq6VSfDV5nJWtg0NWhL0QaZqbpq8n4WTVODU9jEGFytg4Ps+oS4mcqsQhQyb 1tzgpbG8ykXpz70jwYYMhdj0/K952b/4Cs5/5WgeXri3K8etdqytisj08uLm5bnFwCFp m22gvldTGEb9N7E1Na7KXYBTD2QCn/F2p9ojnN7qGKpfXjvU0VoDBmrjzfj0DSGvJeW6 +Fa83OBhTvDfYmseeWdPd50G6QfLjZ6hNlbflBtzRKI1DoFfKXZ3EGh+KVTVZDuf5+EV ISdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=VYBVid+R; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y4si1511292ooh.53.2020.04.01.17.22.09; Wed, 01 Apr 2020 17:22:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=VYBVid+R; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732687AbgDBAUk (ORCPT + 99 others); Wed, 1 Apr 2020 20:20:40 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:43623 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732527AbgDBAUk (ORCPT ); Wed, 1 Apr 2020 20:20:40 -0400 Received: by mail-ed1-f68.google.com with SMTP id bd14so2024477edb.10 for ; Wed, 01 Apr 2020 17:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cy8vIQz2yaGK0zk3nTridT+PraSHoSgW6yCapUf+4BA=; b=VYBVid+R4R8MHVRoNK3oxU0Lzu3hLgOII+La6r+cIfCwIQqnZflVXrRIHHz3tvE2MI Aipae//AdtnRp9Lo0oX5nPWKOSjVuNPljOolfSg1mo8XFeQAstf0SzReIZuxx/SgZUaX gk8Xnfw/bW83bJMD7hQvFG9+InhhKSxonYtWIdBInrkdtiHyceDumbkLNf4IRrBAiCk/ FPd7nfxIEdCkXgN2khixYdOUJP/wPWkjzfolriu2S/f/DpiK0bnQGrS1s1bOizz72xf/ S3e4cF0Iw4vjDOmyt0tV2Aa418KcITIvZWvNZ0mMWw0RbbT5eVQjx812WB+KBYvLivNc oL5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cy8vIQz2yaGK0zk3nTridT+PraSHoSgW6yCapUf+4BA=; b=M5vIL+Q3OUpWGrW3EGKZ2Sv7W32U3M/OlbvUKido3otaJaPKNoibUF32Soq04wOYLv 9jnSywgvGitucMXJfZ8zVWgypScHXwjpRqEZWOPmrJqN0Bnoxegm5B6kW5o8HwO3YtBR RknG2SmCH83NMaDdg0Y+rtYRiER0aos/Ow5EobnI6gHzu6/UuGVI9KQaz+hZBgbRfP8e qhXKO4aFgp4aO5V8qydrkL8Um6AK7RlC0NFLYJMC1YYykmNH5XcDeKIj64SPab90UD13 42js1ztdVbIW60RNbDf534CGUugSLjkY4wO/6mzKPHLFg69mI9YfDXyZLonet55wQbVq izXg== X-Gm-Message-State: AGi0PubkPb6sZmCAzJf3OEJ148iEPeR2BpjbWkAbr2BFgas+XbuBFiLP ThhXiJl2OSsnOu8A4WmMZWafe8rpIFLy/k0OnKC7CA== X-Received: by 2002:a05:6402:3044:: with SMTP id bu4mr501326edb.123.1585786837024; Wed, 01 Apr 2020 17:20:37 -0700 (PDT) MIME-Version: 1.0 References: <20200327071202.2159885-1-alastair@d-silva.org> <20200327071202.2159885-14-alastair@d-silva.org> In-Reply-To: <20200327071202.2159885-14-alastair@d-silva.org> From: Dan Williams Date: Wed, 1 Apr 2020 17:20:25 -0700 Message-ID: Subject: Re: [PATCH v4 13/25] nvdimm/ocxl: Read the capability registers & wait for device ready To: "Alastair D'Silva" Cc: "Aneesh Kumar K . V" , "Oliver O'Halloran" , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Frederic Barrat , Andrew Donnellan , Arnd Bergmann , Greg Kroah-Hartman , Vishal Verma , Dave Jiang , Ira Weiny , Andrew Morton , Mauro Carvalho Chehab , "David S. Miller" , Rob Herring , Anton Blanchard , Krzysztof Kozlowski , Mahesh Salgaonkar , Madhavan Srinivasan , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , Anju T Sudhakar , Hari Bathini , Thomas Gleixner , Greg Kurz , Nicholas Piggin , Masahiro Yamada , Alexey Kardashevskiy , Linux Kernel Mailing List , linuxppc-dev , linux-nvdimm , Linux MM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote: > > This patch reads timeouts & firmware version from the controller, and > uses those timeouts to wait for the controller to report that it is ready > before handing the memory over to libnvdimm. > > Signed-off-by: Alastair D'Silva > --- > drivers/nvdimm/ocxl/Makefile | 2 +- > drivers/nvdimm/ocxl/main.c | 85 +++++++++++++++++++++++++ > drivers/nvdimm/ocxl/ocxlpmem.h | 29 +++++++++ > drivers/nvdimm/ocxl/ocxlpmem_internal.c | 19 ++++++ > 4 files changed, 134 insertions(+), 1 deletion(-) > create mode 100644 drivers/nvdimm/ocxl/ocxlpmem_internal.c > > diff --git a/drivers/nvdimm/ocxl/Makefile b/drivers/nvdimm/ocxl/Makefile > index e0e8ade1987a..bab97082e062 100644 > --- a/drivers/nvdimm/ocxl/Makefile > +++ b/drivers/nvdimm/ocxl/Makefile > @@ -4,4 +4,4 @@ ccflags-$(CONFIG_PPC_WERROR) += -Werror > > obj-$(CONFIG_OCXL_PMEM) += ocxlpmem.o > > -ocxlpmem-y := main.o > \ No newline at end of file > +ocxlpmem-y := main.o ocxlpmem_internal.o > diff --git a/drivers/nvdimm/ocxl/main.c b/drivers/nvdimm/ocxl/main.c > index c0066fedf9cc..be76acd33d74 100644 > --- a/drivers/nvdimm/ocxl/main.c > +++ b/drivers/nvdimm/ocxl/main.c > @@ -8,6 +8,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -327,6 +328,50 @@ static void remove(struct pci_dev *pdev) > } > } > > +/** > + * read_device_metadata() - Retrieve config information from the AFU and save it for future use > + * @ocxlpmem: the device metadata > + * Return: 0 on success, negative on failure > + */ > +static int read_device_metadata(struct ocxlpmem *ocxlpmem) > +{ > + u64 val; > + int rc; > + > + rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu, GLOBAL_MMIO_CCAP0, > + OCXL_LITTLE_ENDIAN, &val); This calling convention would seem to defeat the ability of sparse to validate endian correctness. That's independent of this series, but I wonder how does someone review why this argument is sometimes OCXL_LITTLE_ENDIAN and sometimes OCXL_HOST_ENDIAN? > + if (rc) > + return rc; > + > + ocxlpmem->scm_revision = val & 0xFFFF; > + ocxlpmem->read_latency = (val >> 32) & 0xFFFF; > + ocxlpmem->readiness_timeout = (val >> 48) & 0x0F; > + ocxlpmem->memory_available_timeout = val >> 52; Maybe some macros to parse out these register fields? > + > + rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu, GLOBAL_MMIO_CCAP1, > + OCXL_LITTLE_ENDIAN, &val); > + if (rc) > + return rc; > + > + ocxlpmem->max_controller_dump_size = val & 0xFFFFFFFF; > + > + // Extract firmware version text > + rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu, GLOBAL_MMIO_FWVER, > + OCXL_HOST_ENDIAN, > + (u64 *)ocxlpmem->fw_version); > + if (rc) > + return rc; > + > + ocxlpmem->fw_version[8] = '\0'; > + > + dev_info(&ocxlpmem->dev, > + "Firmware version '%s' SCM revision %d:%d\n", > + ocxlpmem->fw_version, ocxlpmem->scm_revision >> 4, > + ocxlpmem->scm_revision & 0x0F); Does the driver need to be chatty here. If this data is relevant should it appear in sysfs by default? > + > + return 0; > +} > + > /** > * probe_function0() - Set up function 0 for an OpenCAPI persistent memory device > * This is important as it enables templates higher than 0 across all other > @@ -359,6 +404,9 @@ static int probe(struct pci_dev *pdev, const struct pci_device_id *ent) > { > struct ocxlpmem *ocxlpmem; > int rc; > + u64 chi; > + u16 elapsed, timeout; > + bool ready = false; > > if (PCI_FUNC(pdev->devfn) == 0) > return probe_function0(pdev); > @@ -413,6 +461,43 @@ static int probe(struct pci_dev *pdev, const struct pci_device_id *ent) > goto err; > } > > + rc = read_device_metadata(ocxlpmem); > + if (rc) { > + dev_err(&pdev->dev, "Could not read metadata\n"); > + goto err; > + } > + > + elapsed = 0; > + timeout = ocxlpmem->readiness_timeout + > + ocxlpmem->memory_available_timeout; > + > + while (true) { > + rc = ocxlpmem_chi(ocxlpmem, &chi); > + ready = (chi & (GLOBAL_MMIO_CHI_CRDY | GLOBAL_MMIO_CHI_MA)) == > + (GLOBAL_MMIO_CHI_CRDY | GLOBAL_MMIO_CHI_MA); > + > + if (ready) > + break; > + > + if (elapsed++ > timeout) { > + dev_err(&ocxlpmem->dev, > + "OpenCAPI Persistent Memory ready timeout.\n"); > + > + if (!(chi & GLOBAL_MMIO_CHI_CRDY)) > + dev_err(&ocxlpmem->dev, > + "controller is not ready.\n"); > + > + if (!(chi & GLOBAL_MMIO_CHI_MA)) > + dev_err(&ocxlpmem->dev, > + "controller does not have memory available.\n"); > + > + rc = -ENXIO; > + goto err; > + } > + > + msleep(1000); At platform boot this is going to serialize / delay other pci hardware init. Do you need this determination to be synchronous with the call to ->probe()? If not, let's move it out of line. For example nvdimm device registration is asynchronous by default with options to flush if userspace needs to know that the kernel has finished loading drivers. > + } > + > rc = register_lpc_mem(ocxlpmem); > if (rc) { > dev_err(&pdev->dev, > diff --git a/drivers/nvdimm/ocxl/ocxlpmem.h b/drivers/nvdimm/ocxl/ocxlpmem.h > index 322387873b4b..3eadbe19f6d0 100644 > --- a/drivers/nvdimm/ocxl/ocxlpmem.h > +++ b/drivers/nvdimm/ocxl/ocxlpmem.h > @@ -93,4 +93,33 @@ struct ocxlpmem { > void *metadata_addr; > struct resource pmem_res; > struct nd_region *nd_region; > + char fw_version[8 + 1]; > + > + u32 max_controller_dump_size; > + u16 scm_revision; // major/minor > + u8 readiness_timeout; /* The worst case time (in seconds) that the host > + * shall wait for the controller to become > + * operational following a reset (CHI.CRDY). > + */ > + u8 memory_available_timeout; /* The worst case time (in seconds) that > + * the host shall wait for memory to > + * become available following a reset > + * (CHI.MA). > + */ > + > + u16 read_latency; /* The nominal measure of latency (in nanoseconds) > + * associated with an unassisted read of a memory > + * block. > + * This represents the capability of the raw media > + * technology without assistance > + */ > }; > + > +/** > + * ocxlpmem_chi() - Get the value of the CHI register > + * @ocxlpmem: the device metadata > + * @chi: returns the CHI value > + * > + * Returns 0 on success, negative on error > + */ > +int ocxlpmem_chi(const struct ocxlpmem *ocxlpmem, u64 *chi); > diff --git a/drivers/nvdimm/ocxl/ocxlpmem_internal.c b/drivers/nvdimm/ocxl/ocxlpmem_internal.c > new file mode 100644 > index 000000000000..5578169b7515 > --- /dev/null > +++ b/drivers/nvdimm/ocxl/ocxlpmem_internal.c > @@ -0,0 +1,19 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +// Copyright 2020 IBM Corp. > + > +#include > +#include > +#include "ocxlpmem.h" > + > +int ocxlpmem_chi(const struct ocxlpmem *ocxlpmem, u64 *chi) > +{ > + u64 val; > + int rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu, GLOBAL_MMIO_CHI, > + OCXL_LITTLE_ENDIAN, &val); > + if (rc) > + return rc; > + > + *chi = val; > + > + return 0; > +} > -- > 2.24.1 >