All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Alexander Sergeyev <sergeev917@gmail.com>
Cc: Jeremy Szu <jeremy.szu@canonical.com>,
	tiwai@suse.com,
	"moderated list:SOUND" <alsa-devel@alsa-project.org>,
	Kailang Yang <kailang@realtek.com>,
	open list <linux-kernel@vger.kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	Jian-Hong Pan <jhp@endlessos.org>,
	Hui Wang <hui.wang@canonical.com>, PeiSen Hou <pshou@realtek.com>
Subject: Re: [PATCH 1/4] ALSA: hda/realtek: fix mute/micmute LEDs for HP 855 G8
Date: Thu, 13 Jan 2022 08:14:29 +0100	[thread overview]
Message-ID: <s5h8rvk85uy.wl-tiwai@suse.de> (raw)
In-Reply-To: <20220112201824.qmphnz2hx4frda6e@localhost.localdomain>

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

WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Alexander Sergeyev <sergeev917@gmail.com>
Cc: "moderated list:SOUND" <alsa-devel@alsa-project.org>,
	Kailang Yang <kailang@realtek.com>,
	Jeremy Szu <jeremy.szu@canonical.com>,
	Huacai Chen <chenhuacai@kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	tiwai@suse.com, Hui Wang <hui.wang@canonical.com>,
	PeiSen Hou <pshou@realtek.com>, Jian-Hong Pan <jhp@endlessos.org>
Subject: Re: [PATCH 1/4] ALSA: hda/realtek: fix mute/micmute LEDs for HP 855 G8
Date: Thu, 13 Jan 2022 08:14:29 +0100	[thread overview]
Message-ID: <s5h8rvk85uy.wl-tiwai@suse.de> (raw)
In-Reply-To: <20220112201824.qmphnz2hx4frda6e@localhost.localdomain>

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

  reply	other threads:[~2022-01-13  7:14 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-19 17:03 [PATCH 1/4] ALSA: hda/realtek: fix mute/micmute LEDs for HP 855 G8 Jeremy Szu
2021-05-19 17:03 ` Jeremy Szu
2021-05-19 17:03 ` [PATCH 2/4] ALSA: hda/realtek: fix mute/micmute LEDs and speaker for HP Zbook G8 Jeremy Szu
2021-05-19 17:03   ` Jeremy Szu
2021-05-19 17:03 ` [PATCH 3/4] ALSA: hda/realtek: fix mute/micmute LEDs and speaker for HP Zbook Fury 15 G8 Jeremy Szu
2021-05-19 17:03   ` Jeremy Szu
2021-05-19 17:03 ` [PATCH 4/4] ALSA: hda/realtek: fix mute/micmute LEDs and speaker for HP Zbook Fury 17 G8 Jeremy Szu
2021-05-19 17:03   ` Jeremy Szu
2021-05-27  2:00 ` [PATCH 1/4] ALSA: hda/realtek: fix mute/micmute LEDs for HP 855 G8 Jeremy Szu
2021-05-27  2:00   ` Jeremy Szu
2021-05-27  6:14   ` Takashi Iwai
2021-05-27  6:14     ` Takashi Iwai
2022-01-11 19:52 ` Alexander Sergeyev
2022-01-11 19:52   ` Alexander Sergeyev
2022-01-12  9:45   ` Takashi Iwai
2022-01-12  9:45     ` Takashi Iwai
2022-01-12 10:12     ` Alexander Sergeyev
2022-01-12 10:12       ` Alexander Sergeyev
2022-01-12 10:13       ` Takashi Iwai
2022-01-12 10:13         ` Takashi Iwai
2022-01-12 10:48         ` Alexander Sergeyev
2022-01-12 10:48           ` Alexander Sergeyev
2022-01-12 20:18           ` Alexander Sergeyev
2022-01-12 20:18             ` Alexander Sergeyev
2022-01-13  7:14             ` Takashi Iwai [this message]
2022-01-13  7:14               ` Takashi Iwai
2022-01-13 18:31               ` Alexander Sergeyev
2022-01-13 18:31                 ` Alexander Sergeyev
2022-01-13 21:19                 ` Alexander Sergeyev
2022-01-13 21:19                   ` Alexander Sergeyev
2022-01-14 16:37                 ` Takashi Iwai
2022-01-14 16:37                   ` Takashi Iwai
2022-01-14 18:37                   ` Alexander Sergeyev
2022-01-14 18:37                     ` Alexander Sergeyev
2022-01-15  7:55                     ` Takashi Iwai
2022-01-15  7:55                       ` Takashi Iwai
2022-01-15 15:22                       ` Alexander Sergeyev
2022-01-15 15:22                         ` Alexander Sergeyev
2022-01-19  9:12                         ` Takashi Iwai
2022-01-19  9:12                           ` Takashi Iwai
2022-01-19  9:32                           ` Alexander Sergeyev
2022-01-19  9:32                             ` Alexander Sergeyev
2022-01-22 19:05                             ` Alexander Sergeyev
2022-01-22 19:05                               ` Alexander Sergeyev
2022-01-22 20:56                               ` Alexander Sergeyev
2022-01-22 20:56                                 ` Alexander Sergeyev
2022-01-26 15:24                                 ` Takashi Iwai
2022-01-26 15:24                                   ` Takashi Iwai
2022-01-29 14:47                                   ` Alexander Sergeyev
2022-01-29 14:47                                     ` Alexander Sergeyev
2022-01-30 11:10                                     ` Alexander Sergeyev
2022-01-30 11:10                                       ` Alexander Sergeyev
2022-01-31 14:57                                       ` Takashi Iwai
2022-01-31 14:57                                         ` Takashi Iwai
2022-02-05 15:00                                         ` Alexander Sergeyev
2022-02-05 15:00                                           ` Alexander Sergeyev
2022-02-05 17:51                                           ` Alexander Sergeyev
2022-02-05 17:51                                             ` Alexander Sergeyev
2022-02-07 14:21                                             ` Takashi Iwai
2022-02-07 14:21                                               ` Takashi Iwai
2022-02-08 19:49                                               ` Alexander Sergeyev
2022-02-08 19:49                                                 ` Alexander Sergeyev
2022-02-08 14:36                                         ` Takashi Iwai
2022-02-08 14:36                                           ` Takashi Iwai
2022-02-08 19:52                                           ` Alexander Sergeyev
2022-02-08 19:52                                             ` Alexander Sergeyev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5h8rvk85uy.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=chenhuacai@kernel.org \
    --cc=hui.wang@canonical.com \
    --cc=jeremy.szu@canonical.com \
    --cc=jhp@endlessos.org \
    --cc=kailang@realtek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pshou@realtek.com \
    --cc=sergeev917@gmail.com \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.