Using Fedora 44, with bios 4.04 on the 7840hs and the RX7700s.
I used to be able to adjust the dGPU TDP between 100w and 120w. I hadn’t checked lately - until last night when I wanted to mess with my eGPU in lact.
I noticed that I was no longer able to set the TDP past 100w.
Is anyone else seeing this? Just me?
Here is the gitlab issue I I filed for this:
opened 04:19PM - 12 Jul 26 UTC
System Model: Framework Laptop 16 (AMD Ryzen™ 7040 Series)
BIOS Version: 4.04 (s… table)
CPU: AMD Ryzen 7 7840HS
GPU Module: AMD Radeon RX 7700S
OS: Fedora Linux 44
Kernels tested (both reproduce):
• 7.1.3-cachyos1.fc44.x86_64
• 7.0.14-201.fc44.x86_64
Describe the bug
On BIOS 4.04, the RX 7700S power cap is completely locked — power1_cap, power1_cap_max, power1_cap_min, and power1_cap_default are all identical at 100W, with zero range:
```
power1_cap: 100000000
power1_cap_max: 100000000
power1_cap_min: 100000000
power1_cap_default: 100000000
```
Any attempt to write a value other than exactly 100W fails:
```
$ echo 120000000 | sudo tee /sys/class/hwmon/hwmon9/power1_cap
sh: echo: write error: Invalid argument
```
This was working on a previous BIOS version — setting the power cap up to 120W (AMD's rated max for this GPU) was possible via LACT. The regression appeared after a BIOS update.
Root Cause (Diagnosed)
After investigation, the root cause is that PP_OD_FEATURE_PPT_BIT is not set in the VBIOS power play table, meaning the amdgpu driver sees no power OD range and exposes a zero-width [100W, 100W] cap.
Evidence:
1. No OD/PPT entries exist in debugfs for the dGPU:
```
$ sudo find /sys/kernel/debug/dri/0000:03:00.0/ | grep -i "od\|overdrive\|ppt"
# only returns: odm_combine_segments (display pipeline, unrelated)
```
2. pp_od_clk_voltage shows clock OD but no OD_POWER section:
```
OD_SCLK:
0: 800Mhz
1: 2700Mhz
OD_RANGE:
SCLK: 800Mhz 2700Mhz
# no OD_PPT / OD_POWER entries
```
3. The upstream kernel fix for work_items/5227 (drm/amd/pm: fix smu13 power limit default/cap calculation, commit 1eaf26db) calculates max = SocketPowerLimitAc × (100 + od_percent_upper) / 100. Without PP_OD_FEATURE_PPT_BIT, od_percent_upper = 0 and max = 100W regardless of kernel version.
Expected Behavior
power1_cap_max should be 120000000 (120W), matching AMD's rated TGP range for the RX 7700S. The VBIOS PP table should have PP_OD_FEATURE_PPT_BIT set with od_percent_upper = 20 (giving the 20% headroom = 120W), as it apparently was in earlier BIOS versions.
Steps to Reproduce
1. Boot Framework 16 with RX 7700S module on BIOS 4.04
2. Run on any recent Linux kernel (tested 7.0.14 Fedora stable and 7.1.3 CachyOS)
3. Ensure amdgpu.ppfeaturemask=0xffffffff is set
4. Check: for f in power1_cap power1_cap_max power1_cap_min power1_cap_default; do echo "$f: $(cat /sys/class/hwmon/hwmon10/$f)"; done
5. All four values will be 100000000
Additional Context
• Reproducible on two different kernel versions
• ppfeaturemask=0xffffffff is confirmed active: cat /sys/module/amdgpu/parameters/ppfeaturemask → 0xffffffff
• The amdgpu SMU feature mask is 0x0001a33dfbffffff — OD features appear present in the SMU but the PP table doesn't expose power OD
• LACT daemon logs confirm the driver is clamping any non-100W value: Power cap 110W was outside of [100W, 100W], clamped to 100W
• This is distinct from issue #27 (power delivery under load) — this is specifically the PP table not exposing the power OD range at all
tade0
July 14, 2026, 9:29am
2
I recall being able to do it running Ubuntu, but it had no effect on actual power consumption.
1 Like
It definitely worked for me when it was set. Many times I would pull a consistent 115-118w.
Now.. how much it helped is up for debate. But the ultimate issue is the loss of the feature.
I wish I could adjust it below 100W so I could manually set targets for 60W and 80W as a means of avoiding battery drain. I can approximate this by using the balanced profile, but it is not a perfect match for my goals.
I think you can:amdgpu.ignore_min_pcap=1 add this to your kernel cmdline
That being said, not sure if its only in cachyos - or hit other kernels as well.
Oooooo, that’s very interesting. Thanks, I’ll check it out!
Might not work. If you check the bug i have created - seems framework locked down the vbios
my newest comment comes from a review of the vbios after I dumped it to a rom