Received: by 10.192.165.148 with SMTP id m20csp3161096imm; Mon, 23 Apr 2018 01:27:49 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+jR8FQ7qdbIuit85XpYuR8btIc5nQ+hnIHuFSKtL/BeXjJe+fTEkkpA+OJaqT7bUzGtF/c X-Received: by 10.99.45.70 with SMTP id t67mr16121001pgt.439.1524472069595; Mon, 23 Apr 2018 01:27:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524472069; cv=none; d=google.com; s=arc-20160816; b=j/vhMMVBUaIPm3dbEassceWF65bwfUZy2gVrbxW4o/mSVPRi49ZGYSK42kAfmYA451 wHL4aclzpMFd+95UVFY+81YnfBe7p73ckM1/jWLHz9NCEak4S32mcklyfb/h8DDSu2oy ZSvfCczrSxTnrabfepAYtdK1Xos1BVwCedtHgL3VzEkaO9oeX1xxAXTuvV5MN7XjOb1N Nh6xwzJlZc+iPDJR9IWKaVcMAQ+LBrhutJDvX4BYhykjEujTaHePh+ABugpyZcrU5sQp 7OxRGOOCfSofgfwpgQoH+XtjyX3/UvWD6sUrS4NirthIennjvw4X9N2G3pHa/gTem6Um UUtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=7QKPGnHUqIvsRxCRDk9EoZI9TvjxZoosmU7GcXD8hVs=; b=dNvQl7ypxT8tKq+HPXwBHAtQR/FsP0E5M7N3gfZS9BORKaGLj515A2fudBV8uZAasv FtLhavLclStcmRtlFZYE5HHfhATWiFgLeqB3FFfaXUUxBHtIMH3O5ACnVN18Yn/JFiDs wGxK3rQc0HNomNw1gzntQWY74LRUcNGfKDtnoOyl8QPuWCNpNA0YvFSIcVhMvLI/b/eP PmozWXrDbNZ8GV2muYE6AWPM0mgBzE7UbY79aA1dolMIK5umoITeJtD32H3LnrCMkusZ M6Oj4tB9uO34mh11hiXIejCqrMENSPYfPAOtmSTofw/2TNhhqEwGmaLcfHxJSSQvPPYO BA5w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=kUnRo9bI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a13-v6si12612185plt.142.2018.04.23.01.27.35; Mon, 23 Apr 2018 01:27:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=kUnRo9bI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754541AbeDWI0R (ORCPT + 99 others); Mon, 23 Apr 2018 04:26:17 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:34103 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754482AbeDWI0L (ORCPT ); Mon, 23 Apr 2018 04:26:11 -0400 Received: by mail-io0-f193.google.com with SMTP id d6-v6so17485073iog.1 for ; Mon, 23 Apr 2018 01:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7QKPGnHUqIvsRxCRDk9EoZI9TvjxZoosmU7GcXD8hVs=; b=kUnRo9bIfJfOUZZ/VWeu0fC/azbURrxlhcZe6Et9Faj4VsneqjHGvOyavek/bdafHx flPhBcogmou4O/Jjq+r5o7EVuCzz18Qe2pq/fif+1lD7JkXwL+uRB0ZOH0Curvf/MQKC l11xbxaH/chzlUSYpQZCP1U4BiBakXxiLgUM8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7QKPGnHUqIvsRxCRDk9EoZI9TvjxZoosmU7GcXD8hVs=; b=Ir9DZBJlE52/syPJfWXvN0z4vKGbYqOT2yPDtrIQu6KNewDeEkB9a//jah+H01dSon hZ8Al2Czn7YIolm/ZulrnetKrviujbQQvEfjNdVAuSU7tfaBfdFbMTJErNL8HBwvBbOA v0kRgBlvvNxTFXjVZug53ihf3rjToJWLKsaxnOhVfOh5eeMgj6ps29DZ5i6/KXmBg66Y 1Z07usgtpsBLhbJZElLPKv6dU34KW3R6w1Tj+KwyTKW2TdyeSpwAwcfVAkGISusSAK/N 8aqZcApjYg9AQtxwDsj0DuERe8PR6LC8TN7hhpVbsfvtMjGVKpF5P6PvqLVssLxAC+Ot cghg== X-Gm-Message-State: ALQs6tDH2rwD2FPdbDPvYjWZZnJoTr3F4zP4Tzj0kG1KekRCgEsPmTL6 BFYzfW4xPHYBZ1XPv1lwpR9FARPJog0UxMBj4I5niA== X-Received: by 2002:a6b:c6cb:: with SMTP id w194-v6mr20006369iof.131.1524471970583; Mon, 23 Apr 2018 01:26:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:734a:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 01:26:09 -0700 (PDT) In-Reply-To: <20180422213126.32756-1-lukma@denx.de> References: <20180422213126.32756-1-lukma@denx.de> From: Ulf Hansson Date: Mon, 23 Apr 2018 10:26:09 +0200 Message-ID: Subject: Re: [PATCH] mmc: disable card sleep via device-tree To: Lukasz Majewski Cc: Linus Walleij , Linux Kernel Mailing List , Rob Herring , Mark Rutland , Adrian Hunter , Fabio Estevam , Wolfram Sang , Chanho Min , devicetree@vger.kernel.org, "linux-mmc@vger.kernel.org" , Stanislav Meduna Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22 April 2018 at 23:31, Lukasz Majewski wrote: > From: Stanislav Meduna > > On a TQMa53 module the mmc_sleep leaves the eMMC card in a state > that the imx53 rom boot code is unable to probe, resulting in > reboot hanging. Add a device tree property to disable sleeping > on suspend. > > For TQMa53 modules the exact commit to cause hang after reboot > (v3.10 -> v3.11): > commit 486fdbbc1483 ("mmc: core: Add shutdown callback for (e)MMC bus_ops") > > [The exact discussion can be found here: > https://patchwork.kernel.org/patch/8881401/ > "i.MX53 restart via watchdog does not work" > > Signed-off-by: Stanislav Meduna > Signed-off-by: Lukasz Majewski > --- > Documentation/devicetree/bindings/mmc/mmc-card.txt | 4 ++++ > drivers/mmc/core/mmc.c | 7 +++++-- > include/linux/mmc/card.h | 2 +- > 3 files changed, 10 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.txt b/Documentation/devicetree/bindings/mmc/mmc-card.txt > index 8d2d71758907..c3ee151edd7c 100644 > --- a/Documentation/devicetree/bindings/mmc/mmc-card.txt > +++ b/Documentation/devicetree/bindings/mmc/mmc-card.txt > @@ -12,6 +12,9 @@ Required properties: > Optional properties: > -broken-hpi : Use this to indicate that the mmc-card has a broken hpi > implementation, and that hpi should not be used > +-no-sleep-on-suspend : Do not put the card to sleep when suspending. > + There are boards with bootloaders that are unable > + to probe such card when rebooting. > > Example: > > @@ -26,5 +29,6 @@ Example: > reg = <0>; > compatible = "mmc-card"; > broken-hpi; > + no-sleep-on-suspend; > }; > }; > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c > index 208a762b87ef..a3b74b5c8893 100644 > --- a/drivers/mmc/core/mmc.c > +++ b/drivers/mmc/core/mmc.c > @@ -381,8 +381,11 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 *ext_csd) > } > > np = mmc_of_find_child_device(card->host, 0); > - if (np && of_device_is_compatible(np, "mmc-card")) > + if (np && of_device_is_compatible(np, "mmc-card")) { > broken_hpi = of_property_read_bool(np, "broken-hpi"); > + card->no_sleep_on_suspend = > + of_property_read_bool(np, "no-sleep-on-suspend"); > + } > of_node_put(np); > > /* > @@ -1990,7 +1993,7 @@ static int _mmc_suspend(struct mmc_host *host, bool is_suspend) > if (mmc_can_poweroff_notify(host->card) && > ((host->caps2 & MMC_CAP2_FULL_PWR_CYCLE) || !is_suspend)) > err = mmc_poweroff_notify(host->card, notify_type); > - else if (mmc_can_sleep(host->card)) > + else if (mmc_can_sleep(host->card) && !host->card->no_sleep_on_suspend) No, this is wrong. This means that the mmc_power_off() a few lines below would start to violate the eMMC spec. That via powering off the card, without first sending the sleep or power-off-notify command. You are probably just lucky, as your particular eMMC card still copes with this in-correct sequence (I know there are these kind of cards). Well, what is also interesting in this regards, is what is happening during mmc_power_off(). Does your host driver cut power to VMMC and/or VQMMC? > err = mmc_sleep(host); > else if (!mmc_host_is_spi(host)) > err = mmc_deselect_cards(host); > diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h > index 279b39008a33..c64d88e6de3b 100644 > --- a/include/linux/mmc/card.h > +++ b/include/linux/mmc/card.h > @@ -304,8 +304,8 @@ struct mmc_card { > struct dentry *debugfs_root; > struct mmc_part part[MMC_NUM_PHY_PARTITION]; /* physical partitions */ > unsigned int nr_parts; > - > unsigned int bouncesz; /* Bounce buffer size */ > + bool no_sleep_on_suspend; > }; > > static inline bool mmc_large_sector(struct mmc_card *card) > -- > 2.11.0 > My impression is that it seems like there are still some uncertainties around what actually happens when the failure occurs during re-boot. I am guessing this boils done to how VMMC and VQMMC are being managed. BTW, in the the pwrseq_emmc, we register a restart handler to pull the reset GPIO for the eMMC. Perhaps that can help to fix this problem as well!? Kind regards Uffe