pm-utils AC/Battery policy requirement for Audio
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
intel |
Won't Fix
|
Undecided
|
Unassigned | ||
pm-utils (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
On boards with charger connected, pm-utils disable *all* power-saving feture for PCI devices(include audio pci devices), the hooks is pci-devices under power.d.
This policy maybe too regressive.
Here's our case:
On Intel's Harris beach baord, there're two HDA controller, one HDA in GPU side ,which powered by a area "power-well".
Harris Beach has only one eDP panel, if there's no HDMI/DP monitor connected, the audio function is not needed, and power-well should be shutdown. Otherwise some eDP feature will not be enabled.
When charger connected, the pm-utils policy let audio subsystem always active, which power-well always on and block eDP features.
So should we do some changing on the policy?
information type: | Private → Public |
Here's an email with more information (reference: http:// mailman. alsa-project. org/pipermail/ alsa-devel/ 2013-July/ 064462. html )
===
Hi Takashi,
In order to let audio power-save work even with charger connected, two parameters need be modified in userspace pm-utils scripts.
I tested the changes under Ubuntu 13.10 on Harris Beach, no matter charger connected or not, runtime power-saving works and power-well will
Be released as expected.
Here's my test under Ubuntu 13.04, the changes are: pm-utils/ power.d/ intel-audio- powersave
1)
/usr/lib/
case $1 in
true) audio_powersave 1 ;;
+ false) audio_powersave 10 ;;
- false) audio_powersave 0 ;;
help) help;;
*) exit $NA
esac
Audio will enter power-save mode after 10s inactive period. pm-utils/ power.d/ pci_devices
2) /usr/lib/
0x040300) # audio
echo "Setting Audio device $id to $1"
+ echo "auto" > $dev/power/control
- echo $1 > $dev/power/control
This keep audio subsystem always on.
This way the user may not let audio subsystem always active, may bring some delay from codec/controllers, or harm some chips.
Do you think we should add an exception for Haswell only or just make it as a common solution for audio subsystem?
Thanks
--xingchao
===