All of lore.kernel.org
 help / color / mirror / Atom feed
From: 王擎 <wangqing@vivo.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>,
	Rob Herring <robh+dt@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re:Re: [PATCH V6 1/2] watchdog: mtk: support pre-timeout when the bark irq is available
Date: Thu, 22 Apr 2021 15:05:49 +0800 (GMT+08:00)	[thread overview]
Message-ID: <AHkAYwDkDhOuqx67*F9EB4r-.3.1619075149689.Hmail.wangqing@vivo.com> (raw)
In-Reply-To: <26bed2e5-6ec8-72ae-ff2c-c707c00d5125@roeck-us.net>


>On 4/21/21 8:46 PM, 王擎 wrote:
>> 
>>> On 4/21/21 7:45 PM, Wang Qing wrote:
>>>> Use the bark interrupt as the pretimeout notifier if available.
>>>>
>>>> When the watchdog timer expires in dual mode, an interrupt will be
>>>> triggered first, then the timing restarts. The reset signal will be
>>>> initiated when the timer expires again.
>>>>
>>>> The pretimeout notification shall occur at timeout-sec/2.
>>>>
>>>> V2:
>>>> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
>>>>
>>>> V3:
>>>> - Modify the pretimeout behavior, manually reset after the pretimeout
>>>> - is processed and wait until timeout.
>>>>
>>>> V4:
>>>> - Remove pretimeout related processing. 
>>>> - Add dual mode control separately.
>>>>
>>>> V5:
>>>> - Fix some formatting and printing problems.
>>>>
>>>> V6:
>>>> - Realize pretimeout processing through dualmode.
>>>>
>>>> Signed-off-by: Wang Qing <wangqing@vivo.com>
>>>> ---
>>>>  drivers/watchdog/mtk_wdt.c | 53 +++++++++++++++++++++++++++++++++++++++++-----
>>>>  1 file changed, 48 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>>>> index 97ca993..ebc648b
>>>> --- a/drivers/watchdog/mtk_wdt.c
>>>> +++ b/drivers/watchdog/mtk_wdt.c
>>>> @@ -25,6 +25,7 @@
>>>>  #include <linux/reset-controller.h>
>>>>  #include <linux/types.h>
>>>>  #include <linux/watchdog.h>
>>>> +#include <linux/interrupt.h>
>>>>  
>>>>  #define WDT_MAX_TIMEOUT		31
>>>>  #define WDT_MIN_TIMEOUT		1
>>>> @@ -184,15 +185,22 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>>>>  {
>>>>  	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>>>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>>> +	unsigned int timeout_interval;
>>>>  	u32 reg;
>>>>  
>>>> -	wdt_dev->timeout = timeout;
>>>> +	timeout_interval = wdt_dev->timeout = timeout;
>>>> +	/*
>>>> +	 * In dual mode, irq will be triggered at timeout/2
>>>> +	 * the real timeout occurs at timeout
>>>> +	 */
>>>> +	if (wdt_dev->pretimeout)
>>>> +		timeout_interval = wdt_dev->pretimeout = timeout/2;
>>>
>>> Please run checkpatch --strict and fix what it reports.
>>> Also, there should be a set_pretimeout function to set the
>>> pretimeout. It is ok to update it here, but it should be set
>>> in its own function to make sure that the actual value
>>> is reported back to userspace.
>>>
>>> Thanks,
>>> Guenter
>> 
>> The reason why the set_pretimeout interface is not provided is 
>> because the pretimeout is fixed after the timeout is set,  we need
>> to modify timeout after setting pretimeout, which is puzzling.
>> 
>
>What you need to do is to set pretimeout = timeout / 2 if a pretimeout
>is set to a value != 0. Just like we adjust timeout to valid values
>when set, we adjust pretimeout as well. I don't see a problem with that.
>
>Guenter

Thanks, Guenter. But this will complicate the situation:
First, set_pretimeout will become an interface for dynamically enable and
disable the pre-timeout func, instead of adjusting the pretimeout time. 

Secondly, when the irq is not registered, the user cannot be allowed to set
the pretimeout to non-zero. When irq is registered, it doesn't make any sense
to turn off pre-timeout func. 

Because of the particularity of dual mode, I still insist on enabling the
pretimeout or not through devicetree. And looking forward to your suggestions.

Thanks,
Qing



WARNING: multiple messages have this Message-ID (diff)
From: 王擎 <wangqing@vivo.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>,
	Rob Herring <robh+dt@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	 linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org,
	 linux-arm-kernel@lists.infradead.org,
	 linux-mediatek@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re:Re: [PATCH V6 1/2] watchdog: mtk: support pre-timeout when the bark irq is available
Date: Thu, 22 Apr 2021 15:05:49 +0800 (GMT+08:00)	[thread overview]
Message-ID: <AHkAYwDkDhOuqx67*F9EB4r-.3.1619075149689.Hmail.wangqing@vivo.com> (raw)
In-Reply-To: <26bed2e5-6ec8-72ae-ff2c-c707c00d5125@roeck-us.net>


>On 4/21/21 8:46 PM, 王擎 wrote:
>> 
>>> On 4/21/21 7:45 PM, Wang Qing wrote:
>>>> Use the bark interrupt as the pretimeout notifier if available.
>>>>
>>>> When the watchdog timer expires in dual mode, an interrupt will be
>>>> triggered first, then the timing restarts. The reset signal will be
>>>> initiated when the timer expires again.
>>>>
>>>> The pretimeout notification shall occur at timeout-sec/2.
>>>>
>>>> V2:
>>>> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
>>>>
>>>> V3:
>>>> - Modify the pretimeout behavior, manually reset after the pretimeout
>>>> - is processed and wait until timeout.
>>>>
>>>> V4:
>>>> - Remove pretimeout related processing. 
>>>> - Add dual mode control separately.
>>>>
>>>> V5:
>>>> - Fix some formatting and printing problems.
>>>>
>>>> V6:
>>>> - Realize pretimeout processing through dualmode.
>>>>
>>>> Signed-off-by: Wang Qing <wangqing@vivo.com>
>>>> ---
>>>>  drivers/watchdog/mtk_wdt.c | 53 +++++++++++++++++++++++++++++++++++++++++-----
>>>>  1 file changed, 48 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>>>> index 97ca993..ebc648b
>>>> --- a/drivers/watchdog/mtk_wdt.c
>>>> +++ b/drivers/watchdog/mtk_wdt.c
>>>> @@ -25,6 +25,7 @@
>>>>  #include <linux/reset-controller.h>
>>>>  #include <linux/types.h>
>>>>  #include <linux/watchdog.h>
>>>> +#include <linux/interrupt.h>
>>>>  
>>>>  #define WDT_MAX_TIMEOUT		31
>>>>  #define WDT_MIN_TIMEOUT		1
>>>> @@ -184,15 +185,22 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>>>>  {
>>>>  	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>>>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>>> +	unsigned int timeout_interval;
>>>>  	u32 reg;
>>>>  
>>>> -	wdt_dev->timeout = timeout;
>>>> +	timeout_interval = wdt_dev->timeout = timeout;
>>>> +	/*
>>>> +	 * In dual mode, irq will be triggered at timeout/2
>>>> +	 * the real timeout occurs at timeout
>>>> +	 */
>>>> +	if (wdt_dev->pretimeout)
>>>> +		timeout_interval = wdt_dev->pretimeout = timeout/2;
>>>
>>> Please run checkpatch --strict and fix what it reports.
>>> Also, there should be a set_pretimeout function to set the
>>> pretimeout. It is ok to update it here, but it should be set
>>> in its own function to make sure that the actual value
>>> is reported back to userspace.
>>>
>>> Thanks,
>>> Guenter
>> 
>> The reason why the set_pretimeout interface is not provided is 
>> because the pretimeout is fixed after the timeout is set,  we need
>> to modify timeout after setting pretimeout, which is puzzling.
>> 
>
>What you need to do is to set pretimeout = timeout / 2 if a pretimeout
>is set to a value != 0. Just like we adjust timeout to valid values
>when set, we adjust pretimeout as well. I don't see a problem with that.
>
>Guenter

Thanks, Guenter. But this will complicate the situation:
First, set_pretimeout will become an interface for dynamically enable and
disable the pre-timeout func, instead of adjusting the pretimeout time. 

Secondly, when the irq is not registered, the user cannot be allowed to set
the pretimeout to non-zero. When irq is registered, it doesn't make any sense
to turn off pre-timeout func. 

Because of the particularity of dual mode, I still insist on enabling the
pretimeout or not through devicetree. And looking forward to your suggestions.

Thanks,
Qing


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: 王擎 <wangqing@vivo.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>,
	Rob Herring <robh+dt@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	 linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org,
	 linux-arm-kernel@lists.infradead.org,
	 linux-mediatek@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re:Re: [PATCH V6 1/2] watchdog: mtk: support pre-timeout when the bark irq is available
Date: Thu, 22 Apr 2021 15:05:49 +0800 (GMT+08:00)	[thread overview]
Message-ID: <AHkAYwDkDhOuqx67*F9EB4r-.3.1619075149689.Hmail.wangqing@vivo.com> (raw)
In-Reply-To: <26bed2e5-6ec8-72ae-ff2c-c707c00d5125@roeck-us.net>


>On 4/21/21 8:46 PM, 王擎 wrote:
>> 
>>> On 4/21/21 7:45 PM, Wang Qing wrote:
>>>> Use the bark interrupt as the pretimeout notifier if available.
>>>>
>>>> When the watchdog timer expires in dual mode, an interrupt will be
>>>> triggered first, then the timing restarts. The reset signal will be
>>>> initiated when the timer expires again.
>>>>
>>>> The pretimeout notification shall occur at timeout-sec/2.
>>>>
>>>> V2:
>>>> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
>>>>
>>>> V3:
>>>> - Modify the pretimeout behavior, manually reset after the pretimeout
>>>> - is processed and wait until timeout.
>>>>
>>>> V4:
>>>> - Remove pretimeout related processing. 
>>>> - Add dual mode control separately.
>>>>
>>>> V5:
>>>> - Fix some formatting and printing problems.
>>>>
>>>> V6:
>>>> - Realize pretimeout processing through dualmode.
>>>>
>>>> Signed-off-by: Wang Qing <wangqing@vivo.com>
>>>> ---
>>>>  drivers/watchdog/mtk_wdt.c | 53 +++++++++++++++++++++++++++++++++++++++++-----
>>>>  1 file changed, 48 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>>>> index 97ca993..ebc648b
>>>> --- a/drivers/watchdog/mtk_wdt.c
>>>> +++ b/drivers/watchdog/mtk_wdt.c
>>>> @@ -25,6 +25,7 @@
>>>>  #include <linux/reset-controller.h>
>>>>  #include <linux/types.h>
>>>>  #include <linux/watchdog.h>
>>>> +#include <linux/interrupt.h>
>>>>  
>>>>  #define WDT_MAX_TIMEOUT		31
>>>>  #define WDT_MIN_TIMEOUT		1
>>>> @@ -184,15 +185,22 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>>>>  {
>>>>  	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>>>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>>> +	unsigned int timeout_interval;
>>>>  	u32 reg;
>>>>  
>>>> -	wdt_dev->timeout = timeout;
>>>> +	timeout_interval = wdt_dev->timeout = timeout;
>>>> +	/*
>>>> +	 * In dual mode, irq will be triggered at timeout/2
>>>> +	 * the real timeout occurs at timeout
>>>> +	 */
>>>> +	if (wdt_dev->pretimeout)
>>>> +		timeout_interval = wdt_dev->pretimeout = timeout/2;
>>>
>>> Please run checkpatch --strict and fix what it reports.
>>> Also, there should be a set_pretimeout function to set the
>>> pretimeout. It is ok to update it here, but it should be set
>>> in its own function to make sure that the actual value
>>> is reported back to userspace.
>>>
>>> Thanks,
>>> Guenter
>> 
>> The reason why the set_pretimeout interface is not provided is 
>> because the pretimeout is fixed after the timeout is set,  we need
>> to modify timeout after setting pretimeout, which is puzzling.
>> 
>
>What you need to do is to set pretimeout = timeout / 2 if a pretimeout
>is set to a value != 0. Just like we adjust timeout to valid values
>when set, we adjust pretimeout as well. I don't see a problem with that.
>
>Guenter

Thanks, Guenter. But this will complicate the situation:
First, set_pretimeout will become an interface for dynamically enable and
disable the pre-timeout func, instead of adjusting the pretimeout time. 

Secondly, when the irq is not registered, the user cannot be allowed to set
the pretimeout to non-zero. When irq is registered, it doesn't make any sense
to turn off pre-timeout func. 

Because of the particularity of dual mode, I still insist on enabling the
pretimeout or not through devicetree. And looking forward to your suggestions.

Thanks,
Qing


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-04-22  7:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-22  2:45 [PATCH V6 0/2] watchdog: mtk: support pre-timeout when the bark irq is available Wang Qing
2021-04-22  2:45 ` Wang Qing
2021-04-22  2:45 ` Wang Qing
2021-04-22  2:45 ` [PATCH V6 1/2] " Wang Qing
2021-04-22  2:45   ` Wang Qing
2021-04-22  2:45   ` Wang Qing
2021-04-22  3:31   ` Guenter Roeck
2021-04-22  3:31     ` Guenter Roeck
2021-04-22  3:31     ` Guenter Roeck
2021-04-22  3:46     ` 王擎
2021-04-22  3:46       ` 王擎
2021-04-22  3:46       ` 王擎
2021-04-22  4:02       ` Guenter Roeck
2021-04-22  4:02         ` Guenter Roeck
2021-04-22  4:02         ` Guenter Roeck
2021-04-22  7:05         ` 王擎 [this message]
2021-04-22  7:05           ` 王擎
2021-04-22  7:05           ` 王擎
2021-04-22 13:56           ` Guenter Roeck
2021-04-22 13:56             ` Guenter Roeck
2021-04-22 13:56             ` Guenter Roeck
2021-04-22  2:45 ` [PATCH V6 2/2] doc: mtk-wdt: " Wang Qing
2021-04-22  2:45   ` Wang Qing
2021-04-22  2:45   ` Wang Qing
2021-04-22  3:32   ` Guenter Roeck
2021-04-22  3:32     ` Guenter Roeck
2021-04-22  3:32     ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AHkAYwDkDhOuqx67*F9EB4r-.3.1619075149689.Hmail.wangqing@vivo.com' \
    --to=wangqing@vivo.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=wim@linux-watchdog.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.