Smooth fan speed changes

[curiousercreative]

I wrote this for my new galp5 to address a common complaint of the fans jumping from 0 to 100 and back abruptly. The configuration value of SMOOTH_FANS_UP and SMOOTH_FANS_DOWN sets the number of fan speed event loops that a 0 - 100 speed ramp should be smoothed across. Effectively, this determines the maximum fan speed adjustment for each event loop to prevent audible stepping. A high number yields a slower and smoother ramp while a low number yields a fast response.

This PR adds support for new build flags:

• SMOOTH_FANS boolean, defaults to 1 for enabled, set to 0 for disabling
• SMOOTH_FANS_UP sets the fan smoothing (as described above) for the fan speed increases. Defaults 40, about 11 seconds
• SMOOTH_FANS_DOWN sets the fan smoothing (as described above) for the fan speed decreases. Defaults to 100, about 25 seconds
• SMOOTH_FANS_MIN sets the minimum fan speed (in percent) that should be smoothed. Defaults to 0 (smooth all fan speed changes), but set to 25 for oryp6/7

Attempts to fix system76/firmware-open#149, see prior PR for more history: #139

[curiousercreative]

@jackpot51 new PR for fan smoothing here. By default this will:

• interpolate fan speed from curve points
• shorter interval for fan speed updates
• smooth a fan speed change of 0 (off) to 100 (full blast) over (approximately) a 10 second window. For my galp5, that translates to about 600RPM change per second or 150RPM per step (4 steps per second)

With build flag SMOOTH_FANS=0 disables and preserves all current fan speed behavior.

[curiousercreative]

I'm running a build from this on a dGPU galp5 and all is working as expected.

[MilesBHuff]

@curiousercreative This is still breaking CPU temperature detection on the oryp7:

GPU temperature detection works at first, but inevitably goes to 0°C after a few minutes -- same as before. EDIT: Actually, I think this only happens during and right after I've reflashed and am waiting for a reboot.

[curiousercreative]

@MilesBHuff I only have a galp5 and don't observe such behavior. Hopefully S76 can reproduce and debug, but you may be able to help with the following:

• try running this script which outputs CSV that you can share
• try running ./scripts/ectool.sh console from your ec repo folder and that should output the exact values the EC is reading for CPU/PECI and GPU temperature readings as well as the fan speeds it sets in response

[MilesBHuff]

Without #190: (code)

• power.sh: 00:16:00 0.00 9.9 45.0 90.0 59.0 92 100 11.9 42 4452 4594 4589 4607 4584 4581 4600 4189 3246 3288 4472 4313 4664 46234593 4527
• ectool.sh: DGPU temp=44 PECI temp=3185 BAT 12805 mV 0 mA

With #190: (code)

• power.sh: 00:24:30 0.00 14.2 45.0 90.0 83.0 92 100 12.2 42 4669 4425 4488 4457 4383 4524 4514 4665 4272 3759 4678 4515 4514 45164452 4499
• ectool.sh: DGPU temp=42 PECI temp=48 BAT 12804 mV 0 mA

It looks like PECI is reporting in the 40s instead of the 3000s now. Which is honestly probably more correct. I'm guessing system76-acpi-dkms must be expecting something in the 3000s, though, because what it's sending to my KDE monitors is 0°C.
Changing the monitors to use raw data from the BIOS instead of from system76-acpi seems to work fine. So merging #190 may mean an automatic bug in https://github.com/pop-os/system76-acpi-dkms.

The fan smoothing definitely works, though -- so that's good at least! :)

[curiousercreative]

@MilesBHuff you know, I actually observe the same behavior as you, but I am able to obtain the PECI temperature via coretemp rather than system76_acpi. In this screenshot, the lower "CPU temp" that reads 0C is from acpi and notably, there's an acpi reading for GPU temperature as well, but it's always been 0C and I've kept it hidden. I'm using a pSensor Ubuntu .deb from the pop store FWIW.

[curiousercreative]

@MilesBHuff I might play with this in a day or two, but this is my guess as to where we need to update the interpretation of sensor readings: https://github.com/pop-os/system76-acpi-dkms/blob/master/system76_acpi.c#L503-L542

[MilesBHuff]

@curiousercreative

I am able to obtain the PECI temperature via coretemp rather than system76_acpi.

Yep! That's what I'm using right now, as well. Fun fact: coretemp has always been different from system76_acpi, so this may be a long-standing bug that was just exacerbated by this PR.

[jackpot51]

I am looking into this. If I find fixes for what @MilesBHuff found can I push them to your PR's branch directly?

[curiousercreative]

@jackpot51 of course, edit freely for any reason :)

[jackpot51]

@curiousercreative it should be a pretty simple fix, modify this line to not shift anymore: https://github.com/system76/ec/blob/master/src/board/system76/common/acpi.c#L97

[curiousercreative]

@jackpot51 brilliant, works like a charm! My GPU temp as reported by ACPI is still 0C if I'm in "compute" graphics mode, but otherwise did the trick! Also rebased with the latest master.

[MilesBHuff]

@curiousercreative @jackpot51 Confirmed fixed on my oryp7! 🎉

[MilesBHuff]

@curiousercreative Confirmed GPU temperature is broken with compute graphics:

However, this could be entirely unrelated to this PR. We need to see whether this happens with what's in master.

[curiousercreative]

Behavior is the same previously, not a regression.

[MilesBHuff]

@curiousercreative

Behavior is the same previously, not a regression

Oh, that's great news! I was literally just about to hit "enter" to flash my EC with the old code to compare.

[curiousercreative]

You're welcome to confirm, I think there is an issue open on firmware-open repo.

[MilesBHuff]

I am unable to find such an issue there, despite looking at all open or closed issues with "GPU" or "compute" in their name in https://github.com/system76/firmware-open. A websearch for "system76 github gpu temperature is 0 with compute mode" also turned up nothing.
Can you create an issue there, and link it?

[jackpot51]

system76/firmware-open#189

[MilesBHuff]

Thanks, @jackpot51. I didn't think that was the issue, since there was no mention of "compute" graphics. I'll go ahead and post my screenshot there.

[curiousercreative]

@crawfxrd sorry, I rebased on master and it dismissed your review :/ I'll let you all rebase on master or merge master in going forward I think.

[MilesBHuff]

Any updates? :)

[MilesBHuff]

(dummy comment so people can 🎉 react -- the code is merged! 😄)

[MilesBHuff]

Do you guys have an rough guess of when this might be released in an official BIOS update?

[crawfxrd]

After the gaze16 work is done.

[jackpot51]

We will likely release production firmware for these new products including these changes at the same time we release these changes for prior products, to simplify the updates and keep all products in sync.

[ZeddieXX]

After the gaze16 work is done.

We will likely release production firmware for these new products including these changes at the same time we release these changes for prior products, to simplify the updates and keep all products in sync.

I see the gaze16 is now available to configure. Does this mean the firmware will be released soon for all other laptops? Would love to see this in the production firmware as an official update.

Thanks!

[ZeddieXX]

After the gaze16 work is done.
We will likely release production firmware for these new products including these changes at the same time we release these changes for prior products, to simplify the updates and keep all products in sync.

I see the gaze16 is now available to configure. Does this mean the firmware will be released soon for all other laptops? Would love to see this in the production firmware as an official update.

Thanks!

@jackpot51 is the gaze16 already out? If so, when is the new firmware with these merges be officially released and sent out as an update via the built-in firmware updater in Pop!_OS?

[jacobgkau]

@ZeddieXX You will receive a notification when the firmware is released. Testing is still ongoing, there is no guaranteed timeline.

If you don't want to wait, you are welcome to flash updated firmware yourself by installing Rust nightly and then running these commands:

git clone https://github.com/system76/firmware-open
cd firmware-open
./scripts/update.sh
./scripts/deps.sh
./scripts/build.sh <your-model>
./scripts/flash.sh <your-model>

[ZeddieXX]

@ZeddieXX You will receive a notification when the firmware is released. Testing is still ongoing, there is no guaranteed timeline.

If you don't want to wait, you are welcome to flash updated firmware yourself by installing Rust nightly and then running these commands:

git clone https://github.com/system76/firmware-open
cd firmware-open
./scripts/update.sh
./scripts/deps.sh
./scripts/build.sh <your-model>
./scripts/flash.sh <your-model>

Thank you for this. I am not an expert at this, being a Windows user. The readme got to the build, but not how to flash. And even then I needed rust installed apparently. This is why I was asking about the released version, but if I can download, compile, and flash it myself, I'll do it.

When the official firmware comes out, will I still get notifications since I'll be using a non-release firmware?

[jacobgkau]

When the official firmware comes out, will I still get notifications since I'll be using a non-release firmware?

Once you flash a custom version, you'll actually start receiving notifications immediately, as the released version would be an available "update" from your custom version as far as the firmware manager is concerned. You can switch back to released firmware at any time by following the normal update process, before or after the new firmware is released. (You will see the new version show up in the firmware manager's changelog once it's released.)

I still don't have an estimate on the new firmware release, but there was a model-specific issue (unrelated to the fan changes) that was discovered during testing, which is on the tail end of being resolved.

[ZeddieXX]

When the official firmware comes out, will I still get notifications since I'll be using a non-release firmware?

Once you flash a custom version, you'll actually start receiving notifications immediately, as the released version would be an available "update" from your custom version as far as the firmware manager is concerned. You can switch back to released firmware at any time by following the normal update process, before or after the new firmware is released. (You will see the new version show up in the firmware manager's changelog once it's released.)

I still don't have an estimate on the new firmware release, but there was a model-specific issue (unrelated to the fan changes) that was discovered during testing, which is on the tail end of being resolved.

Got it flashed! Immediate difference in fan and noise, so thank you for this!