linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrej Picej <andrej.picej@norik.com>
To: Alexander Stein <alexander.stein@ew.tq-group.com>,
	krzysztof.kozlowski+dt@linaro.org
Cc: linux-watchdog@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, wim@linux-watchdog.org,
	linux@roeck-us.net, robh+dt@kernel.org, shawnguo@kernel.org,
	s.hauer@pengutronix.de, kernel@pengutronix.de,
	festevam@gmail.com, linux-imx@nxp.com, Anson.Huang@nxp.com,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] watchdog: imx2_wdg: suspend watchdog in WAIT mode
Date: Wed, 26 Oct 2022 09:03:30 +0200	[thread overview]
Message-ID: <a5eb7912-4d61-7a9e-07ef-34a3320ca468@norik.com> (raw)
In-Reply-To: <2201746.iZASKD2KPV@steina-w>



On 26. 10. 22 08:01, Alexander Stein wrote:
> Hello Andrej,
> 
> Am Dienstag, 25. Oktober 2022, 13:21:18 CEST schrieb Andrej Picej:
>> Hi Alexander,
>>
>> On 25. 10. 22 11:38, Alexander Stein wrote:
>>> Am Dienstag, 25. Oktober 2022, 09:25:31 CEST schrieb Andrej Picej:
>>>> Putting device into the "Suspend-To-Idle" mode causes watchdog to
>>>> trigger and reset the board after set watchdog timeout period elapses.
>>>>
>>>> Introduce new device-tree property "fsl,suspend-in-wait" which suspends
>>>> watchdog in WAIT mode. This is done by setting WDW bit in WCR
>>>> (Watchdog Control Register) Watchdog operation is restored after exiting
>>>> WAIT mode as expected. WAIT mode coresponds with Linux's
>>>> "Suspend-To-Idle".
>>>>
>>>> Signed-off-by: Andrej Picej <andrej.picej@norik.com>
>>>> Reviewed-by: Fabio Estevam <festevam@gmail.com>
>>>> ---
>>>>
>>>> Changes in v2:
>>>>    - validate the property with compatible string, as this functionality
>>>>    
>>>>      is not supported by all devices.
>>>>
>>>> ---
>>>>
>>>>    drivers/watchdog/imx2_wdt.c | 37 +++++++++++++++++++++++++++++++++++++
>>>>    1 file changed, 37 insertions(+)
>>>>
>>>> diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
>>>> index d0c5d47ddede..dd9866c6f1e5 100644
>>>> --- a/drivers/watchdog/imx2_wdt.c
>>>> +++ b/drivers/watchdog/imx2_wdt.c
>>>> @@ -35,6 +35,7 @@
>>>>
>>>>    #define IMX2_WDT_WCR		0x00		/* Control
>>>
>>> Register */
>>>
>>>>    #define IMX2_WDT_WCR_WT		(0xFF << 8)	/* ->
>>>
>>> Watchdog Timeout Field */
>>>
>>>> +#define IMX2_WDT_WCR_WDW	BIT(7)		/* -> Watchdog disable
>>>
>>> for WAIT */
>>>
>>>>    #define IMX2_WDT_WCR_WDA	BIT(5)		/* -> External Reset
>>>
>>> WDOG_B */
>>>
>>>>    #define IMX2_WDT_WCR_SRS	BIT(4)		/* -> Software Reset
>>>
>>> Signal */
>>>
>>>>    #define IMX2_WDT_WCR_WRE	BIT(3)		/* -> WDOG Reset Enable
>>>
>>> */
>>>
>>>> @@ -67,6 +68,27 @@ struct imx2_wdt_device {
>>>>
>>>>    	bool ext_reset;
>>>>    	bool clk_is_on;
>>>>    	bool no_ping;
>>>>
>>>> +	bool sleep_wait;
>>>> +};
>>>> +
>>>> +static const char * const wdw_boards[] __initconst = {
>>>> +	"fsl,imx25-wdt",
>>>> +	"fsl,imx35-wdt",
>>>> +	"fsl,imx50-wdt",
>>>> +	"fsl,imx51-wdt",
>>>> +	"fsl,imx53-wdt",
>>>> +	"fsl,imx6q-wdt",
>>>> +	"fsl,imx6sl-wdt",
>>>> +	"fsl,imx6sll-wdt",
>>>> +	"fsl,imx6sx-wdt",
>>>> +	"fsl,imx6ul-wdt",
>>>> +	"fsl,imx7d-wdt",
>>>> +	"fsl,imx8mm-wdt",
>>>> +	"fsl,imx8mn-wdt",
>>>> +	"fsl,imx8mp-wdt",
>>>> +	"fsl,imx8mq-wdt",
>>>> +	"fsl,vf610-wdt",
>>>> +	NULL
>>>>
>>>>    };
>>>
>>> So the models listed in
>>> Documentation/devicetree/bindings/watchdog/fsl-imx-
>>> wdt.yaml not supporting this feature are
>>> * fsl,imx21-wdt
>>> * fsl,imx27-wdt
>>> * fsl,imx31-wdt
>>> * fsl,ls1012a-wdt
>>> * fsl,ls1043a-wdt
>>> ?
>>
>> yes, you are correct.
>>
>>> But all models are listed as compatible to fsl,imx21-wdt. So there is
>>> something wrong here. IMHO this sounds like the compatible list has to be
>>> split and updated. Depending on that this feature can be detected.
>>> Maintaining another list seems error prone to me.
>>
>> So basically the compatible lists would be split into two groups, one
>> for the devices which support this WDW bit and the rest which don't
>> support this?
> 
> This was my idea, so only one set has to be maintained.
> 
>> You got a point here, but...this means that every processors
>> device-tree, which has two compatible strings (with "fsl,imx21-wdt")
>> should be updated, right? That sounds like quite a lot of changes, which
>> I'd like to avoid if possible.
> 
> Well, the compatible list right now doesn't reflect the hardware features/
> compatibility correctly, so IMHO it should be fixed.
> But apparently Krzysztof is okay having the special property only applicable
> for a specific set of devices. But in this case you will have to maintain two
> sets of device models (bindings + driver) to which WDW applies/does not apply
> to.
> 
Ok, lets see what @Krzysztof has to say about this.

Best regards,
Andrej

  reply	other threads:[~2022-10-26  7:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25  7:25 [PATCH v2 0/3] Suspending i.MX watchdog in WAIT mode Andrej Picej
2022-10-25  7:25 ` [PATCH v2 1/3] watchdog: imx2_wdg: suspend " Andrej Picej
2022-10-25  9:38   ` Alexander Stein
2022-10-25 11:21     ` Andrej Picej
2022-10-26  6:01       ` Alexander Stein
2022-10-26  7:03         ` Andrej Picej [this message]
2022-10-25 12:27   ` Marco Felsch
2022-10-25 13:01     ` Andrej Picej
2022-10-25 14:21   ` Guenter Roeck
2022-10-26  6:59     ` Andrej Picej
2022-10-25  7:25 ` [PATCH v2 2/3] dt-bindings: watchdog: fsl-imx: document suspend in wait mode Andrej Picej
2022-10-25 13:48   ` Krzysztof Kozlowski
2022-10-26  6:38     ` Andrej Picej
2022-10-26 14:12       ` Krzysztof Kozlowski
2022-10-27  7:16         ` Andrej Picej
2022-10-25  7:25 ` [PATCH v2 3/3] ARM: dts: imx6ul/ull: suspend i.MX6UL watchdog " 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=a5eb7912-4d61-7a9e-07ef-34a3320ca468@norik.com \
    --to=andrej.picej@norik.com \
    --cc=Anson.Huang@nxp.com \
    --cc=alexander.stein@ew.tq-group.com \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=krzysztof.kozlowski+dt@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).