add p50 and p51
This commit is contained in:
Chris McDonough
parent
3bf48d3587
commit
f90db4cb9e
|
|
@ -124,6 +124,8 @@ See code for all available configurations.
|
|||
| [Lenovo ThinkPad P1 Gen 3](lenovo/thinkpad/p1/3th-gen) | `<nixos-hardware/lenovo/thinkpad/p1/3th-gen>` |
|
||||
| [Lenovo ThinkPad P14s AMD Gen 2](lenovo/thinkpad/p14s/amd/gen2) | `<nixos-hardware/lenovo/thinkpad/p14s/amd/gen2>` |
|
||||
| [Lenovo ThinkPad P1](thinkpad/p1) | `<nixos-hardware/lenovo/thinkpad/p1>` |
|
||||
| [Lenovo ThinkPad P50](lenovo/thinkpad/p50) | `<nixos-hardware/lenovo/thinkpad/p50>` |
|
||||
| [Lenovo ThinkPad P51](lenovo/thinkpad/p51) | `<nixos-hardware/lenovo/thinkpad/p51>` |
|
||||
| [Lenovo ThinkPad P53](lenovo/thinkpad/p53) | `<nixos-hardware/lenovo/thinkpad/p53>` |
|
||||
| [Lenovo ThinkPad T14 AMD Gen 1](lenovo/thinkpad/t14/amd/gen1) | `<nixos-hardware/lenovo/thinkpad/t14/amd/gen1>` |
|
||||
| [Lenovo ThinkPad T14 AMD Gen 2](lenovo/thinkpad/t14/amd/gen2) | `<nixos-hardware/lenovo/thinkpad/t14/amd/gen2>` |
|
||||
|
|
|
|||
|
|
@ -0,0 +1,100 @@
|
|||
{ lib, ... }:
|
||||
{
|
||||
imports = [
|
||||
../../../common/gpu/nvidia.nix
|
||||
../../../common/cpu/intel
|
||||
../../../common/pc/laptop/acpi_call.nix
|
||||
../.
|
||||
];
|
||||
|
||||
hardware = {
|
||||
nvidia = {
|
||||
prime = {
|
||||
intelBusId = "PCI:0:2:0";
|
||||
nvidiaBusId = "PCI:1:0:0";
|
||||
};
|
||||
};
|
||||
|
||||
# is this too much? It's convenient for Steam.
|
||||
opengl = {
|
||||
driSupport = lib.mkDefault true;
|
||||
driSupport32Bit = lib.mkDefault true;
|
||||
};
|
||||
};
|
||||
|
||||
# Sleep
|
||||
# -----
|
||||
#
|
||||
# The system will not resume from sleep properly while on battery power in
|
||||
# either offload mode or sync mode. When it tries to resume, it gets to a
|
||||
# state with a cursor in the top left hand side of the panel, the power LED
|
||||
# goes from flashing to solid, and thereafter cannot be interacted with (even
|
||||
# over SSH) and must be power cycled forcefully. Sometimes it doesn't even
|
||||
# finish going to sleep before this behavior kicks in.
|
||||
#
|
||||
# When on AC, the machine either wakes up from sleep before being asked to
|
||||
# (or maybe never gets to sleep state), or it goes into a sleep state and it
|
||||
# appears consistently resume properly when it does.
|
||||
#
|
||||
# But the machine actually sleeps and resumes reliably when tlp is disabled
|
||||
# fully or partially. Disabling RUNTIME_PM and AHCI_RUNTIME_PM appears to be
|
||||
# enough to allow it to work when tlp is active. I couldn't figure out a
|
||||
# more granular way to get it working, despite trying to do a per-device
|
||||
# binary search via powertop.
|
||||
#
|
||||
# My personal configuration to make this work looks like this:
|
||||
#
|
||||
# {config, lib, ...}:
|
||||
#
|
||||
# {
|
||||
# services.tlp = {
|
||||
# settings = {
|
||||
# # DISK_DEVICES must be specified for AHCI_RUNTIME_PM settings to work right.
|
||||
# DISK_DEVICES = "nvme0n1 nvme1n1 sda sdb";
|
||||
#
|
||||
# # with AHCI_RUNTIME_PM_ON_AC/BAT set to defaults in battery mode, P51
|
||||
# # can't resume from sleep and P50 can't go to sleep.
|
||||
# AHCI_RUNTIME_PM_ON_AC = "on";
|
||||
# AHCI_RUNTIME_PM_ON_BAT = "on";
|
||||
#
|
||||
# # with RUNTIME_PM_ON_BAT/AC set to defaults, P50/P51 can't go to sleep
|
||||
# RUNTIME_PM_ON_AC = "on";
|
||||
# RUNTIME_PM_ON_BAT = "on";
|
||||
# };
|
||||
# };
|
||||
# }
|
||||
#
|
||||
# I'm thinking this is too aggressive to put into shared config, and folks may
|
||||
# be concerned with the hit on battery life.
|
||||
#
|
||||
# throttled vs. thermald
|
||||
# -----------------------
|
||||
#
|
||||
# NB: the p53 profile currently uses throttled to prevent too-eager CPU
|
||||
# throttling. I understand throttled to have been a workaround solution at
|
||||
# the time the p53 profile was created (throttled's original name was
|
||||
# "lenovo_fix"). thermald would have been preferred if it worked at the
|
||||
# time.
|
||||
#
|
||||
# I read
|
||||
# https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon_(Gen_6)#Power_management.2FThrottling_issues
|
||||
# as saying that thermald is fixed under the circumstance that led to the
|
||||
# development of throttled given version 5.12+ of the kernel combined
|
||||
# with version 2.4.3+ of thermald. At the time of this writing, the
|
||||
# stable NixOS kernel is 5.15 and 2.4.9 of thermald.
|
||||
#
|
||||
# In the meantime, I also ran the "s-tui" program which can stress test the
|
||||
# system, while eyeing up the core temps and CPU frequency under three
|
||||
# scenarios: under thermald, under throttled, and with neither. None of the
|
||||
# scenarios seem to have massively improved fan behavior, core temps, or
|
||||
# average CPU frequency than another. The highest core temp always seems to
|
||||
# hover around 90 degrees C, the lowest CPU Ghz around 3.4 on a 3.8Ghz machine.
|
||||
#
|
||||
# I ended up choosing throttled because subjectively, the fans seem quieter
|
||||
# when it's stressed and it allows the average temps to get a degree or two
|
||||
# higher when running throttled than when running in the other two scenarios,
|
||||
# but still substantially under critical temp.
|
||||
|
||||
services.throttled.enable = lib.mkDefault true;
|
||||
|
||||
}
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
{ lib, ... }:
|
||||
{
|
||||
imports = [
|
||||
../../../common/gpu/nvidia.nix
|
||||
../../../common/cpu/intel
|
||||
../../../common/cpu/intel/kaby-lake
|
||||
../../../common/pc/laptop/acpi_call.nix
|
||||
../.
|
||||
];
|
||||
|
||||
hardware = {
|
||||
nvidia = {
|
||||
prime = {
|
||||
intelBusId = "PCI:0:2:0";
|
||||
nvidiaBusId = "PCI:1:0:0";
|
||||
};
|
||||
};
|
||||
|
||||
# is this too much? It's convenient for Steam.
|
||||
opengl = {
|
||||
driSupport = lib.mkDefault true;
|
||||
driSupport32Bit = lib.mkDefault true;
|
||||
};
|
||||
};
|
||||
|
||||
# Sleep
|
||||
# -----
|
||||
#
|
||||
# The system will not resume from sleep properly while on battery power in
|
||||
# either offload mode or sync mode. When it tries to resume, it gets to a
|
||||
# state with a cursor in the top left hand side of the panel, the power LED
|
||||
# goes from flashing to solid, and thereafter cannot be interacted with (even
|
||||
# over SSH) and must be power cycled forcefully. Sometimes it doesn't even
|
||||
# finish going to sleep before this behavior kicks in.
|
||||
#
|
||||
# When on AC, the machine either wakes up from sleep before being asked to
|
||||
# (or maybe never gets to sleep state), or it goes into a sleep state and it
|
||||
# appears consistently resume properly when it does.
|
||||
#
|
||||
# But the machine actually sleeps and resumes reliably when tlp is disabled
|
||||
# fully or partially. Disabling RUNTIME_PM and AHCI_RUNTIME_PM appears to be
|
||||
# enough to allow it to work when tlp is active. I couldn't figure out a
|
||||
# more granular way to get it working, despite trying to do a per-device
|
||||
# binary search via powertop.
|
||||
#
|
||||
# My personal configuration to make sleep work looks like this:
|
||||
#
|
||||
# {config, lib, ...}:
|
||||
#
|
||||
# {
|
||||
# services.tlp = {
|
||||
# settings = {
|
||||
# # DISK_DEVICES must be specified for AHCI_RUNTIME_PM settings to work right.
|
||||
# DISK_DEVICES = "nvme0n1 nvme1n1 sda sdb";
|
||||
#
|
||||
# # with AHCI_RUNTIME_PM_ON_AC/BAT set to defaults in battery mode, P51
|
||||
# # can't resume from sleep and P50 can't go to sleep.
|
||||
# AHCI_RUNTIME_PM_ON_AC = "on";
|
||||
# AHCI_RUNTIME_PM_ON_BAT = "on";
|
||||
#
|
||||
# # with RUNTIME_PM_ON_BAT/AC set to defaults, P50/P51 can't go to sleep
|
||||
# RUNTIME_PM_ON_AC = "on";
|
||||
# RUNTIME_PM_ON_BAT = "on";
|
||||
# };
|
||||
# };
|
||||
# }
|
||||
#
|
||||
# I'm thinking this is too aggressive to put into shared config, and folks may
|
||||
# be concerned with the hit on battery life.
|
||||
#
|
||||
# throttled vs. thermald
|
||||
# -----------------------
|
||||
#
|
||||
# NB: the p53 profile currently uses throttled to prevent too-eager CPU
|
||||
# throttling. I understand throttled to have been a workaround solution at
|
||||
# the time the p53 profile was created (throttled's original name was
|
||||
# "lenovo_fix"). thermald would have been preferred if it worked at the
|
||||
# time.
|
||||
#
|
||||
# I read
|
||||
# https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon_(Gen_6)#Power_management.2FThrottling_issues
|
||||
# as saying that thermald is fixed under the circumstance that led to the
|
||||
# development of throttled given version 5.12+ of the kernel combined
|
||||
# with version 2.4.3+ of thermald. At the time of this writing, the
|
||||
# stable NixOS kernel is 5.15 and 2.4.9 of thermald.
|
||||
#
|
||||
# In the meantime, I also ran the "s-tui" program which can stress test the
|
||||
# system, while eyeing up the core temps and CPU frequency under three
|
||||
# scenarios: under thermald, under throttled, and with neither. None of the
|
||||
# scenarios seem to have massively improved fan behavior, core temps, or
|
||||
# average CPU frequency than another. The highest core temp always seems to
|
||||
# hover around 90 degrees C, the lowest CPU Ghz around 3.4 on a 3.8Ghz machine.
|
||||
#
|
||||
# I ended up choosing throttled because subjectively, the fans seem quieter
|
||||
# when it's stressed and it allows the average temps to get a degree or two
|
||||
# higher when running throttled than when running in the other two scenarios,
|
||||
# but still substantially under critical temp.
|
||||
|
||||
services.throttled.enable = lib.mkDefault true;
|
||||
|
||||
}
|
||||
Loading…
Reference in New Issue