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 EAD9CC433EF for ; Wed, 4 May 2022 05:56:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344751AbiEDGAF (ORCPT ); Wed, 4 May 2022 02:00:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230149AbiEDGAE (ORCPT ); Wed, 4 May 2022 02:00:04 -0400 X-Greylist: delayed 572 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Tue, 03 May 2022 22:56:28 PDT Received: from smtp2.math.uni-bielefeld.de (smtp2.math.uni-bielefeld.de [129.70.45.13]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7DE69201BC; Tue, 3 May 2022 22:56:28 -0700 (PDT) Received: from math.uni-bielefeld.de (kvm01.math.uni-bielefeld.de [129.70.45.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp2.math.uni-bielefeld.de (Postfix) with ESMTPSA id 72BA360213; Wed, 4 May 2022 07:46:53 +0200 (CEST) Date: Wed, 4 May 2022 07:46:52 +0200 From: Jean Rene Dawin To: Ulf Hansson Cc: "H . Nikolaus Schaller" , Huijin Park , linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org Subject: Re: [PATCH] mmc: core: Restore (almost) the busy polling for MMC_SEND_OP_COND Message-ID: <20220504054652.GA7851@math.uni-bielefeld.de> References: <20220304105656.149281-1-ulf.hansson@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org Ulf Hansson wrote on Mon 7/03/22 13:17: > On Fri, 4 Mar 2022 at 11:57, Ulf Hansson wrote: > > > > Commit 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1"), > > significantly decreased the polling period from ~10-12ms into just a couple > > of us. The purpose was to decrease the total time spent in the busy polling > > loop, but unfortunate it has lead to problems, that causes eMMC cards to > > never gets out busy and thus fails to be initialized. > > > > To fix the problem, but also to try to keep some of the new improved > > behaviour, let's start by using a polling period of 1-2ms, which then > > increases for each loop, according to common polling loop in > > __mmc_poll_for_busy(). > > > > Reported-by: Jean Rene Dawin > > Reported-by: H. Nikolaus Schaller > > Cc: Huijin Park > > Fixes: 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1") > > Signed-off-by: Ulf Hansson > > --- > > > > Jean Rene and H. Nikolaus, if this doesn't work, please try extending the > > the MMC_OP_COND_PERIOD_US a bit, to so see if we can find a value that always > > works. > > > > Kind regards > > Uffe > > Applied for fixes and by adding two tested-by tags from you, thanks! > > Kind regards > Uffe Hi, with the current value of MMC_OP_COND_PERIOD_US = 1ms I still see mmc1: Card stuck being busy! __mmc_poll_for_busy mmc1: error -110 doing runtime resume regularly. The same with 2ms. Setting it to 4ms makes the messages go away. Would it be ok to increase MMC_OP_COND_PERIOD_US to 4ms? --- drivers/mmc/core/mmc_ops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c index 180d7e9d3400..1fd57f342842 100644 --- a/drivers/mmc/core/mmc_ops.c +++ b/drivers/mmc/core/mmc_ops.c @@ -21,7 +21,7 @@ #define MMC_BKOPS_TIMEOUT_MS (120 * 1000) /* 120s */ #define MMC_SANITIZE_TIMEOUT_MS (240 * 1000) /* 240s */ -#define MMC_OP_COND_PERIOD_US (1 * 1000) /* 1ms */ +#define MMC_OP_COND_PERIOD_US (4 * 1000) /* 1ms */ #define MMC_OP_COND_TIMEOUT_MS 1000 /* 1s */ static const u8 tuning_blk_pattern_4bit[] = { -- 2.35.1 Regards, Jean Rene