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

Adam Thomson Adam.Thomson.Opensource at diasemi.com
Mon Oct 4 08:11:51 PDT 2021


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.


More information about the linux-riscv mailing list