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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?


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.



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux