linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
To: Alexandre Ghiti <alexandre.ghiti@canonical.com>,
	Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Cc: Support Opensource <Support.Opensource@diasemi.com>,
	Lee Jones <lee.jones@linaro.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] drivers: mfd: da9063: Add restart notifier implementation
Date: Thu, 30 Sep 2021 10:47:57 +0000	[thread overview]
Message-ID: <DB9PR10MB46524AA5496F513E34A2BF2480AA9@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CA+zEjCtViMOXERby6A=wOKswQOFL60kTidc4+LY6_Y5svB_kLQ@mail.gmail.com>

On 30 September 2021 10:38, Alexandre Ghiti wrote:

> > Regardless of this though, the consensus right now would be to use the RTC as
> a
> > wake event to restart the platform. An alarm can be set for a couple of seconds
> > into the future (or longer if required) and that would provide the event
> > required to come up from powerdown/shutdown, in the absence of
> AUTOBOOT being
> > set in OTP. I believe this would be the safest route to take in this case. You
> > can then just use the SHUTDOWN bit on CONTROL_F to take down the board.
> >
> > To reiterate, I believe this should be made a board specific quirk, rather than
> > as part of the generic MFD core of DA9063, as the timings may vary for other
> > platforms.
>
> What timings are you referring to? Is the timing you're talking to the
> time between the shutdown and the tick that wakes the device up?

That was one of the considerations.....

> Because I have another series ready which uses a new device tree
> binding so that platforms that want the reset from the DA9063 can ask
> for it via the device tree. And then I could add a property "duration"
> that is platform dependent.

... but having thought further on this. Say you use this approach within the
kernel then you're limiting that platform to immediate reboots are you not?
What happens if you say wanted to shutdown the platform, then reboot at some
more distant future point using the RTC? In this case that option is then off
the table as the kernel hard codes this and overrides any existing alarm.

I don't believe there's anything to stop us configuring an RTC alarm from
user-space, prior to the reboot/shutdown being triggered, and that can act as an
'immediate' restart or, if the user requires, a delayed wake could also used if
necessary.

Of course none of this resolves the watchdog case if that's used, but am not
sure if that's included/used in your setup.

  reply	other threads:[~2021-09-30 10:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-21  5:33 [PATCH] drivers: mfd: da9063: Add restart notifier implementation Alexandre Ghiti
2021-09-21 10:16 ` Anup Patel
2021-09-21 11:20   ` Alexandre Ghiti
2021-09-21 10:25 ` Ben Dooks
2021-09-21 11:33   ` Alexandre Ghiti
2021-09-23 13:16     ` Alexandre Ghiti
2021-09-24 15:04 ` Adam Thomson
2021-09-24 16:17   ` Alexandre Ghiti
2021-09-29 13:33     ` Adam Thomson
2021-09-30  7:51       ` David Abdurachmanov
2021-09-30  9:28         ` Adam Thomson
2021-09-30 10:25         ` Alexandre Ghiti
2021-10-04 12:05           ` Alexandre Ghiti
2021-10-04 15:11             ` Adam Thomson
2021-10-05 13:43               ` Alexandre Ghiti
2021-10-06  9:30                 ` Adam Thomson
2021-10-06 11:35                   ` Alexandre Ghiti
2021-10-08  9:46                     ` Adam Thomson
2021-10-12 10:32                       ` Adam Thomson
2021-10-14 15:51                         ` Alexandre Ghiti
2021-10-15  8:47                           ` Adam Thomson
2021-09-30  9:37       ` Alexandre Ghiti
2021-09-30 10:47         ` Adam Thomson [this message]
2021-09-30  9:55       ` Alexandre Ghiti
2021-10-04 15:29         ` Adam Thomson

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=DB9PR10MB46524AA5496F513E34A2BF2480AA9@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM \
    --to=adam.thomson.opensource@diasemi.com \
    --cc=Support.Opensource@diasemi.com \
    --cc=alexandre.ghiti@canonical.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).