From: Andrew Lunn <andrew@lunn.ch>
To: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: linux@roeck-us.net, gregory.clement@bootlin.com,
jason@lakedaemon.net, linux-arm-kernel@lists.infradead.org,
linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Wim Van Sebroeck <wim@linux-watchdog.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH 2/2] watchdog: orion_wdt: use timer1 as a pretimeout
Date: Tue, 5 Mar 2019 01:57:10 +0100 [thread overview]
Message-ID: <20190305005710.GL26378@lunn.ch> (raw)
In-Reply-To: <20190304225152.26831-3-chris.packham@alliedtelesis.co.nz>
On Tue, Mar 05, 2019 at 11:51:52AM +1300, Chris Packham wrote:
> The orion watchdog can either reset the CPU or generate an interrupt.
> The interrupt would be useful for debugging as it provides panic()
> output about the watchdog expiry, however if the interrupt is used the
> watchdog can't reset the CPU in the event of being stuck in a loop with
> interrupts disabled or if the CPU is prevented from accessing memory
> (e.g. an unterminated DMA).
>
> All of the orion based CPU cores (at least back as far as Kirkwood) have
> spare timers that aren't currently used by the Linux kernel. We can use
> timer1 to provide a pre-timeout ahead of the watchdog timer and provide
> the possibility of gathering debug before the reset triggers.
Hi Chris
I had a quick look at other drivers implementing pre-timeout. They
seem to call watchdog_notify_pretimeout(). I don't see that here? What
happens when timer1 fires?
> @@ -169,38 +174,46 @@ static int armadaxp_wdt_clock_init(struct platform_device *pdev,
> }
>
> /* Enable the fixed watchdog clock input */
> - atomic_io_modify(dev->reg + TIMER_CTRL,
> - WDT_AXP_FIXED_ENABLE_BIT,
> - WDT_AXP_FIXED_ENABLE_BIT);
> + val = WDT_AXP_FIXED_ENABLE_BIT | TIMER1_FIXED_ENABLE_BIT;
> + atomic_io_modify(dev->reg + TIMER_CTRL, val, val);
>
> dev->clk_rate = clk_get_rate(dev->clk);
> +
> +
One blank line is sufficient,
> return 0;
> }
Andrew
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org,
Wim Van Sebroeck <wim@linux-watchdog.org>,
jason@lakedaemon.net, gregory.clement@bootlin.com,
linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
linux@roeck-us.net,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
linux-arm-kernel@lists.infradead.org,
linux-watchdog@vger.kernel.org
Subject: Re: [PATCH 2/2] watchdog: orion_wdt: use timer1 as a pretimeout
Date: Tue, 5 Mar 2019 01:57:10 +0100 [thread overview]
Message-ID: <20190305005710.GL26378@lunn.ch> (raw)
In-Reply-To: <20190304225152.26831-3-chris.packham@alliedtelesis.co.nz>
On Tue, Mar 05, 2019 at 11:51:52AM +1300, Chris Packham wrote:
> The orion watchdog can either reset the CPU or generate an interrupt.
> The interrupt would be useful for debugging as it provides panic()
> output about the watchdog expiry, however if the interrupt is used the
> watchdog can't reset the CPU in the event of being stuck in a loop with
> interrupts disabled or if the CPU is prevented from accessing memory
> (e.g. an unterminated DMA).
>
> All of the orion based CPU cores (at least back as far as Kirkwood) have
> spare timers that aren't currently used by the Linux kernel. We can use
> timer1 to provide a pre-timeout ahead of the watchdog timer and provide
> the possibility of gathering debug before the reset triggers.
Hi Chris
I had a quick look at other drivers implementing pre-timeout. They
seem to call watchdog_notify_pretimeout(). I don't see that here? What
happens when timer1 fires?
> @@ -169,38 +174,46 @@ static int armadaxp_wdt_clock_init(struct platform_device *pdev,
> }
>
> /* Enable the fixed watchdog clock input */
> - atomic_io_modify(dev->reg + TIMER_CTRL,
> - WDT_AXP_FIXED_ENABLE_BIT,
> - WDT_AXP_FIXED_ENABLE_BIT);
> + val = WDT_AXP_FIXED_ENABLE_BIT | TIMER1_FIXED_ENABLE_BIT;
> + atomic_io_modify(dev->reg + TIMER_CTRL, val, val);
>
> dev->clk_rate = clk_get_rate(dev->clk);
> +
> +
One blank line is sufficient,
> return 0;
> }
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-03-05 0:57 UTC|newest]
Thread overview: 35+ 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 ` 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 3:41 ` Guenter Roeck
2017-10-11 4:30 ` Chris Packham
2017-10-11 4:30 ` Chris Packham
2019-02-27 20:59 ` Chris Packham
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 ` Chris Packham
2019-03-04 22:51 ` [PATCH 1/2] watchdog: orion_wdt: remove orion_wdt_set_timeout Chris Packham
2019-03-04 22:51 ` Chris Packham
2019-03-05 17:17 ` Guenter Roeck
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-04 22:51 ` Chris Packham
2019-03-05 0:57 ` Andrew Lunn [this message]
2019-03-05 0:57 ` Andrew Lunn
2019-03-05 1:26 ` Chris Packham
2019-03-05 1:26 ` Chris Packham
2019-03-05 2:09 ` Andrew Lunn
2019-03-05 2:09 ` Andrew Lunn
2019-03-05 2:09 ` Andrew Lunn
2019-03-05 17:27 ` Guenter Roeck
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-11 2:29 ` Chris Packham
2017-10-12 14:16 ` Gregory CLEMENT
2017-10-12 14:16 ` Gregory CLEMENT
2017-10-12 14:16 ` Gregory CLEMENT
2017-10-12 20:12 ` Chris Packham
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=20190305005710.GL26378@lunn.ch \
--to=andrew@lunn.ch \
--cc=chris.packham@alliedtelesis.co.nz \
--cc=devicetree@vger.kernel.org \
--cc=gregory.clement@bootlin.com \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.