[PATCH 0/2] MediaTek MT6735 TOPRGU/WDT support

[PATCH 0/2] MediaTek MT6735 TOPRGU/WDT support

[Yassine Oudjana]

From: Yassine Oudjana <y.oudjana@protonmail.com>

These patches are part of a larger effort to support the MT6735 SoC family in
mainline Linux. More patches (unsent or sent and pending review or revision)
can be found here[1].

This series adds support for the top reset generation unit (TOPRGU) found on
the MediaTek MT6735 SoC. TOPRGU generates several reset signals and provides
watchdog timer functionality.

[1] https://gitlab.com/mt6735-mainline/linux/-/commits/mt6735-staging

Yassine Oudjana (2):
  dt-bindings: reset: Add binding for MediaTek MT6735 TOPRGU/WDT
  watchdog: mtk_wdt: Add support for MT6735 WDT

 .../bindings/watchdog/mediatek,mtk-wdt.yaml     |  1 +
 drivers/watchdog/mtk_wdt.c                      | 12 ++++++++++++
 include/dt-bindings/reset/mediatek,mt6735-wdt.h | 17 +++++++++++++++++
 3 files changed, 30 insertions(+)
 create mode 100644 include/dt-bindings/reset/mediatek,mt6735-wdt.h

-- 
2.39.2

[PATCH 1/2] dt-bindings: reset: Add binding for MediaTek MT6735 TOPRGU/WDT

[Yassine Oudjana]

From: Yassine Oudjana <y.oudjana@protonmail.com>

Add a DT binding for the MT6735 top reset generation unit/watchdog timer.

Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
---
 .../bindings/watchdog/mediatek,mtk-wdt.yaml     |  1 +
 include/dt-bindings/reset/mediatek,mt6735-wdt.h | 17 +++++++++++++++++
 2 files changed, 18 insertions(+)
 create mode 100644 include/dt-bindings/reset/mediatek,mt6735-wdt.h

diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
index 55b34461df1b..009ccdb60b84 100644
--- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
@@ -22,6 +22,7 @@ properties:
       - enum:
           - mediatek,mt2712-wdt
           - mediatek,mt6589-wdt
+          - mediatek,mt6735-wdt
           - mediatek,mt6795-wdt
           - mediatek,mt7986-wdt
           - mediatek,mt8183-wdt
diff --git a/include/dt-bindings/reset/mediatek,mt6735-wdt.h b/include/dt-bindings/reset/mediatek,mt6735-wdt.h
new file mode 100644
index 000000000000..c6056e676d46
--- /dev/null
+++ b/include/dt-bindings/reset/mediatek,mt6735-wdt.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+#ifndef _DT_BINDINGS_RESET_MEDIATEK_MT6735_WDT_H_
+#define _DT_BINDINGS_RESET_MEDIATEK_MT6735_WDT_H_
+
+#define MT6735_TOPRGU_MM_RST		1
+#define MT6735_TOPRGU_MFG_RST		2
+#define MT6735_TOPRGU_VENC_RST		3
+#define MT6735_TOPRGU_VDEC_RST		4
+#define MT6735_TOPRGU_IMG_RST		5
+#define MT6735_TOPRGU_MD_RST		7
+#define MT6735_TOPRGU_CONN_RST		9
+#define MT6735_TOPRGU_C2K_SW_RST	14
+#define MT6735_TOPRGU_C2K_RST		15
+#define MT6735_TOPRGU_RST_NUM		9
+
+#endif
-- 
2.39.2

[PATCH 2/2] watchdog: mtk_wdt: Add support for MT6735 WDT

[Yassine Oudjana]

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);
+
 	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 },
-- 
2.39.2

Re: [PATCH 2/2] watchdog: mtk_wdt: Add support for MT6735 WDT

[AngeloGioacchino Del Regno]

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

Re: [PATCH 1/2] dt-bindings: reset: Add binding for MediaTek MT6735 TOPRGU/WDT

[AngeloGioacchino Del Regno]

Il 02/03/23 13:40, Yassine Oudjana ha scritto:
> From: Yassine Oudjana <y.oudjana@protonmail.com>
> 
> Add a DT binding for the MT6735 top reset generation unit/watchdog timer.
> 
> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Re: [PATCH 1/2] dt-bindings: reset: Add binding for MediaTek MT6735 TOPRGU/WDT

[Krzysztof Kozlowski]

On 02/03/2023 13:40, Yassine Oudjana wrote:
> From: Yassine Oudjana <y.oudjana@protonmail.com>
> 
> Add a DT binding for the MT6735 top reset generation unit/watchdog timer.
> 
> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

Re: [PATCH 2/2] watchdog: mtk_wdt: Add support for MT6735 WDT

[Guenter Roeck]

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 },

Re: [PATCH 1/2] dt-bindings: reset: Add binding for MediaTek MT6735 TOPRGU/WDT

[Guenter Roeck]

On Thu, Mar 02, 2023 at 03:40:14PM +0300, Yassine Oudjana wrote:
> From: Yassine Oudjana <y.oudjana@protonmail.com>
> 
> Add a DT binding for the MT6735 top reset generation unit/watchdog timer.
> 
> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Reviewed-by: Guenter Roeck <linux@roeck-us.net>

> ---
>  .../bindings/watchdog/mediatek,mtk-wdt.yaml     |  1 +
>  include/dt-bindings/reset/mediatek,mt6735-wdt.h | 17 +++++++++++++++++
>  2 files changed, 18 insertions(+)
>  create mode 100644 include/dt-bindings/reset/mediatek,mt6735-wdt.h
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> index 55b34461df1b..009ccdb60b84 100644
> --- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> +++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> @@ -22,6 +22,7 @@ properties:
>        - enum:
>            - mediatek,mt2712-wdt
>            - mediatek,mt6589-wdt
> +          - mediatek,mt6735-wdt
>            - mediatek,mt6795-wdt
>            - mediatek,mt7986-wdt
>            - mediatek,mt8183-wdt
> diff --git a/include/dt-bindings/reset/mediatek,mt6735-wdt.h b/include/dt-bindings/reset/mediatek,mt6735-wdt.h
> new file mode 100644
> index 000000000000..c6056e676d46
> --- /dev/null
> +++ b/include/dt-bindings/reset/mediatek,mt6735-wdt.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +
> +#ifndef _DT_BINDINGS_RESET_MEDIATEK_MT6735_WDT_H_
> +#define _DT_BINDINGS_RESET_MEDIATEK_MT6735_WDT_H_
> +
> +#define MT6735_TOPRGU_MM_RST		1
> +#define MT6735_TOPRGU_MFG_RST		2
> +#define MT6735_TOPRGU_VENC_RST		3
> +#define MT6735_TOPRGU_VDEC_RST		4
> +#define MT6735_TOPRGU_IMG_RST		5
> +#define MT6735_TOPRGU_MD_RST		7
> +#define MT6735_TOPRGU_CONN_RST		9
> +#define MT6735_TOPRGU_C2K_SW_RST	14
> +#define MT6735_TOPRGU_C2K_RST		15
> +#define MT6735_TOPRGU_RST_NUM		9
> +
> +#endif

Re: [PATCH 2/2] watchdog: mtk_wdt: Add support for MT6735 WDT

[Yassine Oudjana]

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?

Re: [PATCH 2/2] watchdog: mtk_wdt: Add support for MT6735 WDT

[AngeloGioacchino Del Regno]

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

Re: [PATCH 2/2] watchdog: mtk_wdt: Add support for MT6735 WDT

[Guenter Roeck]

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

Re: [PATCH 2/2] watchdog: mtk_wdt: Add support for MT6735 WDT

[yassine.oudjana]

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 \x7fworks 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 \x7fsee 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 \x7fresets, I don't care about the watchdog). Not 
>> starting the watchdog means I can't \x7freset the system because all 
>> mtk_wdt_restart will do is make TOPRGU send me an IRQ \x7fthat 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.

Re: [PATCH 2/2] watchdog: mtk_wdt: Add support for MT6735 WDT

[Guenter Roeck]

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 \x7fresets, I don't care about the watchdog). Not starting the watchdog means I can't \x7freset the system because all mtk_wdt_restart will do is make TOPRGU send me an IRQ \x7fthat 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

Re: [PATCH 2/2] watchdog: mtk_wdt: Add support for MT6735 WDT

[AngeloGioacchino Del Regno]

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 \x7fresets, I don't care about the watchdog). Not starting the watchdog means 
>>>> I can't \x7freset the system because all mtk_wdt_restart will do is make TOPRGU 
>>>> send me an IRQ \x7fthat 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

Re: [PATCH 2/2] watchdog: mtk_wdt: Add support for MT6735 WDT

[Guenter Roeck]

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 \x7fresets, I don't care about the watchdog). Not starting the watchdog means I can't \x7freset the system because all mtk_wdt_restart will do is make TOPRGU send me an IRQ \x7fthat 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

Re: [PATCH 2/2] watchdog: mtk_wdt: Add support for MT6735 WDT

[Yassine Oudjana]

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 \x7f\x7f\x7f\x7fthe \x7fresets, I don't care about the watchdog). 
>>>>> Not starting the watchdog means \x7f\x7f\x7f\x7fI can't \x7freset the system 
>>>>> because all mtk_wdt_restart will do is make TOPRGU \x7f\x7f\x7f\x7fsend me an 
>>>>> IRQ \x7fthat 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 \x7f\x7fphone's back cover and remove the battery every time 
>>> :)
>>> 
>>>> 
>>> I think what Guenter said makes sense. We should make sure the 
>>> watchdog is \x7f\x7fstarted when calling mtk_wdt_restart or at least 
>>> configured in such a way that we \x7f\x7fare 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.

Re: [PATCH 2/2] watchdog: mtk_wdt: Add support for MT6735 WDT

[AngeloGioacchino Del Regno]

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 \x7fresets, I don't care about the watchdog). Not starting the watchdog 
>>>>>> means I can't \x7freset the system because all mtk_wdt_restart will do is make 
>>>>>> TOPRGU send me an IRQ \x7fthat 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