LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
To: Alexandre Ghiti <email@example.com>,
Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Cc: David Abdurachmanov <firstname.lastname@example.org>,
Support Opensource <Support.Opensource@diasemi.com>,
Lee Jones <email@example.com>,
Subject: RE: [PATCH] drivers: mfd: da9063: Add restart notifier implementation
Date: Wed, 6 Oct 2021 09:30:14 +0000 [thread overview]
Message-ID: <DB9PR10MB465270EA5D6F25C44E68D1E580B09@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM> (raw)
On 05 October 2021 14:43, Alexandre Ghiti wrote:
> > > > Thanks for the pointer! I have just tested this sequence from the
> > > > u-boot shell, it resets the board correctly. But then if we try to
> > > > power down the board by a long press to the corresponding button on
> > > > the board within 16 seconds, it resets the board: so we cannot
> > > > shutdown the board in the next 16 seconds that follow this sequence.
> > > >
> > > > Maybe that can be resolved by using the one-shot alarm as described by
> > > > Adam, I'll try to find that in the datasheet.
> > >
> > > After configuring the one-shot alarm, I still have those intempestive
> > > reboots if I try to power down the board by a long press within 16
> > > seconds. The only thing I found in the datasheet regarding this timing
> > > is in case of power undervoltage, not sure how this is linked to what
> > > I see.
> > >
> > > @Adam Thomson Any ideas?
> > Nothing immediately springs to mind. Can you confirm this is the nONKEY long
> > press that you're attempting here, which is resetting the board rather than
> > shutting down?
> Yes, this is the nONKEY long press that, if done within ~16sec after
> the board is reset using the alarm, resets the board instead of
> shutting it down.
> > Also, would you able to again provide events and fault log when this unwanted
> > reset occurs, just in case there's anything there to give a clue. Can then
> > discuss internally to see if we can ascertain what might be happening here.
> FAULT_LOG = 0x60
> EVENT_A = 0x12
> EVENT_B to EVENT_D = 0
> But I'm unsure of those values since they are the same after the reset
> triggered by the one-shot alarm *and* if I clear EVENT_A, the
> intempestive reboot does not appear!
Thanks for the info. So we believe, based on the event registers values
provided, it is the RTC event as that's not cleared by a power-cycle (it's in
the always-on domain). The other test would be to mask this event immediately
after an RTC based reboot and see if the long key-press then shuts down the
device. I suspect it would in that case, as per you clearing the event.
I'm still curious as to the 16 seconds though. Would that be when the kernel
finally starts and masks/clears events (seems quite a long time)?
next prev parent reply other threads:[~2021-10-06 9:30 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-21 5:33 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 [this message]
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
2021-09-30 9:55 ` Alexandre Ghiti
2021-10-04 15:29 ` Adam Thomson
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='RE: [PATCH] drivers: mfd: da9063: Add restart notifier implementation' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).