Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp308418pxa; Wed, 5 Aug 2020 01:29:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwpUzzXsni9qnhPQABwIFmr5ZB90fZAgLhXpOFr3s4GrmQZFWZhPXOQ4us3YH7/qumR2Bnw X-Received: by 2002:a17:906:c7d2:: with SMTP id dc18mr2168379ejb.135.1596616142081; Wed, 05 Aug 2020 01:29:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596616142; cv=none; d=google.com; s=arc-20160816; b=qDuoa7oHw+Xsn4Q35Tow/+USvOGSJ1fuPLB3avL++TMJ7eOcSZkHBe6WMh4VGjICyz ZSmtGmnyjd0ppbZxcJmTGG534GAdiyQMczjMdZf7bIrfiYnS67ipQQNL1uBnZhOd/3SW fwHV2TicftBu+HpnfFnQDi/ZceQJCY3Z9N+87bgupTCEthmEGd6GCkZz7mIc119vWxnQ oiPoL7k+LXfiNw9vvuCkCKJEZRH+znu4mMLf11G3Jz9wU5GK99PuybO79dx7vOAzzW5C Kz43CPoiN1CNT2Hh6xdgC28n8lzjT2rYstjtJwfCB57po/hN/cg8riRbG3jbU48NY+ku Szag== 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 :in-reply-to:references:mime-version:dkim-signature; bh=IsPXwyWsTau2EDU/u1Hk2SK//pn/XYCZgs8Tt7Pybic=; b=tf/CR6LyB84DfD6Ruy46QToWpKX4iXJ80kSJQ3nFwtFI/Ue5NAdaUGc+w/AnkcgQAh sUCzA1VYulml8RBmV9aCIgIz9QcbWogBLVrX6VzPCEn26GjieIJPSIL4BGmGMBghy6K9 nMvcGs0hraPmQbZtIshtLXYp+CTNo5SsWL4ZZ2kp9kwpG9hf6rk0Ho5z4lO4kH3zzZgW FZpf+X4To03WO8cGJb89ttfp9Y0XIt1MUYmf84NCAsqApDhDqUSwh5UFrw63B1SJpdji 2L9hhQQwokOHcA/DZKopC3DaQny0QxNzJlLLgFEVgZt6M04chDOqV/5siYyJUXiBjYLQ dYOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=nI6TJXwd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id k10si985541ejr.155.2020.08.05.01.28.38; Wed, 05 Aug 2020 01:29:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=nI6TJXwd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1726841AbgHEI2L (ORCPT + 99 others); Wed, 5 Aug 2020 04:28:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53900 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726563AbgHEI2H (ORCPT ); Wed, 5 Aug 2020 04:28:07 -0400 Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8DC7FC061756 for ; Wed, 5 Aug 2020 01:28:06 -0700 (PDT) Received: by mail-vs1-xe43.google.com with SMTP id 1so17581565vsl.1 for ; Wed, 05 Aug 2020 01:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IsPXwyWsTau2EDU/u1Hk2SK//pn/XYCZgs8Tt7Pybic=; b=nI6TJXwdcL8bsQtueioGpxs1dnaTvpDVsDZvaDqlGBNhUdKfsh3Ax4gkI9R9KzByby 8jJhFplzdD7cedGGornU3Sq/8xENfGxLhTdDZg0LMO0HRolLV3RoODT975OyxFwJK86M zxMyJhe38lQGPCZA7b8IcQANrGzmK+yhmW0cT2sZ1CqtxuhQmzOk2suo0PxTJaBiG7Ct q1skvui95tv+FxbN1SOWHbMuw9brQPG7q9Slbcj39DTVV4mNCn1jQZbG4kLwhf9+EKTr aY+EfjilP05q9s24WEegAZtXoiSsaDMQoKkKROzep7pMY1W1g9lsKFX+NBq6TVTiAqzo NHkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IsPXwyWsTau2EDU/u1Hk2SK//pn/XYCZgs8Tt7Pybic=; b=BM9VjxuQ1tcD8M28KLh9WYacC8GloPO0SAtsp36ovKYRllpGKwQ9qwBwUIZdkXohZ2 7x02eVnueB9uwW2a3D/Kr+/CnEu2axyU/Wkd4D5r98Cbmk+JiIViHNeASVtJcASTXSDy NcTWvB8Yc9pYBeoJm/66Roo+u9XsPBmaLHYub7EXbIr6uhKZL55FjyZrmx4Pu4ULXPtv rIoiC3GbnPp+BeoumbskRGmD3Y3N+NCRKvkk8Ko7j2IhTyCb6xG8VLUPXTdmD1FoWKMb o5aW9wcR8dYcGwlMoksOB6I3Zll46N2PHiPgBmAHH8Nh7ON8xTI28DK09EhoZBSEUEEf dyew== X-Gm-Message-State: AOAM530qsGEKFwu6wkHJVZoS2x8Z4yQOEBVKlDFvmJq2a9h++FhQnNdp wL2sC+egHZNFyAaBSSrXXR93513a6ItNQrc9whINWA== X-Received: by 2002:a67:8c06:: with SMTP id o6mr1130507vsd.200.1596616085611; Wed, 05 Aug 2020 01:28:05 -0700 (PDT) MIME-Version: 1.0 References: <20200721191718.29414-1-alcooperx@gmail.com> In-Reply-To: From: Ulf Hansson Date: Wed, 5 Aug 2020 10:27:29 +0200 Message-ID: Subject: Re: [PATCH] mmc: Some Micron eMMC devices cause reboot to hang To: Alan Cooper Cc: Linux Kernel Mailing List , Bradley Bolen , "linux-mmc@vger.kernel.org" , =?UTF-8?Q?Pali_Roh=C3=A1r?= 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 Mon, 27 Jul 2020 at 15:07, Alan Cooper wrote: > > On Fri, Jul 24, 2020 at 7:03 AM Ulf Hansson wrote: > > > > On Tue, 21 Jul 2020 at 21:18, Al Cooper wrote: > > > > > > When using eMMC as the boot device, some Micron eMMC devices will > > > cause reboot to hang. This is a result of the eMMC device not going > > > into boot mode after the hardware sends CMD0 to reset the eMMC > > > device. This only happens if the kernel driver sends CMD5 (SLEEP_WAKE), > > > to put the device into sleep state, before restarting the system. > > > > What do you mean by "boot mode"? > > I'm referring to the "Boot operation mode" described in Section 6.3 of > the JEDEC spec. > Our hardware will send a CMD0 with 0xf0f0f0f0 argument at powerup or > when the SoC is reset, and then hold the CLK signal low for 74 clock > cycles. This should put the eMMC device into boot mode where it > streams consecutive blocks without additional commands. With this > Micron device I find that if I send a CMD5 before trying to restart > the system by resetting the SoC, that the system hangs. I worked with > Micron on the issue and they finally said to either avoid sending the > CMD5 on restart or use a newer version of the Micron eMMC device. Thanks for clarifying the test sequence! However, I am still not (yet) convinced that a card quirk is the right thing to do. What does the eMMC spec say about sending a CMD0 with 0xf0f0f0f0 to a device that "sleeps"? Moreover, how does your mmc host driver (and platform) treat VCC and VCCQ at system suspend/resume, compared to when a reset is done? Is there a difference? The point is, if the eMMC spec is being violated, we should not make a card quirk - as it may cause problems for other platforms. > > > > > > When the kernel sends the CMD0 to wake up the eMMC from sleep, at > > system resume for example, it all works fine, I guess. What is the > > difference? > > On system resume the hardware will not try to put the eMMC device back > into boot mode. I see. Does your host driver support HW busy signalling, so DAT0 is monitored for de-assertion to confirm the CMD5 is completed by the kernel - or do you rely on the per card sleep timeout to be used in mmc_sleep()? Additionally, I wonder about what options you have to reset the eMMC? Can we use something along the lines of drivers/mmc/core/pwrseq_emmc.c? If it's not possible to do a HW reset, we could try sending CMD0 with argument being '0' in the reset path. What do you think? > > Al > > > > > > The fix is to add a quirk that avoids sending the SLEEP command > > > and to use MMC_FIXUP to set the quirk for these Micron devices. > > > > I am not sure this is Micron device specific, but rather some it's a > > driver/platform bug. Maybe on the kernel side or in the bootloader > > code. > > Kind regards Uffe > > > > > > > > Signed-off-by: Al Cooper > > > --- > > > drivers/mmc/core/mmc.c | 3 ++- > > > drivers/mmc/core/quirks.h | 8 ++++++++ > > > include/linux/mmc/card.h | 1 + > > > 3 files changed, 11 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c > > > index 4203303f946a..4d69e8f8fe59 100644 > > > --- a/drivers/mmc/core/mmc.c > > > +++ b/drivers/mmc/core/mmc.c > > > @@ -1895,7 +1895,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr, > > > > > > static int mmc_can_sleep(struct mmc_card *card) > > > { > > > - return (card && card->ext_csd.rev >= 3); > > > + return card && card->ext_csd.rev >= 3 && > > > + ((card->quirks & MMC_QUIRK_BROKEN_SLEEP) == 0); > > > } > > > > > > static int mmc_sleep(struct mmc_host *host) > > > diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h > > > index 472fa2fdcf13..7263187b6323 100644 > > > --- a/drivers/mmc/core/quirks.h > > > +++ b/drivers/mmc/core/quirks.h > > > @@ -99,6 +99,14 @@ static const struct mmc_fixup mmc_blk_fixups[] = { > > > MMC_FIXUP("V10016", CID_MANFID_KINGSTON, CID_OEMID_ANY, add_quirk_mmc, > > > MMC_QUIRK_TRIM_BROKEN), > > > > > > + /* > > > + * Some Micron eMMC devices will not go into boot mode on > > > + * CMD0 arg: 0XF0F0F0F0 after going into SLEEP state. > > > + * This will hang a reboot. > > > + */ > > > + MMC_FIXUP(CID_NAME_ANY, CID_MANFID_NUMONYX, 0x014e, add_quirk_mmc, > > > + MMC_QUIRK_BROKEN_SLEEP), > > > + > > > END_FIXUP > > > }; > > > > > > diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h > > > index 7d46411ffaa2..0cdddcb5e17d 100644 > > > --- a/include/linux/mmc/card.h > > > +++ b/include/linux/mmc/card.h > > > @@ -270,6 +270,7 @@ struct mmc_card { > > > #define MMC_QUIRK_BROKEN_IRQ_POLLING (1<<11) /* Polling SDIO_CCCR_INTx could create a fake interrupt */ > > > #define MMC_QUIRK_TRIM_BROKEN (1<<12) /* Skip trim */ > > > #define MMC_QUIRK_BROKEN_HPI (1<<13) /* Disable broken HPI support */ > > > +#define MMC_QUIRK_BROKEN_SLEEP (1<<14) /* Broken sleep mode */ > > > > > > bool reenable_cmdq; /* Re-enable Command Queue */ > > > > > > -- > > > 2.17.1 > > >