From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB47AC7EE29 for ; Tue, 13 Jun 2023 09:55:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240129AbjFMJzg (ORCPT ); Tue, 13 Jun 2023 05:55:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241934AbjFMJzY (ORCPT ); Tue, 13 Jun 2023 05:55:24 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AED6590 for ; Tue, 13 Jun 2023 02:55:18 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 69EA81FD6D; Tue, 13 Jun 2023 09:55:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1686650117; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=P265Uv6CcvavmFR5gq/Gw0Drohun0A3BXfzFYfOVCjk=; b=Mv/vVjRTUYdmUgz4jK2/qs07f2XV91aV9ZgTpFL6ExMcWzsCOtCR2JbwR2U2Iy23moqcKG X/of1TalAJHkt72TBvolS67yyXUdpWwFP3FWiT9DEIdP1dHCQRbXsCPWvyOaN5Egls6IKk ZaQ3fncZaBX7/q2E6sPH6SL5zfXPQQw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1686650117; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=P265Uv6CcvavmFR5gq/Gw0Drohun0A3BXfzFYfOVCjk=; b=DY+yVkmYUjd9A5eaevhIWViGx4qzSfwb9m2rqdAiEobI3Zm7emi0inBNNvdYoPDgLmK6Jp sWaG0xrxLrG3/JBg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 2FECC13345; Tue, 13 Jun 2023 09:55:17 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id LcSkCgU9iGS+YgAAMHmgww (envelope-from ); Tue, 13 Jun 2023 09:55:17 +0000 Date: Tue, 13 Jun 2023 11:55:16 +0200 Message-ID: <87mt13elff.wl-tiwai@suse.de> From: Takashi Iwai To: Jon Hunter Cc: Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai , "Thierry Reding" , Sameer Pujar , , , "Oswald Buddenhagen" Subject: Re: [PATCH] ASoC: tegra: Fix Master Volume Control In-Reply-To: <20230613093453.13927-1-jonathanh@nvidia.com> References: <20230613093453.13927-1-jonathanh@nvidia.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org 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 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? thanks, Takashi > --- > sound/soc/tegra/tegra_pcm.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/sound/soc/tegra/tegra_pcm.c b/sound/soc/tegra/tegra_pcm.c > index 468c8e77de21..0b69cebc9a33 100644 > --- a/sound/soc/tegra/tegra_pcm.c > +++ b/sound/soc/tegra/tegra_pcm.c > @@ -117,6 +117,9 @@ int tegra_pcm_open(struct snd_soc_component *component, > return ret; > } > > + /* Set wait time to 500ms by default */ > + substream->wait_time = 500; > + > return 0; > } > EXPORT_SYMBOL_GPL(tegra_pcm_open); > -- > 2.34.1 >