From: Ben Cheatham <benjamin.cheatham@amd.com>
To: Huang Ying <ying.huang@intel.com>
Cc: <linux-cxl@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Alison Schofield <alison.schofield@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Ira Weiny <ira.weiny@intel.com>,
Alejandro Lucero <alucerop@amd.com>,
Dan Williams <dan.j.williams@intel.com>,
Dave Jiang <dave.jiang@intel.com>
Subject: Re: [RFC 3/5] cxl: Separate coherence from target type
Date: Wed, 2 Oct 2024 16:15:35 -0500 [thread overview]
Message-ID: <e0f08438-69cf-4e79-abf2-f5f3240d9517@amd.com> (raw)
In-Reply-To: <20240925024647.46735-4-ying.huang@intel.com>
Hi Huang, quick comments in this patch and the next.
On 9/24/24 9:46 PM, Huang Ying wrote:
> Previously, target type (expander or accelerator) and
> coherence (HOSTONLY (HDM-H) or DEV (HDM-D/DB)) are synonym. So target
> type is used to designate coherence too. However, it's possible for
> expanders to use HDM-DB now. So, we need to separate coherence from
> target type.
>
> Accordingly, the HOSTONLY field of decoder ctrl
> register (CXL_HDM_DECODER0_CTRL_HOSTONLY) need to be set according to
> coherence.
>
> The coherence of decoders can not be determined via target type too.
> So, accelerator/expander device drivers need to specify coherence
> explicitly via newly added coherence field in struct cxl_dev_state.
>
> The coherence of each end points in a region need to be same. So, the
> coherence of the first end point is recorded in struct region. Which
> will be checked against the coherence of all other end points.
>
> Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Davidlohr Bueso <dave@stgolabs.net>
> Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
> Cc: Dave Jiang <dave.jiang@intel.com>
> Cc: Alison Schofield <alison.schofield@intel.com>
> Cc: Vishal Verma <vishal.l.verma@intel.com>
> Cc: Ira Weiny <ira.weiny@intel.com>
> Cc: Alejandro Lucero <alucerop@amd.com>
> ---
> drivers/cxl/core/hdm.c | 22 +++++++++++++++-------
> drivers/cxl/core/mbox.c | 1 +
> drivers/cxl/core/port.c | 1 +
> drivers/cxl/core/region.c | 37 ++++++++++++++++++++++++++++++++++---
> drivers/cxl/cxl.h | 9 +++++++++
> drivers/cxl/cxlmem.h | 11 +++++++++++
> 6 files changed, 71 insertions(+), 10 deletions(-)
>
[snip]
>
> +/*
> + * enum cxl_devcoherence - the coherence of the cxl device
> + * @CXL_DEVCOH_DEV - HDM-D or HDM-DB
> + * @CXL_DEVCOH_HOSTONLY - HDM-H
> + */
Could I suggest mapping the coherence type to the expected device type(s) in this
comment? My thinking here is that the coherence types aren't exactly straightforward
and having the device types they correspond to would help ease any confusion, especially
since it looks like we are expecting type 2 driver writers to fill this in manually. I'm
thinking something along the lines of:
/*
* enum cxl_devcoherence - the coherence of the cxl device
* @CXL_DEVCOH_DEV - HDM-D (type 2) or HDM-DB (type 2/3)
* @CXL_DEVCOH_HOSTONLY - HDM-H (type 3)
*/
> +enum cxl_devcoherence {
> + CXL_DEVCOH_DEV,
> + CXL_DEVCOH_HOSTONLY,
> +};
> +
> /**
> * struct cxl_dpa_perf - DPA performance property entry
> * @dpa_range: range for DPA address
> @@ -438,6 +448,7 @@ struct cxl_dev_state {
> struct resource ram_res;
> u64 serial;
> enum cxl_devtype type;
> + enum cxl_devcoherence coherence;
> };
>
> /**
next prev parent reply other threads:[~2024-10-02 21:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-25 2:46 [RFC 0/5] cxl: Preparation of type2 accelerators support Huang Ying
2024-09-25 2:46 ` [RFC 1/5] cxl: Rename ACPI_CEDT_CFMWS_RESTRICT_TYPE2/TYPE3 Huang Ying
2024-10-01 2:48 ` Davidlohr Bueso
2024-10-01 13:43 ` Gregory Price
2024-09-25 2:46 ` [RFC 2/5] cxl: Rename CXL_DECODER_HOSTONLYMEM/DEVMEM Huang Ying
2024-10-01 3:01 ` Davidlohr Bueso
2024-10-01 13:45 ` Gregory Price
2024-09-25 2:46 ` [RFC 3/5] cxl: Separate coherence from target type Huang Ying
2024-10-01 13:53 ` Gregory Price
2024-10-02 0:41 ` Huang, Ying
2024-10-11 2:40 ` Huang, Ying
2024-10-02 21:15 ` Ben Cheatham [this message]
2024-10-03 1:13 ` Huang, Ying
2024-09-25 2:46 ` [RFC 4/5] cxl: Set type of region to that of the first endpoint Huang Ying
2024-10-01 13:56 ` Gregory Price
2024-10-02 0:40 ` Huang, Ying
2024-10-02 21:15 ` Ben Cheatham
2024-10-03 1:12 ` Huang, Ying
2024-10-03 14:28 ` Ben Cheatham
2024-09-25 2:46 ` [RFC 5/5] cxl: Avoid to create dax regions for type2 accelerators Huang Ying
2024-10-01 13:57 ` Gregory Price
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=e0f08438-69cf-4e79-abf2-f5f3240d9517@amd.com \
--to=benjamin.cheatham@amd.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=alucerop@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vishal.l.verma@intel.com \
--cc=ying.huang@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