| Message ID | 20230302124015.75546-3-y.oudjana@protonmail.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | MediaTek MT6735 TOPRGU/WDT support | expand |
Il 02/03/23 13:40, Yassine Oudjana ha scritto: > From: Yassine Oudjana <y.oudjana@protonmail.com> > > Add support for the watchdog timer/top reset generation unit found on MT6735. > Disable WDT_MODE_IRQ_EN in mtk_wdt_restart in order to make TOPRGU assert > the SYSRST pin instead of issuing an IRQ. This change may be needed in other > SoCs as well. > > Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com> > --- > drivers/watchdog/mtk_wdt.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c > index a9c437598e7e..5a7a7b2b3727 100644 > --- a/drivers/watchdog/mtk_wdt.c > +++ b/drivers/watchdog/mtk_wdt.c > @@ -10,6 +10,7 @@ > */ > > #include <dt-bindings/reset/mt2712-resets.h> > +#include <dt-bindings/reset/mediatek,mt6735-wdt.h> > #include <dt-bindings/reset/mediatek,mt6795-resets.h> > #include <dt-bindings/reset/mt7986-resets.h> > #include <dt-bindings/reset/mt8183-resets.h> > @@ -82,6 +83,10 @@ static const struct mtk_wdt_data mt2712_data = { > .toprgu_sw_rst_num = MT2712_TOPRGU_SW_RST_NUM, > }; > > +static const struct mtk_wdt_data mt6735_data = { > + .toprgu_sw_rst_num = MT6735_TOPRGU_RST_NUM, > +}; > + > static const struct mtk_wdt_data mt6795_data = { > .toprgu_sw_rst_num = MT6795_TOPRGU_SW_RST_NUM, > }; > @@ -187,9 +192,15 @@ static int mtk_wdt_restart(struct watchdog_device *wdt_dev, > { > struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev); > void __iomem *wdt_base; > + u32 reg; > > wdt_base = mtk_wdt->wdt_base; > > + /* Enable reset in order to issue a system reset instead of an IRQ */ > + reg = readl(wdt_base + WDT_MODE); > + reg &= ~WDT_MODE_IRQ_EN; > + writel(reg | WDT_MODE_KEY, wdt_base + WDT_MODE); This is unnecessary and already done in mtk_wdt_start(). If you think you *require* this snippet, you most likely misconfigured the devicetree node for your device :-) Please remove this snippet. Regards, Angelo
On 3/2/23 04:40, Yassine Oudjana wrote: > From: Yassine Oudjana <y.oudjana@protonmail.com> > > Add support for the watchdog timer/top reset generation unit found on MT6735. > Disable WDT_MODE_IRQ_EN in mtk_wdt_restart in order to make TOPRGU assert > the SYSRST pin instead of issuing an IRQ. This change may be needed in other > SoCs as well. > This is two functional changes in one patch. Also, the "may be needed" is vague. It is either needed or it isn't. > Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com> > --- > drivers/watchdog/mtk_wdt.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c > index a9c437598e7e..5a7a7b2b3727 100644 > --- a/drivers/watchdog/mtk_wdt.c > +++ b/drivers/watchdog/mtk_wdt.c > @@ -10,6 +10,7 @@ > */ > > #include <dt-bindings/reset/mt2712-resets.h> > +#include <dt-bindings/reset/mediatek,mt6735-wdt.h> > #include <dt-bindings/reset/mediatek,mt6795-resets.h> > #include <dt-bindings/reset/mt7986-resets.h> > #include <dt-bindings/reset/mt8183-resets.h> > @@ -82,6 +83,10 @@ static const struct mtk_wdt_data mt2712_data = { > .toprgu_sw_rst_num = MT2712_TOPRGU_SW_RST_NUM, > }; > > +static const struct mtk_wdt_data mt6735_data = { > + .toprgu_sw_rst_num = MT6735_TOPRGU_RST_NUM, > +}; > + > static const struct mtk_wdt_data mt6795_data = { > .toprgu_sw_rst_num = MT6795_TOPRGU_SW_RST_NUM, > }; > @@ -187,9 +192,15 @@ static int mtk_wdt_restart(struct watchdog_device *wdt_dev, > { > struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev); > void __iomem *wdt_base; > + u32 reg; > > wdt_base = mtk_wdt->wdt_base; > > + /* Enable reset in order to issue a system reset instead of an IRQ */ > + reg = readl(wdt_base + WDT_MODE); > + reg &= ~WDT_MODE_IRQ_EN; > + writel(reg | WDT_MODE_KEY, wdt_base + WDT_MODE); > + This is at the very least misleading. It appears to confuse "reset" (which is triggered by writing a specific value into the WDT_SWRST register) with the action to be taken when the watchdog triggers. The code below does not trigger the watchdog; it is supposed to trigger a soft reset, which should be independent of the above. So this needs more explanation than just "issue a system reset instead of an IRQ", because that is presumably not supposed to be what is happening when writing into the WDT_SWRST register. The above also doesn't explain what is supposed to happen if WDT_MODE_EXRST_EN is not set, adding more to the confusion. Guenter > while (1) { > writel(WDT_SWRST_KEY, wdt_base + WDT_SWRST); > mdelay(5); > @@ -443,6 +454,7 @@ static int mtk_wdt_resume(struct device *dev) > static const struct of_device_id mtk_wdt_dt_ids[] = { > { .compatible = "mediatek,mt2712-wdt", .data = &mt2712_data }, > { .compatible = "mediatek,mt6589-wdt" }, > + { .compatible = "mediatek,mt6735-wdt", .data = &mt6735_data }, > { .compatible = "mediatek,mt6795-wdt", .data = &mt6795_data }, > { .compatible = "mediatek,mt7986-wdt", .data = &mt7986_data }, > { .compatible = "mediatek,mt8183-wdt", .data = &mt8183_data },
On 02/03/2023 6:15 pm, AngeloGioacchino Del Regno wrote: > Il 02/03/23 13:40, Yassine Oudjana ha scritto: >> From: Yassine Oudjana <y.oudjana@protonmail.com> >> >> Add support for the watchdog timer/top reset generation unit found on >> MT6735. >> Disable WDT_MODE_IRQ_EN in mtk_wdt_restart in order to make TOPRGU assert >> the SYSRST pin instead of issuing an IRQ. This change may be needed in >> other >> SoCs as well. >> >> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com> >> --- >> drivers/watchdog/mtk_wdt.c | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) >> >> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c >> index a9c437598e7e..5a7a7b2b3727 100644 >> --- a/drivers/watchdog/mtk_wdt.c >> +++ b/drivers/watchdog/mtk_wdt.c >> @@ -10,6 +10,7 @@ >> */ >> #include <dt-bindings/reset/mt2712-resets.h> >> +#include <dt-bindings/reset/mediatek,mt6735-wdt.h> >> #include <dt-bindings/reset/mediatek,mt6795-resets.h> >> #include <dt-bindings/reset/mt7986-resets.h> >> #include <dt-bindings/reset/mt8183-resets.h> >> @@ -82,6 +83,10 @@ static const struct mtk_wdt_data mt2712_data = { >> .toprgu_sw_rst_num = MT2712_TOPRGU_SW_RST_NUM, >> }; >> +static const struct mtk_wdt_data mt6735_data = { >> + .toprgu_sw_rst_num = MT6735_TOPRGU_RST_NUM, >> +}; >> + >> static const struct mtk_wdt_data mt6795_data = { >> .toprgu_sw_rst_num = MT6795_TOPRGU_SW_RST_NUM, >> }; >> @@ -187,9 +192,15 @@ static int mtk_wdt_restart(struct watchdog_device >> *wdt_dev, >> { >> struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev); >> void __iomem *wdt_base; >> + u32 reg; >> wdt_base = mtk_wdt->wdt_base; >> + /* Enable reset in order to issue a system reset instead of an >> IRQ */ >> + reg = readl(wdt_base + WDT_MODE); >> + reg &= ~WDT_MODE_IRQ_EN; >> + writel(reg | WDT_MODE_KEY, wdt_base + WDT_MODE); > > This is unnecessary and already done in mtk_wdt_start(). > If you think you *require* this snippet, you most likely misconfigured the > devicetree node for your device :-) Ok so mtk_wdt_start is never called. I'm still not quite sure how the watchdog works but it seems to me like it's supposed to be started from userspace. I also see some drivers calling it in probe. Say I don't want to use the watchdog (which I don't, all I need from TOPRGU is the resets, I don't care about the watchdog). Not starting the watchdog means I can't reset the system because all mtk_wdt_restart will do is make TOPRGU send me an IRQ that I have no use for. According to the datasheet, setting WDT_MODE_IRQ_EN configures TOPRGU to send an IRQ on system reset event (either watchdog timeout or software watchdog reset) while clearing it makes it actually issue a system reset. What can I do in this case?
Il 16/10/24 11:26, Yassine Oudjana ha scritto: > On 02/03/2023 6:15 pm, AngeloGioacchino Del Regno wrote: >> Il 02/03/23 13:40, Yassine Oudjana ha scritto: >>> From: Yassine Oudjana <y.oudjana@protonmail.com> >>> >>> Add support for the watchdog timer/top reset generation unit found on MT6735. >>> Disable WDT_MODE_IRQ_EN in mtk_wdt_restart in order to make TOPRGU assert >>> the SYSRST pin instead of issuing an IRQ. This change may be needed in other >>> SoCs as well. >>> >>> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com> >>> --- >>> drivers/watchdog/mtk_wdt.c | 12 ++++++++++++ >>> 1 file changed, 12 insertions(+) >>> >>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c >>> index a9c437598e7e..5a7a7b2b3727 100644 >>> --- a/drivers/watchdog/mtk_wdt.c >>> +++ b/drivers/watchdog/mtk_wdt.c >>> @@ -10,6 +10,7 @@ >>> */ >>> #include <dt-bindings/reset/mt2712-resets.h> >>> +#include <dt-bindings/reset/mediatek,mt6735-wdt.h> >>> #include <dt-bindings/reset/mediatek,mt6795-resets.h> >>> #include <dt-bindings/reset/mt7986-resets.h> >>> #include <dt-bindings/reset/mt8183-resets.h> >>> @@ -82,6 +83,10 @@ static const struct mtk_wdt_data mt2712_data = { >>> .toprgu_sw_rst_num = MT2712_TOPRGU_SW_RST_NUM, >>> }; >>> +static const struct mtk_wdt_data mt6735_data = { >>> + .toprgu_sw_rst_num = MT6735_TOPRGU_RST_NUM, >>> +}; >>> + >>> static const struct mtk_wdt_data mt6795_data = { >>> .toprgu_sw_rst_num = MT6795_TOPRGU_SW_RST_NUM, >>> }; >>> @@ -187,9 +192,15 @@ static int mtk_wdt_restart(struct watchdog_device *wdt_dev, >>> { >>> struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev); >>> void __iomem *wdt_base; >>> + u32 reg; >>> wdt_base = mtk_wdt->wdt_base; >>> + /* Enable reset in order to issue a system reset instead of an IRQ */ >>> + reg = readl(wdt_base + WDT_MODE); >>> + reg &= ~WDT_MODE_IRQ_EN; >>> + writel(reg | WDT_MODE_KEY, wdt_base + WDT_MODE); >> >> This is unnecessary and already done in mtk_wdt_start(). >> If you think you *require* this snippet, you most likely misconfigured the >> devicetree node for your device :-) > > Ok so mtk_wdt_start is never called. mtk_wdt_init() says if (readl(wdt_base + WDT_MODE) & WDT_MODE_EN) { set_bit(WDOG_HW_RUNNING, &wdt_dev->status); mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout); } Your bootloader starts the watchdog. This driver will set WDOG_HW_RUNNING and will hence prevent calling the .start() callback - that's why. > I'm still not quite sure how the watchdog > works but it seems to me like it's supposed to be started from userspace. No, it's not meant to be just only used in userspace. > I also > see some drivers calling it in probe. > > Say I don't want to use the watchdog (which I don't, all I need from TOPRGU is the > resets, I don't care about the watchdog). Not starting the watchdog means I can't > reset the system because all mtk_wdt_restart will do is make TOPRGU send me an IRQ > that I have no use for. If you don't want to use the watchdog, then you don't need to care about bark interrupts and you don't need any mtk_wdt_restart() functionality at all :-) So, no, that's not your case here. > According to the datasheet, setting WDT_MODE_IRQ_EN > configures TOPRGU to send an IRQ on system reset event (either watchdog timeout or > software watchdog reset) while clearing it makes it actually issue a system reset. > What can I do in this case? I think that we can try with something like... static void mtk_wdt_init(struct watchdog_device *wdt_dev) { struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev); void __iomem *wdt_base; wdt_base = mtk_wdt->wdt_base; /* * Even though the watchdog may be running, avoid setting the * WDOG_HW_RUNNING bit: that will ensure that we call the start * callback to setup the hardware with the desired features */ if (readl(wdt_base + WDT_MODE) & WDT_MODE_EN) mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout); } That should work... and perhaps a better idea would be to just call mtk_wdt_start(), if WDT_MODE_EN at boot... so... Okay, I'll stop blathering. You probably got the point anyway :-) Cheers, Angelo
On 10/16/24 02:56, AngeloGioacchino Del Regno wrote: > Il 16/10/24 11:26, Yassine Oudjana ha scritto: >> On 02/03/2023 6:15 pm, AngeloGioacchino Del Regno wrote: >>> Il 02/03/23 13:40, Yassine Oudjana ha scritto: >>>> From: Yassine Oudjana <y.oudjana@protonmail.com> >>>> >>>> Add support for the watchdog timer/top reset generation unit found on MT6735. >>>> Disable WDT_MODE_IRQ_EN in mtk_wdt_restart in order to make TOPRGU assert >>>> the SYSRST pin instead of issuing an IRQ. This change may be needed in other >>>> SoCs as well. >>>> >>>> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com> >>>> --- >>>> drivers/watchdog/mtk_wdt.c | 12 ++++++++++++ >>>> 1 file changed, 12 insertions(+) >>>> >>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c >>>> index a9c437598e7e..5a7a7b2b3727 100644 >>>> --- a/drivers/watchdog/mtk_wdt.c >>>> +++ b/drivers/watchdog/mtk_wdt.c >>>> @@ -10,6 +10,7 @@ >>>> */ >>>> #include <dt-bindings/reset/mt2712-resets.h> >>>> +#include <dt-bindings/reset/mediatek,mt6735-wdt.h> >>>> #include <dt-bindings/reset/mediatek,mt6795-resets.h> >>>> #include <dt-bindings/reset/mt7986-resets.h> >>>> #include <dt-bindings/reset/mt8183-resets.h> >>>> @@ -82,6 +83,10 @@ static const struct mtk_wdt_data mt2712_data = { >>>> .toprgu_sw_rst_num = MT2712_TOPRGU_SW_RST_NUM, >>>> }; >>>> +static const struct mtk_wdt_data mt6735_data = { >>>> + .toprgu_sw_rst_num = MT6735_TOPRGU_RST_NUM, >>>> +}; >>>> + >>>> static const struct mtk_wdt_data mt6795_data = { >>>> .toprgu_sw_rst_num = MT6795_TOPRGU_SW_RST_NUM, >>>> }; >>>> @@ -187,9 +192,15 @@ static int mtk_wdt_restart(struct watchdog_device *wdt_dev, >>>> { >>>> struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev); >>>> void __iomem *wdt_base; >>>> + u32 reg; >>>> wdt_base = mtk_wdt->wdt_base; >>>> + /* Enable reset in order to issue a system reset instead of an IRQ */ >>>> + reg = readl(wdt_base + WDT_MODE); >>>> + reg &= ~WDT_MODE_IRQ_EN; >>>> + writel(reg | WDT_MODE_KEY, wdt_base + WDT_MODE); >>> >>> This is unnecessary and already done in mtk_wdt_start(). >>> If you think you *require* this snippet, you most likely misconfigured the >>> devicetree node for your device :-) >> >> Ok so mtk_wdt_start is never called. > > mtk_wdt_init() says > > if (readl(wdt_base + WDT_MODE) & WDT_MODE_EN) { > set_bit(WDOG_HW_RUNNING, &wdt_dev->status); > mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout); > } > > Your bootloader starts the watchdog. This driver will set WDOG_HW_RUNNING and > will hence prevent calling the .start() callback - that's why. > FWIW, if the bootloader _doesn't_ start the watchdog, and the watchdog device is never opened, the restart handler has to start the watchdog. Guenter
On Wed, Oct 16 2024 at 11:56:31 +02:00:00, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > Il 16/10/24 11:26, Yassine Oudjana ha scritto: >> On 02/03/2023 6:15 pm, AngeloGioacchino Del Regno wrote: >>> Il 02/03/23 13:40, Yassine Oudjana ha scritto: >>>> From: Yassine Oudjana <y.oudjana@protonmail.com> >>>> >>>> Add support for the watchdog timer/top reset generation unit found >>>> on MT6735. >>>> Disable WDT_MODE_IRQ_EN in mtk_wdt_restart in order to make TOPRGU >>>> assert >>>> the SYSRST pin instead of issuing an IRQ. This change may be >>>> needed in other >>>> SoCs as well. >>>> >>>> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com> >>>> --- >>>> drivers/watchdog/mtk_wdt.c | 12 ++++++++++++ >>>> 1 file changed, 12 insertions(+) >>>> >>>> diff --git a/drivers/watchdog/mtk_wdt.c >>>> b/drivers/watchdog/mtk_wdt.c >>>> index a9c437598e7e..5a7a7b2b3727 100644 >>>> --- a/drivers/watchdog/mtk_wdt.c >>>> +++ b/drivers/watchdog/mtk_wdt.c >>>> @@ -10,6 +10,7 @@ >>>> */ >>>> #include <dt-bindings/reset/mt2712-resets.h> >>>> +#include <dt-bindings/reset/mediatek,mt6735-wdt.h> >>>> #include <dt-bindings/reset/mediatek,mt6795-resets.h> >>>> #include <dt-bindings/reset/mt7986-resets.h> >>>> #include <dt-bindings/reset/mt8183-resets.h> >>>> @@ -82,6 +83,10 @@ static const struct mtk_wdt_data mt2712_data = { >>>> .toprgu_sw_rst_num = MT2712_TOPRGU_SW_RST_NUM, >>>> }; >>>> +static const struct mtk_wdt_data mt6735_data = { >>>> + .toprgu_sw_rst_num = MT6735_TOPRGU_RST_NUM, >>>> +}; >>>> + >>>> static const struct mtk_wdt_data mt6795_data = { >>>> .toprgu_sw_rst_num = MT6795_TOPRGU_SW_RST_NUM, >>>> }; >>>> @@ -187,9 +192,15 @@ static int mtk_wdt_restart(struct >>>> watchdog_device *wdt_dev, >>>> { >>>> struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev); >>>> void __iomem *wdt_base; >>>> + u32 reg; >>>> wdt_base = mtk_wdt->wdt_base; >>>> + /* Enable reset in order to issue a system reset instead of >>>> an IRQ */ >>>> + reg = readl(wdt_base + WDT_MODE); >>>> + reg &= ~WDT_MODE_IRQ_EN; >>>> + writel(reg | WDT_MODE_KEY, wdt_base + WDT_MODE); >>> >>> This is unnecessary and already done in mtk_wdt_start(). >>> If you think you *require* this snippet, you most likely >>> misconfigured the >>> devicetree node for your device :-) >> >> Ok so mtk_wdt_start is never called. > > mtk_wdt_init() says > > if (readl(wdt_base + WDT_MODE) & WDT_MODE_EN) { > set_bit(WDOG_HW_RUNNING, &wdt_dev->status); > mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout); > } > > Your bootloader starts the watchdog. This driver will set > WDOG_HW_RUNNING and > will hence prevent calling the .start() callback - that's why. It doesn't. WDT_MODE reads 0x5c in mtk_wdt_init if you want to see exactly how the bootloader is configuring it. > >> I'm still not quite sure how the watchdog works but it seems to me >> like it's supposed to be started from userspace. > > No, it's not meant to be just only used in userspace. > >> I also see some drivers calling it in probe. >> >> Say I don't want to use the watchdog (which I don't, all I need from >> TOPRGU is the resets, I don't care about the watchdog). Not >> starting the watchdog means I can't reset the system because all >> mtk_wdt_restart will do is make TOPRGU send me an IRQ that I have >> no use for. > > If you don't want to use the watchdog, then you don't need to care > about bark > interrupts and you don't need any mtk_wdt_restart() functionality at > all :-) I need mtk_wdt_restart to restart my system. I shouldn't need to take off my phone's back cover and remove the battery every time :) > I think what Guenter said makes sense. We should make sure the watchdog is started when calling mtk_wdt_restart or at least configured in such a way that we are sure it will issue a system reset.
On 10/16/24 23:43, yassine.oudjana@gmail.com wrote: ... >>> >>> Say I don't want to use the watchdog (which I don't, all I need from TOPRGU is the resets, I don't care about the watchdog). Not starting the watchdog means I can't reset the system because all mtk_wdt_restart will do is make TOPRGU send me an IRQ that I have no use for. >> >> If you don't want to use the watchdog, then you don't need to care about bark >> interrupts and you don't need any mtk_wdt_restart() functionality at all :-) > > I need mtk_wdt_restart to restart my system. I shouldn't need to take off my phone's back cover and remove the battery every time :) > >> > I think what Guenter said makes sense. We should make sure the watchdog is started when calling mtk_wdt_restart or at least configured in such a way that we are sure it will issue a system reset. > It is more than that. There is no limitation in the watchdog API that says "you must only use the watchdog kernel driver to reset the system if the watchdog has been activated from userspace". Such a limitation would be completely arbitrary and not make any sense. It is perfectly fine to enable the watchdog from the restart callback if needed. Actually, all restart handlers in watchdog drivers have to do that if they indeed use a watchdog to reset the system. Actually, I am not entirely sure I understand what we are arguing about. Guenter
Il 17/10/24 16:09, Guenter Roeck ha scritto: > On 10/16/24 23:43, yassine.oudjana@gmail.com wrote: > ... >>>> >>>> Say I don't want to use the watchdog (which I don't, all I need from TOPRGU is >>>> the resets, I don't care about the watchdog). Not starting the watchdog means >>>> I can't reset the system because all mtk_wdt_restart will do is make TOPRGU >>>> send me an IRQ that I have no use for. >>> >>> If you don't want to use the watchdog, then you don't need to care about bark >>> interrupts and you don't need any mtk_wdt_restart() functionality at all :-) >> >> I need mtk_wdt_restart to restart my system. I shouldn't need to take off my >> phone's back cover and remove the battery every time :) >> >>> >> I think what Guenter said makes sense. We should make sure the watchdog is >> started when calling mtk_wdt_restart or at least configured in such a way that we >> are sure it will issue a system reset. >> > > It is more than that. There is no limitation in the watchdog API that says > "you must only use the watchdog kernel driver to reset the system if the > watchdog has been activated from userspace". Such a limitation would be > completely arbitrary and not make any sense. It is perfectly fine to enable > the watchdog from the restart callback if needed. Actually, all restart > handlers in watchdog drivers have to do that if they indeed use a watchdog > to reset the system. > > Actually, I am not entirely sure I understand what we are arguing about. > Guenter: We're arguing about bad configuration and lots of misunderstanding. Regarding WDT_MODE_EXRST_EN: when enabled, it enables an external output reset signal - meaning that it's going to flip the state of a GPIO to active (high in Yassine's case - as that's configured through WDT_MODE BIT(1) and his 0x5c means that it's flipped on), signaling to another chip (usually, the PMIC...!) that we want to reset the system. Explaining what Yassine is doing with this commit: he is flipping the IRQ_EN bit [BIT(5)] in WDT_MODE. When bit 5 *is set*, the watchdog bark event will only raise an interrupt and will not reset the system (that's left to be done to an interrupt handler in the driver). When bit 5 *is NOT set*, the watchdog bark event will trigger a CPU reset. Now, my confusion came from the fact that he's trying to fix a watchdog bark event so that it triggers system reset, but I didn't understand the actual reason why he wants to do that - which is powering off the system! Yassine: You don't *have to* rely on the watchdog to reset the system, and if you use only that - especially on a smartphone - I'm mostly sure that you'll get power leakage. Before you read the following - please note that this is platform dependent so, take this with a grain of salt: it is the PMIC that should get configured to take your system down! I have a hunch that this works for you only because the platform will reboot, and then the bootloader will decide to turn off the system for you by default (that, unless you send a warm reboot indication). That flow looks more like a hack than a solution for an actual problem. Now - whether you want to fix your platform or not, this is out of the scope of this commit, which is - in the end - still fixing something that is wrong. Effectively, as Guenter said, if the watchdog is never started, the restart function is not going to reboot the system, so yes this problem needs to be fixed. There are two problems in this driver that can be solved with: 1. Disable IRQ generation when *no irq* is found in DT; and 2. Implement support for reboot in mtk_wdt_isr() by reading the WDT_STA register and by then taking appropriate actions. Of course my preference would be N.2 because: - The pretimeout way is already supported in the driver, and if you specify a pretimeout, then the watchdog will never trigger SYSRST->XRST: this is actually a bug (IMO!!), as declaring an IRQ in DT means losing reset (!); - The WDT_STA register tells you more than just "SW/HW watchdog reset asserted" and that can be extended in the future to support more than that. However, I recognize that this may be too much work for you, so, if there's no way for you to properly add support for N.2 - I can chime in. As for N.1, the solution is simple: check if platform_get_irq_optional fails and - if it does - force unsetting (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN) in WDT_MODE, if and only if WDT_EN is not set.. but that, in the probe function! Cheers, Angelo
On 10/17/24 08:16, AngeloGioacchino Del Regno wrote: > Il 17/10/24 16:09, Guenter Roeck ha scritto: >> On 10/16/24 23:43, yassine.oudjana@gmail.com wrote: >> ... >>>>> >>>>> Say I don't want to use the watchdog (which I don't, all I need from TOPRGU is the resets, I don't care about the watchdog). Not starting the watchdog means I can't reset the system because all mtk_wdt_restart will do is make TOPRGU send me an IRQ that I have no use for. >>>> >>>> If you don't want to use the watchdog, then you don't need to care about bark >>>> interrupts and you don't need any mtk_wdt_restart() functionality at all :-) >>> >>> I need mtk_wdt_restart to restart my system. I shouldn't need to take off my phone's back cover and remove the battery every time :) >>> >>>> >>> I think what Guenter said makes sense. We should make sure the watchdog is started when calling mtk_wdt_restart or at least configured in such a way that we are sure it will issue a system reset. >>> >> >> It is more than that. There is no limitation in the watchdog API that says >> "you must only use the watchdog kernel driver to reset the system if the >> watchdog has been activated from userspace". Such a limitation would be >> completely arbitrary and not make any sense. It is perfectly fine to enable >> the watchdog from the restart callback if needed. Actually, all restart >> handlers in watchdog drivers have to do that if they indeed use a watchdog >> to reset the system. >> >> Actually, I am not entirely sure I understand what we are arguing about. >> > > Guenter: > We're arguing about bad configuration and lots of misunderstanding. > > Regarding WDT_MODE_EXRST_EN: when enabled, it enables an external output > reset signal - meaning that it's going to flip the state of a GPIO to active > (high in Yassine's case - as that's configured through WDT_MODE BIT(1) and > his 0x5c means that it's flipped on), signaling to another chip (usually, > the PMIC...!) that we want to reset the system. > > Explaining what Yassine is doing with this commit: he is flipping the IRQ_EN > bit [BIT(5)] in WDT_MODE. > > When bit 5 *is set*, the watchdog bark event will only raise an interrupt and > will not reset the system (that's left to be done to an interrupt handler in > the driver). > > When bit 5 *is NOT set*, the watchdog bark event will trigger a CPU reset. > > Now, my confusion came from the fact that he's trying to fix a watchdog bark > event so that it triggers system reset, but I didn't understand the actual > reason why he wants to do that - which is powering off the system! > > > Yassine: > > You don't *have to* rely on the watchdog to reset the system, and if you use > only that - especially on a smartphone - I'm mostly sure that you'll get > power leakage. > > Before you read the following - please note that this is platform dependent > so, take this with a grain of salt: it is the PMIC that should get configured > to take your system down! I have a hunch that this works for you only because > the platform will reboot, and then the bootloader will decide to turn off the > system for you by default (that, unless you send a warm reboot indication). > > That flow looks more like a hack than a solution for an actual problem. > > > Now - whether you want to fix your platform or not, this is out of the scope > of this commit, which is - in the end - still fixing something that is wrong. > > Effectively, as Guenter said, if the watchdog is never started, the restart > function is not going to reboot the system, so yes this problem needs to be > fixed. > > There are two problems in this driver that can be solved with: > 1. Disable IRQ generation when *no irq* is found in DT; and > 2. Implement support for reboot in mtk_wdt_isr() by reading the WDT_STA > register and by then taking appropriate actions. > That won't work because interrupts are likely disabled when the reset callback executes. The reset handler must not depend on an interrupt. It has to be self-contained: It has to configure the hardware to issue a reset. On some systems, that is done by setting the watchdog timeout to a really low value and enabling it. Others have a special configuration in the watchdog register set which triggers a reset immediately. If the hardware supports pretimeout, that would have to be disabled because the idea is to trigger a reset signal, not an interrupt. To repeat, setting up the system and then waiting for an interrupt to do something defeats the purpose of the reset handler, which is to issue a reset signal. Somehow. If that can be done from an interrupt handler, it can and should be done immediately instead. > Of course my preference would be N.2 because: > - The pretimeout way is already supported in the driver, and if you specify > a pretimeout, then the watchdog will never trigger SYSRST->XRST: this > is actually a bug (IMO!!), as declaring an IRQ in DT means losing reset (!); > - The WDT_STA register tells you more than just "SW/HW watchdog reset asserted" > and that can be extended in the future to support more than that. > > However, I recognize that this may be too much work for you, so, if there's no > way for you to properly add support for N.2 - I can chime in. > > As for N.1, the solution is simple: check if platform_get_irq_optional fails > and - if it does - force unsetting (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN) in > WDT_MODE, if and only if WDT_EN is not set.. but that, in the probe function! > All that should be configured in the reset handler. It has to disable interrupts even if there is interrupt support because that is not what is wanted at this point. Thanks, Guenter
On Thu, Oct 17 2024 at 17:16:54 +02:00:00, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > Il 17/10/24 16:09, Guenter Roeck ha scritto: >> On 10/16/24 23:43, yassine.oudjana@gmail.com wrote: >> ... >>>>> >>>>> Say I don't want to use the watchdog (which I don't, all I need >>>>> from TOPRGU is the resets, I don't care about the watchdog). >>>>> Not starting the watchdog means I can't reset the system >>>>> because all mtk_wdt_restart will do is make TOPRGU send me an >>>>> IRQ that I have no use for. >>>> >>>> If you don't want to use the watchdog, then you don't need to care >>>> about bark >>>> interrupts and you don't need any mtk_wdt_restart() functionality >>>> at all :-) >>> >>> I need mtk_wdt_restart to restart my system. I shouldn't need to >>> take off my phone's back cover and remove the battery every time >>> :) >>> >>>> >>> I think what Guenter said makes sense. We should make sure the >>> watchdog is started when calling mtk_wdt_restart or at least >>> configured in such a way that we are sure it will issue a system >>> reset. >>> >> >> It is more than that. There is no limitation in the watchdog API >> that says >> "you must only use the watchdog kernel driver to reset the system if >> the >> watchdog has been activated from userspace". Such a limitation would >> be >> completely arbitrary and not make any sense. It is perfectly fine to >> enable >> the watchdog from the restart callback if needed. Actually, all >> restart >> handlers in watchdog drivers have to do that if they indeed use a >> watchdog >> to reset the system. >> >> Actually, I am not entirely sure I understand what we are arguing >> about. >> > > Guenter: > We're arguing about bad configuration and lots of misunderstanding. > > Regarding WDT_MODE_EXRST_EN: when enabled, it enables an external > output > reset signal - meaning that it's going to flip the state of a GPIO to > active > (high in Yassine's case - as that's configured through WDT_MODE > BIT(1) and > his 0x5c means that it's flipped on), signaling to another chip > (usually, > the PMIC...!) that we want to reset the system. > > Explaining what Yassine is doing with this commit: he is flipping the > IRQ_EN > bit [BIT(5)] in WDT_MODE. > > When bit 5 *is set*, the watchdog bark event will only raise an > interrupt and > will not reset the system (that's left to be done to an interrupt > handler in > the driver). > > When bit 5 *is NOT set*, the watchdog bark event will trigger a CPU > reset. > > Now, my confusion came from the fact that he's trying to fix a > watchdog bark > event so that it triggers system reset, but I didn't understand the > actual > reason why he wants to do that - which is powering off the system! I'm currently aiming for reboot, not poweroff. There was some point during development where holding the power button wasn't enough to force restart and I'm still not sure why that was happening but it's working now. That's why I was removing the battery to power it off then turn it on again with the power button. > > > Yassine: > > You don't *have to* rely on the watchdog to reset the system, and if > you use > only that - especially on a smartphone - I'm mostly sure that you'll > get > power leakage. I did notice that when I tried poweroff. It didn't fully power off and eventually drained the battery. But again I'm not looking into fixing poweroff for the time being, I'm focusing on reboot. I'll probably ask you again about it when I look into fixing poweroff since you seem to know something about the matter. > > Before you read the following - please note that this is platform > dependent > so, take this with a grain of salt: it is the PMIC that should get > configured > to take your system down! I have a hunch that this works for you only > because > the platform will reboot, and then the bootloader will decide to turn > off the > system for you by default (that, unless you send a warm reboot > indication). > > That flow looks more like a hack than a solution for an actual > problem. > > > Now - whether you want to fix your platform or not, this is out of > the scope > of this commit, which is - in the end - still fixing something that > is wrong. > > Effectively, as Guenter said, if the watchdog is never started, the > restart > function is not going to reboot the system, so yes this problem needs > to be > fixed. > > There are two problems in this driver that can be solved with: > 1. Disable IRQ generation when *no irq* is found in DT; and > 2. Implement support for reboot in mtk_wdt_isr() by reading the > WDT_STA > register and by then taking appropriate actions. > > Of course my preference would be N.2 because: > - The pretimeout way is already supported in the driver, and if you > specify > a pretimeout, then the watchdog will never trigger SYSRST->XRST: > this > is actually a bug (IMO!!), as declaring an IRQ in DT means losing > reset (!); > - The WDT_STA register tells you more than just "SW/HW watchdog > reset asserted" > and that can be extended in the future to support more than that. > > However, I recognize that this may be too much work for you, so, if > there's no > way for you to properly add support for N.2 - I can chime in. > > As for N.1, the solution is simple: check if > platform_get_irq_optional fails > and - if it does - force unsetting (WDT_MODE_IRQ_EN | > WDT_MODE_DUAL_EN) in > WDT_MODE, if and only if WDT_EN is not set.. but that, in the probe > function! I still honestly don't see the point in either solution. N.1 sounds like a hack; the interrupt should be described in DT even if we don't want to use it since DT is ultimately hardware description and the interrupt line exists whether we are using it or not. N.2 is unnecessarily complicating things. I mean why should we make the watchdog issue an interrupt then in the interrupt handler perform the reset? When someone calls the restart function they expect an immediate reset. As Guenter said we should configure the hardware to issue reset in the reset handler, and I believe that's what I did originally.
Il 17/10/24 17:39, Guenter Roeck ha scritto: > On 10/17/24 08:16, AngeloGioacchino Del Regno wrote: >> Il 17/10/24 16:09, Guenter Roeck ha scritto: >>> On 10/16/24 23:43, yassine.oudjana@gmail.com wrote: >>> ... >>>>>> >>>>>> Say I don't want to use the watchdog (which I don't, all I need from TOPRGU >>>>>> is the resets, I don't care about the watchdog). Not starting the watchdog >>>>>> means I can't reset the system because all mtk_wdt_restart will do is make >>>>>> TOPRGU send me an IRQ that I have no use for. >>>>> >>>>> If you don't want to use the watchdog, then you don't need to care about bark >>>>> interrupts and you don't need any mtk_wdt_restart() functionality at all :-) >>>> >>>> I need mtk_wdt_restart to restart my system. I shouldn't need to take off my >>>> phone's back cover and remove the battery every time :) >>>> >>>>> >>>> I think what Guenter said makes sense. We should make sure the watchdog is >>>> started when calling mtk_wdt_restart or at least configured in such a way that >>>> we are sure it will issue a system reset. >>>> >>> >>> It is more than that. There is no limitation in the watchdog API that says >>> "you must only use the watchdog kernel driver to reset the system if the >>> watchdog has been activated from userspace". Such a limitation would be >>> completely arbitrary and not make any sense. It is perfectly fine to enable >>> the watchdog from the restart callback if needed. Actually, all restart >>> handlers in watchdog drivers have to do that if they indeed use a watchdog >>> to reset the system. >>> >>> Actually, I am not entirely sure I understand what we are arguing about. >>> >> >> Guenter: >> We're arguing about bad configuration and lots of misunderstanding. >> >> Regarding WDT_MODE_EXRST_EN: when enabled, it enables an external output >> reset signal - meaning that it's going to flip the state of a GPIO to active >> (high in Yassine's case - as that's configured through WDT_MODE BIT(1) and >> his 0x5c means that it's flipped on), signaling to another chip (usually, >> the PMIC...!) that we want to reset the system. >> >> Explaining what Yassine is doing with this commit: he is flipping the IRQ_EN >> bit [BIT(5)] in WDT_MODE. >> >> When bit 5 *is set*, the watchdog bark event will only raise an interrupt and >> will not reset the system (that's left to be done to an interrupt handler in >> the driver). >> >> When bit 5 *is NOT set*, the watchdog bark event will trigger a CPU reset. >> >> Now, my confusion came from the fact that he's trying to fix a watchdog bark >> event so that it triggers system reset, but I didn't understand the actual >> reason why he wants to do that - which is powering off the system! >> >> >> Yassine: >> >> You don't *have to* rely on the watchdog to reset the system, and if you use >> only that - especially on a smartphone - I'm mostly sure that you'll get >> power leakage. >> >> Before you read the following - please note that this is platform dependent >> so, take this with a grain of salt: it is the PMIC that should get configured >> to take your system down! I have a hunch that this works for you only because >> the platform will reboot, and then the bootloader will decide to turn off the >> system for you by default (that, unless you send a warm reboot indication). >> >> That flow looks more like a hack than a solution for an actual problem. >> >> >> Now - whether you want to fix your platform or not, this is out of the scope >> of this commit, which is - in the end - still fixing something that is wrong. >> >> Effectively, as Guenter said, if the watchdog is never started, the restart >> function is not going to reboot the system, so yes this problem needs to be >> fixed. >> >> There are two problems in this driver that can be solved with: >> 1. Disable IRQ generation when *no irq* is found in DT; and >> 2. Implement support for reboot in mtk_wdt_isr() by reading the WDT_STA >> register and by then taking appropriate actions. >> > > That won't work because interrupts are likely disabled when the reset callback > executes. The reset handler must not depend on an interrupt. It has to be > self-contained: It has to configure the hardware to issue a reset. > On some systems, that is done by setting the watchdog timeout to a really low value > and enabling it. Others have a special configuration in the watchdog register set > which triggers a reset immediately. If the hardware supports pretimeout, that would > have to be disabled because the idea is to trigger a reset signal, not an interrupt. > > To repeat, setting up the system and then waiting for an interrupt to do something > defeats the purpose of the reset handler, which is to issue a reset signal. > Somehow. If that can be done from an interrupt handler, it can and should be done > immediately instead. > >> Of course my preference would be N.2 because: >> - The pretimeout way is already supported in the driver, and if you specify >> a pretimeout, then the watchdog will never trigger SYSRST->XRST: this >> is actually a bug (IMO!!), as declaring an IRQ in DT means losing reset (!); >> - The WDT_STA register tells you more than just "SW/HW watchdog reset asserted" >> and that can be extended in the future to support more than that. >> >> However, I recognize that this may be too much work for you, so, if there's no >> way for you to properly add support for N.2 - I can chime in. >> >> As for N.1, the solution is simple: check if platform_get_irq_optional fails >> and - if it does - force unsetting (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN) in >> WDT_MODE, if and only if WDT_EN is not set.. but that, in the probe function! >> > > All that should be configured in the reset handler. It has to disable interrupts > even if there is interrupt support because that is not what is wanted at this point. > Ack. After re-reading this and thinking about it for a bit - you're definitely right. Let's go for the setup in the reset handler then. Though, I think that a v2 is still needed here - one patch to fix the reset handler (at this point, with a Fixes tag for backporting..!), and one to add support for the MT6735 resets. Cheers, Angelo
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index a9c437598e7e..5a7a7b2b3727 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -10,6 +10,7 @@ */ #include <dt-bindings/reset/mt2712-resets.h> +#include <dt-bindings/reset/mediatek,mt6735-wdt.h> #include <dt-bindings/reset/mediatek,mt6795-resets.h> #include <dt-bindings/reset/mt7986-resets.h> #include <dt-bindings/reset/mt8183-resets.h> @@ -82,6 +83,10 @@ static const struct mtk_wdt_data mt2712_data = { .toprgu_sw_rst_num = MT2712_TOPRGU_SW_RST_NUM, }; +static const struct mtk_wdt_data mt6735_data = { + .toprgu_sw_rst_num = MT6735_TOPRGU_RST_NUM, +}; + static const struct mtk_wdt_data mt6795_data = { .toprgu_sw_rst_num = MT6795_TOPRGU_SW_RST_NUM, }; @@ -187,9 +192,15 @@ static int mtk_wdt_restart(struct watchdog_device *wdt_dev, { struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev); void __iomem *wdt_base; + u32 reg; wdt_base = mtk_wdt->wdt_base; + /* Enable reset in order to issue a system reset instead of an IRQ */ + reg = readl(wdt_base + WDT_MODE); + reg &= ~WDT_MODE_IRQ_EN; + writel(reg | WDT_MODE_KEY, wdt_base + WDT_MODE); + while (1) { writel(WDT_SWRST_KEY, wdt_base + WDT_SWRST); mdelay(5); @@ -443,6 +454,7 @@ static int mtk_wdt_resume(struct device *dev) static const struct of_device_id mtk_wdt_dt_ids[] = { { .compatible = "mediatek,mt2712-wdt", .data = &mt2712_data }, { .compatible = "mediatek,mt6589-wdt" }, + { .compatible = "mediatek,mt6735-wdt", .data = &mt6735_data }, { .compatible = "mediatek,mt6795-wdt", .data = &mt6795_data }, { .compatible = "mediatek,mt7986-wdt", .data = &mt7986_data }, { .compatible = "mediatek,mt8183-wdt", .data = &mt8183_data },