RE: [PATCH] drivers: mfd: da9063: Add restart notifier implementation

From: Adam Thomson
Date: Mon Oct 04 2021 - 11:12:06 EST


On 04 October 2021 13:05, Alexandre Ghiti wrote:

> > > Today I was looking into OpenBSD DA9063 drivers and they might be
> > > doing what you described for the reset.
> > >
> > > dev/fdt/dapmic.c
> > >
> > > [..]
> > > 241 void
> > > 242 dapmic_reset(void)
> > > 243 {
> > > 244 struct dapmic_softc *sc = dapmic_cd.cd_devs[0];
> > > 245 uint8_t reg;
> > > 246
> > > 247 /* Enable tick alarm wakeup with a one second interval. */
> > > 248 reg = dapmic_reg_read(sc, ALARM_MO);
> > > 249 reg &= ~ALARM_MO_TICK_TYPE;
> > > 250 reg |= ALARM_MO_TICK_WAKE;
> > > 251 dapmic_reg_write(sc, ALARM_MO, reg);
> > > 252
> > > 253 /* Enable tick function. */
> > > 254 reg = dapmic_reg_read(sc, ALARM_Y);
> > > 255 reg |= ALARM_Y_TICK_ON;
> > > 256 dapmic_reg_write(sc, ALARM_Y, reg);
> > > 257
> > > 258 /* Clear events such that we wake up again. */
> > > 259 dapmic_reg_write(sc, EVENT_A, dapmic_reg_read(sc, EVENT_A));
> > > 260 dapmic_reg_write(sc, CONTROL_F, CONTROL_F_SHUTDOWN);
> > > 261 }
> > > [..]
> > >
> >
> > 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?

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.