public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
To: Aaron Ma <aaron.ma@canonical.com>
Cc: Oder Chiou <oder_chiou@realtek.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
	Takashi Iwai <tiwai@suse.com>,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
	Shuming Fan <shumingf@realtek.com>
Subject: Re: [PATCH] ASoC: rt1320-sdw: don't poll PDE state on power-down
Date: Thu, 30 Apr 2026 10:07:10 +0200	[thread overview]
Message-ID: <78c57b26-505f-473d-8472-a491ede5aad9@linux.dev> (raw)
In-Reply-To: <CAJ6xRxUuOgfoJ1VP3++Hm_UdhYLJH-16J3rXUcN6O1BmSDJVbA@mail.gmail.com>

On 4/29/26 06:12, Aaron Ma wrote:
> On Wed, Apr 29, 2026 at 4:20 AM Pierre-Louis Bossart
> <pierre-louis.bossart@linux.dev> wrote:
>>
>> On 4/28/26 09:37, Aaron Ma wrote:
>>> rt1320_pde23_event(PRE_PMD) writes REQ_POWER_STATE=PS3 then polls
>>> ACTUAL_POWER_STATE. DAPM fires PRE_PMD while the SoundWire data port
>>> is still streaming — the codec cannot reach PS3 until the port stops,
>>> so the poll always times out during playback. This blocks
>>> snd_ctl_elem_write() for 2-3s making mute unresponsive.
>>>
>>> Remove the poll from PRE_PMD in rt1320_pde23_event() and
>>> rt1320_pde11_event(). The codec transitions to PS3 on its own once the
>>> data port becomes inactive. Keep the POST_PMU poll — on power-up the
>>> domain must reach PS0 before audio can flow.
>>>
>>> Fixes: f465d10cd731 ("ASoC: rt1320: Add support for version C")
>>> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
>>> ---
>>>  sound/soc/codecs/rt1320-sdw.c | 2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/sound/soc/codecs/rt1320-sdw.c b/sound/soc/codecs/rt1320-sdw.c
>>> index 192faa431b5e9..e42e8b6de853e 100644
>>> --- a/sound/soc/codecs/rt1320-sdw.c
>>> +++ b/sound/soc/codecs/rt1320-sdw.c
>>> @@ -2000,7 +2000,6 @@ static int rt1320_pde11_event(struct snd_soc_dapm_widget *w,
>>>               regmap_write(rt1320->regmap,
>>>                       SDW_SDCA_CTL(FUNC_NUM_MIC, RT1320_SDCA_ENT_PDE11,
>>>                               RT1320_SDCA_CTL_REQ_POWER_STATE, 0), ps3);
>>> -             rt1320_pde_transition_delay(rt1320, FUNC_NUM_MIC, RT1320_SDCA_ENT_PDE11, ps3);
>>>               break;
>>>       default:
>>>               break;
>>> @@ -2028,7 +2027,6 @@ static int rt1320_pde23_event(struct snd_soc_dapm_widget *w,
>>>               regmap_write(rt1320->regmap,
>>>                       SDW_SDCA_CTL(FUNC_NUM_AMP, RT1320_SDCA_ENT_PDE23,
>>>                               RT1320_SDCA_CTL_REQ_POWER_STATE, 0), ps3);
>>> -             rt1320_pde_transition_delay(rt1320, FUNC_NUM_AMP, RT1320_SDCA_ENT_PDE23, ps3);
>>
>> no, sorry, that's clearly wrong.
>>
>> When we touch the requested power state, we *shall* wait for the power state to be reached.
>> removing the transition delay is silly.
>>
>> You would really need to find out why streaming still occurs when you get a DAPM event. That doesn't seem right in the first place.
>>
> 
>  The stream is active by design — this is a mute, not a stream close.
> 
> To reproduce:
> 
>   1. Play audio through rt1320 speaker (aplay or PipeWire)
>   2. Press speaker mute key (or amixer cset on both FU21 channels)
>   3. Second channel mute takes 2-3s to return
> 
> Muting both channels removes the last DAPM path consumer of PDE23.
> DAPM fires PRE_PMD while PipeWire still holds the PCM open —
> DP1 keeps streaming zeros. The codec cannot reach PS3 while its data
> port is active, so the poll always times out. The mute register write
> that actually silences the speaker happens after this useless wait.
> 
> I confirmed via SoundWire debugfs reads: ACTUAL_POWER_STATE stays PS0
> while the port streams and only transitions to PS3 after PipeWire calls
> hw_free (~3s later). The poll can never succeed in this path.
> 
> Every other Realtek SDCA amp driver does fire-and-forget on PRE_PMD with
> no transition delay — rt712_sdca_pde23_event(), rt721_sdca_pde41_event(),
> rt1316_pde24_event(), and rt1017_sdca_pde23_event() all just write PS3
> and return. rt1320 is the only one that polls on power-down.
> 
> The POST_PMU poll is kept — on power-up the domain must reach PS0 before
> audio can flow, and the port is not yet active at that point so the
> transition succeeds immediately.

well that's an interesting issue. IMHO all those drivers are broken then... 
A mute should let the ports active and not start any power transitions on the codec side. 
That's what should be fixed first.

I am not sure either why PipeWire would send a hw_free on a mute either, that's a sure what to have audible delays and glitches. Mute != Stop.


  reply	other threads:[~2026-04-30  8:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-28  7:37 [PATCH] ASoC: rt1320-sdw: don't poll PDE state on power-down Aaron Ma
2026-04-28 20:10 ` Pierre-Louis Bossart
2026-04-29  4:12   ` Aaron Ma
2026-04-30  8:07     ` Pierre-Louis Bossart [this message]
2026-04-30  8:45       ` Aaron Ma
2026-04-30 19:58         ` Pierre-Louis Bossart
2026-05-01 12:23           ` Aaron Ma
2026-05-04  8:55             ` Pierre-Louis Bossart
2026-05-05  3:10               ` Shuming [范書銘]

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=78c57b26-505f-473d-8472-a491ede5aad9@linux.dev \
    --to=pierre-louis.bossart@linux.dev \
    --cc=aaron.ma@canonical.com \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=oder_chiou@realtek.com \
    --cc=perex@perex.cz \
    --cc=shumingf@realtek.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