Update the memory controller information on notebooks that adjust the memory frequency adaptively

[7Z0t99]

Several notebooks from the Kaby Lake R generation, e.g. the HP Elitebook 840 G5, adjust their memory frequency and timings adaptively. However, CoreFreq apparently only reads the memory controller information once, i.e. it often displays outdated information.
I have got access to an HP Elitebook 840 G5. It runs its memory as DDR4-1333 (the minimum standard speed supported by the modules) in idle and as DDR4-2400 (the maximum speed supported by the processor) under load. I have taken a screenshot in both cases: (When I write standard speed I mean an integer multiple of about 266 (technically 800/3).

I assume that the same applies to the Dell Latitude 5490, because there is data in the CPU-Z validator database that shows some of them running their memory at nominal DDR4-1333 and others at DDR4-2400, see https://valid.x86.fr/qjisaz and https://valid.x86.fr/l2efm3 , and because DDR4-1333 is slower than any DDR4 module I am aware of.

I would be great if CoreFreq could be updated to take this into account and present up-to-date values for the memory controller information.

[cyring]

I would be great if CoreFreq could be updated to take this into account and present up-to-date values for the memory controller information

The UI allows a full refresh pressing the star key *

This asks driver to probe hardware again.
(you will quickly see thermals resetting)

Next close and re-open the Memory Controller window or run corefreq-cli -M again

Does it help ?

[7Z0t99]

I do see the thermals resetting when I press *, but unfortunately the memory controller information is not updated.

[cyring]

I do see the thermals resetting when I press *, but unfortunately the memory controller information is not updated.

1. Can you apply this patch

CoreFreq_ReProbe_MC.patch.gz

2. Rebuild and reload
3. Go to Menu > Settings and switch Experimental ON

4. Now press * key to refresh memory controller
   Your kernel log should print CoreFreq: Probe MC

[cyring]

By the way what is the register bit which announces this DRAM speed capability ?
If one exists then driver could conditionally monitor DRAM changes

In datasheets, since Intel 8th gen , the closest definition I'm reading is PDWN_​CONFIG_​CTL

This bit determined whether BIOS or pcode will control DDR powerdown modes and idle counter (via programming the PM_​PDWN_​config regs in iMC). When clear, pcode will manage the modes based on either core P-states or IA32_​ENERGY_​PERFORMANCE_​BIAS MSR value (when enabled). When set, BIOS is in control of DDR CKE mode and idle timer value, and pcode algorithm does not run.

[7Z0t99]

Thanks for the quick response. Yes, the patch works as expected, but the really interesting part would be to monitor the changes if the notebook adjusts the memory frequency adaptively, because when I first saw that the DRAM was running as DDR4-1333 I thought that the notebook was broken. It took me a while to figure out what was going on, and there doesn't seem to be much information about this on the internet.
To be honest I have no idea how to check that. If it helps: the register whose documentation you linked reads 0x00000160

[cyring]

Thanks for the quick response. Yes, the patch works as expected, but the really interesting part would be to monitor the changes if the notebook adjusts the memory frequency adaptively, because when I first saw that the DRAM was running as DDR4-1333 I thought that the notebook was broken. It took me a while to figure out what was going on, and there doesn't seem to be much information about this on the internet. To be honest I have no idea how to check that. If it helps: the register whose documentation you linked reads 0x00000160

Now you are getting commit b84aa77
Just press * at any time and you are probing PCI again (Experimental not needed anymore)

But my PCI probing function is quiet expensive and I dont feel like executing it at every interval

0x00000160 in binary 101100000 thus PDWN_​CONFIG_​CTL is raised

This register is common at BAR offset 0x5880 among several Intel generations and if I have the guarantee that PDWN_​CONFIG_​CTL means the feature exists and it is enabled then I can probe at every X seconds; less often

How can we tell that PDWN_​CONFIG_​CTL is disable ?
Do you have a BIOS option or profile which disable that DRAM scaling ?
Then read register again to check if bit is clear or not ?

[7Z0t99]

I have found out a bit more in the meantime: the feature is called System Agent Enhanced Intel Speedstep Technology or System Agent Geyserville and described in section 4.5 of the 7th Generation Intel® Processor Families for U/Y Platforms and 8th Generation Intel Processor Family for U Quad-Core and Y Dual Core Platforms Datasheet, Volume 1 of 2.
If I understand the 6th Generation Intel® Processor for U/Y-Platforms Datasheet, Volume 1 of 2 correctly, SA-GV was first introduced with Skylake.

Unfortunately I have not found a way to disable it in the BIOS. When you google for SA-GV, there are various BIOS manuals in the results for mainboards, where you can configure it. And there are various results related to Intel's firmware support package.
The features is also related to the integrated graphics (driver), because the DRAM speed should not be changed at certain times, see https://narkive.com/Kpr1WL8S

In any case, in the meantime I don't think that PDWN_CONFIG_CTL tells whether the feature is enabled, but rather whether the power management microcontroller built into the CPU or the BIOS manages the DDR operating points. Thus I have no idea how to check for sure whether the feature is enabled.

Wouldn't it be sufficient to monitor only one PCI register, e.g. the system agent performance status register 5918h to detect a change in memory speed? How expensive would this be?

[cyring]

Very good find out; thank you for sharing that knowledge.
Apparently some Desktop BIOS allow to disable/enable and even set bin ratio
Z790 AORUS manual
We could cache as much as possible the MC controller MMIO address remapping and leave it opened t'il we stop monitoring its settings.
Although the UI view of MC is so far static which involves to refactor various cells to become dynamic.

About discovering this feature, if it is a SoC firmware one, we may not find an easy to read CPUID bit which announces it. But we could make some assumptions based on the chipset device id (PCI read) and other SMBIOS string(s)

Btw don't you see in your PCI tree list the SA-GV feature ?
Please post (in Markdown) the output of the following command:

lspci -nn

[cyring]

According to SA-GV notes, Gear Mode should give a clue about frequency and settings but it remains at zero value in your screenshot despite decoder is supposed to set a value of {4, 2 or 1}

CoreFreq/x86_64/corefreqd.c

Line 5751 in 018ee77

TIMING(mc, cha).GEAR = \

[7Z0t99]

Sure, here is the output of lspci -nn: (the WiFi was upgraded)

00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers [8086:5914] (rev 08)
00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07)
00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 08)
00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f] (rev 21)
00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21)
00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21)
00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21)
00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP CSME HECI #1 [8086:9d3a] (rev 21)
00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #4 [8086:9d13] (rev f1)
00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 [8086:9d14] (rev f1)
00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 [8086:9d18] (rev f1)
00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point LPC/eSPI Controller [8086:9d4e] (rev 21)
00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-LP PMC [8086:9d21] (rev 21)
00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD Audio [8086:9d71] (rev 21)
00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus [8086:9d23] (rev 21)
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (4) I219-LM [8086:15d7] (rev 21)
01:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6E(802.11ax) AX210/AX1675* 2x2 [Typhoon Peak] [8086:2725] (rev 1a)
02:00.0 PCI bridge [0604]: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] [8086:15da] (rev 02)
03:00.0 PCI bridge [0604]: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] [8086:15da] (rev 02)
03:01.0 PCI bridge [0604]: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] [8086:15da] (rev 02)
03:02.0 PCI bridge [0604]: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] [8086:15da] (rev 02)
04:00.0 System peripheral [0880]: Intel Corporation JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016] [8086:15d9] (rev 02)
3a:00.0 USB controller [0c03]: Intel Corporation JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016] [8086:15db] (rev 02)
3b:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 [144d:a808]

There only is one power management controller in the list, but it belongs to the PCH. I assume that the system agent is a different controller that is part of the CPU. So this doesn't help.

As you have seen in the documentation, there are more SA GV operating points in later generations, as described in the Z790 manual that you have linked, corresponding to the 13th generation. But there were only two when it was first introduced.

Note that the gear mode was only introduced in the 11th generation according to https://www.tomshardware.com/news/alder-lake-multiple-gear-modes-confirmed . The register most likely reads zero, because the bits are reserved in earlier generations. The actual gear ratio should be 1:1.

Since SA-GV is a CPU feature, I recommend to enable a periodic update of the memory controller information based on the CPU generation. In case you want to make it more precise: I saw some comments when I came across the search results related to the FSP saying that it was only available in the mobile processors when it was first introduced. In the meantime, it is also available on the desktop.

[cyring]

Wouldn't it be sufficient to monitor only one PCI register, e.g. the system agent performance status register 5918h to detect a change in memory speed? How expensive would this be?

In fact monitoring this register is already present in driver source code:

CoreFreq/x86_64/corefreqk.c

Line 15609 in 018ee77

#define Pkg_Intel_PMC_PCU_Counters(Core, _T) \

It requires a special build b/c I did not have such hardware for too long.

make clean
make ARCH_PMC=PCU

Save your files before shooting corefreqk.ko module

In corefreq-cli press g to switch to the Package view and check if one of the counters is monitoring a frequency value ?
Please post a screenshot.