From: Alexander Sergeyev <sergeev917@gmail.com>
To: Takashi Iwai <tiwai@suse.de>
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: Sat, 22 Jan 2022 22:05:22 +0300 [thread overview]
Message-ID: <20220122190522.ycaygrqcen7d3hj2@localhost.localdomain> (raw)
In-Reply-To: <20220119093249.eaxem33bjqjxcher@localhost.localdomain>
On Wed, Jan 19, 2022 at 12:32:51PM +0300, Alexander Sergeyev wrote:
> No, I mean "IO_PAGE_FAULT" and "out of range cmd" don't appear on every
> unbind & bind. Sometimes it works cleanly.
Unbind & bind generally works without error messages on the first attempt. The
second unbind & bind tends to generate io page faults like "AMD-Vi: Event
logged [IO_PAGE_FAULT ...]", but might work fine as well.
In some cases "snd_hda_codec_realtek: out of range cmd" errors are triggered in
addition to io page faults.
> This seems to be a bogus COEF. But I have no idea from where this
> comes. The values look completely wrong.
In such cases unexpected COEF values are coming from COEF reads during
read/write pairs that implement update operations.
For example (these traces are from added printk statements):
alc_update_coef_led(codec, led {.idx=0x19, .mask=0x2000, .on=0x2000, .off=0x0}, polarity=0, on=1)
alc_update_coefex_idx(codec, nid, coef_idx=0x19, mask=0x2000, bits_set=0x2000)
alc_update_coef_led(codec, led {.idx=0xb, .mask=0x8, .on=0x8, .off=0x0}, polarity=0, on=1)
alc_update_coefex_idx(codec, nid, coef_idx=0xb, mask=0x8, bits_set=0x8)
snd_hdac_codec_write(hdac, nid, flags=0, verb=0x500, parm=0x19) = 0x0
snd_hdac_codec_write(hdac, nid, flags=0, verb=0x500, parm=0xb) = 0x0
snd_hdac_codec_read(hdac, nid, flags=0, verb=0xc00, parm=0x0) = 0x90170110
alc_update_coefex_idx: alc_read_coefex_idx(codec, nid, coef_idx=0xb) returned 0x90170110
alc_update_coefex_idx: calling alc_write_coefex_idx(codec, nid, coef_idx=0xb, coef_val=0x90170118)
snd_hdac_codec_read(hdac, nid, flags=0, verb=0xc00, parm=0x0) = 0x0
alc_update_coefex_idx: alc_read_coefex_idx(codec, nid, coef_idx=0x19) returned 0x0
alc_update_coefex_idx: calling alc_write_coefex_idx(codec, nid, coef_idx=0x19, coef_val=0x2000)
snd_hdac_codec_write(hdac, nid, flags=0, verb=0x500, parm=0xb) = 0x0
snd_hda_codec_realtek hdaudioC1D0: out of range cmd 0:20:400:90170118
snd_hdac_codec_write(hdac, nid, flags=0, verb=0x400, parm=0x90170118) = 0xffffffff
Then I've specifically added printk on alc_update_coefex_idx entry and exit:
[4.036211] alc_update_coefex_idx(codec, nid, coef_idx=0x10, mask=0x200, bits_set=0x0): entering
[4.036503] alc_update_coefex_idx(codec, nid, coef_idx=0x10, mask=0x200, bits_set=0x0): exiting
[4.036543] alc_update_coefex_idx(codec, nid, coef_idx=0xb, mask=0x8, bits_set=0x0): entering
[4.036546] alc_update_coefex_idx(codec, nid, coef_idx=0x19, mask=0x2000, bits_set=0x0): entering
[4.037139] alc_update_coefex_idx(codec, nid, coef_idx=0xb, mask=0x8, bits_set=0x0): exiting
[4.037609] alc_update_coefex_idx(codec, nid, coef_idx=0x19, mask=0x2000, bits_set=0x0): exiting
I'm not sure about kernel log buffering or maybe the device support for
pipelining, but is it okay that alc_update_coefex_idx() seem to overlap?
next prev parent reply other threads:[~2022-01-22 18:59 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
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 ` [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 ` [PATCH 4/4] ALSA: hda/realtek: fix mute/micmute LEDs and speaker for HP Zbook Fury 17 G8 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 6:14 ` Takashi Iwai
2022-01-11 19:52 ` Alexander Sergeyev
2022-01-12 9:45 ` Takashi Iwai
2022-01-12 10:12 ` Alexander Sergeyev
2022-01-12 10:13 ` Takashi Iwai
2022-01-12 10:48 ` Alexander Sergeyev
2022-01-12 20:18 ` Alexander Sergeyev
2022-01-13 7:14 ` Takashi Iwai
2022-01-13 18:31 ` Alexander Sergeyev
2022-01-13 21:19 ` Alexander Sergeyev
2022-01-14 16:37 ` Takashi Iwai
2022-01-14 18:37 ` Alexander Sergeyev
2022-01-15 7:55 ` Takashi Iwai
2022-01-15 15:22 ` Alexander Sergeyev
2022-01-19 9:12 ` Takashi Iwai
2022-01-19 9:32 ` Alexander Sergeyev
2022-01-22 19:05 ` Alexander Sergeyev [this message]
2022-01-22 20:56 ` Alexander Sergeyev
2022-01-26 15:24 ` Takashi Iwai
2022-01-29 14:47 ` Alexander Sergeyev
2022-01-30 11:10 ` Alexander Sergeyev
2022-01-31 14:57 ` Takashi Iwai
2022-02-05 15:00 ` Alexander Sergeyev
2022-02-05 17:51 ` Alexander Sergeyev
2022-02-07 14:21 ` Takashi Iwai
2022-02-08 19:49 ` Alexander Sergeyev
2022-02-08 14:36 ` Takashi Iwai
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=20220122190522.ycaygrqcen7d3hj2@localhost.localdomain \
--to=sergeev917@gmail.com \
--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=tiwai@suse.com \
--cc=tiwai@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®