[alsa-devel] [CX2075] No sound after suspend/resume from front speaker

[Roman Šmakal]

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