From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Terry Bowman <terry.bowman@amd.com>
Cc: <alison.schofield@intel.com>, <vishal.l.verma@intel.com>,
<ira.weiny@intel.com>, <bwidawsk@kernel.org>,
<dan.j.williams@intel.com>, <dave.jiang@intel.com>,
<linux-cxl@vger.kernel.org>, <rrichter@amd.com>,
<linux-kernel@vger.kernel.org>, <bhelgaas@google.com>
Subject: Re: [PATCH v7 14/27] cxl/port: Store the port's Component Register mappings in struct cxl_port
Date: Fri, 23 Jun 2023 14:32:27 +0100 [thread overview]
Message-ID: <20230623143227.00001bf6@Huawei.com> (raw)
In-Reply-To: <20230622205523.85375-15-terry.bowman@amd.com>
On Thu, 22 Jun 2023 15:55:10 -0500
Terry Bowman <terry.bowman@amd.com> wrote:
> From: Robert Richter <rrichter@amd.com>
>
> CXL capabilities are stored in the Component Registers. To use them,
> the specific I/O ranges of the capabilities must be determined by
> probing the registers. For this, the whole Component Register range
> needs to be mapped temporarily to detect the offset and length of a
> capability range.
>
> In order to use more than one capability of a component (e.g. RAS and
> HDM) the Component Register are probed and its mappings created
> multiple times. This also causes overlapping I/O ranges as the whole
> Component Register range must be mapped again while a capability's I/O
> range is already mapped.
>
> Different capabilities cannot be setup at the same time. E.g. the RAS
> capability must be made available as soon as the PCI driver is bound,
> the HDM decoder is setup later during port enumeration. Moreover,
> during early setup it is still unknown if a certain capability is
> needed. A central capability setup is therefore not possible,
> capabilities must be individually enabled once needed during
> initialization.
>
> To avoid a duplicate register probe and overlapping I/O mappings, only
> probe the Component Registers one time and store the Component
> Register mapping in struct port. The stored mappings can be used later
> to iomap the capability register range when enabling the capability,
> which will be implemented in a follow-on patch.
>
> Signed-off-by: Robert Richter <rrichter@amd.com>
> Signed-off-by: Terry Bowman <terry.bowman@amd.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
next prev parent reply other threads:[~2023-06-23 13:32 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-22 20:54 [PATCH v7 00/27] cxl/pci: Add support for RCH RAS error handling Terry Bowman
2023-06-22 20:54 ` [PATCH v7 01/27] cxl/acpi: Probe RCRB later during RCH downstream port creation Terry Bowman
2023-06-25 19:34 ` Dan Williams
2023-06-22 20:54 ` [PATCH v7 02/27] cxl: Updates for CXL Test to work with RCH Terry Bowman
2023-06-22 20:54 ` [PATCH v7 03/27] cxl/rch: Prepare for caching the MMIO mapped PCIe AER capability Terry Bowman
2023-06-22 20:55 ` [PATCH v7 04/27] cxl: Rename member @dport of struct cxl_dport to @dport_dev Terry Bowman
2023-06-22 20:55 ` [PATCH v7 05/27] cxl: Rename 'uport' to 'uport_dev' Terry Bowman
2023-06-22 20:55 ` [PATCH v7 06/27] cxl/core/regs: Add @dev to cxl_register_map Terry Bowman
2023-06-22 20:55 ` [PATCH v7 07/27] cxl/pci: Refactor component register discovery for reuse Terry Bowman
2023-06-22 20:55 ` [PATCH v7 08/27] cxl/acpi: Move add_host_bridge_uport() after cxl_get_chbs() Terry Bowman
2023-06-22 20:55 ` [PATCH v7 09/27] cxl/acpi: Directly bind the CEDT detected CHBCR to the Host Bridge's port Terry Bowman
2023-06-22 20:55 ` [PATCH v7 10/27] cxl/port: Remove Component Register base address from struct cxl_dport Terry Bowman
2023-06-22 20:55 ` [PATCH v7 11/27] cxl/regs: Remove early capability checks in Component Register setup Terry Bowman
2023-06-22 20:55 ` [PATCH v7 12/27] cxl/mem: Prepare for early RCH dport component register setup Terry Bowman
2023-06-22 20:55 ` [PATCH v7 13/27] cxl/pci: Early setup RCH dport component registers from RCRB Terry Bowman
2023-06-22 20:55 ` [PATCH v7 14/27] cxl/port: Store the port's Component Register mappings in struct cxl_port Terry Bowman
2023-06-23 13:32 ` Jonathan Cameron [this message]
2023-06-22 20:55 ` [PATCH v7 15/27] cxl/port: Store the downstream port's Component Register mappings in struct cxl_dport Terry Bowman
2023-06-22 20:55 ` [PATCH v7 16/27] cxl/pci: Store the endpoint's Component Register mappings in struct cxl_dev_state Terry Bowman
2023-06-25 17:38 ` Dan Williams
2023-06-26 14:16 ` Terry Bowman
2023-06-30 19:51 ` Robert Richter
2023-06-30 19:56 ` Robert Richter
2023-07-03 3:55 ` Jonathan Cameron
2023-06-22 20:55 ` [PATCH v7 17/27] cxl/hdm: Use stored Component Register mappings to map HDM decoder capability Terry Bowman
2023-06-22 20:55 ` [PATCH v7 18/27] cxl/port: Remove Component Register base address from struct cxl_port Terry Bowman
2023-06-22 20:55 ` [PATCH v7 19/27] cxl/pci: Add RCH downstream port AER register discovery Terry Bowman
2023-06-22 20:55 ` [PATCH v7 20/27] PCI/AER: Refactor cper_print_aer() for use by CXL driver module Terry Bowman
2023-06-23 21:22 ` Dave Jiang
2023-06-22 20:55 ` [PATCH v7 21/27] cxl/pci: Update CXL error logging to use RAS register address Terry Bowman
2023-06-23 21:43 ` Dave Jiang
2023-06-22 20:55 ` [PATCH v7 22/27] cxl/pci: Map RCH downstream AER registers for logging protocol errors Terry Bowman
2023-06-23 21:58 ` Dave Jiang
2023-06-22 20:55 ` [PATCH v7 23/27] cxl/pci: Add RCH downstream port error logging Terry Bowman
2023-06-23 22:07 ` Dave Jiang
2023-06-22 20:55 ` [PATCH v7 24/27] cxl/pci: Disable root port interrupts in RCH mode Terry Bowman
2023-06-23 22:08 ` Dave Jiang
2023-06-22 20:55 ` [PATCH v7 25/27] PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler Terry Bowman
2023-06-23 22:16 ` Dave Jiang
2023-06-25 5:47 ` Dan Williams
2023-06-22 20:55 ` [PATCH v7 26/27] PCI/AER: Unmask RCEC internal errors to enable RCH downstream port error handling Terry Bowman
2023-06-23 22:18 ` Dave Jiang
2023-06-22 20:55 ` [PATCH v7 27/27] cxl/core/regs: Rename phys_addr in cxl_map_component_regs() Terry Bowman
2023-06-23 13:30 ` Jonathan Cameron
2023-06-23 22:19 ` Dave Jiang
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=20230623143227.00001bf6@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=bhelgaas@google.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=linux-kernel@vger.kernel.org \
--cc=rrichter@amd.com \
--cc=terry.bowman@amd.com \
--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.