All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Majewski <lukma@denx.de>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Fabio Estevam <fabio.estevam@nxp.com>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Chanho Min <chanho.min@lge.com>,
	devicetree@vger.kernel.org,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Stanislav Meduna <stanislav.meduna@nxtcontrol.com>
Subject: Re: [PATCH] mmc: disable card sleep via device-tree
Date: Mon, 23 Apr 2018 11:36:19 +0200	[thread overview]
Message-ID: <20180423113619.6f557d8e@jawa> (raw)
In-Reply-To: <CAPDyKFqaV0ehiHCNdt0i4sWE9cskBa9AQHdRZmzCphPzCdm9ow@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6088 bytes --]

Hi Ulf,

> On 22 April 2018 at 23:31, Lukasz Majewski <lukma@denx.de> wrote:
> > From: Stanislav Meduna <stanislav.meduna@nxtcontrol.com>
> >
> > 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 <stanislav.meduna@nxtcontrol.com>
> > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > ---
> >  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().

The mmc_power_off() -> mmc_pwrseq_power_off() -> here the *pwrseq is
null, so we do nothing with the power.

In mmc_power_off() function we call mmc_set_initial_state(host);

> Does your host driver cut power to VMMC and/or
> VQMMC?

The esdhci3 controller uses 'vmm-supply' which is a 'regulator-fixed'
with 'regulator-always-on' attribute.

It seems like the eMMC is always powered with 3.3V.

Considering the above it seems like the card is still powered - the HW
design also supports some backup powering (so the voltage from the
board is not took immediately).


To be even more strange the suspend to mem works without any issues
(without this patch).
With "reboot -f" it seems like we hang in imx53 BootROM (as I can read
it from my JTAG debugger).

As written in the commit message - problems started after sending
suspend sequence of eMMC commands to the eMMC device.


[The eMMC memory itself is Micron 4GiB - 4.4.1]

> 
> >                 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




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-04-23  9:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-22 21:31 [PATCH] mmc: disable card sleep via device-tree Lukasz Majewski
2018-04-23  6:04 ` Vladimir Zapolskiy
2018-04-23  6:04   ` Vladimir Zapolskiy
2018-04-23  8:26 ` Ulf Hansson
2018-04-23  9:36   ` Lukasz Majewski [this message]
2018-04-23 10:24     ` Ulf Hansson
2018-04-23 14:11       ` Lukasz Majewski
2018-04-23 15:01         ` Ulf Hansson
2018-04-30  9:13 ` Linus Walleij
2018-04-30  9:31   ` Lukasz Majewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180423113619.6f557d8e@jawa \
    --to=lukma@denx.de \
    --cc=adrian.hunter@intel.com \
    --cc=chanho.min@lge.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fabio.estevam@nxp.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=stanislav.meduna@nxtcontrol.com \
    --cc=ulf.hansson@linaro.org \
    --cc=wsa+renesas@sang-engineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.