linux-watchdog.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Andrej Picej <andrej.picej@norik.com>, linux-watchdog@vger.kernel.org
Cc: wim@linux-watchdog.org, shawnguo@kernel.org,
	s.hauer@pengutronix.de, kernel@pengutronix.de,
	festevam@gmail.com, linux-imx@nxp.com
Subject: Re: [RFC PATCH 0/1] Suspending i.MX watchdog in WAIT mode
Date: Thu, 22 Sep 2022 07:56:50 -0700	[thread overview]
Message-ID: <72fb8f04-52d1-af99-dfff-4a53ee3d3440@roeck-us.net> (raw)
In-Reply-To: <325585e9-3d50-eee2-4443-5509dde6da90@norik.com>

On 9/22/22 00:17, Andrej Picej wrote:
> Hi Guenter,
> 
> On 21. 09. 22 16:18, Guenter Roeck wrote:
>> On 9/21/22 05:46, Andrej Picej wrote:
>>> Hi all,
>>>
>>> we are using i.MX6UL with its watchdog WDOG1 and kernel 5.15.62. It was
>>> discovered that the watchdog triggers reset when the device is put into
>>> 'Suspend-To-Idle' (WAIT) state.
>>>
>>
>> Is that equivalent to "suspend" from Linux perspective, or some other
>> mode ? How does the device get into this state ?
> 
> I think WAIT mode maps to System idle mode in linux [1].
> 

Sorry, I am not going to read that entire manual.

> Sorry don't quite understand your second question.
> Do you mean how we trigger this state?
> We trigger this state with:
>  >     imx6ul-dev:~# echo freeze > /sys/power/state
> 

So it is not "suspend" ? I am not sure if it is appropriate to stop
the watchdog timer in this situation. Normally it is only stopped
in suspend mode.

Also, how does this interact or interfere with the suspend/resume code
in the driver, and does it behave the same for all chips supported by
the driver ? For example, in the current code, i.MX7D is handled
differently. What compatible entry are you using anyway ? There is none
for i.MX6UL. Did you make sure that the same bit doesn't mean something
else for other chips ?

Thanks,
Guenter

> If you mean what is done prior to entering this state?
> The device enters WAIT mode when CLPCR bit is set to WAIT. The device
> enters WAIT mode by gating the CPU clock, all other clocks can be gated
> by programming CGR bits in WAIT mode.
> 
> [1] i.MX Linux Reference Manual, Rev. 0, 07/2016
> 
> Andrej
> 
>>
>> Guenter
>>
>>> i.MX6UL watchdog has a WDW (Watchdog Disable for Wait) bit in WCR
>>> (Watchdog Control Register) which can put the watchdog in suspend when
>>> the device is put to WAIT mode. Similarly, WDZST bit is already set in
>>> imx2_wdt driver by default, which suspends the watchdog in STOP and DOZE
>>> modes.
>>>
>>> This RFC patch suspends watchdog when the device is in WAIT mode, which
>>> fixes our problem. During development, we noticed some reports where
>>> setting WDW bit caused inconsistent timeout events or inability of
>>> watchdog to reset the board. We didn't have these problems but I am
>>> curious if there is a case where device is put into WAIT mode and
>>> watchdog should be enabled?
>>>
>>> Maybe for cases where watchdog is used for WAIT mode supervision? So
>>> basically to reset the system if device doesn't exit WAIT mode on its
>>> own?
>>>
>>> The problem can be recreated with:
>>>
>>>     imx6ul-dev:~# echo freeze > /sys/power/state
>>>     [  101.093336] PM: suspend entry (s2idle)
>>>     [  101.097785] Filesystems sync: 0.000 seconds
>>>     [  101.122295] Freezing user space processes ... (elapsed 0.001 seconds) done.
>>>     [  101.130637] OOM killer disabled.
>>>     [  101.133998] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>>     [  101.142941] printk: Suspending console(s) (use no_console_suspend to debug)
>>>     ...
>>> Device resets after watchdog timeout expires! ~105s
>>>
>>> Thank you for your feedback.
>>>
>>> Best regards,
>>> Andrej
>>>
>>> Andrej Picej (1):
>>>    watchdog: imx2_wdg: suspend watchdog in WAIT mode
>>>
>>>   drivers/watchdog/imx2_wdt.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>
> 


  reply	other threads:[~2022-09-22 14:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 12:46 [RFC PATCH 0/1] Suspending i.MX watchdog in WAIT mode Andrej Picej
2022-09-21 12:46 ` [RFC PATCH 1/1] watchdog: imx2_wdg: suspend " Andrej Picej
2022-09-21 14:18 ` [RFC PATCH 0/1] Suspending i.MX " Guenter Roeck
2022-09-22  7:17   ` Andrej Picej
2022-09-22 14:56     ` Guenter Roeck [this message]
2022-09-23  7:27       ` Andrej Picej
2022-09-23 13:48         ` Guenter Roeck
2022-09-26  7:36           ` Andrej Picej
2022-10-03 11:36             ` Andrej Picej

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=72fb8f04-52d1-af99-dfff-4a53ee3d3440@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=andrej.picej@norik.com \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-imx@nxp.com \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).