Re: [PATCH 1/4] ALSA: hda/realtek: fix mute/micmute LEDs for HP 855 G8

[Takashi Iwai]

On Wed, 12 Jan 2022 21:18:24 +0100,
Alexander Sergeyev wrote:
> 
> On Wed, Jan 12, 2022 at 01:48:28PM +0300, Alexander Sergeyev wrote:
> >On Wed, Jan 12, 2022 at 11:13:44AM +0100, Takashi Iwai wrote:
> >> You may try to get the codec proc dump with COEF by passing
> >> snd_hda_codec.dump_coef=1 module option for both working and
> >> non-working cases.
> >>You can unbind and re-bind the PCI (HD-audio controller) device via sysfs.
> >
> >I'll try both options later today when able, thank you!
> 
> First, about unbind and bind via sysfs -- attempts to unbind the
> HD-audio controller immediately trigger BUGs:
> 
> 05:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family
> 17h (Models 10h-1fh) HD Audio Controller [1022:15e3]
> 
> echo -n '0000:05:00.6' > /sys/bus/pci/drivers/snd_hda_intel/unbind
> 
> BUG: unable to handle page fault for address 000000000000173c
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 0 P4D 0
> Oops: 0000 [#1] SMP NOPTI
> CPU: 2 PID: 167 Comm: kworker/2:3 Tainted: G  T 5.16.0-dirty #3
> Workqueue: events set_brightness_delayed
> RIP: 0010:coef_micmute_led_set+0xf/0x60
> ...
> Call Trace:
>   <TASK>
>   set_brightness_delayed+0x6f/0xb0
>   process_one_work+0x1e1/0x380
>   worker_thread+0x4b/0x3b0
>   ? rescuer_thread+0x370/0x370
>   kthread+0x142/0x160
>   ? set_kthread_struct+0x50/0x50
>   ret_from_work+0x22/0x30
>   </TASK>
> 
> Is it normal/expected?

A sort of.  The sysfs unbind is little tested and may be still buggy
if done during the stream operation.

To be sure, could you check with my latest sound.git tree for-linus
branch?  There are a few fixes that harden the dynamic unbind.

Though, the code path is from the leds class, and it might not be
covered yet.  It's managed via devm, so it should have been cleared,
but there may be still some ordering problem...

> Second, about dump_coef. I've collected a bunch of samples from
> /proc/asound/Generic_1/codec#0. Overall, there are 6 different
> versions across 196 samples, two versions are with working sound (and
> micmute LED).
> 
> 
> Differences between _non-working_ versions:
> 
> Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out
> Amp-Out vals:  [0x3c 0x3c] // (!) OR [0x53 0x53]
> Converter: stream=5, channel=0 // (!) OR stream=0, channel=0
> 
> Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out
> Amp-Out vals:  [0x3c 0x3c] // (!) OR [0x53 0x53]
> Converter: stream=5, channel=0 // (!) OR stream=0, channel=0
> 
> Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono
> Processing caps: benign=0, ncoeff=142
> Coeff 0x0b: 0x8003 // (!) OR 0x7770
> Coeff 0x19: 0x01e3 // (!) OR 0x21e3
> 
> Node 0x08 [Audio Input] wcaps 0x10051b: Stereo Amp-In
> Amp-In vals:  [0x27 0x27] // (!) OR [0xa7 0xa7]
> 
> 
> Differences between _working_ versions:
> 
> Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono
> Processing caps: benign=0, ncoeff=142
> Coeff 0x0b: 0x8003 // (!) OR 0x7770
> 
> 
> Differences between _non_working_ and _working_ versions:
> 
> Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono
> Processing caps: benign=0, ncoeff=142
> Coeff 0x19: 0x01e3 OR 0x21e3 // (!) 0x8e11 for working versions
> 
> 
> In short:
> 1) Coeff 0x0b is flapping between 0x8003 and 0x7770 and does not seem
> to have any effect in both non-working and working versions. Not sure
> about this, maybe microphone is not operational since I haven't
> checked it yet.
> 2) Coeff 0x19 with 0x8e11 value makes speakers work. Non-working
> values are 0x01e3 and 0x21e3.
> 
> Running the following commands makes speakers and micmute LED work
> (0x20 is the node id, which is mentioned in the snippets above):
> 
> hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x19
> hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0x8e11
> 
> Is it possible to somehow trace this particular coefficient to hunt
> the timing issue? It would be great to have a proper fix.

Those might be some codec init values, which aren't set up properly by
whatever reason, e.g. it might need a bit more wait time for init,
etc.  You can fix it rather by issuing those explicitly at the fixup.


Takashi