linux-cxl.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Jiang <dave.jiang@intel.com>, <linux-cxl@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Alejandro Lucero <alucerop@amd.com>
Subject: Re: [PATCH 2/3] cxl: Set target type of region with that of root decoder
Date: Sun, 4 Aug 2024 17:31:55 +0100	[thread overview]
Message-ID: <20240804173141.00007931@Huawei.com> (raw)
In-Reply-To: <87o76ckb88.fsf@yhuang6-desk2.ccr.corp.intel.com>

On Thu, 01 Aug 2024 14:28:55 +0800
"Huang, Ying" <ying.huang@intel.com> wrote:

> Alison Schofield <alison.schofield@intel.com> writes:
> 
> > On Mon, Jul 29, 2024 at 04:46:10PM +0800, Ying Huang wrote:  
> >> Now, the target type of region is hard-coded to HOSTONLYMEM, because
> >> only type3 expanders are supported.  To support type2 accelerators,
> >> set the target type of region root decoder with that of the root
> >> decoder.  
> >
> > Hi Ying,
> >
> > If the target type of a region is always the same as it's root decoder,
> > (is it?)  
> 
> IIUC, it is.  Do you know when they may be different?

Root decoder (CFMW I think) allows both and target device only one.

More likely when it's HDM-DB / HDM-H though I think than
HDM-D / HDM-H.  A host would do this because it has simple
address routing (maybe a single root complex) and doesn't
want to pay the HPA space cost of providing separate regions,
so decisions on protocol etc derived from RC HDM decoder
programming, not the fixed bit in in the host.

Note for those not so buried in CXL terms, HDM-DB includes back
invalidate memory devices (for P2P or hardware coherent sharing),
HDM-H is simpler memory devices that don't support back invalidate.

Jonathan


> 
> > why do we store it as an attribute of the region. Can we look
> > it up when needed?  
> 
> Yes.  This is possible via to_cxl_root_decoder().  It's just
> a little inconvenient.
> 
> > A bit more below -
> >  
> >> 
> >> Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
> >> Suggested-by: 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/region.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> >> index 21ad5f242875..9a483c8a32fd 100644
> >> --- a/drivers/cxl/core/region.c
> >> +++ b/drivers/cxl/core/region.c
> >> @@ -2545,7 +2545,8 @@ static struct cxl_region *__create_region(struct cxl_root_decoder *cxlrd,
> >>  		return ERR_PTR(-EBUSY);
> >>  	}
> >>  
> >> -	return devm_cxl_add_region(cxlrd, id, mode, CXL_DECODER_HOSTONLYMEM);
> >> +	return devm_cxl_add_region(cxlrd, id, mode,
> >> +				   cxlrd->cxlsd.cxld.target_type);
> >>  }  
> >
> > Passing the 'cxlrd' and then a piece of the cxlrd (.target_type) looks
> > redundant.  
> 
> Yes.  We can remove the parameter.  Will change this if we still need
> cxlr->type.  Thanks!
> 
> --
> Best Regards,
> Huang, Ying
> 
> >
> > -- Alison
> >  
> >>  
> >>  static ssize_t create_pmem_region_store(struct device *dev,
> >> -- 
> >> 2.39.2
> >>   
> 
> 


  reply	other threads:[~2024-08-04 16:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-29  8:46 [PATCH 0/3] cxl: Preparation of type2 accelerators support Huang Ying
2024-07-29  8:46 ` [PATCH 1/3] cxl: Set target type of root decoder based on CFMWS restrictions Huang Ying
2024-08-01  1:22   ` Alison Schofield
2024-08-04 16:24   ` Jonathan Cameron
2024-08-06  1:28     ` Huang, Ying
2024-08-12 20:59   ` Fan Ni
2024-07-29  8:46 ` [PATCH 2/3] cxl: Set target type of region with that of root decoder Huang Ying
2024-08-01  1:35   ` Alison Schofield
2024-08-01  6:28     ` Huang, Ying
2024-08-04 16:31       ` Jonathan Cameron [this message]
2024-08-12 21:00   ` Fan Ni
2024-07-29  8:46 ` [PATCH 3/3] cxl: Avoid to create dax regions for type2 accelerators Huang Ying
2024-08-04 16:38   ` Jonathan Cameron
2024-08-06  5:52     ` Huang, Ying
2024-08-12 11:50       ` Alejandro Lucero Palau
2024-08-12 11:54       ` Alejandro Lucero Palau
2024-08-15  1:10         ` Huang, Ying
2024-07-30  6:10 ` [PATCH 0/3] cxl: Preparation of type2 accelerators support Alejandro Lucero Palau
2024-07-30  6:34   ` Huang, Ying

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=20240804173141.00007931@Huawei.com \
    --to=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;
as well as URLs for NNTP newsgroup(s).