mirror of
https://github.com/torvalds/linux
synced 2024-09-22 20:37:18 +00:00
a4b4be3fd7
What it is pointed by a csrow/channel vector is a rank information, and not a channel information. On a traditional architecture, the memory controller directly access the memory ranks, via chip select rows. Different ranks at the same DIMM is selected via different chip select rows. So, typically, one csrow/channel pair means one different DIMM. On FB-DIMMs, there's a microcontroller chip at the DIMM, called Advanced Memory Buffer (AMB) that serves as the interface between the memory controller and the memory chips. The AMB selection is via the DIMM slot, and not via a csrow. It is up to the AMB to talk with the csrows of the DRAM chips. So, the FB-DIMM memory controllers see the DIMM slot, and not the DIMM rank. RAMBUS is similar. Newer memory controllers, like the ones found on Intel Sandy Bridge and Nehalem, even working with normal DDR3 DIMM's, don't use the usual channel A/channel B interleaving schema to provide 128 bits data access. Instead, they have more channels (3 or 4 channels), and they can use several interleaving schemas. Such memory controllers see the DIMMs directly on their registers, instead of the ranks, which is better for the driver, as its main usageis to point to a broken DIMM stick (the Field Repleceable Unit), and not to point to a broken DRAM chip. The drivers that support such such newer memory architecture models currently need to fake information and to abuse on EDAC structures, as the subsystem was conceived with the idea that the csrow would always be visible by the CPU. To make things a little worse, those drivers don't currently fake csrows/channels on a consistent way, as the concepts there don't apply to the memory controllers they're talking with. So, each driver author interpreted the concepts using a different logic. In order to fix it, let's rename the data structure that points into a DIMM rank to "rank_info", in order to be clearer about what's stored there. Latter patches will provide a better way to represent the memory hierarchy for the other types of memory controller. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> |
||
|---|---|---|
| .. | ||
| amd64_edac.c | ||
| amd64_edac.h | ||
| amd64_edac_dbg.c | ||
| amd64_edac_inj.c | ||
| amd76x_edac.c | ||
| amd8111_edac.c | ||
| amd8111_edac.h | ||
| amd8131_edac.c | ||
| amd8131_edac.h | ||
| cell_edac.c | ||
| cpc925_edac.c | ||
| e7xxx_edac.c | ||
| e752x_edac.c | ||
| edac_core.h | ||
| edac_device.c | ||
| edac_device_sysfs.c | ||
| edac_mc.c | ||
| edac_mc_sysfs.c | ||
| edac_module.c | ||
| edac_module.h | ||
| edac_pci.c | ||
| edac_pci_sysfs.c | ||
| edac_stub.c | ||
| i7core_edac.c | ||
| i3000_edac.c | ||
| i3200_edac.c | ||
| i5000_edac.c | ||
| i5100_edac.c | ||
| i5400_edac.c | ||
| i7300_edac.c | ||
| i82443bxgx_edac.c | ||
| i82860_edac.c | ||
| i82875p_edac.c | ||
| i82975x_edac.c | ||
| Kconfig | ||
| Makefile | ||
| mce_amd.c | ||
| mce_amd.h | ||
| mce_amd_inj.c | ||
| mpc85xx_edac.c | ||
| mpc85xx_edac.h | ||
| mv64x60_edac.c | ||
| mv64x60_edac.h | ||
| pasemi_edac.c | ||
| ppc4xx_edac.c | ||
| ppc4xx_edac.h | ||
| r82600_edac.c | ||
| sb_edac.c | ||
| tile_edac.c | ||
| x38_edac.c | ||