From: Jon Hunter <jonathanh@nvidia.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
Takashi Iwai <tiwai@suse.com>,
Thierry Reding <thierry.reding@gmail.com>,
Sameer Pujar <spujar@nvidia.com>,
alsa-devel@alsa-project.org, linux-tegra@vger.kernel.org,
Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Subject: Re: [PATCH] ASoC: tegra: Fix Master Volume Control
Date: Tue, 13 Jun 2023 11:25:12 +0100 [thread overview]
Message-ID: <10c32da4-133f-9e07-d040-82c218900c7d@nvidia.com> (raw)
In-Reply-To: <87legnelbv.wl-tiwai@suse.de>
On 13/06/2023 10:57, Takashi Iwai wrote:
> On Tue, 13 Jun 2023 11:55:16 +0200,
> Takashi Iwai wrote:
>>
>> On Tue, 13 Jun 2023 11:34:53 +0200,
>> Jon Hunter wrote:
>>>
>>> Commit 3ed2b549b39f ("ALSA: pcm: fix wait_time calculations") corrected
>>> the PCM wait_time calculations and in doing so reduced the calculated
>>> wait_time. This exposed an issue with the Tegra Master Volume Control
>>> (MVC) device where the reduced wait_time caused the MVC to fail. For now
>>> fix this by setting the default wait_time for Tegra to be 500ms.
>>>
>>> Fixes: 3ed2b549b39f ("ALSA: pcm: fix wait_time calculations")
>>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>>
>> Hm, it's still not clear why it fails. The commit above changes the
>> timeout of wait_for_avail() to the full-buffer + 10% margin. In
>> thoery, the loop should abort after the full buffer read, and that
>> must be enough. If there were a large FIFO behind, it might be
>> overflow, but the fifo_size of Tegra driver seems 4, so it's
>> negligible.
>>
>> If extending the timeout "fixes" the problem, it might indicate that
>> the period update IRQ is triggered too late. Could you measure the
>> timing of each snd_pcm_period_elapsed() and wait_for_avail() call?
>
> OTOH, it's already at a pretty late stage for 6.4, and we need an
> urgent regression fix. So it's better to paper over it now, while
> hunting further for the real culprit.
I have filed a bug report internally to investigate this, but yes for
now was hoping to get something in place for v6.4 to avoid any regressions.
Thanks
Jon
--
nvpublic
next prev parent reply other threads:[~2023-06-13 10:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 9:34 [PATCH] ASoC: tegra: Fix Master Volume Control Jon Hunter
2023-06-13 9:55 ` Takashi Iwai
2023-06-13 9:57 ` Takashi Iwai
2023-06-13 10:25 ` Jon Hunter [this message]
2023-06-13 13:23 ` Linux regression tracking #adding (Thorsten Leemhuis)
2023-06-13 16:29 ` Mark Brown
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=10c32da4-133f-9e07-d040-82c218900c7d@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-tegra@vger.kernel.org \
--cc=oswald.buddenhagen@gmx.de \
--cc=perex@perex.cz \
--cc=spujar@nvidia.com \
--cc=thierry.reding@gmail.com \
--cc=tiwai@suse.com \
--cc=tiwai@suse.de \
/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