From: "Sheetal ." <sheetal@nvidia.com>
To: "Pierre-Louis Bossart" <pierre-louis.bossart@linux.dev>,
"Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>,
broonie@kernel.org, lgirdwood@gmail.com, perex@perex.cz,
tiwai@suse.com, linux-sound@vger.kernel.org
Cc: linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
jonathanh@nvidia.com, thierry.reding@gmail.com,
mkumard@nvidia.com, spujar@nvidia.com
Subject: Re: [RFC PATCH v2] ASoC: soc-pcm: Optimize hw_params() BE DAI call
Date: Fri, 23 May 2025 16:31:21 +0530 [thread overview]
Message-ID: <897155bb-da81-485a-869c-da587e063bc2@nvidia.com> (raw)
In-Reply-To: <1328ff08-1de7-4c62-b8f7-b09e15f50737@linux.dev>
On 23-05-2025 15:25, Pierre-Louis Bossart wrote:
> External email: Use caution opening links or attachments
>
>
> On 5/13/25 13:10, Péter Ujfalusi wrote:
>>
>>
>> On 08/04/2025 11:30, Sheetal . wrote:
>>> From: Sheetal <sheetal@nvidia.com>
>>>
>>> The hw_params() function for BE DAI was being called multiple times due
>>> to an unnecessary SND_SOC_DPCM_STATE_HW_PARAMS state check.
>>>
>>> Remove the redundant state check to ensure hw_params() is called only once
>>> per BE DAI configuration.
>>
>> The first sentence tells that the hw_params() of the BE is called
>> multiple times.
>>
>> The second sentence states that the check is redundant then tells that
>> it is removed to not call the hw_params() of the BE, so the check was
>> not redundant, it got exercised.
>>
>> Which one is true?
>>
>> Under what circumstance the __soc_pcm_hw_params() got called multiple
>> times? Was it normal or was it error? What causes it?
>
> I share Peter's question. The code has been around since 2016, in what case would the existing logic need to be updated?
As such it is not causing any issue. But I think if the BE DAI state is
already SND_SOC_DPCM_STATE_HW_PARAMS, there is no need to call it again.
Similar to how dpcm_be_dai_prepare() and dpcm_be_dai_startup() won't
call BE DAI prepare() / open() callbacks if the state is already
SND_SOC_DPCM_STATE_PREPARE or SND_SOC_DPCM_STATE_OPEN respectively.
For example:
When two or more streams sharing a common BE DAI are started
consecutively, the following sequence can cause multiple unnecessary
hw_params() calls for the BE DAI:
(1) Stream1 hw_params() called for BE DAI and updates state to
SND_SOC_DPCM_STATE_HW_PARAMS
(2) Before Stream1 BE DAI prepare() call triggered,
Stream2 dpcm_be_dai_hw_params() call happened and now BE DAI
hw_params() callback happen again unnecessarily as the state of BE DAI
is still SND_SOC_DPCM_STATE_HW_PARAMS.
>
> One key point is that hw_params() may be called multiple times with different parameters, it's a feature and not a bug. If a call to hw_params() changes an internal state, a follow-up call to hw_params() shall undo the initial state change and rerun the appropriate configuration.
As per my understanding, after hw_params() callback, prepare() will be
called and the BE DAI state will be updated to PREPARE now, then
hw_params() callback for same BE DAI will not occur as condition will be
unmet. Not sure how the different parameters will be configured in this
case? Please clarify.
>
>>> Signed-off-by: Sheetal <sheetal@nvidia.com>
>>> ---
>>> Changes in v2:
>>> - Update commit message as its not a fix.
>>> - Marked as RFC patch as it requires feedback from other users
>>> perspective as well.
>>> - The patch is being sent separately as other patch is not RFC.
>>>
>>> sound/soc/soc-pcm.c | 1 -
>>> 1 file changed, 1 deletion(-)
>>>
>>> diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
>>> index d7f6d3a6d312..c73be27c4ecb 100644
>>> --- a/sound/soc/soc-pcm.c
>>> +++ b/sound/soc/soc-pcm.c
>>> @@ -2123,7 +2123,6 @@ int dpcm_be_dai_hw_params(struct snd_soc_pcm_runtime *fe, int stream)
>>> continue;
>>>
>>> if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) &&
>>> - (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) &&
>>> (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE))
>>> continue;
>>>
>>
>
next prev parent reply other threads:[~2025-05-23 11:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 8:30 [RFC PATCH v2] ASoC: soc-pcm: Optimize hw_params() BE DAI call Sheetal .
2025-04-08 9:04 ` Sheetal .
2025-05-12 12:01 ` Sameer Pujar
2025-05-13 6:15 ` Péter Ujfalusi
2025-05-21 5:25 ` Sheetal .
2025-05-21 8:17 ` Péter Ujfalusi
2025-05-21 11:33 ` Sheetal .
2025-05-13 11:10 ` Péter Ujfalusi
2025-05-23 9:55 ` Pierre-Louis Bossart
2025-05-23 11:01 ` Sheetal . [this message]
2025-05-26 16:18 ` Pierre-Louis Bossart
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=897155bb-da81-485a-869c-da587e063bc2@nvidia.com \
--to=sheetal@nvidia.com \
--cc=broonie@kernel.org \
--cc=jonathanh@nvidia.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mkumard@nvidia.com \
--cc=perex@perex.cz \
--cc=peter.ujfalusi@linux.intel.com \
--cc=pierre-louis.bossart@linux.dev \
--cc=spujar@nvidia.com \
--cc=thierry.reding@gmail.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