Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

apple/macbook-pro/12-1: PM: set cpuFreqGovernor and power Up/Down commands #214

Merged
merged 2 commits into from Dec 1, 2020
Merged

apple/macbook-pro/12-1: PM: set cpuFreqGovernor and power Up/Down commands #214

merged 2 commits into from Dec 1, 2020

Conversation

ivankovnatsky
Copy link

@ivankovnatsky ivankovnatsky commented Nov 26, 2020

fixes #211.
fixes #210.

Added default CPU governor "conservative" to enable gradually increasing/decreasing CPU freq, rather than using "powersave", which would keep CPU freq at 0.8Ghz.

Added power Up/Down PM commands which will unload and load brcmfmac on state change. This is not elegant way, to say the least.

@ivankovnatsky ivankovnatsky changed the title apple/macbook-pro/12-1: PM: unload brcmfmac with powerDownCommands apple/macbook-pro/12-1: PM: set cpuFreqGovernor and power Up/Down commands Nov 26, 2020
@ivankovnatsky ivankovnatsky marked this pull request as ready for review November 26, 2020 12:21
# enable gradually increasing/decreasing CPU freq, rather than using "powersave", which would keep CPU freq at 0.8Ghz.
cpuFreqGovernor = lib.mkDefault "conservative";

powerUpCommands = ''${pkgs.kmod}/bin/modprobe brcmfmac'';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this both required for suspend and hibernate?

Commands executed when the machine powers down. That is, they're executed both when the system shuts down and when it goes to suspend or hibernation.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for me it's required. wpa_supplicant stops on suspend too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean does brcmfmac also breaks suspend or just hibernate?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, yeah, it does not break resume after suspend, so only required for hibernate.

Copy link
Member

@Mic92 Mic92 Nov 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. So it should be only unloaded for hypernate-sleep.target and hybrid-sleep.target? https://github.com/NixOS/nixpkgs/blob/950bb1452032e8e839ddb2af0dc85350c73025a6/nixos/modules/config/power-management.nix#L92

That would require two services, but systemd's script field should keep the boiler code needed for this low.

Copy link
Member

@Mic92 Mic92 Nov 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just create new systemd services:

    systemd.services.post-resume-brcmfmac = { 
        description = "Post-Resume Actions";
        after = [ "hibernate.target" "hybrid-sleep.target" ];
        script = ''
          # here goes your code
        '';
        serviceConfig.Type = "oneshot";
      };

and the same for pre-hibernate.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

recalled another case: sometimes on lid close (sleep/suspend) brcmfmac could crash itself, so i guess the better approach would be to still use it in powerUp/Down commands of PM. unload/load driver.

if that's too hacky, let's leave it as it, and I might keep it in my local configuration for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. If this is the case, than we keep the original.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added lib.mkBefore for both Up/Down commands.

As an example similar code could be used to restart wireless interface:

```nix
powerManagement.powerUpCommands = ''
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@infinisil How can we make this string appended after our own module value? We are currently doing rmmod. I think there was a way to do priorities.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how rmmod relates, but if you mean how to order different powerUpCommand assignments, you can use mkBefore or mkAfter for that, which make sure the value is ordered before or after the default priority.

Copy link
Member

@Mic92 Mic92 Nov 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This were the helper functions I was looking for.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sevenfourk If you revert to the previous powerManagement.powerUpCommands/powerDownCommands
but use mkBefore:

powerManagement.powerUpCommands = lib.mkBefore ''
  ${pkgs.kmod}/bin/modprobe brcmfmac
'';

Than users can just follow the readme to restart their network manager daemon of choice and the ordering will make sure that their services gets added after the modprobe.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks guys, leaving ordering for README example as is. added lib.mkBefore for module manipulation.

@Mic92 Mic92 merged commit 34c1bf1 into NixOS:master Dec 1, 2020
@Mic92
Copy link
Member

Mic92 commented Dec 1, 2020

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants