Linux CXL
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: <alison.schofield@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Ben Widawsky <bwidawsk@kernel.org>,
	Dave Jiang <dave.jiang@intel.com>, <linux-cxl@vger.kernel.org>
Subject: Re: [PATCH v8 2/3] cxl/acpi: Support CXL XOR Interleave Math (CXIMS)
Date: Wed, 30 Nov 2022 18:14:36 +0000	[thread overview]
Message-ID: <20221130181436.0000782f@Huawei.com> (raw)
In-Reply-To: <168ca3d06756bade7d2d11f2fc9122c19206ff9a.1669153633.git.alison.schofield@intel.com>

On Tue, 22 Nov 2022 14:52:24 -0800
alison.schofield@intel.com wrote:

> From: Alison Schofield <alison.schofield@intel.com>
> 
> When the CFMWS is using XOR math, parse the corresponding
> CXIMS structure and store the xormaps in the root decoder
> structure. Use the xormaps in a new lookup, cxl_hb_xor(),
> to find a targets entry in the host bridge interleave
> target list.
> 
> Defined in CXL Specfication 3.0 Section: 9.17.1
> 
> Signed-off-by: Alison Schofield <alison.schofield@intel.com>

I've been avoiding reading this because the xormap stuff gives me a headache..
Anyhow, finally looked at it properly and maths looks right to me.
A few queries and minor suggestions inline but nothing important.

With or without dragging the refactoring into here from your new patch series
(to avoid introducing code only to factor a chunk out a few patches later).

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

> ---
>  drivers/cxl/acpi.c      | 126 +++++++++++++++++++++++++++++++++++++++-
>  drivers/cxl/core/port.c |   9 ++-
>  drivers/cxl/cxl.h       |  13 ++++-
>  3 files changed, 140 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
> index fb649683dd3a..98c84942ed37 100644
> --- a/drivers/cxl/acpi.c
> +++ b/drivers/cxl/acpi.c
> @@ -6,9 +6,107 @@
>  #include <linux/kernel.h>
>  #include <linux/acpi.h>
>  #include <linux/pci.h>
> +#include <asm/div64.h>
>  #include "cxlpci.h"
>  #include "cxl.h"
>  
> +struct cxl_cxims_data {
> +	int nr_maps;
> +	u64 xormaps[];
> +};
> +
> +/*
> + * Find a targets entry (n) in the host bridge interleave list.
> + * CXL Specfication 3.0 Table 9-22
> + */
> +static struct cxl_dport *cxl_hb_xor(struct cxl_root_decoder *cxlrd, int pos)
> +{
> +	struct cxl_cxims_data *cximsd = cxlrd->platform_data;
> +	struct cxl_switch_decoder *cxlsd = &cxlrd->cxlsd;
> +	struct cxl_decoder *cxld = &cxlsd->cxld;
> +	int ig = cxld->interleave_granularity;
> +	int iw = cxld->interleave_ways;
> +	int eiw, i = 0, n = 0;
> +	u64 hpa;
> +
> +	if (dev_WARN_ONCE(&cxld->dev,
> +			  cxld->interleave_ways != cxlsd->nr_targets,
> +			  "misconfigured root decoder\n"))
> +		return NULL;
> +
> +	if (iw == 1)
> +		/* Entry is always 0 for no interleave */
> +		return cxlrd->cxlsd.target[0];
> +
> +	hpa = cxlrd->res->start + pos * ig;
> +
> +	if (iw == 3)
> +		goto no_map;
> +
> +	/* IW: 2,4,6,8,12,16 begin building 'n' using xormaps */
> +	for (i = 0; i < cximsd->nr_maps; i++)
> +		n |= (hweight64(hpa & cximsd->xormaps[i]) & 1) << i;

> +
> +no_map:
> +	/* IW: 3,6,12 add a modulo calculation to 'n' */
> +	if (!is_power_of_2(iw)) {
> +		eiw = ilog2(iw / 3) + 8;

Obviously duplicates some checks, but ways_to_cxl() still better here I think
because it documents that it's just the normal switch to eiw.

> +		hpa &= GENMASK_ULL(51, eiw + ig);
> +		n |= do_div(hpa, 3) << i;

Seeing as we haven't merged this set yet, maybe just factor this out from the
start rather than in your follow on set?

> +	}
> +	return cxlrd->cxlsd.target[n];
> +}
> +
> +struct cxl_cxims_context {
> +	struct device *dev;
> +	struct cxl_root_decoder *cxlrd;
> +};
> +
> +static int cxl_parse_cxims(union acpi_subtable_headers *header, void *arg,
> +			   const unsigned long end)
> +{
> +	struct acpi_cedt_cxims *cxims = (struct acpi_cedt_cxims *)header;
> +	struct cxl_cxims_context *ctx = arg;
> +	struct cxl_root_decoder *cxlrd = ctx->cxlrd;
> +	struct cxl_decoder *cxld = &cxlrd->cxlsd.cxld;
> +	struct device *dev = ctx->dev;
> +	struct cxl_cxims_data *cximsd;
> +	unsigned int hbig, nr_maps;
> +	int rc;
> +
> +	rc = cxl_to_granularity(cxims->hbig, &hbig);
> +	if (rc)
> +		return rc;
> +
> +	if (hbig == cxld->interleave_granularity) {
> +		/* IW 1,3 do not use xormaps and skip this parsing entirely */
> +
> +		if (is_power_of_2(cxld->interleave_ways))
> +			/* 2, 4, 8, 16 way */
> +			nr_maps = ilog2(cxld->interleave_ways);
> +		else
> +			/* 6, 12 way */
> +			nr_maps = ilog2(cxld->interleave_ways / 3);
> +
> +		if (cxims->nr_xormaps < nr_maps) {

Why is cxims->nr_xormaps > nr_maps not an error?
Whilst we are just going to drop the extra entries it certainly seems
like an oddity we should perhaps report?

> +			dev_dbg(dev, "CXIMS nr_xormaps[%d] expected[%d]\n",
> +				cxims->nr_xormaps, nr_maps);
> +			return -ENXIO;
> +		}
> +
> +		cximsd = devm_kzalloc(dev,
> +				      struct_size(cximsd, xormaps, nr_maps),
> +				      GFP_KERNEL);
> +		if (!cximsd)
> +			return -ENOMEM;

Trivial, I'd like a blank line here after the error handler.

> +		memcpy(cximsd->xormaps, cxims->xormap_list,
> +		       nr_maps * sizeof(*cximsd->xormaps));
> +		cximsd->nr_maps = nr_maps;
> +		cxlrd->platform_data = cximsd;
> +	}

For local consistency and because it is nicer in general to have
returns separated by a blank line, put one here as well.

> +	return 0;
> +}
> +


> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index ac75554b5d76..d03aa1776fc8 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -324,18 +324,24 @@ struct cxl_switch_decoder {
>  	struct cxl_dport *target[];
>  };
>  
> +struct cxl_root_decoder;
> +struct cxl_endpoint_decoder;

Looks like the cxl_endpoint_decoder is currently defined above this anyway so don't
think this forwards ref is needed.

> +typedef struct cxl_dport *(*cxl_calc_hb_fn)(struct cxl_root_decoder *cxlrd,
> +					    int pos);
>  
>  /**
>   * struct cxl_root_decoder - Static platform CXL address decoder
>   * @res: host / parent resource for region allocations
>   * @region_id: region id for next region provisioning event
>   * @calc_hb: which host bridge covers the n'th position by granularity
> + * @platform_data: platform specific configuration data
>   * @cxlsd: base cxl switch decoder
>   */
>  struct cxl_root_decoder {
>  	struct resource *res;
>  	atomic_t region_id;
> -	struct cxl_dport *(*calc_hb)(struct cxl_root_decoder *cxlrd, int pos);
> +	cxl_calc_hb_fn calc_hb;
> +	void *platform_data;
>  	struct cxl_switch_decoder cxlsd;
>  };
>  
> @@ -580,8 +586,11 @@ struct cxl_root_decoder *to_cxl_root_decoder(struct device *dev);
>  struct cxl_endpoint_decoder *to_cxl_endpoint_decoder(struct device *dev);
>  bool is_root_decoder(struct device *dev);
>  bool is_endpoint_decoder(struct device *dev);
> +

trivial, but unrelated whitespace change shouldn't really be in here.

>  struct cxl_root_decoder *cxl_root_decoder_alloc(struct cxl_port *port,
> -						unsigned int nr_targets);
> +						unsigned int nr_targets,
> +						cxl_calc_hb_fn calc_hb);
> +struct cxl_dport *cxl_hb_modulo(struct cxl_root_decoder *cxlrd, int pos);
>  struct cxl_switch_decoder *cxl_switch_decoder_alloc(struct cxl_port *port,
>  						    unsigned int nr_targets);
>  int cxl_decoder_add(struct cxl_decoder *cxld, int *target_map);


  reply	other threads:[~2022-11-30 18:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-22 22:52 [PATCH v8 0/3] CXL XOR Interleave Arithmetic alison.schofield
2022-11-22 22:52 ` [PATCH v8 1/3] ACPICA commit 2d8dc0383d3c908389053afbdc329bbd52f009ce alison.schofield
2022-11-22 22:52 ` [PATCH v8 2/3] cxl/acpi: Support CXL XOR Interleave Math (CXIMS) alison.schofield
2022-11-30 18:14   ` Jonathan Cameron [this message]
2022-11-30 18:23     ` Jonathan Cameron
2022-11-30 22:51     ` Alison Schofield
2022-11-22 22:52 ` [PATCH v8 3/3] tools/testing/cxl: Add XOR Math support to cxl_test alison.schofield
2022-11-30 18:24   ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221130181436.0000782f@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=bwidawsk@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=vishal.l.verma@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox