devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Andrej Picej <andrej.picej@norik.com>
Cc: linux-watchdog@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, shawnguo@kernel.org,
	linux@roeck-us.net, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, linux-imx@nxp.com,
	festevam@gmail.com, kernel@pengutronix.de,
	s.hauer@pengutronix.de, wim@linux-watchdog.org,
	robh+dt@kernel.org
Subject: Re: Re: [PATCH 2/3] dt-bindings: watchdog: fsl-imx: document suspend in wait mode
Date: Thu, 20 Oct 2022 14:41:40 +0200	[thread overview]
Message-ID: <24401572.EfDdHjke4D@steina-w> (raw)
In-Reply-To: <143f1466-e34a-254d-4e6e-fefa17ad1390@norik.com>

Am Donnerstag, 20. Oktober 2022, 14:36:10 CEST schrieb Andrej Picej:
> On 20. 10. 22 14:18, Krzysztof Kozlowski wrote:
> > On 20/10/2022 02:23, Andrej Picej wrote:
> >> Hi Alexander and Krzysztof,
> >> 
> >> hope I can reply to both questions here.
> >> 
> >> On 19. 10. 22 17:51, Krzysztof Kozlowski wrote:
> >>> On 19/10/2022 09:00, Alexander Stein wrote:
> >>>> Hello Andrej,
> >>> 
> >>>> Am Mittwoch, 19. Oktober 2022, 13:17:13 CEST schrieb Andrej Picej:
> >>> Missing commit msg.
> >>> 
> >>>>> Signed-off-by: Andrej Picej <andrej.picej@norik.com>
> >>>>> ---
> >>>>> 
> >>>>>    Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml | 5
> >>>>>    +++++
> >>>>>    1 file changed, 5 insertions(+)
> >>>>> 
> >>>>> diff --git
> >>>>> a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
> >>>>> b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml index
> >>>>> fb7695515be1..01b3e04e7e65 100644
> >>>>> --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
> >>>>> +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
> >>>>> 
> >>>>> @@ -55,6 +55,11 @@ properties:
> >>>>>          If present, the watchdog device is configured to assert its
> >>>>>          external reset (WDOG_B) instead of issuing a software reset.
> >>>>> 
> >>>>> +  fsl,suspend-in-wait:
> >>>>> +    $ref: /schemas/types.yaml#/definitions/flag
> >>>>> +    description: |
> >>>>> +      If present, the watchdog device is suspended in WAIT mode.
> >>>>> +
> >>>>> 
> >>>>>    required:
> >>>>>      - compatible
> >>>>>      - interrupts
> >>>> 
> >>>> What is the condition the watchdog is suspended in WAIT mode? Is this
> >>>> specific to SoC or platform or something else?
> >> 
> >> Sorry, what exactly do you mean by condition?
> > 
> > Ugh, I also cannot parse it now...

Sorry, Krzysztof already asked the right question: When does one want to 
enable/disable this feature?

> >> When the property
> >> "fsl,suspend-in-wait" is set the watchdog is suspended in WAIT mode, so
> >> this is defined by the user. Didn't want to apply it for all the
> >> supported machines since there could be devices which depend on watchdog
> >> triggering in WAIT mode. We stumbled on this problem on imx6 devices,
> >> but the same bit (with the same description) is found on imx25, imx35,
> >> imx50/51/53, imx7 and imx8.
> > 
> > I meant, what is expected to happen if you do not enable this bit and
> > watchdog triggers in WAIT mode? IOW, why someone might want to enable or
> > disable this property?
> 
> If this is not enabled and you put the device into the Suspend-to-idle
> mode the device resets after 128 seconds. If not, the device can be left
> in that state for infinite time. I'm guessing you want me to better
> explain the property in device tree docs right?
> I can do that in v2.
> 
> >>> And what happens else? When it is not suspended in WAIT mode?
> >> 
> >> When you put the device in "freeze"/"Suspend-To-Idle" low-power mode the
> >> watchdog keeps running and triggers a reset after 128 seconds. So the
> >> maximum length the device can stay in this mode is limited to 128
> >> seconds.
> > 
> > And who wakes up the system before 128 seconds? IOW is there a use case
> > of not enabling this property?
> 
> Well I can think of one, system can be woken up by some other interrupt.
> Like RTC which triggers interrupt (for example every 10s). So if this
> property is left disabled the watchdog can handle errors where other
> wakeup sources don't trigger interrupt or if the system is unable to
> wake from low-power state. In that case the watchdog will do a hard
> reset of the device.
> 
> But I'm not really sure if anybody uses this, just wanted to make sure
> that we keep the default behaviour as it is, since this driver is used
> by many devices and for quite some time.

This sounds more like (application) configuration. If so this should not be 
configured in device tree, IMHO.

Best regards,
Alexander




  reply	other threads:[~2022-10-20 12:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-19 11:17 [PATCH 0/3] Suspending i.MX watchdog in WAIT mode Andrej Picej
2022-10-19 11:17 ` [PATCH 1/3] watchdog: imx2_wdg: suspend " Andrej Picej
2022-10-19 15:33   ` Guenter Roeck
2022-10-20  6:02     ` Andrej Picej
2022-10-19 11:17 ` [PATCH 2/3] dt-bindings: watchdog: fsl-imx: document suspend in wait mode Andrej Picej
2022-10-19 13:00   ` Alexander Stein
2022-10-19 15:51     ` Krzysztof Kozlowski
2022-10-20  6:23       ` Andrej Picej
2022-10-20 12:18         ` Krzysztof Kozlowski
2022-10-20 12:36           ` Andrej Picej
2022-10-20 12:41             ` Alexander Stein [this message]
2022-10-20 13:05               ` Andrej Picej
2022-10-20 18:23                 ` Krzysztof Kozlowski
2022-10-21  5:56                   ` Andrej Picej
2022-10-19 11:17 ` [PATCH 3/3] ARM: dts: imx6ul/ull: suspend i.MX6UL watchdog " Andrej Picej
2022-10-19 12:16 ` [PATCH 0/3] Suspending i.MX watchdog in WAIT mode Fabio Estevam
2022-10-19 15:30 ` Guenter Roeck
2022-10-20  5:21   ` Andrej Picej
2022-10-19 15:46 ` Krzysztof Kozlowski
2022-10-20  5:49   ` Andrej Picej
2022-10-20 12:04     ` Krzysztof Kozlowski
2022-10-20 12:16       ` 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=24401572.EfDdHjke4D@steina-w \
    --to=alexander.stein@ew.tq-group.com \
    --cc=andrej.picej@norik.com \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=robh+dt@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).