Dne čtvrtek 30. ledna 2020 14:59:20 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 14:29:08 +0100,
Roman Šmakal wrote:
Dne čtvrtek 30. ledna 2020 14:07:53 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 13:07:46 +0100,
Roman Šmakal wrote:
Dne čtvrtek 30. ledna 2020 12:57:32 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 12:42:01 +0100,
Roman Šmakal wrote:
Dne středa 29. ledna 2020 12:33:06 CET jste napsal(a): > On Sat, 25 Jan 2020 23:30:32 +0100, > > Roman Šmakal wrote: > > Hi, > > > > this still seem to be an issue. After startup everything works > > well > > until > > the laptop goes to suspend. > > > > Tried pretty much everything basic user can do (unmutes, > > rmmods > > and so > > on), > > still no way to wake the output. ALSA seems to be thinking, > > that > > output is > > active, you can set volume and stuff, but nothing happens. > > > > ALSA info: > > http://alsa-project.org/db/?f=9d1ee81fe037acb53ca381f2de27be42 > > 0f83 > > a373 > > > > Related links: > > https://www.reddit.com/r/archlinux/comments/4nwzua/ > > no_sound_after_suspend_killing_or_restarting/ > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851404 > > The first thing to check is to compare alsa-info.sh outputs > before > and > after the suspend. > > Also pass snd_hda_codec.dump_coef=1 module option to enable the > COEF > dump. This will give more information in alsa-info.sh outputs. > > > Takashi
Okay, i did some comparing with module option enabled.
Sound working http://alsa-project.org/db/?f=adfb0b3ad5d9b8d88289ac7e35b742254beb 7588
Sound not working: http://alsa-project.org/db/?f=c796b14df0efb0079aef1df5f70764194cff 8d4d
What's wierd to me is, that on the row 521 there is change in aplay Subdevices from 1/1 to 0/1.
Also, state.PCH control 18 shows change in playback channel map.
Any other thing i can check or try to dofor debuging?
You passed a wrong option. The option is for snd_hda_codec module.
So either create a modprobe.d/*.conf file containing: options snd_hda_codec dump_coef=1
or pass snd_hda_codec.dump_coef=1 at boot cmdline option.
BTW, it'd be better to get the outputs with --no-upload option of alsa-info.sh, and attach them.
Last but not least, please don't drop Cc to ML unless you need to do so.
thanks,
Takashi
Alright, my bad, i'm new to this.
Attaching alsainfos with proper module options, no big difference though.
OK, so it has the codec has COEF things and there is no significant difference between those two outputs. It implies that something outside HD-audio bus is needed and it's probably done by BIOS.
Takashi
Okay, so are there any further steps required from me, or it's just matter of time for devs for pick this bug up?
Well, if you meant us as "devs", currently there is no much thing we can do for now. As said, the issue is pretty much vendor-specific implementation details. You can try asking the h/w vendor, but the chance isn't high, unfortunately.
I suppose here that the runtime PM works; i.e. after some time without activity the chip will be suspended. Check /sys/bus/hdaudio/devices/*/power/runtime_status. If it's "suspended", and if you can play back tone after this state, runtime PM basically works, and it implies that the rest is the system-wide power up problem that is deeply involved with BIOS.
Takashi
I can confirm that runtime PM works, but there is no way to make sound work after suspend so far. At least for BIOS ver. 1.9
Gonna try, if possible, to upgrade BIOS just to confirm it's still an issue.
Thanks Roman