Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #81765 > unrolled thread

Bug#1063161: Add amd_pmf module

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1063161: Add amd_pmf module Nate <nathan.malo@gmail.com> - 2024-02-05 16:00 +0100
    Processed: Re: Bug#1063161: Add amd_pmf module "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-02-08 00:20 +0100
    Bug#1063161: Add amd_pmf module Diederik de Haas <didi.debian@cknow.org> - 2024-02-08 00:20 +0100
    Bug#1063161: marked as done (Add amd_pmf module) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-05-16 18:10 +0200
    Bug#1063161:  Diederik de Haas <didi.debian@cknow.org> - 2024-05-23 18:20 +0200
      Bug#1063161:  Daniele Gobbetti <daniele-deb@gobbetti.name> - 2024-06-06 11:10 +0200
    Bug#1063161:  Nathan MALO <nathan.malo@gmail.com> - 2024-05-23 17:20 +0200
      Bug#1063161:  Vincent Blut <vincent.debian@free.fr> - 2024-05-23 17:40 +0200
        Bug#1063161:  Diederik de Haas <didi.debian@cknow.org> - 2024-06-25 20:20 +0200
    Processed: Re: Bug#1063161: "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-06-25 20:20 +0200
    Bug#1063161: marked as done (Add amd_pmf module) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-06-28 00:20 +0200
    Bug#1063161: Add amd_pmf module Diederik de Haas <didi.debian@cknow.org> - 2024-06-28 17:50 +0200
    Bug#1063161: Add amd_pmf module Diederik de Haas <didi.debian@cknow.org> - 2024-06-28 18:30 +0200
    Bug#1063161: Add amd_pmf module Diederik de Haas <didi.debian@cknow.org> - 2024-06-28 19:10 +0200
    Bug#1063161: Add amd_pmf module Diederik de Haas <didi.debian@cknow.org> - 2024-06-28 19:50 +0200
    Bug#1063161: Add amd_pmf module Diederik de Haas <didi.debian@cknow.org> - 2024-06-28 20:00 +0200
      Bug#1063161: Add amd_pmf module Nathan MALO <nathan.malo@gmail.com> - 2024-07-01 17:30 +0200
        Bug#1063161: Add amd_pmf module Diederik de Haas <didi.debian@cknow.org> - 2024-07-01 17:40 +0200

#81765 — Bug#1063161: Add amd_pmf module

Package: linux-image-amd64
Version: 6.5.10-1~bpo12+1
Severity: normal
X-Debbugs-Cc: nathan.malo@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

[toc] | [next] | [standalone]

#81783 — Processed: Re: Bug#1063161: Add amd_pmf module

Processing control commands:

> tag -1 moreinfo
Bug #1063161 [src:linux] Add amd_pmf module
Added tag(s) moreinfo.

-- 
1063161: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063161
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#81784

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#82438 — Bug#1063161: marked as done (Add amd_pmf module)

[Multipart message — attachments visible in raw view] — view raw

Your message dated Thu, 16 May 2024 16:00:12 +0000
with message-id <E1s7dWe-002JdC-1a@fasolo.debian.org>
and subject line Bug#1063161: fixed in linux 6.8.9-1
has caused the Debian Bug report #1063161,
regarding Add amd_pmf module
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1063161: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063161
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#82554 — Bug#1063161:

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#82683 — Bug#1063161:

On Thu, 23 May 2024 18:08:18 +0200 Diederik de Haas <didi.debian@cknow.org> 
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

--

[toc] | [prev] | [next] | [standalone]

#82556 — Bug#1063161:

[Multipart message — attachments visible in raw view] — view raw

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 !

[toc] | [prev] | [next] | [standalone]

#82558 — Bug#1063161:

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#82834 — Bug#1063161:

[Multipart message — attachments visible in raw view] — view raw

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
> > <URL> 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

[toc] | [prev] | [next] | [standalone]

#82833 — Processed: Re: Bug#1063161:

Processing control commands:

> reopen -1
Bug #1063161 {Done: Ben Hutchings <benh@debian.org>} [src:linux] Add amd_pmf module
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions linux/6.8.9-1.
> found -1 6.8.9-1
Bug #1063161 [src:linux] Add amd_pmf module
Marked as found in versions linux/6.8.9-1.
> found -1 6.9.2-1~exp1
Bug #1063161 [src:linux] Add amd_pmf module
Marked as found in versions linux/6.9.2-1~exp1.

-- 
1063161: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063161
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#82860 — Bug#1063161: marked as done (Add amd_pmf module)

[Multipart message — attachments visible in raw view] — view raw

Your message dated Thu, 27 Jun 2024 22:10:11 +0000
with message-id <E1sMxJj-000sYp-DQ@fasolo.debian.org>
and subject line Bug#1063161: fixed in linux 6.9.7-1
has caused the Debian Bug report #1063161,
regarding Add amd_pmf module
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1063161: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063161
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#82871

[Multipart message — attachments visible in raw view] — view raw

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_pmf                61440  0
amdtee                 28672  0
amd_sfh                49152  1 amd_pmf
tee                    45056  2 amd_pmf,amdtee
amdgpu              12845056  0
amd_atl                40960  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_helper    12288  1 amdgpu
drm_display_helper    262144  1 amdgpu
drm_ttm_helper         12288  1 amdgpu
ttm                   102400  2 amdgpu,drm_ttm_helper
drm_kms_helper        249856  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

[toc] | [prev] | [next] | [standalone]

#82872

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#82874

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#82875

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#82876

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#82906

[Multipart message — attachments visible in raw view] — view raw

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 0000: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_atl                40960  1
amd_pmf                61440  0
amdtee                 28672  0
amd_sfh                49152  1 amd_pmf
amd_pmc                40960  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 <didi.debian@cknow.org> 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

[toc] | [prev] | [next] | [standalone]

#82907

[Multipart message — attachments visible in raw view] — view raw

On Monday, 1 July 2024 17:17:46 CEST Nathan MALO wrote:
> It seems to me that it is working as expected !

Awesome :-)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web