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);
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.