Automatically switching snd_hda_intel.power_save value when switching from battery to ac ?

Hans de Goede hdegoede at redhat.com
Fri Mar 6 09:25:49 CET 2020


Hi,

On 3/6/20 8:59 AM, Takashi Iwai wrote:
> On Thu, 05 Mar 2020 15:33:04 +0100,
> Hans de Goede wrote:
>>
>> Hi,
>>
>> Because of a bug-report about power-saving related plops/clocks on a
>> Lenovo T470s, I've asked inside Red Hat if people with a T470s and
>> running a recent kernel were also experiencing this.
>>
>> Most people are happy with the audio, but I did get a few bug reports
>> about plops on the headphones-jack.
>>
>> One of the suggestions which I got from 2 different users is to
>> disable power-saving for the HDA driver when on AC, esp. since most
>> headphones-jack use (esp. with an external amplifier which amplifies
>> the problem) is done while the laptop is sitting on a desk and thus
>> typically is connected to a charger.
>>
>> I'm personally not necessarily a fan of changing settings based
>> on being connected to ac or not, but I guess that in this case
>> it might not be such a bad idea ?
> 
> Actually the power-saving-toggle-on-demand used to be the standard
> behavior by some power management tools including some
> thinkpad-specific one, IIRC.  So the behavior itself isn't too bad if
> the pop noise can't be fully eliminated.

Right, atleast TLP does something like this, and maybe also some of
the Ubuntu pm scripts. But if we are going to do this I would like to
come up with some upstream, non 3th party (from a std gnu/linux
perspective), solution.

Note upstream does not necessarily mean inside the kernel, it could be
e.g. part of systemd, e.g. a udev rule (not sure if that is possible)
or done by some pm suspend/resume hooks which are installed by default
(not sure if systemd's suspend code supports hooks though).

If there is consensus that this is something which is a good idea /
a reasonable thing to do; and also consensus that this should be done
outside the kernel I can take a look at putting together a systemd
pull-req for this.

Regards,

Hans



More information about the Alsa-devel mailing list