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:
- 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