Bug#1063161: Add amd_pmf module
On Monday, 1 July 2024 17:17:46 CEST Nathan MALO wrote: > It seems to me that it is working as expected ! Awesome :-) signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
Hi all, I am getting back to you with updated info. I currently own a Framework AMD 13 laptop running Debian Bookworm. I've installed the new kernel from unstable. apt-cache policy linux-image-amd64 linux-image-amd64: Installed : 6.9.7-1 Candidate : 6.9.7-1 Version table : *** 6.9.7-1 100 99 http://ftp.debian.org/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status apt-cache policy firmware-linux-free firmware-linux-free: Installed: 20240610-1 Candidate: 20240610-1 Version table: *** 20240610-1 100 99 http://ftp.debian.org/debian unstable/main amd64 Packages 99 http://ftp.debian.org/debian unstable/main i386 Packages 100 /var/lib/dpkg/status apt-cache policy firmware-linux-nonfree firmware-linux-nonfree: Installed: 20230625-2 Candidate: 20230625-2 Version table: *** 20230625-2 100 99 http://ftp.debian.org/debian unstable/non-free-firmware amd64 Packages 99 http://ftp.debian.org/debian unstable/non-free-firmware i386 Packages 100 /var/lib/dpkg/status apt-cache policy firmware-misc-nonfree firmware-misc-nonfree: Installed: 20230625-2 Candidate: 20230625-2 Version table: *** 20230625-2 100 99 http://ftp.debian.org/debian unstable/non-free-firmware amd64 Packages 99 http://ftp.debian.org/debian unstable/non-free-firmware i386 Packages 100 /var/lib/dpkg/status apt-cache policy amd64-microcode amd64-microcode: Installed: 3.20240116.2+nmu1 Candidate: 3.20240116.2+nmu1 Version table: *** 3.20240116.2+nmu1 100 99 http://ftp.debian.org/debian unstable/non-free-firmware amd64 Packages 100 /var/lib/dpkg/status I've installed power-profiles-daemon from ubuntu jammy PPA (because PPD from unstable resulted in too much updated packages, I want to stay as much as possible on stable). apt-cache policy power-profiles-daemon power-profiles-daemon: Installed: 0.21-1~jammy2 Candidate: 0.21-1~jammy2 Version table: 0.21-2 99 99 http://ftp.debian.org/debian unstable/main amd64 Packages *** 0.21-1~jammy2 500 500 https://ppa.launchpadcontent.net/superm1/ppd/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status Upon restart, the amd_pmf modules is successfully loaded, and visible in dmesg: [ 21.093436] ccp :c1:00.2: tee enabled [ 21.104955] amd-tee driver initialization successful ... [ 21.236595] amd-pmf AMDI0102:00: registered PMF device successfully lsmod | grep -E "^amd" amd_atl40960 1 amd_pmf61440 0 amdtee 28672 0 amd_sfh49152 1 amd_pmf amd_pmc40960 0 amdgpu 12845056 33 amdxcp 12288 1 amdgpu The platform_profile is visible in PPD output: powerprofilesctl performance: CpuDriver: amd_pstate PlatformDriver: platform_profile Degraded: no balanced: CpuDriver: amd_pstate PlatformDriver: platform_profile * power-saver: CpuDriver: amd_pstate PlatformDriver: platform_profile It seems to me that it is working as expected ! I would like to thanks a thousand times all the people involved in fixing this issue, you made my laptop an even better one <3 Best regards, nate Le ven. 28 juin 2024 à 19:49, Diederik de Haas a écrit : > On Friday, 28 June 2024 19:40:50 CEST Mario Limonciello wrote: > > > As this will normally be a headless system, I'm actually looking if I > can > > > turn the GPU off, *unless* there's an HDMI cable plugged in. > > > So (at least for now), the GPUs only function is to have a display > when I > > > need it for troubleshooting. > > > > With nothing plugged in, modern AMD GPUs will go into runtime PM and > > depending on the motherboard design either D3hot or D3cold. > > I need to figure out how I can query the various things and learn what > they > actually mean. F.e. on the frame.work forum I found: > `cat /sys/class/drm/card0/device/power/runtime_status` > > and that returns 'active', but I have no idea what that means. > > Like I said before: lots of research to do ;-) > > > D3cold is as close to off as you can get. > > Good to know :-) > > Cheers, > Diederik
Bug#1063161: Add amd_pmf module
On Friday, 28 June 2024 19:40:50 CEST Mario Limonciello wrote: > > As this will normally be a headless system, I'm actually looking if I can > > turn the GPU off, *unless* there's an HDMI cable plugged in. > > So (at least for now), the GPUs only function is to have a display when I > > need it for troubleshooting. > > With nothing plugged in, modern AMD GPUs will go into runtime PM and > depending on the motherboard design either D3hot or D3cold. I need to figure out how I can query the various things and learn what they actually mean. F.e. on the frame.work forum I found: `cat /sys/class/drm/card0/device/power/runtime_status` and that returns 'active', but I have no idea what that means. Like I said before: lots of research to do ;-) > D3cold is as close to off as you can get. Good to know :-) Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On Friday, 28 June 2024 19:24:58 CEST Mario Limonciello wrote: > On 6/28/2024 12:05, Diederik de Haas wrote: > > On Friday, 28 June 2024 18:37:06 CEST Mario Limonciello wrote: > >> On 6/28/2024 11:18, Diederik de Haas wrote: > I don't think so. I've never heard of this actually used in a desktop > board. It's for mobile designs AFAIK. > >>> > >>> I can understand that the initial/original goal/target was mobile. > >>> But is there a(ny) technical reason why it couldn't also support > >>> 'desktop' > >>> systems? > >>> IIRC and IIUC it does need Zen 3, which my CPU/SoC does. > >> > >> It needs information about the hardware thermal design to change the > >> correct coefficients. > > > > Isn't that something that AMD would know? > > I have software interfaces that I can use to tell you what APU > coefficient is currently programmed. I can tell you what the MAX an APU > can support is but I can't tell you what the "rest" of the hardware > design can support. > > This depends on hardware stuff. For example: > 1) how big of a heat pipe there is > 2) how big of a power supply there is > 3) how many fans there are > 4) is there a beefy GPU sharing power > 5) etc. > > Even if you have the thermal headroom if you turn PPT limits up too much > your GPU performance might suffer. As this will normally be a headless system, I'm actually looking if I can turn the GPU off, *unless* there's an HDMI cable plugged in. So (at least for now), the GPUs only function is to have a display when I need it for troubleshooting. > Designers do thermal simulations to come up with the numbers for all > this stuff and it's proprietary information to go with their design. > > That's why it's encoded in BIOS or EC and OS will read it and offer the > interface to the user. I really don't think it makes sense in a design > it yourself desktop. Ah, ok. Clear :-) I (initially) thought you meant hardware thermal design *of the CPU*, but I now know it's 'a bit' more then that. Thanks, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
As this will normally be a headless system, I'm actually looking if I can turn the GPU off, *unless* there's an HDMI cable plugged in. So (at least for now), the GPUs only function is to have a display when I need it for troubleshooting. With nothing plugged in, modern AMD GPUs will go into runtime PM and depending on the motherboard design either D3hot or D3cold. D3cold is as close to off as you can get.
Bug#1063161: Add amd_pmf module
On 6/28/2024 12:05, Diederik de Haas wrote: On Friday, 28 June 2024 18:37:06 CEST Mario Limonciello wrote: On 6/28/2024 11:18, Diederik de Haas wrote: I don't think so. I've never heard of this actually used in a desktop board. It's for mobile designs AFAIK. I can understand that the initial/original goal/target was mobile. But is there a(ny) technical reason why it couldn't also support 'desktop' systems? IIRC and IIUC it does need Zen 3, which my CPU/SoC does. It needs information about the hardware thermal design to change the correct coefficients. Isn't that something that AMD would know? I have software interfaces that I can use to tell you what APU coefficient is currently programmed. I can tell you what the MAX an APU can support is but I can't tell you what the "rest" of the hardware design can support. This depends on hardware stuff. For example: 1) how big of a heat pipe there is 2) how big of a power supply there is 3) how many fans there are 4) is there a beefy GPU sharing power 5) etc. Even if you have the thermal headroom if you turn PPT limits up too much your GPU performance might suffer. Designers do thermal simulations to come up with the numbers for all this stuff and it's proprietary information to go with their design. That's why it's encoded in BIOS or EC and OS will read it and offer the interface to the user. I really don't think it makes sense in a design it yourself desktop.
Bug#1063161: Add amd_pmf module
On Friday, 28 June 2024 18:37:06 CEST Mario Limonciello wrote: > On 6/28/2024 11:18, Diederik de Haas wrote: > >> I don't think so. I've never heard of this actually used in a desktop > >> board. It's for mobile designs AFAIK. > > > > I can understand that the initial/original goal/target was mobile. > > But is there a(ny) technical reason why it couldn't also support 'desktop' > > systems? > > IIRC and IIUC it does need Zen 3, which my CPU/SoC does. > > It needs information about the hardware thermal design to change the > correct coefficients. Isn't that something that AMD would know? > For example just changing the sPPT or fPPT without the appropriate > thermal headroom will cause the SOC to go into thermal throttling > prematurely and hurt your performance. > > That's why OEMs encode this information in their EC or in the BIOS and > advertise it in the PMF ACPI tables what they can do. > > > Ok. I might be able to convince Asus to add it, but I can also configure > > my system to 'modprobe' it on boot up. > > Loading it with modprobe doesn't do anything if there is no ACPI device > to bind to. It's just like having it compiled into your kernel and it > not binding to any device. Ok, understood. I'm not too positive I could convince Asus to add that to their 'BIOS', but I can try. > Like I said; I've never seen it on a desktop. Because of what it's > intended to do in it's current form, I think it's unlikely that it would > be added there. Understood. Hopefully this does make AMD aware that non-laptop/mobile devices could (or should!) be a potential target too. Even if it won't directly benefit me now, that would still be a win :) > >> The way that it works is that the OEM will set bits in their BIOS for > >> that ACPI device indicating which "AMD_PMF" features they support. > >> That's things like Static Slider, Auto mode, CNQF, Smart PC, slider > >> notifications. > > > > I have no idea what those things are, but I can research it ... > > > > But I think everyone and the planet would benefit from a (more) energy > > efficient system, regardless if it (normally) runs on batteries or not. > > In my case, this system will likely be my NAS, so idle 99(.9)% of the time > > and (in the future) on 24/7, so I'm extra motivated to make it consume as > > little energy as possible. > > > > Keep in mind PPD does multiple things based on what the hardware > advertises support for. > > For your system, you are using amd-pstate in active mode. I can see > this from your powerprofilesctl output. This will make sure the SoC is > properly biased towards efficiency or performance based on your preference. > > It will operate under the limitations of the coefficients programmed by > the firmware at max load (so you can't change PPT), but when idle it > shouldn't consume more power than needed. > > There is a kernel patch series coming in kernel 6.11 for "Core > performance boost" which will let you turn on/off boost above nominal > frequency. You can turn it off, and then CPU cores won't ever go above > nominal frequency. > > I'm proposing that we would leave boost on for PPD balanced and > performance states. For PPD power-saver we would turn it off. > > This is merged in the PPD tree and unless anyone complains will be part > of the next PPD release. > > The other thing that could be really interesting to do for power savings > purposes is to put certain tasks only the non-preferred cores or tune > EPP towards efficiency on cores running long running tasks that don't > need to finish quickly. > > In my opinion this is going to open up a lot of potential for sched-ext. > and for systemd. Userspace can read the core rankings and when starting > up and moving tasks around adjust EPP, boost and which cores tasks run > on. It's a lot of complicated work ahead though with a lot of profiling > needed. I hadn't used PPD before, so I'll experiment with it. Looks like I have lots of research to do ;-) Thanks for your detailed response :-) Hack (and Save) the Planet! Diederik signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On 6/28/2024 11:18, Diederik de Haas wrote: I don't think so. I've never heard of this actually used in a desktop board. It's for mobile designs AFAIK. I can understand that the initial/original goal/target was mobile. But is there a(ny) technical reason why it couldn't also support 'desktop' systems? IIRC and IIUC it does need Zen 3, which my CPU/SoC does. It needs information about the hardware thermal design to change the correct coefficients. For example just changing the sPPT or fPPT without the appropriate thermal headroom will cause the SOC to go into thermal throttling prematurely and hurt your performance. That's why OEMs encode this information in their EC or in the BIOS and advertise it in the PMF ACPI tables what they can do. Ok. I might be able to convince Asus to add it, but I can also configure my system to 'modprobe' it on boot up. Loading it with modprobe doesn't do anything if there is no ACPI device to bind to. It's just like having it compiled into your kernel and it not binding to any device. Like I said; I've never seen it on a desktop. Because of what it's intended to do in it's current form, I think it's unlikely that it would be added there. The way that it works is that the OEM will set bits in their BIOS for that ACPI device indicating which "AMD_PMF" features they support. That's things like Static Slider, Auto mode, CNQF, Smart PC, slider notifications. I have no idea what those things are, but I can research it ... I think someone with a laptop that supports PMF would be best to confirm this. Framework 13 AMD and Framework 16 both support it. It would be great if someone with such a system can confirm whether it now can/ does work for the original target. Yeah maybe someone on the Framework forums will be able to confirm it's working now for them. They've been very vocal about it broken in Debian. But I think everyone and the planet would benefit from a (more) energy efficient system, regardless if it (normally) runs on batteries or not. In my case, this system will likely be my NAS, so idle 99(.9)% of the time and (in the future) on 24/7, so I'm extra motivated to make it consume as little energy as possible. Cheers and thanks for your fast response, Diederik Keep in mind PPD does multiple things based on what the hardware advertises support for. For your system, you are using amd-pstate in active mode. I can see this from your powerprofilesctl output. This will make sure the SoC is properly biased towards efficiency or performance based on your preference. It will operate under the limitations of the coefficients programmed by the firmware at max load (so you can't change PPT), but when idle it shouldn't consume more power than needed. There is a kernel patch series coming in kernel 6.11 for "Core performance boost" which will let you turn on/off boost above nominal frequency. You can turn it off, and then CPU cores won't ever go above nominal frequency. I'm proposing that we would leave boost on for PPD balanced and performance states. For PPD power-saver we would turn it off. This is merged in the PPD tree and unless anyone complains will be part of the next PPD release. The other thing that could be really interesting to do for power savings purposes is to put certain tasks only the non-preferred cores or tune EPP towards efficiency on cores running long running tasks that don't need to finish quickly. In my opinion this is going to open up a lot of potential for sched-ext. and for systemd. Userspace can read the core rankings and when starting up and moving tasks around adjust EPP, boost and which cores tasks run on. It's a lot of complicated work ahead though with a lot of profiling needed.
Bug#1063161: Add amd_pmf module
On Friday, 28 June 2024 17:49:40 CEST Mario Limonciello wrote: > On 6/28/2024 10:41, Diederik de Haas wrote: > > On Monday, 5 February 2024 15:47:08 CEST Nate wrote: > >> AMD has introduced a feature called Power Management Framework. > > > > With the upload of 6.9.7 this module now is available in the kernel. > > > AFAIK one of my systems should benefit from this too: > > MB: Asus ROG STRIX B550-F GAMING, BIOS 3607 03/18/2024 > > CPU(/APU?): AMD Ryzen 5 5500GT > > amd-microcode: version 3.20240116.2+nmu1 (has AMD-TEE firmware, #1062678) > > firmware-amd-graphics: 20240220-1~exp0 (sorry ;-P) > > power-profiles-daemon: 0.21-2 > > > > So I think I'm all set... > > I don't think so. I've never heard of this actually used in a desktop > board. It's for mobile designs AFAIK. I can understand that the initial/original goal/target was mobile. But is there a(ny) technical reason why it couldn't also support 'desktop' systems? IIRC and IIUC it does need Zen 3, which my CPU/SoC does. > >> The power-profiles-daemon software gained recently support for amd-pstate > >> driver, and also gained support to handle simultaneously cpu driver > >> (amd-pstate) and platform driver (amd-pmf). > > > > The version in that PPA is 0.21-1, so the Debian Testing/Unstable version > > should be fine now? > > Yes. Excellent > >> And when I list the existing power-profiles I get the following: > >> > >> user@machine:> sudo powerprofilesctl > >> > >>performance: > >> CpuDriver:amd_pstate > >> Degraded: no > >> > >> * balanced: > >> CpuDriver:amd_pstate > >> PlatformDriver: placeholder > >> > >>power-saver: > >> CpuDriver:amd_pstate > >> PlatformDriver: placeholder > >> > >> This (PlatformDriver: placeholder) indicates that the AMD_PMF module is > >> not included in the kernel. > > > > So I booted into the 6.9.7 kernel and ran that command ... only to be > > greeted with the exact same output ... > > > > So I verified whether AMD_PMF was indeed included ... and it was. > > Then I ran ``lsmod | grep amd`` and I saw various modules listed, but I > > did > > NOT see an ``amd_pmf`` driver loaded. Or and ``amdtee`` ... > > > > So I did ``modprobe amd_pmf`` and checked ``lsmod`` again and there it > > was: > > ... > > Ran ``powerprofilesctl`` again ... and saw no change (thus still > > 'placeholder')> > >> There may be technical limitations that I am not aware of. > > > > I would have expected that amd_pmf and related modules would be loaded > > automatically. And ofc that it would actually work. > > > > The only real thing that I can think off that could interfere (from my > > side) is that I'm still using an 'old fashioned' BIOS, thus not UEFI. > > > > What other causes could there be that makes it not work properly? > > If there is no matching PMF ACPI device the driver won't automatically load. Ok. I might be able to convince Asus to add it, but I can also configure my system to 'modprobe' it on boot up. > The way that it works is that the OEM will set bits in their BIOS for > that ACPI device indicating which "AMD_PMF" features they support. > That's things like Static Slider, Auto mode, CNQF, Smart PC, slider > notifications. I have no idea what those things are, but I can research it ... > I think someone with a laptop that supports PMF would be best to confirm > this. Framework 13 AMD and Framework 16 both support it. It would be great if someone with such a system can confirm whether it now can/ does work for the original target. But I think everyone and the planet would benefit from a (more) energy efficient system, regardless if it (normally) runs on batteries or not. In my case, this system will likely be my NAS, so idle 99(.9)% of the time and (in the future) on 24/7, so I'm extra motivated to make it consume as little energy as possible. Cheers and thanks for your fast response, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
On 6/28/2024 10:41, Diederik de Haas wrote: On Monday, 5 February 2024 15:47:08 CEST Nate wrote: AMD has introduced a feature called Power Management Framework. See here for more info: https://www.phoronix.com/news/AMD-PMF-Linux-Driver It seems that this module is not included in the Debian Linux Kernel. With the upload of 6.9.7 this module now is available in the kernel. Great. AFAIK one of my systems should benefit from this too: MB: Asus ROG STRIX B550-F GAMING, BIOS 3607 03/18/2024 CPU(/APU?): AMD Ryzen 5 5500GT amd-microcode: version 3.20240116.2+nmu1 (has AMD-TEE firmware, #1062678) firmware-amd-graphics: 20240220-1~exp0 (sorry ;-P) power-profiles-daemon: 0.21-2 So I think I'm all set... I don't think so. I've never heard of this actually used in a desktop board. It's for mobile designs AFAIK. A bit of context: The power-profiles-daemon software gained recently support for amd-pstate driver, and also gained support to handle simultaneously cpu driver (amd-pstate) and platform driver (amd-pmf). (https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/merge_request s/127). It seems that the power-profiles-daemon in unstable do not include the commit that allows to handle both drivers at the same time. So I've installed the power-profile-daemons for jammy from this Ubuntu PPA (https://launchpad.net/~superm1/+archive/ubuntu/ppd/+packages). The version in that PPA is 0.21-1, so the Debian Testing/Unstable version should be fine now? Yes. And when I list the existing power-profiles I get the following: user@machine:> sudo powerprofilesctl performance: CpuDriver: amd_pstate Degraded: no * balanced: CpuDriver: amd_pstate PlatformDriver:placeholder power-saver: CpuDriver: amd_pstate PlatformDriver:placeholder This (PlatformDriver: placeholder) indicates that the AMD_PMF module is not included in the kernel. So I booted into the 6.9.7 kernel and ran that command ... only to be greeted with the exact same output ... So I verified whether AMD_PMF was indeed included ... and it was. Then I ran ``lsmod | grep amd`` and I saw various modules listed, but I did NOT see an ``amd_pmf`` driver loaded. Or and ``amdtee`` ... So I did ``modprobe amd_pmf`` and checked ``lsmod`` again and there it was: ```sh # lsmod | grep amd amd_pmf61440 0 amdtee 28672 0 amd_sfh49152 1 amd_pmf tee45056 2 amd_pmf,amdtee amdgpu 12845056 0 amd_atl40960 1 edac_mce_amd 28672 0 kvm_amd 184320 0 kvm 1343488 1 kvm_amd amdxcp 12288 1 amdgpu drm_exec 12288 1 amdgpu gpu_sched 65536 1 amdgpu drm_buddy 20480 1 amdgpu drm_suballoc_helper12288 1 amdgpu drm_display_helper262144 1 amdgpu drm_ttm_helper 12288 1 amdgpu ttm 102400 2 amdgpu,drm_ttm_helper drm_kms_helper249856 2 drm_display_helper,amdgpu platform_profile 12288 2 amd_pmf,asus_wmi i2c_algo_bit 12288 1 amdgpu ccp 155648 2 kvm_amd,amdtee video 73728 2 asus_wmi,amdgpu button 24576 1 amd_pmf drm 737280 11 gpu_sched,drm_kms_helper,drm_exec,drm_suballoc_helper,drm_display_helper,drm_buddy,amdgpu,drm_ttm_helper,ttm,amdxcp hid 172032 3 usbhid,hid_generic,amd_sfh gpio_amdpt 16384 0 gpio_generic 20480 1 gpio_amdpt ``` Ran ``powerprofilesctl`` again ... and saw no change (thus still 'placeholder') There may be technical limitations that I am not aware of. I would have expected that amd_pmf and related modules would be loaded automatically. And ofc that it would actually work. The only real thing that I can think off that could interfere (from my side) is that I'm still using an 'old fashioned' BIOS, thus not UEFI. What other causes could there be that makes it not work properly? Cheers, Diederik If there is no matching PMF ACPI device the driver won't automatically load. The way that it works is that the OEM will set bits in their BIOS for that ACPI device indicating which "AMD_PMF" features they support. That's things like Static Slider, Auto mode, CNQF, Smart PC, slider notifications. I think someone with a laptop that supports PMF would be best to confirm this. Framework 13 AMD and Framework 16 both support it.
Bug#1063161: Add amd_pmf module
On Monday, 5 February 2024 15:47:08 CEST Nate wrote: > AMD has introduced a feature called Power Management Framework. > See here for more info: https://www.phoronix.com/news/AMD-PMF-Linux-Driver > > It seems that this module is not included in the Debian Linux Kernel. With the upload of 6.9.7 this module now is available in the kernel. AFAIK one of my systems should benefit from this too: MB: Asus ROG STRIX B550-F GAMING, BIOS 3607 03/18/2024 CPU(/APU?): AMD Ryzen 5 5500GT amd-microcode: version 3.20240116.2+nmu1 (has AMD-TEE firmware, #1062678) firmware-amd-graphics: 20240220-1~exp0 (sorry ;-P) power-profiles-daemon: 0.21-2 So I think I'm all set... > A bit of context: > The power-profiles-daemon software gained recently support for amd-pstate > driver, and also gained support to handle simultaneously cpu driver > (amd-pstate) and platform driver (amd-pmf). > (https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/merge_request > s/127). It seems that the power-profiles-daemon in unstable do not include > the commit that allows to handle both drivers at the same time. > So I've installed the power-profile-daemons for jammy from this Ubuntu PPA > (https://launchpad.net/~superm1/+archive/ubuntu/ppd/+packages). The version in that PPA is 0.21-1, so the Debian Testing/Unstable version should be fine now? > And when I list the existing power-profiles I get the following: > > user@machine:> sudo powerprofilesctl > performance: > CpuDriver:amd_pstate > Degraded: no > > * balanced: > CpuDriver:amd_pstate > PlatformDriver: placeholder > > power-saver: > CpuDriver:amd_pstate > PlatformDriver: placeholder > > This (PlatformDriver: placeholder) indicates that the AMD_PMF module is not > included in the kernel. So I booted into the 6.9.7 kernel and ran that command ... only to be greeted with the exact same output ... So I verified whether AMD_PMF was indeed included ... and it was. Then I ran ``lsmod | grep amd`` and I saw various modules listed, but I did NOT see an ``amd_pmf`` driver loaded. Or and ``amdtee`` ... So I did ``modprobe amd_pmf`` and checked ``lsmod`` again and there it was: ```sh # lsmod | grep amd amd_pmf61440 0 amdtee 28672 0 amd_sfh49152 1 amd_pmf tee45056 2 amd_pmf,amdtee amdgpu 12845056 0 amd_atl40960 1 edac_mce_amd 28672 0 kvm_amd 184320 0 kvm 1343488 1 kvm_amd amdxcp 12288 1 amdgpu drm_exec 12288 1 amdgpu gpu_sched 65536 1 amdgpu drm_buddy 20480 1 amdgpu drm_suballoc_helper12288 1 amdgpu drm_display_helper262144 1 amdgpu drm_ttm_helper 12288 1 amdgpu ttm 102400 2 amdgpu,drm_ttm_helper drm_kms_helper249856 2 drm_display_helper,amdgpu platform_profile 12288 2 amd_pmf,asus_wmi i2c_algo_bit 12288 1 amdgpu ccp 155648 2 kvm_amd,amdtee video 73728 2 asus_wmi,amdgpu button 24576 1 amd_pmf drm 737280 11 gpu_sched,drm_kms_helper,drm_exec,drm_suballoc_helper,drm_display_helper,drm_buddy,amdgpu,drm_ttm_helper,ttm,amdxcp hid 172032 3 usbhid,hid_generic,amd_sfh gpio_amdpt 16384 0 gpio_generic 20480 1 gpio_amdpt ``` Ran ``powerprofilesctl`` again ... and saw no change (thus still 'placeholder') > There may be technical limitations that I am not aware of. I would have expected that amd_pmf and related modules would be loaded automatically. And ofc that it would actually work. The only real thing that I can think off that could interfere (from my side) is that I'm still using an 'old fashioned' BIOS, thus not UEFI. What other causes could there be that makes it not work properly? Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1063161:
Control: reopen -1
Control: found -1 6.8.9-1
Control: found -1 6.9.2-1~exp1
On Thursday, 23 May 2024 17:33:47 CEST Vincent Blut wrote:
> Le 2024-05-23 17:12, Nathan MALO a écrit :
> > Thank you very much for enabling those two features in the kernel.
> > Your work is much appreciated !
> >
> > Maybe I am missing something but I've download the 6.8.9-1 package from
> > and while fiddling with it, I was not able to find the keys
> > CONFIG_AMDTEE and CONFIG_AMD_PMF in the /boot/config file.
> >
> > Am I missing something ?
> > Maybe the package was not rebuilt with this new configuration ?
>
> We are just lacking a configuration symbol. Diederik, starting with
> linux 6.8 AMD PMF requires TEE. Do you want me to send a MR?
As Vincent remarked, that means the bug is not fixed, so reopening it.
@Vincent: Can you add a Closes: #1063161 to ``debian/changelog``?
And while you're at it, add the following line to the commit message?
Fixes: 7399dff4b4af ("[amd64] drivers/platform/x86/amd/pmf: Enable AMD_PMF as
module")
> Thanks for the report,
Indeed. Sorry for missing that.
Cheers,
Diederik
signature.asc
Description: This is a digitally signed message part.
Bug#1063161:
On Thu, 23 May 2024 18:08:18 +0200 Diederik de Haas wrote: > On Thursday, 23 May 2024 17:33:47 CEST Vincent Blut wrote: > > We are just lacking a configuration symbol. Diederik, starting with > > linux 6.8 AMD PMF requires TEE. Do you want me to send a MR? > > Sure. > Bit surprised it wouldn't be automatically selected though. Dear maintainers, I can confirm that a locally built kernel that includes the patch shows no regression on my Framework laptop. I fully understand that we're in the post-Jia Tan world and pushing for merging a change is not appropriate, but I've noticed a new kernel release happened on unstable without merging the mentioned MR [0] which is still open, and I wanted to know if something is blocking it or maybe it just flew under the radar. Best regards, Daniele Gobbetti [0] https://salsa.debian.org/kernel-team/linux/-/merge_requests/1088 --
Bug#1063161:
On Thursday, 23 May 2024 17:33:47 CEST Vincent Blut wrote: > We are just lacking a configuration symbol. Diederik, starting with > linux 6.8 AMD PMF requires TEE. Do you want me to send a MR? Sure. Bit surprised it wouldn't be automatically selected though. signature.asc Description: This is a digitally signed message part.
Bug#1063161:
Hi Nathan, Le 2024-05-23 17:12, Nathan MALO a écrit : > Hello ! > > Thank you very much for enabling those two features in the kernel. > Your work is much appreciated ! > > Maybe I am missing something but I've download the 6.8.9-1 package from > here > http://ftp.us.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.8.9-amd64_6.8.9-1_amd64.deb > and while fiddling with it, I was not able to find the keys CONFIG_AMDTEE > and CONFIG_AMD_PMF in the /boot/config file. > > I was able to see those two keys activated in salsa : > https://salsa.debian.org/kernel-team/linux/-/blob/sid/debian/config/amd64/config?ref_type=heads > > Am I missing something ? > Maybe the package was not rebuilt with this new configuration ? We are just lacking a configuration symbol. Diederik, starting with linux 6.8 AMD PMF requires TEE. Do you want me to send a MR? > Thanks for your help ! Thanks for the report, Vincent signature.asc Description: PGP signature
Bug#1063161:
Hello ! Thank you very much for enabling those two features in the kernel. Your work is much appreciated ! Maybe I am missing something but I've download the 6.8.9-1 package from here http://ftp.us.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.8.9-amd64_6.8.9-1_amd64.deb and while fiddling with it, I was not able to find the keys CONFIG_AMDTEE and CONFIG_AMD_PMF in the /boot/config file. I was able to see those two keys activated in salsa : https://salsa.debian.org/kernel-team/linux/-/blob/sid/debian/config/amd64/config?ref_type=heads Am I missing something ? Maybe the package was not rebuilt with this new configuration ? Thanks for your help !
Bug#1063161: Processed: Re: Bug#1063161: Add amd_pmf module
Yes, please set CONFIG_AMDTEE and CONFIG_AMD_PMF both. The firmware is optional, certain functions for amd-pmf will be non-functional without it.
Bug#1063161: Add amd_pmf module
Control: tag -1 moreinfo On Monday, 5 February 2024 15:47:08 CET Nate wrote: > Would be possible to compile it as a module in the kernel ? > There may be technical limitations that I am not aware of. The kernel module depends on AMDTEE (Trusted Execution Environment) and I'm not sure if you'd need amdtee firmware for that. In https://bugs.debian.org/1062678 I requested that, but that is about AMD PMF TA (Trusted Application) and that *could* be something else. signature.asc Description: This is a digitally signed message part.
Bug#1063161: Add amd_pmf module
Package: linux-image-amd64 Version: 6.5.10-1~bpo12+1 Severity: normal X-Debbugs-Cc: nathan.m...@gmail.com Hi, AMD has introduced a feature called Power Management Framework. See here for more info: https://www.phoronix.com/news/AMD-PMF-Linux-Driver It seems that this module is not included in the Debian Linux Kernel. I have found '# CONFIG_AMD_PMF is not set' for the following versions : - linux-image-6.1.0-11-amd64_6.1.38-4 - linux-image-6.5.0-0.deb12.4-amd64_6.5.10-1~bpo12+1 - linux-image-6.6.13-amd64_6.6.13-1 Enabling this would offer better battery life for AMD Laptops (like my Framework 13). A bit of context: The power-profiles-daemon software gained recently support for amd-pstate driver, and also gained support to handle simultaneously cpu driver (amd-pstate) and platform driver (amd-pmf). (https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/merge_requests/127). It seems that the power-profiles-daemon in unstable do not include the commit that allows to handle both drivers at the same time. So I've installed the power-profile-daemons for jammy from this Ubuntu PPA (https://launchpad.net/~superm1/+archive/ubuntu/ppd/+packages). And when I list the existing power-profiles I get the following: user@machine:> sudo powerprofilesctl performance: CpuDriver: amd_pstate Degraded: no * balanced: CpuDriver: amd_pstate PlatformDriver: placeholder power-saver: CpuDriver: amd_pstate PlatformDriver: placeholder This (PlatformDriver: placeholder) indicates that the AMD_PMF module is not included in the kernel. Would be possible to compile it as a module in the kernel ? There may be technical limitations that I am not aware of. Thank your for your time, Best regards, Nate -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-amd64 depends on: ii linux-image-6.5.0-0.deb12.4-amd64 6.5.10-1~bpo12+1 linux-image-amd64 recommends no packages. linux-image-amd64 suggests no packages. -- no debconf information
