From: Emanuele Ghidoli <ghidoliemanuele@gmail.com>
To: alsa-devel@alsa-project.org
Cc: Charles Keepax <ckeepax@opensource.cirrus.com>,
Takashi Iwai <tiwai@suse.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Michael Walle <michael@walle.cc>, Mark Brown <broonie@kernel.org>,
Francesco Dolcini <francesco.dolcini@toradex.com>,
emanuele.ghidoli@toradex.com
Subject: wm8904 and output volume control
Date: Sat, 17 Dec 2022 00:47:14 +0100 [thread overview]
Message-ID: <c7864c35-738c-a867-a6a6-ddf9f98df7e7@gmail.com> (raw)
Hello,
I have found that output volume is set to the default value after a
limited time (~4 seconds) after play stop.
I have analyzed what is happening:
- at first play the volume is the expected one
- After stopping playing + ~4 seconds wm8904_set_bias_level (...,
SND_SOC_BIAS_OFF) is called
- Chip is reset and regulator is switched off if "possible" (not in our
case, it is important to note)
- at second play wm8904_set_bias_level (..., SND_SOC_BIAS_STANDBY) is
called. wm8904_hw_params is also called just before.
I see that all I2C transactions are good, registers are written as
expected, especially volume control register (even the silly HPOUT_VU
bit, to do a volume update is correctly written).
Reading out this register, using i2cget (bypassing regcache), report the
"expected" value. But the real output volume correspond to the default
value (hw default, that it is the same value in wm8904_reg_defaults
structure).
I checked that SYSCLK_ENA is 0 during register writing (needed if
MCLK/SYSCLK is not present). I do not know if there is some other
constrain on these registers.
If I rewrite the volume control register, a second time, the volume is
set (tested with i2cset, from user space. And from kernel space,
bypassing regcache).
I resolve also by reverting e9149b8c00d2 ("ASoC: wm8904: fix regcache
handling").
I'm not here to say that the commit is wrong. I analyzed it and seem
perfect (in few words it align the hw with the regcache avoiding
potential incoherence).
I'm trying to compare first play and second play register programming
sequence. They are similar but not the same. But on the first play the
volume output is good.
Do someone remember something similar fixed on another codec?
Any idea is appreciated.
Thank you.
Best regards,
Emanuele Ghidoli
next reply other threads:[~2022-12-16 23:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 23:47 Emanuele Ghidoli [this message]
2022-12-19 9:58 ` wm8904 and output volume control Charles Keepax
2022-12-19 15:20 ` Emanuele Ghidoli
2022-12-20 10:00 ` Charles Keepax
2022-12-20 19:12 ` Emanuele Ghidoli
2022-12-21 16:56 ` Charles Keepax
2022-12-21 17:38 ` Emanuele Ghidoli
2022-12-28 10:04 ` Charles Keepax
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=c7864c35-738c-a867-a6a6-ddf9f98df7e7@gmail.com \
--to=ghidoliemanuele@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=ckeepax@opensource.cirrus.com \
--cc=emanuele.ghidoli@toradex.com \
--cc=francesco.dolcini@toradex.com \
--cc=lgirdwood@gmail.com \
--cc=michael@walle.cc \
--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.