Message ID | 20221019111714.1953262-3-andrej.picej@norik.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp328753wrs; Wed, 19 Oct 2022 06:31:29 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7pWu2k5cHgslwLLIdEGmhKBX9WZqp1rGuPRexOvMqiDB4yORW9cTBY6qRxKymuhwy20jZq X-Received: by 2002:a05:6402:847:b0:453:944a:ba8e with SMTP id b7-20020a056402084700b00453944aba8emr7451620edz.326.1666186289398; Wed, 19 Oct 2022 06:31:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666186289; cv=none; d=google.com; s=arc-20160816; b=qdMhg/P9YOxUem98DTd/vIfvqp8GtHIUcyubSCJIQSU2KxzacNLaXJqHL13SuM9IRC ZqpNLkf28qr0PhIiAKh7gy3MMmKSqOVhTz/yC0o8gwd8smFSrayQgpo0XBLuZGSO1Bdc A8NY751F49KcizhKbZ/tvsOnO/aZKuZETUQI2j6+1Eh6i5ndi7+tB9Ls3XDVyTlcSx5Z 6gxrMSZZJWViAu13e57HbUx1/e+bqmsLrct1BxgiLXnTq0CYpOQoJt/I4UvtrJBpWis/ 6/7S9ymYVyGJPGbLlpFKwqUH6f2uzabOsPRdZvfjJKKBubXJZaeZDZ1Hyk5SM6PzCbV9 tt9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=eNRpwG4buJx4Tvqox9EQWn+avHOAaaONBH2lWfkT/jc=; b=tJJ235ETxK7eVSdJru4z93pBy5qIr7h1CeOI1zI80RaeTEuDJqaM+yPFHdDdhLzl3K VAwL5CHK9i1m2hMfYGIWnoCBYwcd79BDFPgBpNR14ruGHwMCUfoiYY5YZczi6yajG4fS cPfPYIE6GOJAHk8M8zCKwi6bDWJJbA6TeeAHJEL9yQVsiiAAURyUD/97pdQF9AJdd/Nt knQVguURPirR9Z9Yj18q9ZyMS76Mp8gEVpLWuMPqP/TEWBYZ9lerspFaCLqf3qfqrPk+ Nl0PHPJ8tk68AkUZcMyRiDFR83Y9hGlbYezKTn3eyzWhIaN7hY71i80NcLIDjv4lmDZr zGDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@norik.com header.s=default header.b=BXivr5bd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dm12-20020a170907948c00b0078a802cce5dsi1801455ejc.592.2022.10.19.06.31.04; Wed, 19 Oct 2022 06:31:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@norik.com header.s=default header.b=BXivr5bd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232180AbiJSNQE (ORCPT <rfc822;samuel.l.nystrom@gmail.com> + 99 others); Wed, 19 Oct 2022 09:16:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231987AbiJSNPV (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Oct 2022 09:15:21 -0400 X-Greylist: delayed 3540 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Wed, 19 Oct 2022 06:01:02 PDT Received: from cpanel.siel.si (cpanel.siel.si [46.19.9.99]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90E451D1E37; Wed, 19 Oct 2022 06:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=norik.com; s=default; h=Content-Transfer-Encoding:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=eNRpwG4buJx4Tvqox9EQWn+avHOAaaONBH2lWfkT/jc=; b=BXivr5bd5mQEaqcXCZNEmiEbz3 t9zNa27BFIH1TNvmhWDiBYB8ubQHWGHrxwRFyF4v6GtWMeekMRw860/wjdY+/Gbv9EfyhgLgMZfEM UdmPkFKp8d1fydsswt4egcumijRwIlS9oKk1TQdPCC4XTO/yQGGPRO2rKCII8tBn86zPKSOvK/J5W Brjit72EQEoAJ+ZAHWUZoPIkaEJ9nOKXiAQyRvwz/0lwOXfDIPlA2XoAkRFlQnbv8TG1Y321NegFP p2o8ISBUdoCDt3xe6LO7b1CElwkXf3PBQLhBnSIpIbVJVVj/Swzl+xcMNR9kZOBBT6ZfowdMdsOLg VezasqOw==; Received: from 89-212-21-243.static.t-2.net ([89.212.21.243]:45936 helo=localhost.localdomain) by cpanel.siel.si with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from <andrej.picej@norik.com>) id 1ol74W-007ZXa-DP; Wed, 19 Oct 2022 13:17:16 +0200 From: Andrej Picej <andrej.picej@norik.com> To: linux-watchdog@vger.kernel.org Cc: shawnguo@kernel.org, linux@roeck-us.net, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.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: [PATCH 2/3] dt-bindings: watchdog: fsl-imx: document suspend in wait mode Date: Wed, 19 Oct 2022 13:17:13 +0200 Message-Id: <20221019111714.1953262-3-andrej.picej@norik.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20221019111714.1953262-1-andrej.picej@norik.com> References: <20221019111714.1953262-1-andrej.picej@norik.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel.siel.si X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - norik.com X-Get-Message-Sender-Via: cpanel.siel.si: authenticated_id: andrej.picej@norik.com X-Authenticated-Sender: cpanel.siel.si: andrej.picej@norik.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747122911854658234?= X-GMAIL-MSGID: =?utf-8?q?1747122954361595584?= |
Series |
Suspending i.MX watchdog in WAIT mode
|
|
Commit Message
Andrej Picej
Oct. 19, 2022, 11:17 a.m. UTC
Signed-off-by: Andrej Picej <andrej.picej@norik.com>
---
Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml | 5 +++++
1 file changed, 5 insertions(+)
Comments
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? > And what happens else? When it is not suspended in WAIT mode? Best regards, Krzysztof
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? 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. > 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. Hope this answers your questions. Best regards, Andrej
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... > 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? > >> 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? Best regards, Krzysztof
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... > >> 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. Best regards, Andrej
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
On 20. 10. 22 14:41, Alexander Stein wrote: > 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. > Do you have an idea where should it be configured? Just keep in mind that this can not be configured at runtime, since this is write-once bit so any configuration changes regarding this functionality can not be done. Basically if I can sum up the problem: Without this property enabled, the WDW bit is left unset: $ echo freeze > /sys/power/state #device enters Suspend-to-idle, watchdog is left running and the device resets after 128 seconds in this state With this property set, the WDW bit is set at watchdog initialization: $ echo freeze > /sys/power/state #device enters Suspend-to-idle, watchdog is suspended and the device can be left in this state until some other wakeup source triggers interrupt. Thanks, Andrej
On 20/10/2022 09:05, Andrej Picej wrote: > > > On 20. 10. 22 14:41, Alexander Stein wrote: >> 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. >> > > Do you have an idea where should it be configured? Just keep in mind > that this can not be configured at runtime, since this is write-once bit > so any configuration changes regarding this functionality can not be done. > > Basically if I can sum up the problem: > > Without this property enabled, the WDW bit is left unset: > $ echo freeze > /sys/power/state > #device enters Suspend-to-idle, watchdog is left running and the device > resets after 128 seconds in this state I still wonder (and still did not receive) about such use case. When would you like to have such behavior? > > With this property set, the WDW bit is set at watchdog initialization: > $ echo freeze > /sys/power/state > #device enters Suspend-to-idle, watchdog is suspended and the device can > be left in this state until some other wakeup source triggers interrupt. Assuming there is such use case, for keeping watchdog running even though system sleeps (and cannot poke watchdog), it's fine. Best regards, Krzysztof
On 20. 10. 22 20:23, Krzysztof Kozlowski wrote: > On 20/10/2022 09:05, Andrej Picej wrote: >> >> >> On 20. 10. 22 14:41, Alexander Stein wrote: >>> 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. >>> >> >> Do you have an idea where should it be configured? Just keep in mind >> that this can not be configured at runtime, since this is write-once bit >> so any configuration changes regarding this functionality can not be done. >> >> Basically if I can sum up the problem: >> >> Without this property enabled, the WDW bit is left unset: >> $ echo freeze > /sys/power/state >> #device enters Suspend-to-idle, watchdog is left running and the device >> resets after 128 seconds in this state > > I still wonder (and still did not receive) about such use case. When > would you like to have such behavior? > Is this not a valid one?: >>>>> 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. Basically watchdog acting as a supervisor for suspend states. >> >> With this property set, the WDW bit is set at watchdog initialization: >> $ echo freeze > /sys/power/state >> #device enters Suspend-to-idle, watchdog is suspended and the device can >> be left in this state until some other wakeup source triggers interrupt. > > Assuming there is such use case, for keeping watchdog running even > though system sleeps (and cannot poke watchdog), it's fine. > Best regards, Andrej
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