Re: [PATCH] watchdog: Fix omap watchdogs to enable the magic close bit
Hi Tony, * Tony Lindgren t...@atomide.com [141014 12:27]: This allows testing the watchdog easily with distros just by doing pkill -9 watchdog. Reported-by: Thomas Dziedzic gos...@gmail.com Signed-off-by: Tony Lindgren t...@atomide.com Wim, still not seeing this applied, did you forget about this one? I just applied it to linux-watchdog-next. Didn't forgot about it, just didn't had the time yet. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 02/23] watchdog: omap_wdt: raw read and write endian fix
Hi Victor, Taras, From: Victor Kamensky victor.kamen...@linaro.org All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky victor.kamen...@linaro.org Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org This was added to linux-watchdog-next. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] watchdog: introduce retu_wdt driver
Hi Aaro, Introduce Retu watchdog driver. Cc: linux-watch...@vger.kernel.org Acked-by: Felipe Balbi ba...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: Wim Van Sebroeck w...@iguana.be Added tolinux-watchdog-next. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
Hi Paul, The OMAP watchdog timer driver directly calls a function exported by code in arch/arm/mach-omap2. This is not good; it tightly couples this driver to the mach-omap2 integration code. Instead, add a temporary platform_data function pointer to abstract this function call. A subsequent patch will convert the watchdog driver to use this function pointer. This patch also moves the device creation code out of arch/arm/mach-omap2/devices.c and into arch/arm/mach-omap2/wd_timer.c. This is another step towards the removal of arch/arm/mach-omap2/devices.c. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Wim Van Sebroeck w...@iguana.be Signed-off-by: Wim Van Sebroeck w...@iguana.be Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr
Hi Paul, Previously the OMAP watchdog driver used a non-standard way to report the chip reset source via the GETBOOTSTATUS ioctl. This patch converts the driver to use the standard WDIOF_* flags for this purpose. This patch may break existing userspace code that uses the existing non-standard data format returned by the OMAP watchdog driver's GETBOOTSTATUS ioctl. To fetch detailed reset source information, userspace code will need to retrieve it directly from the CGRM or PRM drivers when those are completed. Previously, to fetch the reset source, the driver either read a register outside the watchdog IP block (OMAP1), or called a function exported directly from arch/arm/mach-omap2. Both approaches are broken. This patch also converts the driver to use a platform_data function pointer. This approach is temporary, and is due to the lack of drivers for the OMAP16xx+ Clock Generation and Reset Management IP block and the OMAP2+ Power and Reset Management IP block. Once drivers are available for those IP blocks, the watchdog driver can be converted to call exported drivers from those functions directly. At that point, the platform_data function pointer can be removed. In the short term, this patch is needed to allow the PRM code to be removed from arch/arm/mach-omap2 (it is being moved to a driver). Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Wim Van Sebroeck w...@iguana.be Signed-off-by: Wim Van Sebroeck w...@iguana.be Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer (fwd)
Hi Paul, When you have the opportunity, could you take a look at this patch, and the subsequent patch 6/7, and ack them if you're okay with them? Signed them off, Acked-by would probably have been better :-). We'd like to merge thse as part of a larger cleanup series through the arm-soc tree. They like cleanup patches to arrive at the beginning of the -rc series, which means that we need to have the pull request sent pretty soon. Please go ahead. The sooner those ifdefs are gone the better. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH_v2] watchdog: Convert twl4030_wdt to watchdog core
Hi, On 09/11/2012 09:01 AM, Jarkko Nikula wrote: Convert the twl4030_wdt watchdog driver to watchdog core. While at there use devm_kzalloc and set the default timeout in order to be able test this driver with a simple shell script. Signed-off-by: Jarkko Nikulajarkko.nik...@jollamobile.com Tested-by: Aaro Koskinenaaro.koski...@iki.fi on my todo list. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/17] ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+
Hi Tony, As the plat and mach includes need to disappear for single zImage work, we need to remove plat/hardware.h. Do this by splitting plat/hardware.h into omap1 and omap2+ specific files. The old plat/hardware.h already has omap1 only defines, so it gets moved to mach/hardware.h for omap1. For omap2+, we use the local soc.h that for now just includes the related SoC headers to keep this patch more readable. Note that the local soc.h still includes plat/cpu.h that can be dealt with in later patches. Let's also include plat/serial.h from common.h for all the board-*.c files. This allows making the include files local later on without patching these files again. Note that only minimal changes are done in this patch for the drivers/watchdog/omap_wdt.c driver to keep things compiling. Further patches are needed to eventually remove cpu_is_omap usage in the drivers. Also only minimal changes are done to sound/soc/omap/* to remove the unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's no need to include omap44xx.h. While at it, also sort some of the includes in the standard way. Cc: linux-watch...@vger.kernel.org Cc: Wim Van Sebroeck w...@iguana.be Acked-by for the watchdog part. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
Hi All, On Mon, Jun 18, 2012 at 10:53 AM, Lokesh Vutla lokeshvu...@ti.com wrote: OMAP watchdong driver is adapted to runtime PM like a general device driver but it is not appropriate. It is causing couple of functional issues. 1. On OMAP4 SYSCLK can't be gated, because of issue with WDTIMER2 module, which constantly stays in in transition state. Value of register CM_WKUP_WDTIMER2_CLKCTRL is always 0x0001 in this case. Issue occurs immediately after first idle, when hwmod framework tries to disable WDTIMER2 functional clock - wd_timer2_fck. After this module falls to in transition state, and SYSCLK gating is blocked. 2. Due to runtime PM, watchdog timer may be completely disabled. In current code base watchdog timer is not disabled only because of issue 1. Otherwise state of WDTIMER2 module will be Disabled, and there will be no interrupts from omap_wdt. In other words watchdog will not work at all. Watchdong is a special IP and it should not be disabled otherwise purpose of it itself is defeated. Watchdog functional clock should never be disabled. This patch updates the runtime PM handling in driver so that runtime PM is limited only during probe/shutdown and suspend/resume. The patch fixes issue 1 and 2 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Wim Van Sebroeck w...@iguana.be --- Any comments on this patch ? If not, can you please queue this up for the 3.5-rc? Added to linux-watchdog-next. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/3] watchdog: omap_wdt: add device tree support
Hi Tony, Hi Wim, * jgq...@gmail.com jgq...@gmail.com [120531 20:56]: From: Xiao Jiang jgq...@gmail.com Add device table for omap_wdt to support dt. Care to ack this patch in the series? Yep. Acked-by: Wim Van Sebroeck w...@iguana.be Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] watchdog: twl4030_wdt: Watchdog device registration issue fix
Hi All, Hello All, Any comments on this patch? Regards, Keerthy On Wed, Mar 2, 2011 at 2:17 AM, Keerthy j-keer...@ti.com wrote: twl4030_wdt driver and omap_wdt driver are registering as misc_device name as watchdog and the same minor number WATCHDOG_MINOR( value = 130). There is a conflict since the name and minor were the same for both the misc_device registered by omap_wdt.c as well as twl4030_wdt.c The omap_wdt.c probe is getting called first. Hence it succeeds. twl4030_wdt.c always failed on the minor number comparison check. Now requesting for MISC_DYNAMIC_MINOR as the minor number for twl4030_watchdog and renamed the device name as twl4030_watchdog. Tested for basic boot up on OMAP4 Blaze and OMAP3630 SDP. OMAP3630 SDP twl4030_wdt registration succeeds.2430SDP boot tested, watchdog registration without errors. Signed-off-by: Keerthy j-keer...@ti.com NAK. Reason: a watchdog daemon will only be using /dev/watchdog. The plan is to get the generic watchdog framework in, convert most of the drivers, extend teh generic watchdog framework with a sysfs interface so that we can support multiple watchdogs. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] OMAP3: wdtimer: Fix CORE idle
Hi All, These patches fix the issue where the wdtimer blocks CORE idle transitions on n900 (OMAP3). The root cause was that SMART idle mode in wdtimer did not allow the CORE idle transition to happen. v2: updated commit message on patch 1/2, Cc'd Wim, and added comments to code about possible HW bug in wdtimer2. Wim, please check patch number one and add your acked by. I propose that we push these upstream via linux-omap-pm, as the patches deal with PM and need to be applied together to get the desired functionality. Paul Walmsley (2): Watchdog: omap_wdt: add fine grain runtime-pm OMAP3: wdtimer: Fix CORE idle transition arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 + drivers/watchdog/omap_wdt.c| 25 +++-- 2 files changed, 24 insertions(+), 2 deletions(-) Acked-by: Wim Van Sebroeck w...@iguana.be linux-omap-pm is indeed the best tree for getting this upstream. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Handling multiple watchdogs
Hi Alan, 1) make sure that we have the new watchdog core infrastructure going in for 2.6.32. This new core integrates the common code that we use over and over again. I once wrote code for it and then Alan had different ideas and thoughts and wrote his updated code. I reviewed that and I am changing some small bits so that we will have the new What is the status of this ? I was thinking it had been a while but it seems to be 18 months ago.. I did that dev_* fix as we agreed on sunday. I will sent out the code (for additional comments) out tonight to linux-kernel and linux-watchdog mailing lists. Aiming to get it in for 2.6.39. Code can allready be looked at, at: http://git.kernel.org/?p=linux/kernel/git/wim/linux-2.6-watchdog-next.git;a=shortlog;h=refs/heads/generic-watchdog Open issues: get min adn max timeout in so that the generic code can check the boundarys. Need to think about MAGIC_CLOSE_FEATURE. There seem to be people that are surprised that if you do a cat /dev/watchdog that the system reboots. Whiwh is normal: it's an open with a close without the magic character. One solution I see is to add a module_param that can disable magic_close_feature. Default will be on though). And after that we can consider the read function that you proposed. And then we need to go for the sysfs interface so that we can support multiple watchdogs via sysfs. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs
Hi All, Call runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync() for enabling/disabling the clocks, sysconfig settings instead of using clock FW APIs. Signed-off-by: Charulatha V ch...@ti.com This is all omap specific code. So if Kevin and Tony are fine with the code then tou gave my ACK also. Kind regards, WIm. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] twl4030_wdt: Disable watchdog while probing
Hi Timo, It seems that in this patch, you disable the watchdog regardless whether the registration fails or not. I wonder if this is a good thing to do. What if the bootloader have already enabled the watchdog and then user space booting fails for some reason before any process is able to open and re-enable the watchdog? We could end up with a hung system that does not have the watchdog enabled. Maybe we should disable the watchdog only in case the registration actually fails? And even in that case, do we want to disable the watchdog? What are the situations where watchdog registration can fail? Is there a possibility that we would like to leave watchdog running in such case and cause a reboot (say, something bad happened before the watchdog module was loaded and the system ran out of memory, which causes watchdog registration to fail)? Maybe there is something I've missed, but this kind of questions came in my mind.. The default behaviour should be to stop the watchdog. Why? you will probably ask. Let's first take a step back and go to the basis of the watchdog userspace API. In essence userspace start the watchdog by opening /dev/watchdog, then pings the watchdog by writing to /dev/watchdog and stops the watchdog when /dev/watchdog is being closed. That's the basis of the API and it does mean that the watchdog should not be running unless userspace starts the watchdog by opening /dev/watchdog. Later on ioctl calls have been added to extend functionality, we also added extra feautures like the Magic Close feauture (so that a close is not always stopping the watchdog - this to prevent userspace daemon crashes) and the nowayout feature (to prevent a watchdog from being stopped once started). So default is that the watchdog doesn't work unless userspace starts it. That's the API like it is now. So let's take a second step back and look at why we want/need watchdog's: we want them to make sure that our systems can reboot when the systems becomes unstable and crashes. The decision to reboot a system actually is driven by userspace: if userspace pings the watchdog then we now the system is stable enough, if not then we reboot. And that's why we have a grey zone: userspace control is only there after the system has booted. And the system is only booted and available for userspace after the filesystem checks are done. So that's why in the past the people that wrote the first watchdog's disabled all watchdog's before userspace was able to control the watchdog: you didn't want (and in most cases still don't want) your system to be rebooted during a filesystem check (because after the reboot, the filesystem will have to be checked again which could result in an endless loop). And this still is the default behaviour. On the other hand: systems are faster, we have other types of filesystems, we use flash-drives, ... . So for some embedded systems you might want to secure booting in a different way then what we used to do on traditional systems. The way I see it is to add a module_parameter that allows you to have the driver keep the watchdog active on start and don't stop it. The default behaviour would be to stop the watchdog, but it gives you the possibility to override the default. This is how I was adding this to the generic watchdog framework. (I'm doing some last veryfications before releasing it for comments). I hope the reasoning is clearer now and that your questions are answered. (If not, just let me know which questions you still have). = bottom line: this patch adds the correct default behaviour and should not be changed. Feel free to add the module-parameter to keep the watchog running at start. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] twl4030_wdt: Disable watchdog while probing
Hi Ameya, If we are not able to register then it is better to have watchdog in disabled state than noticing a system reboot. Signed-off-by: Ameya Palande ameya.pala...@nokia.com This was added in my linux-2.6-watchdog-next tree. Will be sent to Linus for mainline inclusion in a couple of days. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH] watchdog_info separation and constify
Hi All,
please comment on following patch.
Kind regards,
Wim.
commit 88d0b1a9c071d26e7b4831320067c84b04ea04a8
Author: Wim Van Sebroeck w...@iguana.be
Date: Sat Dec 26 18:55:22 2009 +
[WATCHDOG] watchdog_info separation and constify
make sure that the watchdog_info struct is seperated from the ioctl code.
Also make the struct const where possible.
Signed-off-by: Wim Van Sebroeck w...@iguana.be
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index 6f8ebe1..072b948 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -553,7 +553,7 @@ static ssize_t mpc52xx_wdt_write(struct file *file, const
char __user *data,
return 0;
}
-static struct watchdog_info mpc5200_wdt_info = {
+static const struct watchdog_info mpc5200_wdt_info = {
.options= WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
.identity = WDT_IDENTITY,
};
diff --git a/drivers/hwmon/fschmd.c b/drivers/hwmon/fschmd.c
index bd0fc67..878284b 100644
--- a/drivers/hwmon/fschmd.c
+++ b/drivers/hwmon/fschmd.c
@@ -845,14 +845,15 @@ static ssize_t watchdog_write(struct file *filp, const
char __user *buf,
return count;
}
+static struct watchdog_info ident = {
+ .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT |
+ WDIOF_CARDRESET,
+ .identity = FSC watchdog
+};
+
static int watchdog_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg)
{
- static struct watchdog_info ident = {
- .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT |
- WDIOF_CARDRESET,
- .identity = FSC watchdog
- };
int i, ret = 0;
struct fschmd_data *data = filp-private_data;
diff --git a/drivers/watchdog/acquirewdt.c b/drivers/watchdog/acquirewdt.c
index 4d18c87..f0c956f 100644
--- a/drivers/watchdog/acquirewdt.c
+++ b/drivers/watchdog/acquirewdt.c
@@ -145,16 +145,17 @@ static ssize_t acq_write(struct file *file, const char
__user *buf,
return count;
}
+static const struct watchdog_info ident = {
+ .options = WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
+ .firmware_version = 1,
+ .identity = WATCHDOG_NAME,
+};
+
static long acq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
int options, retval = -EINVAL;
void __user *argp = (void __user *)arg;
int __user *p = argp;
- static struct watchdog_info ident = {
- .options = WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
- .firmware_version = 1,
- .identity = WATCHDOG_NAME,
- };
switch (cmd) {
case WDIOC_GETSUPPORT:
diff --git a/drivers/watchdog/advantechwdt.c b/drivers/watchdog/advantechwdt.c
index 824d076..3a9f1df 100644
--- a/drivers/watchdog/advantechwdt.c
+++ b/drivers/watchdog/advantechwdt.c
@@ -132,18 +132,19 @@ static ssize_t advwdt_write(struct file *file, const char
__user *buf,
return count;
}
+static const struct watchdog_info ident = {
+ .options = WDIOF_KEEPALIVEPING |
+ WDIOF_SETTIMEOUT |
+ WDIOF_MAGICCLOSE,
+ .firmware_version = 1,
+ .identity = WATCHDOG_NAME,
+};
+
static long advwdt_ioctl(struct file *file, unsigned int cmd, unsigned long
arg)
{
int new_timeout;
void __user *argp = (void __user *)arg;
int __user *p = argp;
- static struct watchdog_info ident = {
- .options = WDIOF_KEEPALIVEPING |
- WDIOF_SETTIMEOUT |
- WDIOF_MAGICCLOSE,
- .firmware_version = 1,
- .identity = WATCHDOG_NAME,
- };
switch (cmd) {
case WDIOC_GETSUPPORT:
diff --git a/drivers/watchdog/adx_wdt.c b/drivers/watchdog/adx_wdt.c
index 9d7d155..a5ca7a6 100644
--- a/drivers/watchdog/adx_wdt.c
+++ b/drivers/watchdog/adx_wdt.c
@@ -37,7 +37,7 @@ struct adx_wdt {
spinlock_t lock;
};
-static struct watchdog_info adx_wdt_info = {
+static const struct watchdog_info adx_wdt_info = {
.identity = Avionic Design Xanthos Watchdog,
.options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
};
diff --git a/drivers/watchdog/alim1535_wdt.c b/drivers/watchdog/alim1535_wdt.c
index 937a80f..d5225ad 100644
--- a/drivers/watchdog/alim1535_wdt.c
+++ b/drivers/watchdog/alim1535_wdt.c
@@ -176,17 +176,18 @@ static ssize_t ali_write(struct file *file, const char
__user *data,
* we want an extension to enable irq ack monitoring and the like
*/
+static const struct watchdog_info ident = {
+ .options = WDIOF_KEEPALIVEPING |
+ WDIOF_SETTIMEOUT |
+ WDIOF_MAGICCLOSE,
+ .firmware_version = 0,
+ .identity = ALi M1535 WatchDog Timer,
+};
+
static long ali_ioctl(struct file *file
Re: [PATCH 0/2] watchdog:OMAP3:Add support for IVA2, SECURE WDTs
Hi Ulrik, This patch series enables support for IVA2 and SECURE WDTs, available on omap34xx. The WDTs will be accessible (when present on device) through: MPU: /dev/watchdog SECURE: /dev/watchdog_secure IVA2: /dev/watchdog_iva2 Tested on Zoom1 OMAP3 platform, compile-tested for OMAP2 Signed-off-by: Ulrik Bech Hald u...@ti.com Reviewed-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap1/clock.c |6 +- arch/arm/mach-omap2/clock24xx.c |4 - arch/arm/mach-omap2/clock34xx.c | 12 ++--- arch/arm/plat-omap/devices.c| 91 drivers/watchdog/omap_wdt.c | 34 +++--- 5 files changed, 112 insertions(+), 35 deletions(-) Thanks for sending in this patch, but I will put the patch aside for some time. The reason for this is that: 1) we need to have the new watchdog core infrastructure going in for 2.6.32. This new core means that we won't reproduce the same code over and over again. (Both Alan and myself are working on it). 2) We need a thorough discussion first on how we will support multiple watchdog devices and what the best interface is. I'm not convinced dat the /dev/watchdog* solution is the right way to go. I think a sysfs interface is suited more. This sysfs interface would be version 2 of the new core. Sorry for the inconvenience, we will get back on this. Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Handling multiple watchdogs
Hi Simon, I have two watchdogs on my board that I both want to handle. What would be the proper approach in this case? Fixing the watchdog core to create a class of watchdog drivers and treating the existing /dev/watchdog as a back compatibility hack. It's been talked about for a very long time but not done, although I believe Wim had some test code at one point ? The support of multiple watchdog's is not there at this moment. But we will indeed need it. The embedded platforms (like omap) start to have devices with different watchdogs that all need to be supported. To overcome this issue we will indeed need to: 1) make sure that we have the new watchdog core infrastructure going in for 2.6.32. This new core integrates the common code that we use over and over again. I once wrote code for it and then Alan had different ideas and thoughts and wrote his updated code. I reviewed that and I am changing some small bits so that we will have the new watchdog core version 1. Expect the code to appear in the linux-2.6-watchdog-next tree in the coming weeks (I first did some pre-cleanup stuff). 2) Then we will need a dicussion on how we will support multiple watchdog's with this new framework. My feeling is that the /dev/watchdog* solution is not the right way to go. I think a sysfs interface will be better. This sysfs interface would then be added to the core version (and makes core version 2). I once wrote the first basis of this sysfs interface (based on rusty's input I believe). I need to check if I still have it after the hard-disk crash I had almost a year ago. I hope this gives you an idea about how we are proceeding with the watchdog devices driver core and what we are trying to do (and OK i'm slower than other maintainers but I'm doing this all in my own time and for free and thus my priority's are different...). Kind regards, Wim. (Note: for completeness; I know that the following drivers have a non-standard watchdog part: drivers/watchdog/cpwd.c drivers/hwmon/fschmd.c). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] watchdog: OMAP fixes: enable clock in probe, trigger timer reload
Hi Ulrik, This patch contains two bugfixes: 1)In omap_wdt_probe() the watchdog is reset and disabled. This requires register access and the clks needs to be enabled temporarily 2)In omap_wdt_open() the timer register needs to be reloaded to trigger a new timer value (the default of 60s) Tested on OMAP34xx platform (Zoom1) Reviewed-by: Kevin Hilman khil...@ti.deeprootsystems.com Signed-off-by: Ulrik Bech Hald u...@ti.com These fixes have been added to the linux-2.6-watchdog-next tree. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] omap: twl4030_wdt: twl4030 watchdog driver
Hi Russell, Samuel, David,
I reviewed the twl watchdog driver written by Timo and Atal (reviewed version -
see below).
could you review them also (arm driver and touches drivers/mfd/twl4030-core).
Thanks in advance,
Wim.
---
commit ca1a9726d1e0655c39d07f8b77659c5d017748cb
Author: Timo Kokkonen timo.t.kokko...@nokia.com
Date: Fri Mar 27 16:42:17 2009 +0200
[WATCHDOG] twl4030 watchdog driver
Implementation of twl4030 watchdog driver.
Signed-off-by: Timo Kokkonen timo.t.kokko...@nokia.com
Signed-off-by: Atal Shargorodsky ext-atal.shargorod...@nokia.com
Signed-off-by: Wim Van Sebroeck w...@iguana.be
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index ec90e95..b8df518 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -101,6 +101,12 @@
#define twl_has_usb() false
#endif
+#if defined(CONFIG_TWL4030_WATCHDOG) || \
+ defined(CONFIG_TWL4030_WATCHDOG_MODULE)
+#define twl_has_watchdog()true
+#else
+#define twl_has_watchdog()false
+#endif
/* Triton Core internal information (BEGIN) */
@@ -526,6 +532,12 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
usb_transceiver = child;
}
+ if (twl_has_watchdog()) {
+ child = add_child(0, twl4030_wdt, NULL, 0, false, 0, 0);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ }
+
if (twl_has_regulator()) {
/*
child = add_regulator(TWL4030_REG_VPLL1, pdata-vpll1);
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9f6766b..d92bf63 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -250,6 +250,13 @@ config COH901327_WATCHDOG
This watchdog is used to reset the system and thus cannot be
compiled as a module.
+config TWL4030_WATCHDOG
+ tristate TWL4030 Watchdog
+ depends on TWL4030_CORE
+ help
+ Support for TI TWL4030 watchdog. Say 'Y' here to enable the
+ watchdog timer support for TWL4030 chips.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 8d75e62..9eb74b7 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
obj-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
+obj-$(CONFIG_TWL4030_WATCHDOG) += twl4030_wdt.o
obj-$(CONFIG_21285_WATCHDOG) += wdt285.o
obj-$(CONFIG_977_WATCHDOG) += wdt977.o
obj-$(CONFIG_IXP2000_WATCHDOG) += ixp2000_wdt.o
diff --git a/drivers/watchdog/twl4030_wdt.c b/drivers/watchdog/twl4030_wdt.c
new file mode 100644
index 000..cb46556
--- /dev/null
+++ b/drivers/watchdog/twl4030_wdt.c
@@ -0,0 +1,272 @@
+/*
+ * Copyright (C) Nokia Corporation
+ *
+ * Written by Timo Kokkonen timo.t.kokkonen at nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/fs.h
+#include linux/watchdog.h
+#include linux/platform_device.h
+#include linux/miscdevice.h
+#include linux/uaccess.h
+#include linux/i2c/twl4030.h
+
+#define TWL4030_WATCHDOG_CFG_REG_OFFS 0x3
+
+#define TWL4030_WDT_STATE_OPEN 0x1
+#define TWL4030_WDT_STATE_ACTIVE 0x8
+
+static struct platform_device *twl4030_wdt_dev;
+
+struct twl4030_wdt {
+ struct miscdevice miscdev;
+ int timer_margin;
+ unsigned long state;
+};
+
+static int nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, int, 0);
+MODULE_PARM_DESC(nowayout, Watchdog cannot be stopped once started
+ (default= __MODULE_STRING(WATCHDOG_NOWAYOUT) ));
+
+static int twl4030_wdt_write(unsigned char val)
+{
+ return twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, val,
+ TWL4030_WATCHDOG_CFG_REG_OFFS);
+}
+
+static int twl4030_wdt_enable(struct twl4030_wdt *wdt)
+{
+ return twl4030_wdt_write(wdt-timer_margin + 1);
+}
+
+static int twl4030_wdt_disable(struct twl4030_wdt *wdt)
+{
+ return twl4030_wdt_write(0);
+}
+
+static int twl4030_wdt_set_timeout(struct
Re: [PATCH 35/58] move omap_wdt's probe function to .devinit.text
Hi Uwe,
A pointer to omap_wdt_probe is passed to the core via
platform_driver_register and so the function must not disappear when the
.init sections are discarded. Otherwise (if also having HOTPLUG=y)
unbinding and binding a device to the driver via sysfs will result in an
oops as does a device being registered late.
An alternative to this patch is using platform_driver_probe instead of
platform_driver_register plus removing the pointer to the probe function
from the struct platform_driver.
Agree with the explanation, but ...
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 2f2ce74..c9c14dd 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -269,7 +269,7 @@ static const struct file_operations omap_wdt_fops = {
.release = omap_wdt_release,
};
-static int __init omap_wdt_probe(struct platform_device *pdev)
+static int __devinit omap_wdt_probe(struct platform_device *pdev)
{
struct resource *res, *mem;
struct omap_wdt_dev *wdev;
...imho this would be the correct fix:
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index aa5ad6e..f271385 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -258,7 +258,7 @@ static const struct file_operations omap_wdt_fops = {
.release = omap_wdt_release,
};
-static int __init omap_wdt_probe(struct platform_device *pdev)
+static int __devinit omap_wdt_probe(struct platform_device *pdev)
{
struct resource *res, *mem;
struct omap_wdt_dev *wdev;
@@ -367,7 +367,7 @@ static void omap_wdt_shutdown(struct platform_device *pdev)
omap_wdt_disable(wdev);
}
-static int omap_wdt_remove(struct platform_device *pdev)
+static int __devexit omap_wdt_remove(struct platform_device *pdev)
{
struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -426,7 +426,7 @@ static int omap_wdt_resume(struct platform_device *pdev)
static struct platform_driver omap_wdt_driver = {
.probe = omap_wdt_probe,
- .remove = omap_wdt_remove,
+ .remove = __devexit_p(omap_wdt_remove),
.shutdown = omap_wdt_shutdown,
.suspend= omap_wdt_suspend,
.resume = omap_wdt_resume,
Kind regards,
Wim.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] watchdog: another ioremap() fix
Hi All, On Thu, Sep 18, 2008 at 11:02:58PM +0300, Felipe Balbi wrote: Well, what can I say. I'll try to get rid of those cpu conditional code in the driver and sync omap_wdt.c with mainline. Send all the patches via Wim, so Tony can get them later. BTW, I'd also suggest copying Andrew Morton as well - I think Wim doesn't have very much time to spend doing kernel stuff, so you may not receive a reply for a while. If Andrew takes the patches, then you have to worry less about Wim forgetting about them (or if Andrew times out pinging Wim, akpm may decide to send them up to Linus himself, or akpm might re-route them via someone else like me.) Please indeed Cc: Andrew Morton as well, for the reasons that Russell explained above. (The not have very much time means that I have been occupied with our new house. We moved 15th of august and we still have some small details to fix (like electricity, the basics for the garden so that the kids can play safely enough, some plumbing work, ...). But the good news is that we allready moved and that we are getting there. On the other hand I have now an extra constraint due to the fact that I was fired at work 3 weeks ago and that I thus have to find a new job...) Greetings, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] watchdog: sync linux-omap changes
Hi Balbi, And thanks for the review. I'll fix your comments and resend the series ;-) Thanks because I had the same objections then Russell. Greetings, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] watchdog: introduce platform_data and remove cpu conditional code
Hi Balbi, Well, patches 4 and 5 should be ignored. Should I resend or could I rely on the fact that people won't pick them up ? I will not pick them up (to add them in the watchdog tree). Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
