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=-0.7 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 2AAB5CA9EAF for ; Thu, 24 Oct 2019 18:24:30 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2BD9720684 for ; Thu, 24 Oct 2019 18:24:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="Qo0bEcME"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="F2nNcF/u" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2BD9720684 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id DC3B116FF; Thu, 24 Oct 2019 20:23:36 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz DC3B116FF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1571941467; bh=UPnQ2t0DqMlSwuZl/FcfPmy3am+MJwUm2Rg9ARtOxKc=; h=From:Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From; b=Qo0bEcMEAWMX/wwpSYLgkJ1p7mqBdevP5ZrmwdNomiX2hgJFLA3n7NLgc9jiZ3W+k qakBJO3Yt7wjs/JOZ1OxxmlCoI6bZ3NIuBV8TqyA+dQ7sJxU21Y9Ti+AI3cVXTufVq 0x8mlpDjGFApZ5OIzrcK1IurGoLo8mDgpf8R0C00= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 57A27F80367; Thu, 24 Oct 2019 20:23:36 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id DC1DBF8036B; Thu, 24 Oct 2019 20:23:34 +0200 (CEST) Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 33811F80274 for ; Thu, 24 Oct 2019 20:23:31 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 33811F80274 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="F2nNcF/u" Received: by mail-ot1-x341.google.com with SMTP id 53so9925247otv.4 for ; Thu, 24 Oct 2019 11:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=hCs2FuxbDBa/uwBY4Y8k7cKxguq9rRFLJ7isgBrWpbE=; b=F2nNcF/uNAU2yWtZgNDCggJBxm3JJDLnbvceCMTbZcUntbBcHhhoIzX+1Q6qiA4k/v yAUrapLUL87sFZsnTShkPD2HGJo2Mj86HRlRQTmQWycU1W83JXpg1D6/Rl72EGAcdf0O btp7W8B32vkJR/BKgQyb8FYVcYkhfA2cNo97uMNXqHjySCKRWZNPrsfAtRgRGE/4/QeR GqTx0WOJjMnEo/t0+KJrlNluWxuNT3o6pojV+thCfuq4Nc3wUX8o78P+PcqM6RVI2J+G 6Bv2kf7e1LefJcPZlBN5cOn8RtXq2X1xUrbrX0l/yT++u4pFwVxJEjNgjpEweyqvbq4a KYdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=hCs2FuxbDBa/uwBY4Y8k7cKxguq9rRFLJ7isgBrWpbE=; b=k0+QO5RIaGo7PO+VAK/M5WZrA2SbbU8Jf2PmaMUgqxmcXmBEopzBeO3mB+Pho0Kkrj drkWDbyQks7gBv2eKErleqDJYsGj8U7wDi0FvgJ2nqaWplT5YhKRxVCgUAY3P5I5rTnr jfl4BsE/WCFbeaTmYozXqawvF3UEv+XlVpdQF0Gh+IkBvnde8hZdN74q2YDgKkSKsgLF bWV4FTu3i3IiGqUj6FndZZnsfDLy9YCYvWqt10KOVuyECaFv+LlG2477GZ29X7p20Ndh qtMzvAruIO3SkoQBe9SMmXG96GkaR2B4+6AYB9zBS1Cfl/cAx77ll1iGS9AS2bkdYDsA ODnA== X-Gm-Message-State: APjAAAWlFT35Vnj3EQqYr+5iOyXkSoXIxV7aQzMdtOOwtbf26KIVK+CA c0T7ONYvAdSKVirMQVce08U5G5TQip91CmXYS+P0mA== X-Google-Smtp-Source: APXvYqzxSnfQMJlcXU+5F1IsFWuQkXMN8JDnIO0ygbXFVEcHevekp0asJLH7pIIrSwMP/hNfWxSoyiDZa4W2egr59NY= X-Received: by 2002:a9d:baf:: with SMTP id 44mr3613764oth.182.1571941409590; Thu, 24 Oct 2019 11:23:29 -0700 (PDT) MIME-Version: 1.0 From: Tzung-Bi Shih Date: Fri, 25 Oct 2019 02:23:18 +0800 Message-ID: To: Liam Girdwood , Mark Brown , Takashi Iwai , Pierre-Louis Bossart , jarkko.nikula@linux.intel.com Cc: ALSA development , Jimmy Cheng-Yi Chiang , Tzung-Bi Shih , Benson Leung , Dylan Reid , Hsin-yu Chao Subject: [alsa-devel] Questions about max98090 codec driver X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Hi, I am studying an odd issue of max98090 codec on Baytrail-based chromebook. The issue is: when user playback and capture simultaneously, it seems the PLL never get locked if msleep(10) between the SHDN off and on (https://elixir.bootlin.com/linux/v5.4-rc2/source/sound/soc/codecs/max98090.c#L2120). The playback stream becomes silent and the console keeps printing "PLL unlocked". But, if comment out the msleep(10) between the SHDN off and on, the issue fixed. I am trying to find the reason but facing further more questions and may need your inputs. 1. The commit b8a3ee820f7b ("ASoC: max98090: Add recovery for PLL lock failure") enables ULK interrupts (https://elixir.bootlin.com/linux/v5.4-rc2/source/sound/soc/codecs/max98090.c#L2088) when PCM stream starting. If max98090 claims its PLL is unlocked, max98090_pll_work() get scheduled to workaround it by SHDN off and on (https://elixir.bootlin.com/linux/v5.4-rc2/source/sound/soc/codecs/max98090.c#L2106). I feel it is weird to sleep in max98090_pll_work(). Especially, at this line https://elixir.bootlin.com/linux/v5.4-rc2/source/sound/soc/codecs/max98090.c#L2125 (it makes less sense to "wait" in another thread). Note that, the threaded IRQF_ONESHOT handler and max98090_pll_work() are in 2 different threads. I guess the original intention is: - disable ULK interrupt in IRQ handler (https://elixir.bootlin.com/linux/v5.4-rc2/source/sound/soc/codecs/max98090.c#L2260) - schedule max98090_pll_work() to workaround it - wait 10ms to give PLL chance to lock - enable ULK interrupt again If max98090 claims its PLL is unlocked again, repeat the above by receiving another ULK interrupt. Unfortunately, the odd issue seems not be fixed by my rough implementation of these. 2. According to the datasheet page 164 table 90 (https://datasheets.maximintegrated.com/en/ds/MAX98090.pdf), there are some registers should only be adjusted when SHDN==0. But I fail to find max98090.c tries to set SHDN to 0 and restore it afterwards when writing to these registers. For example, https://elixir.bootlin.com/linux/v5.4-rc2/source/sound/soc/codecs/max98090.c#L1897. I am wondering if it would bring any side effects because the datasheet states "Changing these settings during normal operation (SHDN=1) can compromise device stability and performance specifications." 3. By searching some history data, I found a previous version did not have the msleep(10) between the SHDN off and on (https://crrev.com/c/191740, click the file name in the middle of the window to see the diff. Pardon me, I do not find another public repository for this). I am curious if anyone of you still remember why the upstream version contains the msleep(10). I am also curious if anyone of your environment works well with the upstream version max98090.c. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel