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 X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36E12C2D0C6 for ; Fri, 27 Dec 2019 17:51:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 117E52067D for ; Fri, 27 Dec 2019 17:51:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1577469072; bh=M5YR3Aja1kN2HFjnI1fjDZZmVPUiQ4RWomKcTuwqkyQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=L58g0ja+kF0T0czHTd3obXp7/U3fTazVjQvgu1N8Sle7gM2mmdGBVza7unEg1Xmxy ujU3k3ltJlddyQ3qDK4ynH7sXHk/rx5lmi1MkvsyEPxjsQ5/3R2incXntGbvsGawCG PiIZ91fveIlnqLH54UVLw8Sgo+grHhy28l19SpZU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728295AbfL0Rn4 (ORCPT ); Fri, 27 Dec 2019 12:43:56 -0500 Received: from mail.kernel.org ([198.145.29.99]:41656 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727511AbfL0Rnz (ORCPT ); Fri, 27 Dec 2019 12:43:55 -0500 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6993921D7E; Fri, 27 Dec 2019 17:43:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1577468635; bh=M5YR3Aja1kN2HFjnI1fjDZZmVPUiQ4RWomKcTuwqkyQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TWIZ6NB6AvJzbESLu3n0aK/WW0FXLma1q0xSjUuj+yQRn/OWwZVhyiyAOLFt0NR+C jaF7PC5d9a95uf0IRRM1Y3Sgq/udetS5FV4yZ5rvdrxLQp5A2wgiijbwY40h8NSwrW vGnOlo/CR0mEkrjJYHRr5TauN2xZMy7kI7odCyF8= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tzung-Bi Shih , Pierre-Louis Bossart , Mark Brown , Sasha Levin , alsa-devel@alsa-project.org Subject: [PATCH AUTOSEL 4.19 02/84] ASoC: max98090: remove msleep in PLL unlocked workaround Date: Fri, 27 Dec 2019 12:42:30 -0500 Message-Id: <20191227174352.6264-2-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20191227174352.6264-1-sashal@kernel.org> References: <20191227174352.6264-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Tzung-Bi Shih [ Upstream commit acb874a7c049ec49d8fc66c893170fb42c01bdf7 ] It was observed Baytrail-based chromebooks could cause continuous PLL unlocked when using playback stream and capture stream simultaneously. Specifically, starting a capture stream after started a playback stream. As a result, the audio data could corrupt or turn completely silent. As the datasheet suggested, the maximum PLL lock time should be 7 msec. The workaround resets the codec softly by toggling SHDN off and on if PLL failed to lock for 10 msec. Notably, there is no suggested hold time for SHDN off. On Baytrail-based chromebooks, it would easily happen continuous PLL unlocked if there is a 10 msec delay between SHDN off and on. Removes the msleep(). Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20191122073114.219945-2-tzungbi@google.com Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- sound/soc/codecs/max98090.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index c3b28b2f4b10..f8c8b9decab6 100644 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -2132,10 +2132,16 @@ static void max98090_pll_work(struct work_struct *work) dev_info_ratelimited(component->dev, "PLL unlocked\n"); + /* + * As the datasheet suggested, the maximum PLL lock time should be + * 7 msec. The workaround resets the codec softly by toggling SHDN + * off and on if PLL failed to lock for 10 msec. Notably, there is + * no suggested hold time for SHDN off. + */ + /* Toggle shutdown OFF then ON */ snd_soc_component_update_bits(component, M98090_REG_DEVICE_SHUTDOWN, M98090_SHDNN_MASK, 0); - msleep(10); snd_soc_component_update_bits(component, M98090_REG_DEVICE_SHUTDOWN, M98090_SHDNN_MASK, M98090_SHDNN_MASK); -- 2.20.1