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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D31A5C433EF for ; Wed, 27 Apr 2022 04:42:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/q7gKTambbCIBZ5e0X3uyS86HKRymolHZTCWniZNWbQ=; b=uEpR9SMDIAzjR/ VlkztT2QHGCuyFnqdumthESttf4i7Y8t+O1R0OIfa/K3f/INw17K7uz/aDikOJZBuL9guE0jjwmDe Wjc/7TqF4yhrpzuGa0kLp7jc0qZ6vKP2ttilAyrQoAFapQ8F9qnJf/NJuverBfpchMcZlhseqyKUv xko0zjjOoKHnhbUELEElQCIgY2BdLDsapwIkcHA66LdobgdxvbV6mTqrEfDx2k7SqSfQ+A9e3KoOO 0caARks8H5suxLvJBPfadhE0wbhEjeDCdeAcFGfJnF/gIQpaL5Sg3u4vL6nn0Le/WXZ7gPsBengMK smS+yugfc4WnhL3yw2cQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1njZUL-00HPKA-MO; Wed, 27 Apr 2022 04:41:17 +0000 Received: from mga05.intel.com ([192.55.52.43]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1njZUH-00HPIy-HP for linux-arm-kernel@lists.infradead.org; Wed, 27 Apr 2022 04:41:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651034473; x=1682570473; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=FOoMj3CV1xNcLvj1+jF+2iIlIlqLKQAJc7bxju62e08=; b=LK/WMI02pAQ5l9tldZ7IzhgLDqbr27uD4ozhBzGitl6fkkLp9tRbtOCW 1JBqZjp1DY/TbqtZpEK23ZiUoZ8o/ZtprkRAMynRi+ai498ynLxhMkCqy uYuXTRvSZMgdtxVhsn69M1ym524K7Hc9Sg5AU7PrkvuBEwULiktRU0y5c 4gN2tAArq2LrGnKe6G9xUNAo8dJg988yG36lpelyQYe+mU2mo0q2QN/F9 aAqNDhsbbxSBMA7Gs7mTSkaQ9Mqs2TCrcWLklwN7zvJpdxegJeaB3PFAP TIV3vYUPsp+0KP/TWdn9h8XocauFxzd+X2rs2GVYZVUNEymTjRtji7Zo2 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10329"; a="352250059" X-IronPort-AV: E=Sophos;i="5.90,292,1643702400"; d="scan'208";a="352250059" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 21:41:09 -0700 X-IronPort-AV: E=Sophos;i="5.90,292,1643702400"; d="scan'208";a="580363700" Received: from ahunter6-mobl1.ger.corp.intel.com (HELO [10.0.2.15]) ([10.252.60.122]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 21:41:06 -0700 Message-ID: <7ef5d473-a3ce-c66e-df33-14c4e91596e2@intel.com> Date: Wed, 27 Apr 2022 07:41:02 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.7.0 Subject: Re: [PATCH 1/5] mmc: sdhci-brcmstb: "mmc1: Internal clock never stabilised." seen on 72113 Content-Language: en-US To: Kamal Dasu , ulf.hansson@linaro.org, robh+dt@kernel.org, krzk+dt@kernel.org, alcooperx@gmail.com Cc: f.fainelli@gmail.com, bcm-kernel-feedback-list@broadcom.com, linux-mmc@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20220421182803.6495-1-kdasu.kdev@gmail.com> <20220421182803.6495-2-kdasu.kdev@gmail.com> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki In-Reply-To: <20220421182803.6495-2-kdasu.kdev@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220426_214113_637788_C65DF8D6 X-CRM114-Status: GOOD ( 26.99 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 21/04/22 21:27, Kamal Dasu wrote: > From: Al Cooper > > The problem is in the .shutdown callback that was added to the > sdhci-iproc and sdhci-brcmstb drivers to save power in S5. The > shutdown callback will just call the sdhci_pltfm_suspend() function > to suspend the lower level driver and then stop the sdhci system > clock. The problem is that in some cases there can be a worker > thread in the "system_freezable_wq" work queue that is scanning > for a device every second. In normal system suspend, this queue > is suspended before the driver suspend is called. In shutdown the > queue is not suspended and the thread my run after we stop the > sdhci clock in the shutdown callback which will cause the "clock > never stabilised" error. The solution will be to have the shutdown > callback cancel the worker thread before calling suspend (and > stopping the sdhci clock). > > NOTE: This is only happening on systems with the Legacy RPi SDIO > core because that's the only controller that doesn't have the > presence signal and needs to use a worker thread to do a 1 second > poll loop. > > Fixes: 5b191dcba719 ("mmc: sdhci-brcmstb: Fix mmc timeout errors on S5 suspend") > Signed-off-by: Al Cooper > Signed-off-by: Kamal Dasu > --- > drivers/mmc/host/sdhci-brcmstb.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/mmc/host/sdhci-brcmstb.c b/drivers/mmc/host/sdhci-brcmstb.c > index f24623aac2db..11037cd14cfa 100644 > --- a/drivers/mmc/host/sdhci-brcmstb.c > +++ b/drivers/mmc/host/sdhci-brcmstb.c > @@ -313,6 +313,10 @@ static int sdhci_brcmstb_probe(struct platform_device *pdev) > > static void sdhci_brcmstb_shutdown(struct platform_device *pdev) > { > + struct sdhci_host *host = platform_get_drvdata(pdev); > + > + /* Cancel possible rescan worker thread */ > + cancel_delayed_work_sync(&host->mmc->detect); > sdhci_pltfm_suspend(&pdev->dev); > } > I think we fixed that already with the commit below: commit 66c915d09b942fb3b2b0cb2f56562180901fba17 Author: Ulf Hansson Date: Fri Dec 3 15:15:54 2021 +0100 mmc: core: Disable card detect during shutdown It's seems prone to problems by allowing card detect and its corresponding mmc_rescan() work to run, during platform shutdown. For example, we may end up turning off the power while initializing a card, which potentially could damage it. To avoid this scenario, let's add ->shutdown_pre() callback for the mmc host class device and then turn of the card detect from there. Reported-by: Al Cooper Suggested-by: Adrian Hunter Signed-off-by: Ulf Hansson Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211203141555.105351-1-ulf.hansson@linaro.org _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel