From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
To: Guenter Roeck <linux@roeck-us.net>,
"wim@iguana.be" <wim@iguana.be>,
"gregory.clement@free-electrons.com"
<gregory.clement@free-electrons.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] watchdog: orion: don't enable rstout if an interrupt is configured
Date: Wed, 27 Feb 2019 20:59:07 +0000 [thread overview]
Message-ID: <636717314b294a5f9a4ed1ffa44625c4@svr-chch-ex1.atlnz.lc> (raw)
In-Reply-To: 4f82b24c3b244d3eba0f8de8cb25049f@svr-chch-ex1.atlnz.lc
Hijacking an old thread,
On 11/10/17 5:30 PM, Chris Packham wrote:
> On 11/10/17 16:42, Guenter Roeck wrote:
>> On 10/10/2017 07:29 PM, Chris Packham wrote:
>>> The orion_wdt_irq invokes panic() so we are going to reset the CPU
>>> regardless. By not setting this bit we get a chance to gather debug
>>> from the panic output before the system is reset.
>>>
>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>>
>> Unless I am missing something, this assumes that the interrupt is
>> handled, ie that the system is not stuck with interrupts disabled.
>> This makes the watchdog less reliable. This added verbosity comes
>> at a significant cost. I'd like to get input from others if this
>> is acceptable.
>>
>> That would be different if there was a means to configure a pretimeout,
>> ie a means to tell the system to generate an irq first, followed by a
>> hard reset if the interrupt is not served. that does not seem to be
>> the case here, though.
>>
>
> As far as I can tell there is no pretimeout capability in the orion
> /armada WDT. I have got a work-in-progress patch that enables the RSTOUT
> in the interrupt handler which some-what mitigates your concern but
> still requires the interrupt to be handled at least once.
>
> Another option would be to use one of the spare global timers to provide
> the interrupt-driven aspect.
So as Guenter rightly pointed out my original patch meant that we'd hang
if we got stuck in a loop with interrupts disabled. Shortly after that
that's exactly what happened on my test setup.
I've now been able to follow-up on the idea of using one of the spare
global timers as a pretimeout indication and it's looking pretty
promising. The patch is below (beware MUA wrapping). I'll submit it
properly but I'm wondering if I should add the timer1 based watchdog as
a separate watchdog device or like I have below roll it into the
existing watchdog device.
--- 8< ---
diff --git a/arch/arm/boot/dts/armada-38x.dtsi
b/arch/arm/boot/dts/armada-38x.dtsi
index 8530d3594ca2..abd45adb4728 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -421,6 +421,7 @@
reg = <0x20300 0x34>, <0x20704 0x4>,
<0x18260 0x4>;
clocks = <&coreclk 2>, <&refclk>;
clock-names = "nbclk", "fixed";
+ interrupts-extended = <&gic GIC_SPI 9
IRQ_TYPE_LEVEL_HIGH>;
};
cpurst: cpurst@20800 {
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index c6b8f4a43bde..89eae53b1b17 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -37,13 +37,16 @@
#define TIMER_CTRL 0x0000
#define TIMER_A370_STATUS 0x04
+#define TIMER1_RELOAD_OFF 0x0018
+#define TIMER1_VAL_OFF 0x001c
+
#define WDT_MAX_CYCLE_COUNT 0xffffffff
#define WDT_A370_RATIO_MASK(v) ((v) << 16)
#define WDT_A370_RATIO_SHIFT 5
#define WDT_A370_RATIO (1 << WDT_A370_RATIO_SHIFT)
-#define WDT_AXP_FIXED_ENABLE_BIT BIT(10)
+#define WDT_AXP_FIXED_ENABLE_BIT BIT(10) | BIT(12)
#define WDT_A370_EXPIRED BIT(31)
static bool nowayout = WATCHDOG_NOWAYOUT;
@@ -183,6 +186,9 @@ static int orion_wdt_ping(struct watchdog_device
*wdt_dev)
/* Reload watchdog duration */
writel(dev->clk_rate * wdt_dev->timeout,
dev->reg + dev->data->wdt_counter_offset);
+ writel(dev->clk_rate * (wdt_dev->timeout/2),
+ dev->reg + TIMER1_VAL_OFF);
+
return 0;
}
@@ -194,6 +200,8 @@ static int armada375_start(struct watchdog_device
*wdt_dev)
/* Set watchdog duration */
writel(dev->clk_rate * wdt_dev->timeout,
dev->reg + dev->data->wdt_counter_offset);
+ writel(dev->clk_rate * (wdt_dev->timeout/2),
+ dev->reg + TIMER1_VAL_OFF);
/* Clear the watchdog expiration bit */
atomic_io_modify(dev->reg + TIMER_A370_STATUS,
WDT_A370_EXPIRED, 0);
@@ -443,7 +451,7 @@ static const struct orion_watchdog_data
armada375_data = {
static const struct orion_watchdog_data armada380_data = {
.rstout_enable_bit = BIT(8),
.rstout_mask_bit = BIT(10),
- .wdt_enable_bit = BIT(8),
+ .wdt_enable_bit = BIT(8) | BIT(2),
.wdt_counter_offset = 0x34,
.clock_init = armadaxp_wdt_clock_init,
.enabled = armada375_enabled,
--- 8< ---
>
> Of course if the irq isn't specified then the existing behaviour is
> retained which would make the 3/3 patch of this series the debatable part.
>
>
>> Guenter
>>
>>> ---
>>> drivers/watchdog/orion_wdt.c | 25 +++++++++++++++++--------
>>> 1 file changed, 17 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
>>> index ea676d233e1e..ce88f339ef7f 100644
>>> --- a/drivers/watchdog/orion_wdt.c
>>> +++ b/drivers/watchdog/orion_wdt.c
>>> @@ -71,6 +71,7 @@ struct orion_watchdog {
>>> unsigned long clk_rate;
>>> struct clk *clk;
>>> const struct orion_watchdog_data *data;
>>> + int irq;
>>> };
>>>
>>> static int orion_wdt_clock_init(struct platform_device *pdev,
>>> @@ -203,9 +204,11 @@ static int armada375_start(struct watchdog_device *wdt_dev)
>>> dev->data->wdt_enable_bit);
>>>
>>> /* Enable reset on watchdog */
>>> - reg = readl(dev->rstout);
>>> - reg |= dev->data->rstout_enable_bit;
>>> - writel(reg, dev->rstout);
>>> + if (!dev->irq) {
>>> + reg = readl(dev->rstout);
>>> + reg |= dev->data->rstout_enable_bit;
>>> + writel(reg, dev->rstout);
>>> + }
>>>
>>> atomic_io_modify(dev->rstout_mask, dev->data->rstout_mask_bit, 0);
>>> return 0;
>>> @@ -228,9 +231,12 @@ static int armada370_start(struct watchdog_device *wdt_dev)
>>> dev->data->wdt_enable_bit);
>>>
>>> /* Enable reset on watchdog */
>>> - reg = readl(dev->rstout);
>>> - reg |= dev->data->rstout_enable_bit;
>>> - writel(reg, dev->rstout);
>>> + if (!dev->irq) {
>>> + reg = readl(dev->rstout);
>>> + reg |= dev->data->rstout_enable_bit;
>>> + writel(reg, dev->rstout);
>>> + }
>>> +
>>> return 0;
>>> }
>>>
>>> @@ -247,8 +253,9 @@ static int orion_start(struct watchdog_device *wdt_dev)
>>> dev->data->wdt_enable_bit);
>>>
>>> /* Enable reset on watchdog */
>>> - atomic_io_modify(dev->rstout, dev->data->rstout_enable_bit,
>>> - dev->data->rstout_enable_bit);
>>> + if (!dev->irq)
>>> + atomic_io_modify(dev->rstout, dev->data->rstout_enable_bit,
>>> + dev->data->rstout_enable_bit);
>>>
>>> return 0;
>>> }
>>> @@ -595,6 +602,8 @@ static int orion_wdt_probe(struct platform_device *pdev)
>>> dev_err(&pdev->dev, "failed to request IRQ\n");
>>> goto disable_clk;
>>> }
>>> +
>>> + dev->irq = irq;
>>> }
>>>
>>> watchdog_set_nowayout(&dev->wdt, nowayout);
>>>
>>
>>
>
>
next prev parent reply other threads:[~2019-02-27 20:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-11 2:29 [PATCH 0/3] getting more output from orion_wdt Chris Packham
2017-10-11 2:29 ` [PATCH 1/3] watchdog: orion: fix typo Chris Packham
2017-10-11 3:35 ` Guenter Roeck
2017-10-11 2:29 ` [PATCH 2/3] watchdog: orion: don't enable rstout if an interrupt is configured Chris Packham
2017-10-11 3:41 ` Guenter Roeck
2017-10-11 4:30 ` Chris Packham
2019-02-27 20:59 ` Chris Packham [this message]
2019-02-27 23:07 ` Guenter Roeck
2019-03-04 22:51 ` [PATCH 0/2] watchdog: orion_wdt: add pretimeout support Chris Packham
2019-03-04 22:51 ` [PATCH 1/2] watchdog: orion_wdt: remove orion_wdt_set_timeout Chris Packham
2019-03-05 17:17 ` Guenter Roeck
2019-03-04 22:51 ` [PATCH 2/2] watchdog: orion_wdt: use timer1 as a pretimeout Chris Packham
2019-03-05 0:57 ` Andrew Lunn
2019-03-05 1:26 ` Chris Packham
2019-03-05 2:09 ` Andrew Lunn
2019-03-05 17:27 ` Guenter Roeck
2017-10-11 2:29 ` [PATCH 3/3] ARM: mvebu: dts: connect interrupt for WD on armada-38x Chris Packham
2017-10-12 14:16 ` Gregory CLEMENT
2017-10-12 20:12 ` Chris Packham
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=636717314b294a5f9a4ed1ffa44625c4@svr-chch-ex1.atlnz.lc \
--to=chris.packham@alliedtelesis.co.nz \
--cc=devicetree@vger.kernel.org \
--cc=gregory.clement@free-electrons.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=wim@iguana.be \
/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).