git/linux-cryptodev-2.6
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git synced 2026-04-18 11:33:36 -04:00
Code Issues Packages Projects Releases Wiki Activity

cxl: docs - add self-referencing cross-links

Browse Source 
Add some crosslinks between pages in the CXL docs - mostly to the
ACPI tables.

Suggested-by: Bagas Sanjaya <bagasdotme@gmail.com>
Signed-off-by: Gregory Price <gourry@gourry.net>
Link: https://patch.msgid.link/20250512162134.3596150-18-gourry@gourry.net
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
This commit is contained in:
Gregory Price
2025-05-12 12:21:34 -04:00
committed by Dave Jiang
parent df63e0120b
commit dba600d0f2
9 changed files with 69 additions and 59 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
Documentation/driver-api/cxl/linux/access-coordinates.rst
View File

@@ -24,7 +24,7 @@ asymmetry in properties does not happen and all paths to EPs are equal.
There can be multiple switches under an RP. There can be multiple RPs under
a CXL Host Bridge (HB). There can be multiple HBs under a CXL Fixed Memory
Window Structure (CFMWS).
Window Structure (CFMWS) in the :doc:`CEDT <../platform/acpi/cedt>`.
An example hierarchy::
@@ -83,8 +83,9 @@ also the index for the resulting xarray.
The next step is to take the min() of the per host bridge bandwidth and the
bandwidth from the Generic Port (GP). The bandwidths for the GP are retrieved
via ACPI tables SRAT/HMAT. The minimum bandwidth are aggregated under the same
ACPI0017 device to form a new xarray.
via ACPI tables (:doc:`SRAT <../platform/acpi/srat>` and
:doc:`HMAT <../platform/acpi/hmat>`). The minimum bandwidth are aggregated
under the same ACPI0017 device to form a new xarray.
Finally, the cxl_region_update_bandwidth() is called and the aggregated
bandwidth from all the members of the last xarray is updated for the

35
Documentation/driver-api/cxl/linux/cxl-driver.rst
View File

@@ -77,11 +77,11 @@ Root Object` Device Class is found.
The Root contains links to:
* `Host Bridge Ports` defined by ACPI CEDT CHBS.
* `Host Bridge Ports` defined by CHBS in the :doc:`CEDT<../platform/acpi/cedt>`
* `Downstream Ports` typically connected to `Host Bridge Ports`.
* `Root Decoders` defined by ACPI CEDT CFMWS.
* `Root Decoders` defined by CFMWS the :doc:`CEDT<../platform/acpi/cedt>`
::
@@ -150,9 +150,8 @@ An `endpoint` is a terminal port in the fabric. This is a `logical device`,
and may be one of many `logical devices` presented by a memory device. It
is still considered a type of `port` in the fabric.
An `endpoint` contains `endpoint decoders` available for use and the
*Coherent Device Attribute Table* (CDAT) used to describe the capabilities
of the device. ::
An `endpoint` contains `endpoint decoders` and the device's Coherent Device
Attribute Table (which describes the device's capabilities). ::
# ls /sys/bus/cxl/devices/endpoint5
CDAT decoders_committed modalias uevent
@@ -247,17 +246,18 @@ parameter.
Root Decoder
~~~~~~~~~~~~
A `Root Decoder` is logical construct of the physical address and interleave
configurations present in the ACPI CEDT CFMWS. Linux presents this information
as a decoder present in the `CXL Root`. We consider this a `Root Decoder`,
though technically it exists on the boundary of the CXL specification and
platform-specific CXL root implementations.
configurations present in the CFMWS field of the :doc:`CEDT
<../platform/acpi/cedt>`.
Linux presents this information as a decoder present in the `CXL Root`. We
consider this a `Root Decoder`, though technically it exists on the boundary
of the CXL specification and platform-specific CXL root implementations.
Linux considers these logical decoders a type of `Routing Decoder`, and is the
first decoder in the CXL fabric to receive a memory access from the platform's
memory controllers.
`Root Decoders` are created during :code:`cxl_acpi_probe`. One root decoder
is created per CFMWS entry in the ACPI CEDT.
is created per CFMWS entry in the :doc:`CEDT <../platform/acpi/cedt>`.
The :code:`target_list` parameter is filled by the CFMWS target fields. Targets
of a root decoder are `Host Bridges`, which means interleave done at the root
@@ -267,9 +267,11 @@ Only root decoders are capable of `Inter-Host-Bridge Interleave`.
Such interleaves must be configured by the platform and described in the ACPI
CEDT CFMWS, as the target CXL host bridge UIDs in the CFMWS must match the CXL
host bridge UIDs in the ACPI CEDT CHBS and ACPI DSDT.
host bridge UIDs in the CHBS field of the :doc:`CEDT
<../platform/acpi/cedt>` and the UID field of CXL Host Bridges defined in
the :doc:`DSDT <../platform/acpi/dsdt>`.
Interleave settings in a rootdecoder describe how to interleave accesses among
Interleave settings in a root decoder describe how to interleave accesses among
the *immediate downstream targets*, not the entire interleave set.
The memory range described in the root decoder is used to
@@ -531,10 +533,11 @@ granularity configuration.
At Root
~~~~~~~
Root decoder interleave is defined by the ACPI CEDT CFMWS. The CEDT
may actually define multiple CFMWS configurations to describe the same
physical capacity - with the intent to allow users to decide at runtime
whether to online memory as interleaved or non-interleaved. ::
Root decoder interleave is defined by CFMWS field of the :doc:`CEDT
<../platform/acpi/cedt>`. The CEDT may actually define multiple CFMWS
configurations to describe the same physical capacity, with the intent to allow
users to decide at runtime whether to online memory as interleaved or
non-interleaved. ::
Subtable Type : 01 [CXL Fixed Memory Window Structure]
Window base address : 0000000100000000

32
Documentation/driver-api/cxl/linux/early-boot.rst
View File

@@ -12,8 +12,9 @@ read EFI and ACPI information throughout this process to configure logical
representations of the devices.
During Linux Early Boot stage (functions in the kernel that have the __init
decorator), the system takes the resources created by EFI/BIOS (ACPI tables)
and turns them into resources that the kernel can consume.
decorator), the system takes the resources created by EFI/BIOS
(:doc:`ACPI tables <../platform/acpi>`) and turns them into resources that the
kernel can consume.
BIOS, Build and Boot Options
@@ -70,13 +71,14 @@ significant impact performance depending on the memory capacity of the system.
NUMA Node Reservation
=====================
Linux refers to the proximity domains (:code:`PXM`) defined in the SRAT to
create NUMA nodes in :code:`acpi_numa_init`. Typically, there is a 1:1 relation
between :code:`PXM` and NUMA node IDs.
Linux refers to the proximity domains (:code:`PXM`) defined in the :doc:`SRAT
<../platform/acpi/srat>` to create NUMA nodes in :code:`acpi_numa_init`.
Typically, there is a 1:1 relation between :code:`PXM` and NUMA node IDs.
SRAT is the only ACPI defined way of defining Proximity Domains. Linux chooses
to, at most, map those 1:1 with NUMA nodes. CEDT adds a description of SPA
ranges which Linux may wish to map to one or more NUMA nodes.
The SRAT is the only ACPI defined way of defining Proximity Domains. Linux
chooses to, at most, map those 1:1 with NUMA nodes.
:doc:`CEDT <../platform/acpi/cedt>` adds a description of SPA ranges which
Linux may map to one or more NUMA nodes.
If there are CXL ranges in the CFMWS but not in SRAT, then a fake :code:`PXM`
is created (as of v6.15). In the future, Linux may reject CFMWS not described
@@ -89,7 +91,8 @@ data for Linux to identify NUMA nodes their associated memory regions.
The relevant code exists in: :code:`linux/drivers/acpi/numa/srat.c`.
See the Example Platform Configurations section for more information.
See :doc:`Example Platform Configurations <../platform/example-configs>`
for more info.
Memory Tiers Creation
=====================
@@ -108,10 +111,13 @@ Tier membership can be inspected in ::
/sys/devices/virtual/memory_tiering/memory_tierN/nodelist
0-1
If nodes are grouped which have clear difference in performance, check the HMAT
and CDAT information for the CXL nodes. All nodes default to the DRAM tier,
unless HMAT/CDAT information is reported to the memory_tier component via
`access_coordinates`.
If nodes are grouped which have clear difference in performance, check the
:doc:`HMAT <../platform/acpi/hmat>` and CDAT information for the CXL nodes. All
nodes default to the DRAM tier, unless HMAT/CDAT information is reported to the
memory_tier component via `access_coordinates`.
For more, see :doc:`CXL access coordinates documentation
<../linux/access-coordinates>`.
Contiguous Memory Allocation
============================