Hi Dave,
On 15 September 2015 at 16:43, Dave Young dyoung@redhat.com wrote:
On 08/25/15 at 01:01am, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
This can be a example of adding SBSA Generic Watchdog device node into some dts files for the Soc which contains SBSA Generic Watchdog.
Acked-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Fu Wei fu.wei@linaro.org
arch/arm64/boot/dts/arm/foundation-v8.dts | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dts b/arch/arm64/boot/dts/arm/foundation-v8.dts index 4eac8dc..824431f 100644 --- a/arch/arm64/boot/dts/arm/foundation-v8.dts +++ b/arch/arm64/boot/dts/arm/foundation-v8.dts @@ -237,4 +237,11 @@ }; }; };
watchdog@2a440000 {
compatible = "arm,sbsa-gwdt";
reg = <0x0 0x2a440000 0 0x1000>,
<0x0 0x2a450000 0 0x1000>;
interrupts = <0 27 4>;
timeout-sec = <10 5>;
I assume 10 is timeout, 5 is pre timeout, but in the driver code the default value is 30/10, I think the example dts[i] should use same default values as in code.
yes, that is good idea, will make them to be the same. :-)
BTW, for kdump kernel Pratyush is working on kdump on wdt enabled system. Basiclly we expect one configure longer timeout, and kick it in shorter period so we can get a chance to save vmcore. 10s sounds too short for the case..
Thanks for your info.
So that means: we may need that long timeout support in the second stage. WOR is not enough for the second stage in most of kdump case.
};
};
2.4.3