From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Christian Loehle <christian.loehle@arm.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
kernel@pengutronix.de, linux-kernel@vger.kernel.org,
linux-mmc@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Brown <broonie@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH v1 1/1] mmc: core: Handle undervoltage events and register regulator notifiers
Date: Thu, 13 Feb 2025 09:57:54 +0100 [thread overview]
Message-ID: <Z620Ei5FwhhPfBu9@pengutronix.de> (raw)
In-Reply-To: <96959ef4-2287-4601-85fb-2ce457c605d2@arm.com>
On Wed, Feb 12, 2025 at 11:47:08PM +0000, Christian Loehle wrote:
> On 2/12/25 13:24, Oleksij Rempel wrote:
> > Extend the MMC core to handle undervoltage events by implementing
> > infrastructure to notify the MMC bus about voltage drops.
> >
> > Background & Decision at LPC24:
> >
> > This solution was proposed and refined during LPC24 in the talk
> > "Graceful Under Pressure: Prioritizing Shutdown to Protect Your Data in
> > Embedded Systems" which aimed to address how Linux should handle power
> > fluctuations in embedded devices to prevent data corruption or storage
> > damage.
> >
> > At the time, multiple possible solutions were considered:
> >
> > 1. Triggering a system-wide suspend or shutdown: when undervoltage is
> > detected, with device-specific prioritization to ensure critical
> > components shut down first.
> > - This approach was disliked by Greg Kroah-Hartman, as it introduced
> > complexity and was not suitable for all use cases.
> >
> > 2. Notifying relevant devices through the regulator framework: to allow
> > graceful per-device handling.
> > - This approach was agreed upon as the most acceptable: by participants
> > in the discussion, including Greg Kroah-Hartman, Mark Brown,
> > and Rafael J. Wysocki.
> > - This patch implements that decision by integrating undervoltage
> > handling into the MMC subsystem.
> >
> > This patch was tested on iMX8MP based system with SDHCI controller.
>
> Any details here? How long does it take from undervoltage to
> poweroff notification.
On this system, with current implementation, it takes 4.5 millisecond
from voltage drop detection to mmc_poweroff_notify.
> Roughly how long of a heads up would that yield in realistic
> undervoltage scenarios?
It depends on the board implementation and attached power supply.
In my case, the testing system provides about 100ms capacity on board.
The power supply provides additional 1-2 seconds.
If the power is cut between power supply and board, we will have max
100ms.
> > +static int _mmc_handle_undervoltage(struct mmc_host *host)
> > +{
> > + return mmc_shutdown(host);
> > +}
> > +
>
> The poweroff notification part I understand, because it polls for busy
> (i.e. hopefully until the card thinks it's done committing to flash).
> Poweroff isn't always available though, the other paths of
> _mmc_suspend() are:
>
> else if (mmc_can_sleep(host->card))
> err = mmc_sleep(host);
> else if (!mmc_host_is_spi(host))
> err = mmc_deselect_cards(host);
>
> if (!err) {
> mmc_power_off(host);
>
> So we may also just deselect, which AFAIR succeeds as a FSM (i.e.
> doesn't mean anything was committed to flash) and then we just
> poweroff.
> Is that what we want in an undervoltage scenario?
Yes. In an undervoltage scenario, our primary priority is to protect the
hardware from damage. Data integrity is secondary in this case. The most
critical action is to immediately stop writing to the card.
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2025-02-13 8:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 13:24 [PATCH v1 1/1] mmc: core: Handle undervoltage events and register regulator notifiers Oleksij Rempel
2025-02-12 23:47 ` Christian Loehle
2025-02-13 8:57 ` Oleksij Rempel [this message]
2025-02-13 11:13 ` Christian Loehle
2025-02-13 10:14 ` Avri Altman
2025-02-13 11:09 ` Oleksij Rempel
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=Z620Ei5FwhhPfBu9@pengutronix.de \
--to=o.rempel@pengutronix.de \
--cc=broonie@kernel.org \
--cc=christian.loehle@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=ulf.hansson@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox