alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Cc: James Schulman <james.schulman@cirrus.com>,
	David Rhodes <david.rhodes@cirrus.com>,
	Richard Fitzgerald <rf@opensource.cirrus.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	"Stefan Binding" <sbinding@opensource.cirrus.com>,
	<alsa-devel@alsa-project.org>, <patches@opensource.cirrus.com>,
	<linux-kernel@vger.kernel.org>, <kernel@collabora.com>
Subject: Re: [PATCH 4/9] ASoC: cs35l41: Fix broken shared boost activation
Date: Tue, 5 Sep 2023 10:29:33 +0000	[thread overview]
Message-ID: <20230905102933.GL103419@ediswmail.ad.cirrus.com> (raw)
In-Reply-To: <20230902210621.1184693-5-cristian.ciocaltea@collabora.com>

On Sun, Sep 03, 2023 at 12:06:16AM +0300, Cristian Ciocaltea wrote:
> Enabling the active/passive shared boosts involves writing the MDSYNC UP
> register sequence, which cannot be performed before receiving the PLL
> lock signal.
> 
> Due to improper error handling, it was not obvious the wait operation
> times out and, consequently, the shared boost gets never enabled.
> 
> Further investigations revealed the signal is triggered while
> snd_pcm_start() is executed, right after receiving the
> SNDRV_PCM_TRIGGER_START command, which happens long after the
> SND_SOC_DAPM_PRE_PMU event handler is invoked as part of
> snd_pcm_prepare().  That is where cs35l41_global_enable() is called
> from.
> 
> Increasing the wait duration doesn't help, as it only causes an
> unnecessary delay in the invocation of snd_pcm_start().  Moving the wait
> and the subsequent regmap operations to the SNDRV_PCM_TRIGGER_START
> callback is not a solution either, since they would be executed in an
> IRQ-off atomic context.
> 
> Solve the issue by deferring the processing to a workqueue task, which
> allows to correctly wait for the signal and then safely proceed with
> the required regmap operations.
> 
> Fixes: f5030564938b ("ALSA: cs35l41: Add shared boost feature")
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---

Thanks for looking at this apologies this was missed in the
initial review of the patch.

> +int cs35l41_mdsync_up(struct regmap *regmap)
> +{
> +	struct reg_sequence cs35l41_mdsync_up_seq[] = {
> +		{CS35L41_PWR_CTRL3, 0},
> +		{CS35L41_PWR_CTRL1, 0x00000000, 3000},
> +		{CS35L41_PWR_CTRL1, 0x00000001, 3000},
> +	};
> +	unsigned int pwr_ctrl3, int_status;
> +	int ret;
> +
> +	regmap_read(regmap, CS35L41_PWR_CTRL3, &pwr_ctrl3);
> +	pwr_ctrl3 |= CS35L41_SYNC_EN_MASK;
> +	cs35l41_mdsync_up_seq[0].def = pwr_ctrl3;
> +
> +	ret = regmap_multi_reg_write(regmap, cs35l41_mdsync_up_seq,
> +				     ARRAY_SIZE(cs35l41_mdsync_up_seq));
> +	if (ret < 0)
> +		return ret;

Is this now safe? By pulling this out into a worker thread, it is
no longer under the DAPM lock, which makes me worry this can race
with the other uses of PWR_CTRL3 which could theoretically change
state between when you read the reg and when you write it.

> @@ -1243,33 +1289,27 @@ int cs35l41_global_enable(struct device *dev, struct regmap *regmap, enum cs35l4
>  		cs35l41_mdsync_down_seq[2].def = pwr_ctrl1;
>  		ret = regmap_multi_reg_write(regmap, cs35l41_mdsync_down_seq,
>  					     ARRAY_SIZE(cs35l41_mdsync_down_seq));
> -		if (ret || !enable)
> +		if (ret)
>  			break;
>  
> -		if (!pll_lock)
> -			return -EINVAL;
> -
> -		ret = wait_for_completion_timeout(pll_lock, msecs_to_jiffies(1000));
> -		if (ret == 0) {
> -			dev_err(dev, "Timed out waiting for pll_lock\n");
> -			return -ETIMEDOUT;
> +		if (enable) {
> +			if (mdsync_up_work) {
> +				/* Call cs35l41_mdsync_up() after receiving PLL lock signal */
> +				schedule_work(mdsync_up_work);
> +			} else {
> +				dev_err(dev, "MDSYNC UP work not provided\n");
> +				ret = -EINVAL;
> +			}
> +			break;

One question I might also have would be does a worker thread make
more sense or would it be simpler to do the mdsync power up
directly in response to the PLL lock IRQ?

Thanks,
Charles

  reply	other threads:[~2023-09-05 10:31 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-02 21:06 [PATCH 0/9] Improve CS35l41 ALSA SoC audio driver Cristian Ciocaltea
2023-09-02 21:06 ` [PATCH 1/9] ASoC: cs35l41: Handle mdsync_down reg write errors Cristian Ciocaltea
2023-09-05  9:19   ` Charles Keepax
2023-09-02 21:06 ` [PATCH 2/9] ASoC: cs35l41: Handle mdsync_up " Cristian Ciocaltea
2023-09-05  9:23   ` Charles Keepax
2023-09-02 21:06 ` [PATCH 3/9] ASoC: cs35l41: Initialize completion object before requesting IRQ Cristian Ciocaltea
2023-09-05  9:23   ` Charles Keepax
2023-09-02 21:06 ` [PATCH 4/9] ASoC: cs35l41: Fix broken shared boost activation Cristian Ciocaltea
2023-09-05 10:29   ` Charles Keepax [this message]
2023-09-05 18:11     ` Rhodes, David
2023-09-05 20:05       ` Cristian Ciocaltea
2023-09-05 20:25         ` Rhodes, David
2023-09-02 21:06 ` [PATCH 5/9] ASoC: cs35l41: Rename pll_lock to pll_lock_done Cristian Ciocaltea
2023-09-05  9:35   ` Charles Keepax
2023-09-02 21:06 ` [PATCH 6/9] ASoC: cs35l41: Make use of dev_err_probe() Cristian Ciocaltea
2023-09-05  9:36   ` Charles Keepax
2023-09-02 21:06 ` [PATCH 7/9] ASoC: cs35l41: Verify PM runtime resume errors in IRQ handler Cristian Ciocaltea
2023-09-05  9:37   ` Charles Keepax
2023-09-02 21:06 ` [PATCH 8/9] ASoC: cs35l41: Use modern pm_ops Cristian Ciocaltea
2023-09-05  9:37   ` Charles Keepax
2023-09-02 21:06 ` [PATCH 9/9] ASoC: cs35l41: Use devm_pm_runtime_enable() Cristian Ciocaltea
2023-09-05  9:45   ` Charles Keepax
2023-09-05 19:15     ` Cristian Ciocaltea
2023-09-06 16:37       ` Charles Keepax
2023-09-06 19:55         ` Cristian Ciocaltea
2023-09-07  8:37           ` 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=20230905102933.GL103419@ediswmail.ad.cirrus.com \
    --to=ckeepax@opensource.cirrus.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cristian.ciocaltea@collabora.com \
    --cc=david.rhodes@cirrus.com \
    --cc=james.schulman@cirrus.com \
    --cc=kernel@collabora.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@opensource.cirrus.com \
    --cc=perex@perex.cz \
    --cc=rf@opensource.cirrus.com \
    --cc=sbinding@opensource.cirrus.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).