Message-ID: <DB9PR10MB46525FC6EAF1610178A20B7580B69@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM>
Date:   Tue, 12 Oct 2021 10:32:53 +0000
From:   Adam Thomson <Adam.Thomson.Opensource@...semi.com>
To:     Adam Thomson <Adam.Thomson.Opensource@...semi.com>,
        Alexandre Ghiti <alexandre.ghiti@...onical.com>,
        Adam Thomson <Adam.Thomson.Opensource@...semi.com>
CC:     David Abdurachmanov <david.abdurachmanov@...il.com>,
        Support Opensource <Support.Opensource@...semi.com>,
        Lee Jones <lee.jones@...aro.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] drivers: mfd: da9063: Add restart notifier implementation

On 08 October 2021 10:46, Adam Thomson wrote:

> > > 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.
> >
> > Indeed if I mask the RTC alarm in IRQ_MASK_A, the intempestive reboot
> > disappears. But that's not something we can do: the reset driver will
> > actually be implemented in openSBI at some point where the devices are
> > probed on-demand (the same applies to u-boot I think), so we cannot
> > clear or mask anything at boot.
> >
> > >
> > > 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)?
> >
> > No, the kernel is not up yet. Maybe 16sec is not the right value, I
> > may have been influenced by the discussion here
> > https://www.dialog-semiconductor.com/products/pmics?post_id=10052#tab-
> > support_tab_content.
> >
> > It seems there is some consensus about having this reset driver be a
> > SiFive Unmatched board specific thing: quid of the sequence I propose
> > in this patch then? It does not mess with the RTC registers, it
> > reboots reliably and there's no intempestive reboot: is it dangerous
> > to use? Or do you have another alternative?
>
> Yes, a board specific implementation would be the way to go. We're just checking
> through the sequence again to be absolutely sure of any pitfalls that may
> present themselves, and will get back to you when we have something more.

So having examined your sequence again it's now clearer as to what is happening.
With the sequence you provided this is only a partial reset whereby all of the
output rails are sequenced down then up again and restored to OTP voltages.
However the remainder of the chip settings aren't reset as this isn't a true
reset of the device going through full reload from OTP, so for example settings
of regulator mode GPIO states, or IRQ mask bits would persist on the restart,
which could have implications on system operation.

In addition the only bits of interest for you should be:

 - CONTROL_F (0x13)
	WAKE_UP (BIT 2) = 1
 - CONTROL_A (0x0E)
	SYSTEM_EN (BIT 0) = 0

Setting those two bits should be enough to trigger the partial reset sequence.
The other bits you had in your sequence don't seem to be necessary or relevant.

One final caveat to this approach is that there is a 16s internal timer (as you
noted before, VDD_START) which is started when the device moves to ACTIVE mode.
When that 16s timer expires the device will clear the WAKE_UP bit automatically.
This means there's the outside chance that you could try the reset command
sequence above around the same time, and that could mean you set the WAKE_UP
bit, but it's immediately cleared again by this timer expiry before the
SYSTEM_EN bit is set low. In that case there would be a need for an external
event (e.g. ONKEY) to kick the system to start again.

Powered by blists - more mailing lists