Hi Robert, On 28/11/2019 17.17, Robert Hancock wrote: > On 2019-11-28 6:34 a.m., Harald Seiler wrote: >> Hello Claudius, >> >> On Thu, 2019-11-28 at 13:06 +0100, Claudius Heine wrote: >>> Hi, >>> >>> currently the reset on the DHCOM i.MX6 board is brocken in u-boot. >>> >>> This patchset fixes that by integrating the sysreset and watchdog dm driver. >> >> I think you should clarify that reset was broken by commit f2929d11a639 >> ("watchdog: imx: Use immediate reset bits for expire_now") which changed >> reset to, by default, only assert the external reset [1]. DHCOM i.MX6 >> needs the internal reset though, which previously was asserted as as >> well. Maybe you can add a `Fixes:` line to one of your commits? > > The behavior of the driver in the DM mode should match what the Linux > IMX watchdog driver is doing for both the watchdog timeout and reset > operations. The reset operation there explicitly uses either internal > reset or external reset, not both. For the actual watchdog timeout, they > both set the WDT bit or not depending on whether ext-reset is set, which > it seems would result in either internal+external reset or just internal > reset (it doesn't look like you can trigger only an external reset on > timeout). > >> >> Additionally, I am still unsure whether the current default behavior is >> correct. I'd rather assert both external and internal reset, which is >> what the i.MX watchdog does on timeout as well (as long as WDT bit is >> set, which we do by default [2]). There is also an inconsistency >> between the non-DM implementation (external by default) and DM >> implementation (internal by default). > > The legacy non-DM implementation kept the settings for timeout the same > as they were before. For the reset, it appears that it used to do > internal+external reset whereas now it does external only, so it's > possible that might cause an issue on some boards. However, they should > really be switching to DM and setting the ext-reset attribute properly > depending on which reset they actually want, as that's needed to get > proper watchdog timeout/restart behavior in Linux as well. I doubt any > board actually needs both internal and external resets since then Linux > would be unable to reboot properly.
Thx, for the explanation! An issue I could think of is in the SPL, where DM is not possible because of size limitations. If that SPL wants to trigger a reset, will that not cause only an external reset and boards that need a internal one will just hang? If that is the case, then there probably should be a way to configure that or let it trigger both like it did before. regards, Claudius -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: c...@denx.de PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153 Keyserver: hkp://pool.sks-keyservers.net _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot