Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver
Hi Dave, On 16 September 2015 at 09:57, Dave Young wrote: >> >> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c >> >> new file mode 100644 >> >> index 000..7ae45cc >> >> --- /dev/null >> >> +++ b/drivers/watchdog/sbsa_gwdt.c >> >> @@ -0,0 +1,459 @@ >> >> +/* >> >> + * SBSA(Server Base System Architecture) Generic Watchdog driver >> >> + * >> >> + * Copyright (c) 2015, Linaro Ltd. >> >> + * Author: Fu Wei >> >> + * Suravee Suthikulpanit >> >> + * >> >> + * This program is free software; you can redistribute it and/or modify >> >> + * it under the terms of the GNU General Public License 2 as published >> >> + * by the Free Software Foundation. >> >> + * >> >> + * This program is distributed in the hope that it will be useful, >> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> >> + * GNU General Public License for more details. >> >> + * >> >> + * The SBSA Generic watchdog driver is compatible with the pretimeout >> >> + * concept of Linux kernel. >> >> + * The timeout and pretimeout are determined by WCV or WOR. >> >> + * The first watch period is set by writing WCV directly, that can >> >> + * support more than 10s timeout at the maximum system counter >> >> + * frequency (400MHz). >> >> + * When WS0 is triggered, the second watch period (pretimeout) is >> >> + * determined by one of these registers: >> >> + * (1)WOR: 32bit register, this gives a maximum watch period of >> >> + * around 10s at the maximum system counter frequency. It's loaded >> >> + * automatically by hardware. >> >> + * (2)WCV: If the pretimeout value is greater then "max_wor_timeout", >> >> + * it will be loaded in WS0 interrupt routine. If system is in >> >> + * ws0_mode (reboot by kexec/kdump in panic with watchdog enabled >> >> + * and WS0 == true), the ping operation will only reload WCV. >> > >> > Below is the field comment about ws0_mode, it says ws0_mode is only >> > for rebooting in second stage timeout, but kexec/kdump can reboot in >> > either first or second stage >> >> Great thanks for your feedback. >> >> yes, if kexec/kdump reboot the system before the WS0, ws0_mode may not be >> set. >> in this case, if WS0 is triggered during the reboot(AFAIK, panic will >> disable irq, and in the early boot stage of system, irq is disabled, >> too.), ws0_mode will be set at the next "open" in kdump kernel >> if WS0 haven't triggered until the watchdog is opened again in kdump >> kernel , ws0_mode won't be set. >> >> ws0_mode doesn't indicate if the system is in the kdump kernel, it >> indicates that if WS0 is triggered, when the watchdog is initialized. >> >> Do I answer your question? > > Yes, thanks for explanation. So it sounds better to change the comment like > below? > from > (reboot by kexec/kdump in panic with watchdog enabled and WS0 == true) > to > (reboot in the pre-timeout stage and WS0 == true) " in the pre-timeout stage" means " WS0 == true", so I think we should say: (reboot with watchdog enabled and WS0 == true) Thanks for your suggestion. > > Thanks > Dave -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver
> >> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c > >> new file mode 100644 > >> index 000..7ae45cc > >> --- /dev/null > >> +++ b/drivers/watchdog/sbsa_gwdt.c > >> @@ -0,0 +1,459 @@ > >> +/* > >> + * SBSA(Server Base System Architecture) Generic Watchdog driver > >> + * > >> + * Copyright (c) 2015, Linaro Ltd. > >> + * Author: Fu Wei > >> + * Suravee Suthikulpanit > >> + * > >> + * This program is free software; you can redistribute it and/or modify > >> + * it under the terms of the GNU General Public License 2 as published > >> + * by the Free Software Foundation. > >> + * > >> + * This program is distributed in the hope that it will be useful, > >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of > >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >> + * GNU General Public License for more details. > >> + * > >> + * The SBSA Generic watchdog driver is compatible with the pretimeout > >> + * concept of Linux kernel. > >> + * The timeout and pretimeout are determined by WCV or WOR. > >> + * The first watch period is set by writing WCV directly, that can > >> + * support more than 10s timeout at the maximum system counter > >> + * frequency (400MHz). > >> + * When WS0 is triggered, the second watch period (pretimeout) is > >> + * determined by one of these registers: > >> + * (1)WOR: 32bit register, this gives a maximum watch period of > >> + * around 10s at the maximum system counter frequency. It's loaded > >> + * automatically by hardware. > >> + * (2)WCV: If the pretimeout value is greater then "max_wor_timeout", > >> + * it will be loaded in WS0 interrupt routine. If system is in > >> + * ws0_mode (reboot by kexec/kdump in panic with watchdog enabled > >> + * and WS0 == true), the ping operation will only reload WCV. > > > > Below is the field comment about ws0_mode, it says ws0_mode is only > > for rebooting in second stage timeout, but kexec/kdump can reboot in > > either first or second stage > > Great thanks for your feedback. > > yes, if kexec/kdump reboot the system before the WS0, ws0_mode may not be set. > in this case, if WS0 is triggered during the reboot(AFAIK, panic will > disable irq, and in the early boot stage of system, irq is disabled, > too.), ws0_mode will be set at the next "open" in kdump kernel > if WS0 haven't triggered until the watchdog is opened again in kdump > kernel , ws0_mode won't be set. > > ws0_mode doesn't indicate if the system is in the kdump kernel, it > indicates that if WS0 is triggered, when the watchdog is initialized. > > Do I answer your question? Yes, thanks for explanation. So it sounds better to change the comment like below? from (reboot by kexec/kdump in panic with watchdog enabled and WS0 == true) to (reboot in the pre-timeout stage and WS0 == true) Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver
Hi Dave, On 15 September 2015 at 16:38, Dave Young wrote: > On 08/25/15 at 01:01am, fu@linaro.org wrote: >> From: Fu Wei >> >> This driver bases on linux kernel watchdog framework, and >> use "pretimeout" in the framework. It supports getting timeout and >> pretimeout from parameter and FDT at the driver init stage. >> In first timeout, the interrupt routine run panic to save >> system context. >> >> Signed-off-by: Fu Wei >> --- >> drivers/watchdog/Kconfig | 14 ++ >> drivers/watchdog/Makefile| 1 + >> drivers/watchdog/sbsa_gwdt.c | 459 >> +++ >> 3 files changed, 474 insertions(+) >> >> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >> index 241fafd..b2734f0 100644 >> --- a/drivers/watchdog/Kconfig >> +++ b/drivers/watchdog/Kconfig >> @@ -173,6 +173,20 @@ config ARM_SP805_WATCHDOG >> ARM Primecell SP805 Watchdog timer. This will reboot your system when >> the timeout is reached. >> >> +config ARM_SBSA_WATCHDOG >> + tristate "ARM SBSA Generic Watchdog" >> + depends on ARM64 >> + depends on ARM_ARCH_TIMER >> + select WATCHDOG_CORE >> + help >> + ARM SBSA Generic Watchdog. This watchdog has two Watchdog timeouts. >> + The first timeout will trigger a panic; the second timeout will >> + trigger a system reset. >> + More details: ARM DEN0029B - Server Base System Architecture (SBSA) >> + >> + To compile this driver as module, choose M here: The module >> + will be called sbsa_gwdt. >> + >> config AT91RM9200_WATCHDOG >> tristate "AT91RM9200 watchdog" >> depends on SOC_AT91RM9200 && MFD_SYSCON >> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile >> index 59ea9a1..be8e7c5 100644 >> --- a/drivers/watchdog/Makefile >> +++ b/drivers/watchdog/Makefile >> @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o >> >> # ARM Architecture >> obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o >> +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o >> obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o >> obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o >> obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o >> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c >> new file mode 100644 >> index 000..7ae45cc >> --- /dev/null >> +++ b/drivers/watchdog/sbsa_gwdt.c >> @@ -0,0 +1,459 @@ >> +/* >> + * SBSA(Server Base System Architecture) Generic Watchdog driver >> + * >> + * Copyright (c) 2015, Linaro Ltd. >> + * Author: Fu Wei >> + * Suravee Suthikulpanit >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License 2 as published >> + * by the Free Software Foundation. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * The SBSA Generic watchdog driver is compatible with the pretimeout >> + * concept of Linux kernel. >> + * The timeout and pretimeout are determined by WCV or WOR. >> + * The first watch period is set by writing WCV directly, that can >> + * support more than 10s timeout at the maximum system counter >> + * frequency (400MHz). >> + * When WS0 is triggered, the second watch period (pretimeout) is >> + * determined by one of these registers: >> + * (1)WOR: 32bit register, this gives a maximum watch period of >> + * around 10s at the maximum system counter frequency. It's loaded >> + * automatically by hardware. >> + * (2)WCV: If the pretimeout value is greater then "max_wor_timeout", >> + * it will be loaded in WS0 interrupt routine. If system is in >> + * ws0_mode (reboot by kexec/kdump in panic with watchdog enabled >> + * and WS0 == true), the ping operation will only reload WCV. > > Below is the field comment about ws0_mode, it says ws0_mode is only > for rebooting in second stage timeout, but kexec/kdump can reboot in > either first or second stage Great thanks for your feedback. yes, if kexec/kdump reboot the system before the WS0, ws0_mode may not be set. in this case, if WS0 is triggered during the reboot(AFAIK, panic will disable irq, and in the early boot stage of system, irq is disabled, too.), ws0_mode will be set at the next "open" in kdump kernel if WS0 haven't triggered until the watchdog is opened again in kdump kernel , ws0_mode won't be set. ws0_mode doesn't indicate if the system is in the kdump kernel, it indicates that if WS0 is triggered, when the watchdog is initialized. Do I answer your question? > * @ws0_mode: indicate the system boot in the second stage timeout. > > >> + * More details about the hardware specification of this device: >> + * ARM DEN0029B - Server Base System Architecture (SBSA) >> + * >> + * Kernel/API: P--
Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver
On 08/25/15 at 01:01am, fu@linaro.org wrote: > From: Fu Wei > > This driver bases on linux kernel watchdog framework, and > use "pretimeout" in the framework. It supports getting timeout and > pretimeout from parameter and FDT at the driver init stage. > In first timeout, the interrupt routine run panic to save > system context. > > Signed-off-by: Fu Wei > --- > drivers/watchdog/Kconfig | 14 ++ > drivers/watchdog/Makefile| 1 + > drivers/watchdog/sbsa_gwdt.c | 459 > +++ > 3 files changed, 474 insertions(+) > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index 241fafd..b2734f0 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -173,6 +173,20 @@ config ARM_SP805_WATCHDOG > ARM Primecell SP805 Watchdog timer. This will reboot your system when > the timeout is reached. > > +config ARM_SBSA_WATCHDOG > + tristate "ARM SBSA Generic Watchdog" > + depends on ARM64 > + depends on ARM_ARCH_TIMER > + select WATCHDOG_CORE > + help > + ARM SBSA Generic Watchdog. This watchdog has two Watchdog timeouts. > + The first timeout will trigger a panic; the second timeout will > + trigger a system reset. > + More details: ARM DEN0029B - Server Base System Architecture (SBSA) > + > + To compile this driver as module, choose M here: The module > + will be called sbsa_gwdt. > + > config AT91RM9200_WATCHDOG > tristate "AT91RM9200 watchdog" > depends on SOC_AT91RM9200 && MFD_SYSCON > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > index 59ea9a1..be8e7c5 100644 > --- a/drivers/watchdog/Makefile > +++ b/drivers/watchdog/Makefile > @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o > > # ARM Architecture > obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o > +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o > obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o > obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o > obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o > diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c > new file mode 100644 > index 000..7ae45cc > --- /dev/null > +++ b/drivers/watchdog/sbsa_gwdt.c > @@ -0,0 +1,459 @@ > +/* > + * SBSA(Server Base System Architecture) Generic Watchdog driver > + * > + * Copyright (c) 2015, Linaro Ltd. > + * Author: Fu Wei > + * Suravee Suthikulpanit > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License 2 as published > + * by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * The SBSA Generic watchdog driver is compatible with the pretimeout > + * concept of Linux kernel. > + * The timeout and pretimeout are determined by WCV or WOR. > + * The first watch period is set by writing WCV directly, that can > + * support more than 10s timeout at the maximum system counter > + * frequency (400MHz). > + * When WS0 is triggered, the second watch period (pretimeout) is > + * determined by one of these registers: > + * (1)WOR: 32bit register, this gives a maximum watch period of > + * around 10s at the maximum system counter frequency. It's loaded > + * automatically by hardware. > + * (2)WCV: If the pretimeout value is greater then "max_wor_timeout", > + * it will be loaded in WS0 interrupt routine. If system is in > + * ws0_mode (reboot by kexec/kdump in panic with watchdog enabled > + * and WS0 == true), the ping operation will only reload WCV. Below is the field comment about ws0_mode, it says ws0_mode is only for rebooting in second stage timeout, but kexec/kdump can reboot in either first or second stage * @ws0_mode: indicate the system boot in the second stage timeout. > + * More details about the hardware specification of this device: > + * ARM DEN0029B - Server Base System Architecture (SBSA) > + * > + * Kernel/API: P--| pretimeout > + * |T timeout > + * SBSA GWDT: P---WOR (or WCV)---WS1 pretimeout > + * |---WCV--WS0~~~(ws0_mode)T timeout > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* SBSA Generic Watchdog register definitions */ > +/* refresh frame */ > +#define SBSA_GWDT_WRR0x000 > + > +/* control frame */ > +#define SBSA_GWDT_WCS0x000 > +#define SBSA_GWDT_WOR0x008 > +#define SBSA_GWDT_WCV_LO 0x010 > +#define SBSA_GW
Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver
Hi Guenter, Jon, On 11 September 2015 at 10:50, Guenter Roeck wrote: > On 09/10/2015 03:29 PM, Jon Masters wrote: >> >> On 08/24/2015 01:01 PM, fu@linaro.org wrote: >> >>> + /* >>> +* Get the frequency of system counter from the cp15 interface of >>> ARM >>> +* Generic timer. We don't need to check it, because if it >>> returns "0", >>> +* system would panic in very early stage. >>> +*/ >>> + gwdt->clk = arch_timer_get_cntfrq(); >> >> >> Just thinking out loud... >> >> What happens later if we virtualize this device within KVM/QEMU/Xen and >> then live migrate to another system in which the frequency changes? >> > > Thinking about it, this scenario would cause severe trouble. I think clocks > (like I would assume pretty much all other hardware parameters / registers) > need to be virtualized and must not change. > > Example: clock is set to 100 kHz on original system, and 400 kHz on new > system. Timeout is set to 30s, and registers are programmed accordingly. > User space sends heartbeats every 15 seconds. > > In this scenario, the watchdog would time out after 30/4 = 7.5 seconds > on the new system, or in other words almost immediately. > > This would be even worse if the original system had a clock of, say, > 10 kHz and the new system would use 400 kHz. This just doesn't work. I have rechecked the SBSA spec and "Architecture Reference Manual(ARM)", I think we don't need to worry about "the frequency changes", let me explain this, but if I misunderstand something, please correct me! (1) what is the clock source (or reference) of SBSA watchdog timer? SBSA spec(2.3) has answered this well at page 23: --- The Watchdog uses the Generic Timer system count value as the timebase against which the decision to trigger an interrupt is made. --- (2) Can the frequency of the Generic Timer System counter be changed? At ARMv8 ARM, D6.1.1 System counter : --- The Generic Timer provides a system counter with the following specification: Frequency Increments at *a fixed frequency*, typically in the range 1-50MHz. Can support one or more alternative operating modes in which it increments by larger amounts at a lower frequency, typically for power-saving. To support lower-power operating modes, the counter can increment by larger amounts at a lower frequency. For example, a 10MHz system counter might either increment either: • By 1 at 10MHz. • By 500 at 20kHz, when the system lowers the clock frequency, to reduce power consumption. In this case, the counter must support transitions between high-frequency, high-precision operation, and lower-frequency, lower-precision operation, without any impact on the required accuracy of the counter. --- So even the frequency of the Generic Timer System counter be changed by some reason(typically for power-saving), this won't affect the timeout(and pretimeout) of watchdog, the actual time will be always right. *we were talking about real hardware above. Now we think about virtualization.* (3) if the virtual watchdog device in KVM/QEMU/Xen is migrated to another system in which the frequency changes, will it affect the "dog feeding procedure"? I don't think so. if the frequency changes, the frequency of System counter is changed. But in ARM system, System counter is a global reference for all clocks or timers(per-cpu and Memory-mapped). So if System counter is getting faster, everything in this virtual machine is getting faster, and vice versa. Now we use the example above if clock is set to 100 kHz on original system, and 400 kHz on new system. Timeout is set to 30s, and registers are programmed accordingly. User space sends heartbeats every 15 seconds. In this scenario, On the new system, the watchdog would time out after 30/4 = 7.5 seconds. * User space sends heartbeats every 15/4 = 3.25 second now , but NOT 15 seconds.* If everything goes well, system will keep running. Hope I understand the question correctly, please correct me if I miss something or said anything wrong. Great thanks for your feedback! > > Guenter > -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver
On 09/10/2015 03:29 PM, Jon Masters wrote: On 08/24/2015 01:01 PM, fu@linaro.org wrote: + /* +* Get the frequency of system counter from the cp15 interface of ARM +* Generic timer. We don't need to check it, because if it returns "0", +* system would panic in very early stage. +*/ + gwdt->clk = arch_timer_get_cntfrq(); Just thinking out loud... What happens later if we virtualize this device within KVM/QEMU/Xen and then live migrate to another system in which the frequency changes? Thinking about it, this scenario would cause severe trouble. I think clocks (like I would assume pretty much all other hardware parameters / registers) need to be virtualized and must not change. Example: clock is set to 100 kHz on original system, and 400 kHz on new system. Timeout is set to 30s, and registers are programmed accordingly. User space sends heartbeats every 15 seconds. In this scenario, the watchdog would time out after 30/4 = 7.5 seconds on the new system, or in other words almost immediately. This would be even worse if the original system had a clock of, say, 10 kHz and the new system would use 400 kHz. This just doesn't work. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver
On Thu, Sep 10, 2015 at 06:29:53PM -0400, Jon Masters wrote: > On 08/24/2015 01:01 PM, fu@linaro.org wrote: > > > + /* > > +* Get the frequency of system counter from the cp15 interface of ARM > > +* Generic timer. We don't need to check it, because if it returns "0", > > +* system would panic in very early stage. > > +*/ > > + gwdt->clk = arch_timer_get_cntfrq(); > > Just thinking out loud... > > What happens later if we virtualize this device within KVM/QEMU/Xen and > then live migrate to another system in which the frequency changes? > I don't know, but I would suspect that we might end up in all kinds of trouble if clocks can change like that, and not just in this driver. Many drivers make the assumption that clock rates are not changed under the hood. If it can happen, shouldn't there be a callback into the drivers using the affected clock(s) ? Also, it seems to me that changing a clock like that would be inherently unsafe. For example, what will happen if the system is stopped and migrated right after the clock frequency is read, but before the returned value is used ? Can that happen ? Or does it only happen during suspend/resume cycles, if it happens ? Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver
On 08/24/2015 01:01 PM, fu@linaro.org wrote: > + /* > + * Get the frequency of system counter from the cp15 interface of ARM > + * Generic timer. We don't need to check it, because if it returns "0", > + * system would panic in very early stage. > + */ > + gwdt->clk = arch_timer_get_cntfrq(); Just thinking out loud... What happens later if we virtualize this device within KVM/QEMU/Xen and then live migrate to another system in which the frequency changes? Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver
From: Fu Wei This driver bases on linux kernel watchdog framework, and use "pretimeout" in the framework. It supports getting timeout and pretimeout from parameter and FDT at the driver init stage. In first timeout, the interrupt routine run panic to save system context. Signed-off-by: Fu Wei --- drivers/watchdog/Kconfig | 14 ++ drivers/watchdog/Makefile| 1 + drivers/watchdog/sbsa_gwdt.c | 459 +++ 3 files changed, 474 insertions(+) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 241fafd..b2734f0 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -173,6 +173,20 @@ config ARM_SP805_WATCHDOG ARM Primecell SP805 Watchdog timer. This will reboot your system when the timeout is reached. +config ARM_SBSA_WATCHDOG + tristate "ARM SBSA Generic Watchdog" + depends on ARM64 + depends on ARM_ARCH_TIMER + select WATCHDOG_CORE + help + ARM SBSA Generic Watchdog. This watchdog has two Watchdog timeouts. + The first timeout will trigger a panic; the second timeout will + trigger a system reset. + More details: ARM DEN0029B - Server Base System Architecture (SBSA) + + To compile this driver as module, choose M here: The module + will be called sbsa_gwdt. + config AT91RM9200_WATCHDOG tristate "AT91RM9200 watchdog" depends on SOC_AT91RM9200 && MFD_SYSCON diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 59ea9a1..be8e7c5 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o # ARM Architecture obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c new file mode 100644 index 000..7ae45cc --- /dev/null +++ b/drivers/watchdog/sbsa_gwdt.c @@ -0,0 +1,459 @@ +/* + * SBSA(Server Base System Architecture) Generic Watchdog driver + * + * Copyright (c) 2015, Linaro Ltd. + * Author: Fu Wei + * Suravee Suthikulpanit + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License 2 as published + * by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * The SBSA Generic watchdog driver is compatible with the pretimeout + * concept of Linux kernel. + * The timeout and pretimeout are determined by WCV or WOR. + * The first watch period is set by writing WCV directly, that can + * support more than 10s timeout at the maximum system counter + * frequency (400MHz). + * When WS0 is triggered, the second watch period (pretimeout) is + * determined by one of these registers: + * (1)WOR: 32bit register, this gives a maximum watch period of + * around 10s at the maximum system counter frequency. It's loaded + * automatically by hardware. + * (2)WCV: If the pretimeout value is greater then "max_wor_timeout", + * it will be loaded in WS0 interrupt routine. If system is in + * ws0_mode (reboot by kexec/kdump in panic with watchdog enabled + * and WS0 == true), the ping operation will only reload WCV. + * More details about the hardware specification of this device: + * ARM DEN0029B - Server Base System Architecture (SBSA) + * + * Kernel/API: P--| pretimeout + * |T timeout + * SBSA GWDT: P---WOR (or WCV)---WS1 pretimeout + * |---WCV--WS0~~~(ws0_mode)T timeout + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* SBSA Generic Watchdog register definitions */ +/* refresh frame */ +#define SBSA_GWDT_WRR 0x000 + +/* control frame */ +#define SBSA_GWDT_WCS 0x000 +#define SBSA_GWDT_WOR 0x008 +#define SBSA_GWDT_WCV_LO 0x010 +#define SBSA_GWDT_WCV_HI 0x014 + +/* refresh/control frame */ +#define SBSA_GWDT_W_IIDR 0xfcc +#define SBSA_GWDT_IDR 0xfd0 + +/* Watchdog Control and Status Register */ +#define SBSA_GWDT_WCS_EN BIT(0) +#define SBSA_GWDT_WCS_WS0 BIT(1) +#define SBSA_GWDT_WCS_WS1 BIT(2) + +/** + * struct sbsa_gwdt - Internal representation of the SBSA GWDT + * @wdd: kernel watchdog_device structure + * @
