From: David Abdurachmanov <david.abdurachmanov@gmail.com> To: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Cc: Alexandre Ghiti <alexandre.ghiti@canonical.com>, 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:51:14 +0300 [thread overview] Message-ID: <CAEn-LTqVd8z=kpCtWjiPbKuw24NuHLTQxWzw7g34fEJgDYrp8w@mail.gmail.com> (raw) In-Reply-To: <DB9PR10MB46523AE6EF51D6C801B4A9BF80A99@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM> On Wed, Sep 29, 2021 at 4:36 PM Adam Thomson <Adam.Thomson.Opensource@diasemi.com> wrote: > > On 24 September 2021 17:17, Alexandre Ghiti wrote: > > > > > +static int da9063_restart_notify(struct notifier_block *this, > > > > + unsigned long mode, void *cmd) > > > > +{ > > > > + struct da9063 *da9063 = container_of(this, struct da9063, > > > > restart_handler); > > > > + > > > > + regmap_write(da9063->regmap, DA9063_REG_PAGE_CON, 0x00); > > > > + regmap_write(da9063->regmap, DA9063_REG_CONTROL_F, 0x04); > > > > + regmap_write(da9063->regmap, DA9063_REG_CONTROL_A, 0x68); > > > > + > > > > + return NOTIFY_DONE; > > > > +} > > > > > > I will talk with our HW team to clarify, but this sequence looks to be very > > > specific to the needs of the platform in question which doesn't feel right to > > > me. As was mentioned on another thread as well, the watchdog driver already > > has > > > a restart function to reset the device (and thus the system), so I don't believe > > > we should have multiple of these. > > > > From the discussion that happened here > > https://www.dialog-semiconductor.com/products/pmics?post_id=10052#tab- > > support_tab_content, > > it does not seem possible to use the watchdog on a chip whose OTP does > > not set AUTOBOOT. But anyway, I'm looking forward to hearing from the > > HW team :) > > So I've discussed this internally and so far it's not completely clear how the > sequence you provided actually performs the reset as you suggest. It certainly > doesn't look like it should, so maybe this relates to an external pin somehow > triggering the restart in this particular scenario? I'd be interested to > understand which event bits are set when the board does restart to understand > what did actually trigger the boot-up. > > 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. 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 } [..] > > 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. Agree. Currently it seems Linux drivers expect DA9063 boards to have AUTOBOOT ON set in OTP, which is not the case for SiFive Unmatched (thus issues with reset and WDT). david > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: David Abdurachmanov <david.abdurachmanov@gmail.com> To: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Cc: Alexandre Ghiti <alexandre.ghiti@canonical.com>, 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:51:14 +0300 [thread overview] Message-ID: <CAEn-LTqVd8z=kpCtWjiPbKuw24NuHLTQxWzw7g34fEJgDYrp8w@mail.gmail.com> (raw) In-Reply-To: <DB9PR10MB46523AE6EF51D6C801B4A9BF80A99@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM> On Wed, Sep 29, 2021 at 4:36 PM Adam Thomson <Adam.Thomson.Opensource@diasemi.com> wrote: > > On 24 September 2021 17:17, Alexandre Ghiti wrote: > > > > > +static int da9063_restart_notify(struct notifier_block *this, > > > > + unsigned long mode, void *cmd) > > > > +{ > > > > + struct da9063 *da9063 = container_of(this, struct da9063, > > > > restart_handler); > > > > + > > > > + regmap_write(da9063->regmap, DA9063_REG_PAGE_CON, 0x00); > > > > + regmap_write(da9063->regmap, DA9063_REG_CONTROL_F, 0x04); > > > > + regmap_write(da9063->regmap, DA9063_REG_CONTROL_A, 0x68); > > > > + > > > > + return NOTIFY_DONE; > > > > +} > > > > > > I will talk with our HW team to clarify, but this sequence looks to be very > > > specific to the needs of the platform in question which doesn't feel right to > > > me. As was mentioned on another thread as well, the watchdog driver already > > has > > > a restart function to reset the device (and thus the system), so I don't believe > > > we should have multiple of these. > > > > From the discussion that happened here > > https://www.dialog-semiconductor.com/products/pmics?post_id=10052#tab- > > support_tab_content, > > it does not seem possible to use the watchdog on a chip whose OTP does > > not set AUTOBOOT. But anyway, I'm looking forward to hearing from the > > HW team :) > > So I've discussed this internally and so far it's not completely clear how the > sequence you provided actually performs the reset as you suggest. It certainly > doesn't look like it should, so maybe this relates to an external pin somehow > triggering the restart in this particular scenario? I'd be interested to > understand which event bits are set when the board does restart to understand > what did actually trigger the boot-up. > > 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. 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 } [..] > > 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. Agree. Currently it seems Linux drivers expect DA9063 boards to have AUTOBOOT ON set in OTP, which is not the case for SiFive Unmatched (thus issues with reset and WDT). david > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2021-09-30 7:51 UTC|newest] Thread overview: 50+ 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 5:33 ` Alexandre Ghiti 2021-09-21 10:16 ` Anup Patel 2021-09-21 10:16 ` Anup Patel 2021-09-21 11:20 ` Alexandre Ghiti 2021-09-21 11:20 ` Alexandre Ghiti 2021-09-21 10:25 ` Ben Dooks 2021-09-21 10:25 ` Ben Dooks 2021-09-21 11:33 ` Alexandre Ghiti 2021-09-21 11:33 ` Alexandre Ghiti 2021-09-23 13:16 ` Alexandre Ghiti 2021-09-23 13:16 ` Alexandre Ghiti 2021-09-24 15:04 ` Adam Thomson 2021-09-24 15:04 ` Adam Thomson 2021-09-24 16:17 ` Alexandre Ghiti 2021-09-24 16:17 ` Alexandre Ghiti 2021-09-29 13:33 ` Adam Thomson 2021-09-29 13:33 ` Adam Thomson 2021-09-30 7:51 ` David Abdurachmanov [this message] 2021-09-30 7:51 ` David Abdurachmanov 2021-09-30 9:28 ` Adam Thomson 2021-09-30 9:28 ` Adam Thomson 2021-09-30 10:25 ` Alexandre Ghiti 2021-09-30 10:25 ` Alexandre Ghiti 2021-10-04 12:05 ` Alexandre Ghiti 2021-10-04 12:05 ` Alexandre Ghiti 2021-10-04 15:11 ` Adam Thomson 2021-10-04 15:11 ` Adam Thomson 2021-10-05 13:43 ` Alexandre Ghiti 2021-10-05 13:43 ` Alexandre Ghiti 2021-10-06 9:30 ` Adam Thomson 2021-10-06 9:30 ` Adam Thomson 2021-10-06 11:35 ` Alexandre Ghiti 2021-10-06 11:35 ` Alexandre Ghiti 2021-10-08 9:46 ` Adam Thomson 2021-10-08 9:46 ` Adam Thomson 2021-10-12 10:32 ` Adam Thomson 2021-10-12 10:32 ` Adam Thomson 2021-10-14 15:51 ` Alexandre Ghiti 2021-10-14 15:51 ` Alexandre Ghiti 2021-10-15 8:47 ` Adam Thomson 2021-10-15 8:47 ` Adam Thomson 2021-09-30 9:37 ` Alexandre Ghiti 2021-09-30 9:37 ` Alexandre Ghiti 2021-09-30 10:47 ` Adam Thomson 2021-09-30 10:47 ` Adam Thomson 2021-09-30 9:55 ` Alexandre Ghiti 2021-09-30 9:55 ` Alexandre Ghiti 2021-10-04 15:29 ` Adam Thomson 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='CAEn-LTqVd8z=kpCtWjiPbKuw24NuHLTQxWzw7g34fEJgDYrp8w@mail.gmail.com' \ --to=david.abdurachmanov@gmail.com \ --cc=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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.