All of lore.kernel.org
 help / color / mirror / Atom feed
From: Emanuele Ghidoli <ghidoliemanuele@gmail.com>
To: Charles Keepax <ckeepax@opensource.cirrus.com>,
	Emanuele Ghidoli <ghidoliemanuele@gmail.com>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>,
	Takashi Iwai <tiwai@suse.com>, Michael Walle <michael@walle.cc>,
	Mark Brown <broonie@kernel.org>,
	Francesco Dolcini <francesco.dolcini@toradex.com>,
	emanuele.ghidoli@toradex.com
Subject: Re: wm8904 and output volume control
Date: Tue, 20 Dec 2022 20:12:23 +0100	[thread overview]
Message-ID: <9657ab8d-0c60-7c81-b1cb-8a5b43d07c40@gmail.com> (raw)
In-Reply-To: <20221220100005.GD36097@ediswmail.ad.cirrus.com>

On 20/12/2022 11:00, Charles Keepax wrote:
> On Mon, Dec 19, 2022 at 04:20:10PM +0100, Emanuele Ghidoli wrote:
>> On 19/12/2022 10:58, Charles Keepax wrote:
>>> On Sat, Dec 17, 2022 at 12:47:14AM +0100, Emanuele Ghidoli wrote:
>> I infer, from datasheet, that volume update is applied in different
>> way based on charge pump dynamic vs register control (CP_DYN_PWR bit
>> in CLASS_W register):
>> "Under Register control, the HPOUTL_VOL, HPOUTR_VOL, LINEOUTL_VOL
>> and LINEOUTR_VOL register settings are used to control the charge
>> pump mode of operation.
>> Under Dynamic control, the audio signal level in the DAC is used to
>> control the charge pump mode of operation."
>>
>> The second sentence do not explain that volume register is still
>> considered by the component but likely in a different way.
>>
>> It is important to note that I trace I2C transactions and, without
>> the patch, the CLASS_W register is written JUST after volume update
>> registers (with the patch is written before and after).
>>
>> At this point I have no doubt that we have to update that register
>> before writing volume.
>>
> 
> Hmm... I think my only concern here is this feels a bit counter
> intuitive, the default value is described as "controlled by
> volume register settings" and we are saying in that situation the
> volume registers don't seem to update properly. That is far from
> impossible but I think we should perhaps poke a little more to
> make sure we understand the bounds here.
I did some more test and I'm not 100% sure of what is going on anymore.


> I see that that CP_DYN_PWR bit is disabled when audio is going
> through one of the bypass paths. Would you be able to enable one
> of the bypass paths and see if you can manually adjust the volume
> on the headphone output, with a bypass path active?
With the previous change, I tested all the possible combination with one 
channel from the DAC and the other toggling from DAC to Bypass changing 
the volume and it's always correct.


> Would also perhaps be interesting as a test to completely remove
> the write to CP_DYN_PWR from probe and leave things set to manual
> and see how the volume behaves then?
When I tried to remove any write to this register my modification 
stopped working.


> I guess the interests here are to find out if the SYSCLK is
> involved at all.
I tested keep the clock always enabled, removing clk_disable_unprepare 
when going into SND_SOC_BIAS_OFF and it has zero effects.
Or did you mean something else?

Said all of that, I did one last test, forcing a volume update on
the charge pump enable callback, cp_event(), with this and only this
modification in everything is working fine.

Could it just be as easy as that the volume is applied only when the 
charge pump is already active?

 From the datasheet this seems a good explanation:

  The Charge Pump is enabled by setting the CP_ENA bit. When enabled, the
  charge pump adjusts the output voltages (CPVOUTP and CPVOUTN).

What do you think?

Emanuele


  reply	other threads:[~2022-12-20 19:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-16 23:47 wm8904 and output volume control Emanuele Ghidoli
2022-12-19  9:58 ` Charles Keepax
2022-12-19 15:20   ` Emanuele Ghidoli
2022-12-20 10:00     ` Charles Keepax
2022-12-20 19:12       ` Emanuele Ghidoli [this message]
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=9657ab8d-0c60-7c81-b1cb-8a5b43d07c40@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.