[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1ckyqeoWQAs6R9B@rric.localdomain>
Date: Tue, 25 Oct 2022 01:50:34 +0200
From: Robert Richter <rrichter@....com>
To: Dave Jiang <dave.jiang@...el.com>
CC: Dan Williams <dan.j.williams@...el.com>,
Alison Schofield <alison.schofield@...el.com>,
Vishal Verma <vishal.l.verma@...el.com>,
"Ira Weiny" <ira.weiny@...el.com>,
Ben Widawsky <bwidawsk@...nel.org>,
<linux-cxl@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Len Brown <lenb@...nel.org>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
"Davidlohr Bueso" <dave@...olabs.net>,
Terry Bowman <terry.bowman@....com>
Subject: Re: [PATCH v2 06/12] cxl/acpi: Extract component registers of
restricted hosts from RCRB
On 24.10.22 16:23:39, Dave Jiang wrote:
> On 10/24/2022 3:37 PM, Dan Williams wrote:
> Dan Williams wrote:
> Robert Richter wrote:
> Ok, I see where to go here. Could you point me to Dave's postings you
> are referring to? I checked linux-cxl and could not find anything
> related to RCRB or that changes regs.c.
>
> He was in the middle of tidying them when you posted your series, but I
> think it would not hurt to push them to a git tree so you can grab the
> bits and pieces you want.
>
> Dave?
>
> Looks like the list delivery is backed up, so I added Dave to the Cc:.
>
> He pushed:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/djiang/linux.git/log/?h=cxl-rch
>
> ...which was his original attempt and:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/djiang/linux.git/log/?h=cxl-rch-robert
>
> ...which was an attempt to rebase on top of your bits.
>
> The common RCRB mapping function is here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/djiang/linux.git/commit/?h=cxl-rch-robert&id=5be44cad37972517dae6a79001080ccfbdb67c49
Thanks for the pointers.
>
> I think the path forward is to build on that common RCRB code, fix
> cxl_acpi to register the pci host bridge device instead of the APCI
> device as the dport device, and then rely on a flag to skip over
> devm_enumerate_cxl_ports() in favor of just calling cxl_mem_find_port()
> directly in the RCIEP / RCH case.
Yes, we can completely skip devm_enumerate_cxl_ports() now. Though, I
am not convinced on using the pci host bridge as dport_dev as RCD and
non-RCD mode will diverge too much then. Looking into details here.
> Then we can figure out what to do
> about RCDs that choose not to implement the HDM decoder capability which
> was forbidden in CXL 2.0, but now allowed in CXL 3.0.
>
> Hi Robert. As follow on to your work, I'm also working on reworking the hdm
> decoder enumeration. I have this table from Dan where rr - range register exist
> but not setup, RR - range register exist and setup, hdm - HDM decoder exist but
> not programmed, HDM - HDM decoders exist and programmed. And I'm trying to
> refactor the current code to cover all those scenarios:
>
> rr RR rr hdm rr HDM RR hdm RR HDM
> D2 unsupported emulate RR enable HDM keep HDM enable HDM keep HDM
> D1 unsupported emulate RR enable HDM keep HDM enable HDM keep HDM
>
> The current test device I have that's attached to RCH host, I'm seeing the RR
> has setup a single range, but none of the HDM decoders are programmed.
>
Right, HDM decoder init need to be changed next.
Thanks,
-Robert
Powered by blists - more mailing lists