Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Johan Hovold <johan+linaro@kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Banajit Goswami <bgoswami@quicinc.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	alsa-devel@alsa-project.org, linux-sound@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 2/7] ASoC: codecs: lpass-wsa-macro: fix compander volume hack
Date: Tue, 16 Jan 2024 14:10:19 +0100	[thread overview]
Message-ID: <ZaaAO8SMczq7YUAE@hovoldconsulting.com> (raw)
In-Reply-To: <8bb1cad6-6a85-444a-b881-c03ab0051009@linaro.org>

On Tue, Jan 16, 2024 at 11:10:21AM +0000, Srinivas Kandagatla wrote:
> Thanks Johan for this patch,
> 
> On 16/01/2024 09:38, Johan Hovold wrote:
> > The LPASS WSA macro codec driver is updating the digital gain settings
> > behind the back of user space on DAPM events if companding has been
> > enabled.
> > 
> > As compander control is exported to user space, this can result in the
> > digital gain setting being incremented (or decremented) every time the
> > sound server is started and the codec suspended depending on what the
> > UCM configuration looks like.
> > 
> > Soon enough playback will become distorted (or too quiet).
> > 
> > This is specifically a problem on the Lenovo ThinkPad X13s as this
> > bypasses the limit for the digital gain setting that has been set by the
> > machine driver.
> > 
> > Fix this by simply dropping the compander gain hack. If someone cares
> > about modelling the impact of the compander setting this can possibly be
> > done by exporting it as a volume control later.
> > 
> This is not a hack, wsa codec requires gain to be programmed after the 
> clk is enabled for that particular interpolator.

Ok, but then it's also broken as, as I mentioned off-list, these
registers are cached so unless companding is enabled, the write on
enable will have no effect.

> However I agree with you on programming the gain that is different to 
> what user set it.
> 
> This is because of unimplemented or half baked implementation of half-db 
> feature of gain control in this codec.
> 
> We can clean that half baked implementation for now and still continue 
> to program the gain values after the clks are enabled.
> 
> lets remove spkr_gain_offset and associated code paths in this codec, 
> which should fix the issue that you have reported and still do the right 
> thing of programming gain after clks are enabled.

Removing the offset which can alter the gain, will cause both of these
writes to become no-ops as the registers are cached (e.g. just as for
the follow-on codec cleanups). So then we might as well just remove
this too.

How is the half-dB feature supposed to work?

And are you sure that you need to reprogram the gain value after
enabling the clock? Everything seems to work without doing so.

Johan

  reply	other threads:[~2024-01-16 13:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-16  9:38 [PATCH 0/7] ASoC: qcom: volume fixes and codec cleanups Johan Hovold
2024-01-16  9:38 ` [PATCH 1/7] ASoC: qcom: sc8280xp: limit speaker volumes Johan Hovold
2024-01-16 11:11   ` Srinivas Kandagatla
2024-01-16 15:10     ` Mark Brown
2024-01-16  9:38 ` [PATCH 2/7] ASoC: codecs: lpass-wsa-macro: fix compander volume hack Johan Hovold
2024-01-16 11:10   ` Srinivas Kandagatla
2024-01-16 13:10     ` Johan Hovold [this message]
2024-01-17  9:08       ` Johan Hovold
2024-01-16  9:38 ` [PATCH 3/7] ASoC: codecs: lpass-wsa-macro: drop dead mixer-path gain hack Johan Hovold
2024-01-16  9:39 ` [PATCH 4/7] ASoC: codecs: lpass-rx-macro: " Johan Hovold
2024-01-16  9:39 ` [PATCH 5/7] ASoC: codecs: wcd9335: drop dead gain hacks Johan Hovold
2024-01-16  9:39 ` [PATCH 6/7] ASoC: codecs: wcd934x: " Johan Hovold
2024-01-16  9:39 ` [PATCH 7/7] ASoC: codecs: msm8916-wcd-digital: " Johan Hovold
2024-01-16 12:33   ` Srinivas Kandagatla

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=ZaaAO8SMczq7YUAE@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=bgoswami@quicinc.com \
    --cc=broonie@kernel.org \
    --cc=johan+linaro@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=stable@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox