[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v10 02/45] hw/cxl/component: Introduce CXL components (8.1.x,
From: |
Jonathan Cameron |
Subject: |
Re: [PATCH v10 02/45] hw/cxl/component: Introduce CXL components (8.1.x, 8.2.5) |
Date: |
Mon, 30 May 2022 18:50:32 +0100 |
On Fri, 29 Apr 2022 15:40:27 +0100
Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
> From: Ben Widawsky <ben.widawsky@intel.com>
>
> A CXL 2.0 component is any entity in the CXL topology. All components
> have a analogous function in PCIe. Except for the CXL host bridge, all
> have a PCIe config space that is accessible via the common PCIe
> mechanisms. CXL components are enumerated via DVSEC fields in the
> extended PCIe header space. CXL components will minimally implement some
> subset of CXL.mem and CXL.cache registers defined in 8.2.5 of the CXL
> 2.0 specification. Two headers and a utility library are introduced to
> support the minimum functionality needed to enumerate components.
>
> The cxl_pci header manages bits associated with PCI, specifically the
> DVSEC and related fields. The cxl_component.h variant has data
> structures and APIs that are useful for drivers implementing any of the
> CXL 2.0 components. The library takes care of making use of the DVSEC
> bits and the CXL.[mem|cache] registers. Per spec, the registers are
> little endian.
>
> None of the mechanisms required to enumerate a CXL capable hostbridge
> are introduced at this point.
>
> Note that the CXL.mem and CXL.cache registers used are always 4B wide.
> It's possible in the future that this constraint will not hold.
>
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
> Reviewed-by: Adam Manzanares <a.manzanares@samsung.com>
FYI on a bug, in case anyone else hits it.
> +static void hdm_init_common(uint32_t *reg_state, uint32_t *write_msk)
> +{
> + int decoder_count = 1;
> + int i;
> +
> + ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY, DECODER_COUNT,
> + cxl_decoder_count_enc(decoder_count));
> + ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY, TARGET_COUNT, 1);
> + ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY, INTERLEAVE_256B,
> 1);
> + ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY, INTERLEAVE_4K,
> 1);
> + ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY,
> POISON_ON_ERR_CAP, 0);
> + ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_GLOBAL_CONTROL,
> + HDM_DECODER_ENABLE, 0);
> + write_msk[R_CXL_HDM_DECODER_GLOBAL_CONTROL] = 0x3;
> + for (i = 0; i < decoder_count; i++) {
> + write_msk[R_CXL_HDM_DECODER0_BASE_LO + i * 0x20] = 0xf0000000;
> + write_msk[R_CXL_HDM_DECODER0_BASE_HI + i * 0x20] = 0xffffffff;
> + write_msk[R_CXL_HDM_DECODER0_SIZE_LO + i * 0x20] = 0xf0000000;
> + write_msk[R_CXL_HDM_DECODER0_SIZE_HI + i * 0x20] = 0xffffffff;
> + write_msk[R_CXL_HDM_DECODER0_CTRL + i * 0x20] = 0x13ff;
For some unknown reason I missed write masks for the target lists in here.
It was hidden from superficial testing by a bug in the kernel code I was using
that mean these were mostly written to 0.
I'll send a fix out tomorrow (just adds 0xffffffff masks for each of the
target registers).
Given issues I'm seeing in testing around HDM decoder programming I'll look
to follow that up with a patch adding some more rigorous checking of the
values on commit.
Jonathan
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH v10 02/45] hw/cxl/component: Introduce CXL components (8.1.x, 8.2.5),
Jonathan Cameron <=