diff options
author | Furquan Shaikh <furquan@google.com> | 2021-01-15 17:12:12 -0800 |
---|---|---|
committer | Patrick Georgi <pgeorgi@google.com> | 2021-01-25 08:48:38 +0000 |
commit | 859ca18ced83ed3b8b529112da5f214ede3d38b0 (patch) | |
tree | 442530c9f30c04b1792731414587852aa76a8c5e /src/soc/intel/common/block/include/intelblocks | |
parent | 99157c1f4a80556462ca22a4ade87b2c8d09e674 (diff) |
soc/intel/common: Add support for populating meminit data
This change adds support for a common block memory driver that can be
used for performing the required operations to read SPD data for
different memory channel DIMMs. This data can then be used by the SoC
code to populate different memory related UPDs.
Most recent Intel platforms follow a similar pattern for configuring
FSP-M UPDs for initializing memory. These platforms use one of the
following topologies:
1. Memory down
2. DIMM modules
3. Mixed
Thus, SPD data is either obtained from CBFS (for memory down topology)
or from on-module EEPROM (for DIMM modules). This SPD data read from
CBFS or EEPROM is then passed into FSP-M using SPD UPDs for different
channels/DIMMs as per the memory organization.
Similarly, DQ/DQS configuration is accepted from mainboard and passed
into FSP-M using UPDs as per the FSP-M/MRC organization of memory
channels.
Different memory technologies on a platform support physical channels
of different widths. Since the data bus width is fixed for a platform,
the number of physical channels is determined by data bus width /
physical channel width. The number of physical channels are different
depending upon the size of physical channel supported by the memory
technology. FSP-M for a platform uses the same set of UPDs for
different memory technologies and aims at providing maximum
flexibility. Thus, the platform code needs to format mainboard inputs
for DQ, DQS and SPD into the UPDs appropriately as per the memory
technology used by the board.
Example: DDR4 on TGL supports 2 physical channels each 64-bit
wide. However, FSP-M UPDs assume channels 16-bit wide. Thus, FSP-M
provides 16 UPDs for SPDs (considering 2 DIMMs per channel and 8
channels with each channel 16-bit wide). Hence, for DDR4, only the SPD
UPDs for MRC channel 0 and 4 are supposed to be used.
This common driver allows the SoC to define the attributes of the
platform:
1. DIMMS_PER_CHANNEL: Maximum DIMMs that are supported per channel by
any memory technology on the platform
2. DATA_BUS_WIDTH: Width of the data bus.
3. MRC_CHANNEL_WIDTH: Width of the channel as used by the MRC to
define UPDs.
In addition to this, the SoC can define different attributes of each
memory technology supported by the platform using `struct
soc_mem_cfg`:
1. Number of physical channels
2. Physical channel to MRC channel mapping
3. Masks for memory down topologies
Using the above information about different memory technologies
supported by the platform and the mainboard configuration for SPD,
the common block memory driver reads SPD data and provides pointers to
this data for each dimm within each channel back to the SoC code. SoC
code can then use this information to configure FSP-M UPDs
accordingly. In addition to that, the common block driver also returns
information about how the channels are populated so that the SoC code
can use this information to expose DQ/DQS information in FSP-M UPDs.
This driver aims at minimizing the effort required for supporting
different memory technologies on any new Intel SoC by reducing per-SoC
effort to a table of configurations rather than having to implement
similar logic for each SoC.
BUG=b:172978729
Change-Id: I256747f0ffc49fb326cd8bc54a6a7b493af139c0
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49040
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Diffstat (limited to 'src/soc/intel/common/block/include/intelblocks')
-rw-r--r-- | src/soc/intel/common/block/include/intelblocks/meminit.h | 159 |
1 files changed, 159 insertions, 0 deletions
diff --git a/src/soc/intel/common/block/include/intelblocks/meminit.h b/src/soc/intel/common/block/include/intelblocks/meminit.h new file mode 100644 index 0000000000..cbec04ddb2 --- /dev/null +++ b/src/soc/intel/common/block/include/intelblocks/meminit.h @@ -0,0 +1,159 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef __SOC_INTEL_COMMON_BLOCK_MEMINIT_H__ +#define __SOC_INTEL_COMMON_BLOCK_MEMINIT_H__ + +#include <stddef.h> +#include <stdint.h> +#include <types.h> + +/* + * Calculates the number of channels depending upon the data bus width of the + * platform and the channel width. + */ +#define CHANNEL_COUNT(ch_width) (CONFIG_DATA_BUS_WIDTH / (ch_width)) + +/* + * UPDs for FSP-M are organized depending upon the MRC's view of channel. Thus, + * the number of channels as seen by the MRC are dependent on the channel width + * assumption in the UPDs. These channels might not necessarily be the same as + * the physical channels supported by the platform. + */ +#define MRC_CHANNELS CHANNEL_COUNT(CONFIG_MRC_CHANNEL_WIDTH) + +/* Different memory topologies supported by the platform. */ +enum mem_topology { + MEM_TOPO_MEMORY_DOWN = BIT(0), + MEM_TOPO_DIMM_MODULE = BIT(1), + MEM_TOPO_MIXED = MEM_TOPO_MEMORY_DOWN | MEM_TOPO_DIMM_MODULE, +}; + +/* + * SPD provides information about the memory module. Depending upon the memory + * topology, the SPD data can be obtained from different sources. Example: for + * memory down topology, SPD is read from CBFS using cbfs_index. For DIMM + * modules, SPD is read from EEPROM using the DIMM addresses provided by the + * mainboard. + */ +struct mem_spd { + enum mem_topology topo; + /* + * SPD data is read from CBFS spd.bin file using cbfs_index to locate + * the entry. This is used in case of MEM_TOPO_MEMORY_DOWN and + * MEM_TOPO_MIXED topologies. + */ + size_t cbfs_index; + + /* + * SPD data is read from on-module EEPROM using the DIMM addresses + * provided by the mainboard. This is used in case of + * MEM_TOPO_DIMM_MODULE and MEM_TOPO_MIXED topologies. + * + * Up to a maximum of MRC_CHANNELS * CONFIG_DIMMS_PER_CHANNEL addresses + * can be provided by mainboard. However, depending upon the memory + * technology being used and the number of physical channels supported + * by that technology, the actual channels might be less than + * MRC_CHANNELS. + */ + struct { + uint8_t addr_dimm[CONFIG_DIMMS_PER_CHANNEL]; + } smbus[MRC_CHANNELS]; +}; + +/* Information about memory technology supported by SoC */ +struct soc_mem_cfg { + /* + * Number of physical channels that are supported by the memory + * technology. + */ + size_t num_phys_channels; + + /* + * Map of physical channel numbers to MRC channel numbers. This is + * helpful in identifying what SPD entries need to be filled for a + * physical channel. + * + * Example: MRC supports 8 channels 0 - 7, but a memory technology + * supports only 2 physical channels 0 - 1. In this case, the map could + * be: + * [0] = 0, + * [1] = 4, + * indicating that physical channel 0 is mapped to MRC channel 0 and + * physical channel 1 is mapped to MRC channel 4. + */ + size_t phys_to_mrc_map[MRC_CHANNELS]; + + /* + * Masks to be applied in case of memory down topology. For memory down + * topology, there is no separate EEPROM. Thus, the masks need to be + * hard-coded by the SoC to indicate what combinations are supported. + * This is a mask of physical channels for the memory technology. + * + * Example: For the memory technology supporting 2 physical channels, + * where the population rules restrict use of channel 0 for + * half-channel, half_channel mask would be set to 0x1 indicating + * channel 0 is always populated. + */ + struct { + /* + * Mask of physical channels that are populated in case of + * half-channel configuration. + */ + uint32_t half_channel; + /* + * Mask of physical channels that are populated with memory + * down parts in case of mixed topology. + */ + uint32_t mixed_topo; + } md_phy_masks; +}; + +/* Flags indicating how the channels are populated. */ +enum channel_population { + NO_CHANNEL_POPULATED = 0, + TOP_HALF_POPULATED = BIT(0), + BOTTOM_HALF_POPULATED = BIT(1), + FULLY_POPULATED = TOP_HALF_POPULATED | BOTTOM_HALF_POPULATED, +}; + +/* + * Data for the memory channels that can be used by SoC code to populate FSP + * UPDs. + */ +struct mem_channel_data { + /* Pointer to SPD data for each DIMM of each channel */ + uintptr_t spd[MRC_CHANNELS][CONFIG_DIMMS_PER_CHANNEL]; + /* Length of SPD data */ + size_t spd_len; + /* Flags indicating how channels are populated */ + enum channel_population ch_population_flags; +}; + +/* + * This change populates data regarding memory channels in `struct + * mem_channel_data` using the following inputs from SoC code: + * soc_mem_cfg : SoC-specific information about the memory technology used by + * the mainboard. + * spd_info : Information about the memory topology. + * half_populated: Hint from mainboard if channels are half populated. + */ +void mem_populate_channel_data(const struct soc_mem_cfg *soc_mem_cfg, + const struct mem_spd *spd_info, + bool half_populated, + struct mem_channel_data *data); + +/* + * Given a channel number and the maximum number of supported channels, this + * function returns if a channel is populated. This is useful for populating + * DQ/DQS UPDs by the SoC code. + */ +static inline bool channel_is_populated(size_t curr_ch, size_t max_ch, + enum channel_population flags) +{ + if ((curr_ch * 2) < max_ch) + return !!(flags & BOTTOM_HALF_POPULATED); + + return !!(flags & TOP_HALF_POPULATED); +} + +#endif /* __SOC_INTEL_COMMON_BLOCK_MEMINIT_H__ */ |