All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
@ 2012-06-18  5:23 Lokesh Vutla
  2012-06-18  5:41   ` Shilimkar, Santosh
                   ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Lokesh Vutla @ 2012-06-18  5:23 UTC (permalink / raw)
  To: linux-arm-kernel

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 0x00010000 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 <lokeshvutla@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Wim Van Sebroeck <wim@iguana.be>
---
Tested on OMAP4430SDP.

Issue #1 can be easily reproduced on mainline kernel.
- Take latest mainline kernel and create uImage using omap2plus_defconfig
- Write a program to open watchdog,like
void main(void)
{
	int fd = open("/dev/watchdog", O_WRONLY);

	if (fd == -1) {
		perror("Watchdog device interface is not available!\n");
	}
}  
- Build with arm compiler and copy it to your file syatem
- Boot the image and run the executable.


 drivers/watchdog/omap_wdt.c |   17 -----------------
 1 files changed, 0 insertions(+), 17 deletions(-)

diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 8285d65..27ab8db 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -126,8 +126,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
 	u32 pre_margin = GET_WLDR_VAL(timer_margin);
 	void __iomem *base = wdev->base;
 
-	pm_runtime_get_sync(wdev->dev);
-
 	/* just count up at 32 KHz */
 	while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
 		cpu_relax();
@@ -135,8 +133,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
 	__raw_writel(pre_margin, base + OMAP_WATCHDOG_LDR);
 	while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
 		cpu_relax();
-
-	pm_runtime_put_sync(wdev->dev);
 }
 
 /*
@@ -166,8 +162,6 @@ static int omap_wdt_open(struct inode *inode, struct file *file)
 	omap_wdt_ping(wdev); /* trigger loading of new timeout value */
 	omap_wdt_enable(wdev);
 
-	pm_runtime_put_sync(wdev->dev);
-
 	return nonseekable_open(inode, file);
 }
 
@@ -179,8 +173,6 @@ static int omap_wdt_release(struct inode *inode, struct file *file)
 	 *      Shut off the timer unless NOWAYOUT is defined.
 	 */
 #ifndef CONFIG_WATCHDOG_NOWAYOUT
-	pm_runtime_get_sync(wdev->dev);
-
 	omap_wdt_disable(wdev);
 
 	pm_runtime_put_sync(wdev->dev);
@@ -199,11 +191,9 @@ static ssize_t omap_wdt_write(struct file *file, const char __user *data,
 
 	/* Refresh LOAD_TIME. */
 	if (len) {
-		pm_runtime_get_sync(wdev->dev);
 		spin_lock(&wdt_lock);
 		omap_wdt_ping(wdev);
 		spin_unlock(&wdt_lock);
-		pm_runtime_put_sync(wdev->dev);
 	}
 	return len;
 }
@@ -236,18 +226,15 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
 					(int __user *)arg);
 		return put_user(0, (int __user *)arg);
 	case WDIOC_KEEPALIVE:
-		pm_runtime_get_sync(wdev->dev);
 		spin_lock(&wdt_lock);
 		omap_wdt_ping(wdev);
 		spin_unlock(&wdt_lock);
-		pm_runtime_put_sync(wdev->dev);
 		return 0;
 	case WDIOC_SETTIMEOUT:
 		if (get_user(new_margin, (int __user *)arg))
 			return -EFAULT;
 		omap_wdt_adjust_timeout(new_margin);
 
-		pm_runtime_get_sync(wdev->dev);
 		spin_lock(&wdt_lock);
 		omap_wdt_disable(wdev);
 		omap_wdt_set_timeout(wdev);
@@ -255,7 +242,6 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
 
 		omap_wdt_ping(wdev);
 		spin_unlock(&wdt_lock);
-		pm_runtime_put_sync(wdev->dev);
 		/* Fall */
 	case WDIOC_GETTIMEOUT:
 		return put_user(timer_margin, (int __user *)arg);
@@ -363,7 +349,6 @@ static void omap_wdt_shutdown(struct platform_device *pdev)
 	struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
 
 	if (wdev->omap_wdt_users) {
-		pm_runtime_get_sync(wdev->dev);
 		omap_wdt_disable(wdev);
 		pm_runtime_put_sync(wdev->dev);
 	}
@@ -403,7 +388,6 @@ static int omap_wdt_suspend(struct platform_device *pdev, pm_message_t state)
 	struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
 
 	if (wdev->omap_wdt_users) {
-		pm_runtime_get_sync(wdev->dev);
 		omap_wdt_disable(wdev);
 		pm_runtime_put_sync(wdev->dev);
 	}
@@ -419,7 +403,6 @@ static int omap_wdt_resume(struct platform_device *pdev)
 		pm_runtime_get_sync(wdev->dev);
 		omap_wdt_enable(wdev);
 		omap_wdt_ping(wdev);
-		pm_runtime_put_sync(wdev->dev);
 	}
 
 	return 0;
-- 
1.7.5.4

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* Re: [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
  2012-06-18  5:23 [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state Lokesh Vutla
@ 2012-06-18  5:41   ` Shilimkar, Santosh
  2012-07-05 14:36 ` Bedia, Vaibhav
  2012-07-08  7:49 ` Zumeng Chen
  2 siblings, 0 replies; 22+ messages in thread
From: Shilimkar, Santosh @ 2012-06-18  5:41 UTC (permalink / raw)
  To: Lokesh Vutla; +Cc: linux-arm-kernel, Wim Van Sebroeck, linux-omap

(You should cc linux-omap too.  CC'ing linux-omap)

On Mon, Jun 18, 2012 at 10:53 AM, Lokesh Vutla <lokeshvutla@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 0x00010000 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 <lokeshvutla@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Wim Van Sebroeck <wim@iguana.be>
> ---
> Tested on OMAP4430SDP.
>
> Issue #1 can be easily reproduced on mainline kernel.
> - Take latest mainline kernel and create uImage using omap2plus_defconfig
> - Write a program to open watchdog,like
> void main(void)
> {
>        int fd = open("/dev/watchdog", O_WRONLY);
>
>        if (fd == -1) {
>                perror("Watchdog device interface is not available!\n");
>        }
> }
> - Build with arm compiler and copy it to your file syatem
> - Boot the image and run the executable.
>
>
>  drivers/watchdog/omap_wdt.c |   17 -----------------
>  1 files changed, 0 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> index 8285d65..27ab8db 100644
> --- a/drivers/watchdog/omap_wdt.c
> +++ b/drivers/watchdog/omap_wdt.c
> @@ -126,8 +126,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
>        u32 pre_margin = GET_WLDR_VAL(timer_margin);
>        void __iomem *base = wdev->base;
>
> -       pm_runtime_get_sync(wdev->dev);
> -
>        /* just count up at 32 KHz */
>        while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
>                cpu_relax();
> @@ -135,8 +133,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
>        __raw_writel(pre_margin, base + OMAP_WATCHDOG_LDR);
>        while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
>                cpu_relax();
> -
> -       pm_runtime_put_sync(wdev->dev);
>  }
>
>  /*
> @@ -166,8 +162,6 @@ static int omap_wdt_open(struct inode *inode, struct file *file)
>        omap_wdt_ping(wdev); /* trigger loading of new timeout value */
>        omap_wdt_enable(wdev);
>
> -       pm_runtime_put_sync(wdev->dev);
> -
>        return nonseekable_open(inode, file);
>  }
>
> @@ -179,8 +173,6 @@ static int omap_wdt_release(struct inode *inode, struct file *file)
>         *      Shut off the timer unless NOWAYOUT is defined.
>         */
>  #ifndef CONFIG_WATCHDOG_NOWAYOUT
> -       pm_runtime_get_sync(wdev->dev);
> -
>        omap_wdt_disable(wdev);
>
>        pm_runtime_put_sync(wdev->dev);
> @@ -199,11 +191,9 @@ static ssize_t omap_wdt_write(struct file *file, const char __user *data,
>
>        /* Refresh LOAD_TIME. */
>        if (len) {
> -               pm_runtime_get_sync(wdev->dev);
>                spin_lock(&wdt_lock);
>                omap_wdt_ping(wdev);
>                spin_unlock(&wdt_lock);
> -               pm_runtime_put_sync(wdev->dev);
>        }
>        return len;
>  }
> @@ -236,18 +226,15 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
>                                        (int __user *)arg);
>                return put_user(0, (int __user *)arg);
>        case WDIOC_KEEPALIVE:
> -               pm_runtime_get_sync(wdev->dev);
>                spin_lock(&wdt_lock);
>                omap_wdt_ping(wdev);
>                spin_unlock(&wdt_lock);
> -               pm_runtime_put_sync(wdev->dev);
>                return 0;
>        case WDIOC_SETTIMEOUT:
>                if (get_user(new_margin, (int __user *)arg))
>                        return -EFAULT;
>                omap_wdt_adjust_timeout(new_margin);
>
> -               pm_runtime_get_sync(wdev->dev);
>                spin_lock(&wdt_lock);
>                omap_wdt_disable(wdev);
>                omap_wdt_set_timeout(wdev);
> @@ -255,7 +242,6 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
>
>                omap_wdt_ping(wdev);
>                spin_unlock(&wdt_lock);
> -               pm_runtime_put_sync(wdev->dev);
>                /* Fall */
>        case WDIOC_GETTIMEOUT:
>                return put_user(timer_margin, (int __user *)arg);
> @@ -363,7 +349,6 @@ static void omap_wdt_shutdown(struct platform_device *pdev)
>        struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
>
>        if (wdev->omap_wdt_users) {
> -               pm_runtime_get_sync(wdev->dev);
>                omap_wdt_disable(wdev);
>                pm_runtime_put_sync(wdev->dev);
>        }
> @@ -403,7 +388,6 @@ static int omap_wdt_suspend(struct platform_device *pdev, pm_message_t state)
>        struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
>
>        if (wdev->omap_wdt_users) {
> -               pm_runtime_get_sync(wdev->dev);
>                omap_wdt_disable(wdev);
>                pm_runtime_put_sync(wdev->dev);
>        }
> @@ -419,7 +403,6 @@ static int omap_wdt_resume(struct platform_device *pdev)
>                pm_runtime_get_sync(wdev->dev);
>                omap_wdt_enable(wdev);
>                omap_wdt_ping(wdev);
> -               pm_runtime_put_sync(wdev->dev);
>        }
>
>        return 0;
> --
> 1.7.5.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
@ 2012-06-18  5:41   ` Shilimkar, Santosh
  0 siblings, 0 replies; 22+ messages in thread
From: Shilimkar, Santosh @ 2012-06-18  5:41 UTC (permalink / raw)
  To: linux-arm-kernel

(You should cc linux-omap too.  CC'ing linux-omap)

On Mon, Jun 18, 2012 at 10:53 AM, Lokesh Vutla <lokeshvutla@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 0x00010000 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 <lokeshvutla@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Wim Van Sebroeck <wim@iguana.be>
> ---
> Tested on OMAP4430SDP.
>
> Issue #1 can be easily reproduced on mainline kernel.
> - Take latest mainline kernel and create uImage using omap2plus_defconfig
> - Write a program to open watchdog,like
> void main(void)
> {
> ? ? ? ?int fd = open("/dev/watchdog", O_WRONLY);
>
> ? ? ? ?if (fd == -1) {
> ? ? ? ? ? ? ? ?perror("Watchdog device interface is not available!\n");
> ? ? ? ?}
> }
> - Build with arm compiler and copy it to your file syatem
> - Boot the image and run the executable.
>
>
> ?drivers/watchdog/omap_wdt.c | ? 17 -----------------
> ?1 files changed, 0 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> index 8285d65..27ab8db 100644
> --- a/drivers/watchdog/omap_wdt.c
> +++ b/drivers/watchdog/omap_wdt.c
> @@ -126,8 +126,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
> ? ? ? ?u32 pre_margin = GET_WLDR_VAL(timer_margin);
> ? ? ? ?void __iomem *base = wdev->base;
>
> - ? ? ? pm_runtime_get_sync(wdev->dev);
> -
> ? ? ? ?/* just count up at 32 KHz */
> ? ? ? ?while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
> ? ? ? ? ? ? ? ?cpu_relax();
> @@ -135,8 +133,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
> ? ? ? ?__raw_writel(pre_margin, base + OMAP_WATCHDOG_LDR);
> ? ? ? ?while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
> ? ? ? ? ? ? ? ?cpu_relax();
> -
> - ? ? ? pm_runtime_put_sync(wdev->dev);
> ?}
>
> ?/*
> @@ -166,8 +162,6 @@ static int omap_wdt_open(struct inode *inode, struct file *file)
> ? ? ? ?omap_wdt_ping(wdev); /* trigger loading of new timeout value */
> ? ? ? ?omap_wdt_enable(wdev);
>
> - ? ? ? pm_runtime_put_sync(wdev->dev);
> -
> ? ? ? ?return nonseekable_open(inode, file);
> ?}
>
> @@ -179,8 +173,6 @@ static int omap_wdt_release(struct inode *inode, struct file *file)
> ? ? ? ? * ? ? ?Shut off the timer unless NOWAYOUT is defined.
> ? ? ? ? */
> ?#ifndef CONFIG_WATCHDOG_NOWAYOUT
> - ? ? ? pm_runtime_get_sync(wdev->dev);
> -
> ? ? ? ?omap_wdt_disable(wdev);
>
> ? ? ? ?pm_runtime_put_sync(wdev->dev);
> @@ -199,11 +191,9 @@ static ssize_t omap_wdt_write(struct file *file, const char __user *data,
>
> ? ? ? ?/* Refresh LOAD_TIME. */
> ? ? ? ?if (len) {
> - ? ? ? ? ? ? ? pm_runtime_get_sync(wdev->dev);
> ? ? ? ? ? ? ? ?spin_lock(&wdt_lock);
> ? ? ? ? ? ? ? ?omap_wdt_ping(wdev);
> ? ? ? ? ? ? ? ?spin_unlock(&wdt_lock);
> - ? ? ? ? ? ? ? pm_runtime_put_sync(wdev->dev);
> ? ? ? ?}
> ? ? ? ?return len;
> ?}
> @@ -236,18 +226,15 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(int __user *)arg);
> ? ? ? ? ? ? ? ?return put_user(0, (int __user *)arg);
> ? ? ? ?case WDIOC_KEEPALIVE:
> - ? ? ? ? ? ? ? pm_runtime_get_sync(wdev->dev);
> ? ? ? ? ? ? ? ?spin_lock(&wdt_lock);
> ? ? ? ? ? ? ? ?omap_wdt_ping(wdev);
> ? ? ? ? ? ? ? ?spin_unlock(&wdt_lock);
> - ? ? ? ? ? ? ? pm_runtime_put_sync(wdev->dev);
> ? ? ? ? ? ? ? ?return 0;
> ? ? ? ?case WDIOC_SETTIMEOUT:
> ? ? ? ? ? ? ? ?if (get_user(new_margin, (int __user *)arg))
> ? ? ? ? ? ? ? ? ? ? ? ?return -EFAULT;
> ? ? ? ? ? ? ? ?omap_wdt_adjust_timeout(new_margin);
>
> - ? ? ? ? ? ? ? pm_runtime_get_sync(wdev->dev);
> ? ? ? ? ? ? ? ?spin_lock(&wdt_lock);
> ? ? ? ? ? ? ? ?omap_wdt_disable(wdev);
> ? ? ? ? ? ? ? ?omap_wdt_set_timeout(wdev);
> @@ -255,7 +242,6 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
>
> ? ? ? ? ? ? ? ?omap_wdt_ping(wdev);
> ? ? ? ? ? ? ? ?spin_unlock(&wdt_lock);
> - ? ? ? ? ? ? ? pm_runtime_put_sync(wdev->dev);
> ? ? ? ? ? ? ? ?/* Fall */
> ? ? ? ?case WDIOC_GETTIMEOUT:
> ? ? ? ? ? ? ? ?return put_user(timer_margin, (int __user *)arg);
> @@ -363,7 +349,6 @@ static void omap_wdt_shutdown(struct platform_device *pdev)
> ? ? ? ?struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
>
> ? ? ? ?if (wdev->omap_wdt_users) {
> - ? ? ? ? ? ? ? pm_runtime_get_sync(wdev->dev);
> ? ? ? ? ? ? ? ?omap_wdt_disable(wdev);
> ? ? ? ? ? ? ? ?pm_runtime_put_sync(wdev->dev);
> ? ? ? ?}
> @@ -403,7 +388,6 @@ static int omap_wdt_suspend(struct platform_device *pdev, pm_message_t state)
> ? ? ? ?struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
>
> ? ? ? ?if (wdev->omap_wdt_users) {
> - ? ? ? ? ? ? ? pm_runtime_get_sync(wdev->dev);
> ? ? ? ? ? ? ? ?omap_wdt_disable(wdev);
> ? ? ? ? ? ? ? ?pm_runtime_put_sync(wdev->dev);
> ? ? ? ?}
> @@ -419,7 +403,6 @@ static int omap_wdt_resume(struct platform_device *pdev)
> ? ? ? ? ? ? ? ?pm_runtime_get_sync(wdev->dev);
> ? ? ? ? ? ? ? ?omap_wdt_enable(wdev);
> ? ? ? ? ? ? ? ?omap_wdt_ping(wdev);
> - ? ? ? ? ? ? ? pm_runtime_put_sync(wdev->dev);
> ? ? ? ?}
>
> ? ? ? ?return 0;
> --
> 1.7.5.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
  2012-06-18  5:41   ` Shilimkar, Santosh
@ 2012-06-30  7:23     ` Vutla, Lokesh
  -1 siblings, 0 replies; 22+ messages in thread
From: Vutla, Lokesh @ 2012-06-30  7:23 UTC (permalink / raw)
  To: Shilimkar, Santosh; +Cc: Wim Van Sebroeck, linux-omap, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 6842 bytes --]

Gentle ping on this....



Thanks n regards
Lokesh Vutla
LDC MPUSS Platform Team



On Mon, Jun 18, 2012 at 11:11 AM, Shilimkar, Santosh <
santosh.shilimkar@ti.com> wrote:

> (You should cc linux-omap too.  CC'ing linux-omap)
>
> On Mon, Jun 18, 2012 at 10:53 AM, Lokesh Vutla <lokeshvutla@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 0x00010000 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 <lokeshvutla@ti.com>
> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Wim Van Sebroeck <wim@iguana.be>
> > ---
> > Tested on OMAP4430SDP.
> >
> > Issue #1 can be easily reproduced on mainline kernel.
> > - Take latest mainline kernel and create uImage using omap2plus_defconfig
> > - Write a program to open watchdog,like
> > void main(void)
> > {
> >        int fd = open("/dev/watchdog", O_WRONLY);
> >
> >        if (fd == -1) {
> >                perror("Watchdog device interface is not available!\n");
> >        }
> > }
> > - Build with arm compiler and copy it to your file syatem
> > - Boot the image and run the executable.
> >
> >
> >  drivers/watchdog/omap_wdt.c |   17 -----------------
> >  1 files changed, 0 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> > index 8285d65..27ab8db 100644
> > --- a/drivers/watchdog/omap_wdt.c
> > +++ b/drivers/watchdog/omap_wdt.c
> > @@ -126,8 +126,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev
> *wdev)
> >        u32 pre_margin = GET_WLDR_VAL(timer_margin);
> >        void __iomem *base = wdev->base;
> >
> > -       pm_runtime_get_sync(wdev->dev);
> > -
> >        /* just count up at 32 KHz */
> >        while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
> >                cpu_relax();
> > @@ -135,8 +133,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev
> *wdev)
> >        __raw_writel(pre_margin, base + OMAP_WATCHDOG_LDR);
> >        while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
> >                cpu_relax();
> > -
> > -       pm_runtime_put_sync(wdev->dev);
> >  }
> >
> >  /*
> > @@ -166,8 +162,6 @@ static int omap_wdt_open(struct inode *inode, struct
> file *file)
> >        omap_wdt_ping(wdev); /* trigger loading of new timeout value */
> >        omap_wdt_enable(wdev);
> >
> > -       pm_runtime_put_sync(wdev->dev);
> > -
> >        return nonseekable_open(inode, file);
> >  }
> >
> > @@ -179,8 +173,6 @@ static int omap_wdt_release(struct inode *inode,
> struct file *file)
> >         *      Shut off the timer unless NOWAYOUT is defined.
> >         */
> >  #ifndef CONFIG_WATCHDOG_NOWAYOUT
> > -       pm_runtime_get_sync(wdev->dev);
> > -
> >        omap_wdt_disable(wdev);
> >
> >        pm_runtime_put_sync(wdev->dev);
> > @@ -199,11 +191,9 @@ static ssize_t omap_wdt_write(struct file *file,
> const char __user *data,
> >
> >        /* Refresh LOAD_TIME. */
> >        if (len) {
> > -               pm_runtime_get_sync(wdev->dev);
> >                spin_lock(&wdt_lock);
> >                omap_wdt_ping(wdev);
> >                spin_unlock(&wdt_lock);
> > -               pm_runtime_put_sync(wdev->dev);
> >        }
> >        return len;
> >  }
> > @@ -236,18 +226,15 @@ static long omap_wdt_ioctl(struct file *file,
> unsigned int cmd,
> >                                        (int __user *)arg);
> >                return put_user(0, (int __user *)arg);
> >        case WDIOC_KEEPALIVE:
> > -               pm_runtime_get_sync(wdev->dev);
> >                spin_lock(&wdt_lock);
> >                omap_wdt_ping(wdev);
> >                spin_unlock(&wdt_lock);
> > -               pm_runtime_put_sync(wdev->dev);
> >                return 0;
> >        case WDIOC_SETTIMEOUT:
> >                if (get_user(new_margin, (int __user *)arg))
> >                        return -EFAULT;
> >                omap_wdt_adjust_timeout(new_margin);
> >
> > -               pm_runtime_get_sync(wdev->dev);
> >                spin_lock(&wdt_lock);
> >                omap_wdt_disable(wdev);
> >                omap_wdt_set_timeout(wdev);
> > @@ -255,7 +242,6 @@ static long omap_wdt_ioctl(struct file *file,
> unsigned int cmd,
> >
> >                omap_wdt_ping(wdev);
> >                spin_unlock(&wdt_lock);
> > -               pm_runtime_put_sync(wdev->dev);
> >                /* Fall */
> >        case WDIOC_GETTIMEOUT:
> >                return put_user(timer_margin, (int __user *)arg);
> > @@ -363,7 +349,6 @@ static void omap_wdt_shutdown(struct platform_device
> *pdev)
> >        struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
> >
> >        if (wdev->omap_wdt_users) {
> > -               pm_runtime_get_sync(wdev->dev);
> >                omap_wdt_disable(wdev);
> >                pm_runtime_put_sync(wdev->dev);
> >        }
> > @@ -403,7 +388,6 @@ static int omap_wdt_suspend(struct platform_device
> *pdev, pm_message_t state)
> >        struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
> >
> >        if (wdev->omap_wdt_users) {
> > -               pm_runtime_get_sync(wdev->dev);
> >                omap_wdt_disable(wdev);
> >                pm_runtime_put_sync(wdev->dev);
> >        }
> > @@ -419,7 +403,6 @@ static int omap_wdt_resume(struct platform_device
> *pdev)
> >                pm_runtime_get_sync(wdev->dev);
> >                omap_wdt_enable(wdev);
> >                omap_wdt_ping(wdev);
> > -               pm_runtime_put_sync(wdev->dev);
> >        }
> >
> >        return 0;
> > --
> > 1.7.5.4
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[-- Attachment #1.2: Type: text/html, Size: 8612 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
@ 2012-06-30  7:23     ` Vutla, Lokesh
  0 siblings, 0 replies; 22+ messages in thread
From: Vutla, Lokesh @ 2012-06-30  7:23 UTC (permalink / raw)
  To: linux-arm-kernel

Gentle ping on this....



Thanks n regards
Lokesh Vutla
LDC MPUSS Platform Team



On Mon, Jun 18, 2012 at 11:11 AM, Shilimkar, Santosh <
santosh.shilimkar@ti.com> wrote:

> (You should cc linux-omap too.  CC'ing linux-omap)
>
> On Mon, Jun 18, 2012 at 10:53 AM, Lokesh Vutla <lokeshvutla@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 0x00010000 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 <lokeshvutla@ti.com>
> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Wim Van Sebroeck <wim@iguana.be>
> > ---
> > Tested on OMAP4430SDP.
> >
> > Issue #1 can be easily reproduced on mainline kernel.
> > - Take latest mainline kernel and create uImage using omap2plus_defconfig
> > - Write a program to open watchdog,like
> > void main(void)
> > {
> >        int fd = open("/dev/watchdog", O_WRONLY);
> >
> >        if (fd == -1) {
> >                perror("Watchdog device interface is not available!\n");
> >        }
> > }
> > - Build with arm compiler and copy it to your file syatem
> > - Boot the image and run the executable.
> >
> >
> >  drivers/watchdog/omap_wdt.c |   17 -----------------
> >  1 files changed, 0 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> > index 8285d65..27ab8db 100644
> > --- a/drivers/watchdog/omap_wdt.c
> > +++ b/drivers/watchdog/omap_wdt.c
> > @@ -126,8 +126,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev
> *wdev)
> >        u32 pre_margin = GET_WLDR_VAL(timer_margin);
> >        void __iomem *base = wdev->base;
> >
> > -       pm_runtime_get_sync(wdev->dev);
> > -
> >        /* just count up at 32 KHz */
> >        while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
> >                cpu_relax();
> > @@ -135,8 +133,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev
> *wdev)
> >        __raw_writel(pre_margin, base + OMAP_WATCHDOG_LDR);
> >        while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
> >                cpu_relax();
> > -
> > -       pm_runtime_put_sync(wdev->dev);
> >  }
> >
> >  /*
> > @@ -166,8 +162,6 @@ static int omap_wdt_open(struct inode *inode, struct
> file *file)
> >        omap_wdt_ping(wdev); /* trigger loading of new timeout value */
> >        omap_wdt_enable(wdev);
> >
> > -       pm_runtime_put_sync(wdev->dev);
> > -
> >        return nonseekable_open(inode, file);
> >  }
> >
> > @@ -179,8 +173,6 @@ static int omap_wdt_release(struct inode *inode,
> struct file *file)
> >         *      Shut off the timer unless NOWAYOUT is defined.
> >         */
> >  #ifndef CONFIG_WATCHDOG_NOWAYOUT
> > -       pm_runtime_get_sync(wdev->dev);
> > -
> >        omap_wdt_disable(wdev);
> >
> >        pm_runtime_put_sync(wdev->dev);
> > @@ -199,11 +191,9 @@ static ssize_t omap_wdt_write(struct file *file,
> const char __user *data,
> >
> >        /* Refresh LOAD_TIME. */
> >        if (len) {
> > -               pm_runtime_get_sync(wdev->dev);
> >                spin_lock(&wdt_lock);
> >                omap_wdt_ping(wdev);
> >                spin_unlock(&wdt_lock);
> > -               pm_runtime_put_sync(wdev->dev);
> >        }
> >        return len;
> >  }
> > @@ -236,18 +226,15 @@ static long omap_wdt_ioctl(struct file *file,
> unsigned int cmd,
> >                                        (int __user *)arg);
> >                return put_user(0, (int __user *)arg);
> >        case WDIOC_KEEPALIVE:
> > -               pm_runtime_get_sync(wdev->dev);
> >                spin_lock(&wdt_lock);
> >                omap_wdt_ping(wdev);
> >                spin_unlock(&wdt_lock);
> > -               pm_runtime_put_sync(wdev->dev);
> >                return 0;
> >        case WDIOC_SETTIMEOUT:
> >                if (get_user(new_margin, (int __user *)arg))
> >                        return -EFAULT;
> >                omap_wdt_adjust_timeout(new_margin);
> >
> > -               pm_runtime_get_sync(wdev->dev);
> >                spin_lock(&wdt_lock);
> >                omap_wdt_disable(wdev);
> >                omap_wdt_set_timeout(wdev);
> > @@ -255,7 +242,6 @@ static long omap_wdt_ioctl(struct file *file,
> unsigned int cmd,
> >
> >                omap_wdt_ping(wdev);
> >                spin_unlock(&wdt_lock);
> > -               pm_runtime_put_sync(wdev->dev);
> >                /* Fall */
> >        case WDIOC_GETTIMEOUT:
> >                return put_user(timer_margin, (int __user *)arg);
> > @@ -363,7 +349,6 @@ static void omap_wdt_shutdown(struct platform_device
> *pdev)
> >        struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
> >
> >        if (wdev->omap_wdt_users) {
> > -               pm_runtime_get_sync(wdev->dev);
> >                omap_wdt_disable(wdev);
> >                pm_runtime_put_sync(wdev->dev);
> >        }
> > @@ -403,7 +388,6 @@ static int omap_wdt_suspend(struct platform_device
> *pdev, pm_message_t state)
> >        struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
> >
> >        if (wdev->omap_wdt_users) {
> > -               pm_runtime_get_sync(wdev->dev);
> >                omap_wdt_disable(wdev);
> >                pm_runtime_put_sync(wdev->dev);
> >        }
> > @@ -419,7 +403,6 @@ static int omap_wdt_resume(struct platform_device
> *pdev)
> >                pm_runtime_get_sync(wdev->dev);
> >                omap_wdt_enable(wdev);
> >                omap_wdt_ping(wdev);
> > -               pm_runtime_put_sync(wdev->dev);
> >        }
> >
> >        return 0;
> > --
> > 1.7.5.4
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120630/b186e4b9/attachment-0001.html>

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
  2012-06-18  5:41   ` Shilimkar, Santosh
@ 2012-07-02  5:19     ` Vutla, Lokesh
  -1 siblings, 0 replies; 22+ messages in thread
From: Vutla, Lokesh @ 2012-07-02  5:19 UTC (permalink / raw)
  To: Shilimkar, Santosh; +Cc: Wim Van Sebroeck, linux-omap, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 83 bytes --]

Gentle ping on this......



Thanks n regards
Lokesh Vutla
LDC MPUSS Platform Team

[-- Attachment #1.2: Type: text/html, Size: 163 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
@ 2012-07-02  5:19     ` Vutla, Lokesh
  0 siblings, 0 replies; 22+ messages in thread
From: Vutla, Lokesh @ 2012-07-02  5:19 UTC (permalink / raw)
  To: linux-arm-kernel

Gentle ping on this......



Thanks n regards
Lokesh Vutla
LDC MPUSS Platform Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120702/9d857084/attachment-0001.html>

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
  2012-06-18  5:41   ` Shilimkar, Santosh
@ 2012-07-04 16:02     ` Shilimkar, Santosh
  -1 siblings, 0 replies; 22+ messages in thread
From: Shilimkar, Santosh @ 2012-07-04 16:02 UTC (permalink / raw)
  To: Wim Van Sebroeck
  Cc: linux-arm-kernel, linux-omap, Lokesh Vutla, linux-watchdog

Wim,

On Mon, Jun 18, 2012 at 11:11 AM, Shilimkar, Santosh
<santosh.shilimkar@ti.com> wrote:
> (You should cc linux-omap too.  CC'ing linux-omap)
>
> On Mon, Jun 18, 2012 at 10:53 AM, Lokesh Vutla <lokeshvutla@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 0x00010000 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 <lokeshvutla@ti.com>
>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Wim Van Sebroeck <wim@iguana.be>
>> ---

Any comments on this patch ? If not, can you please
queue this up for the 3.5-rc?

Regards
Santosh

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
@ 2012-07-04 16:02     ` Shilimkar, Santosh
  0 siblings, 0 replies; 22+ messages in thread
From: Shilimkar, Santosh @ 2012-07-04 16:02 UTC (permalink / raw)
  To: linux-arm-kernel

Wim,

On Mon, Jun 18, 2012 at 11:11 AM, Shilimkar, Santosh
<santosh.shilimkar@ti.com> wrote:
> (You should cc linux-omap too.  CC'ing linux-omap)
>
> On Mon, Jun 18, 2012 at 10:53 AM, Lokesh Vutla <lokeshvutla@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 0x00010000 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 <lokeshvutla@ti.com>
>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Wim Van Sebroeck <wim@iguana.be>
>> ---

Any comments on this patch ? If not, can you please
queue this up for the 3.5-rc?

Regards
Santosh

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
  2012-06-18  5:23 [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state Lokesh Vutla
  2012-06-18  5:41   ` Shilimkar, Santosh
@ 2012-07-05 14:36 ` Bedia, Vaibhav
  2012-07-06  7:21     ` Shilimkar, Santosh
  2012-07-08  7:49 ` Zumeng Chen
  2 siblings, 1 reply; 22+ messages in thread
From: Bedia, Vaibhav @ 2012-07-05 14:36 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Mon, Jun 18, 2012 at 10:53:16, Vutla, Lokesh 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. 
> 

A few questions based on the description given in the commit message.

> 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 0x00010000 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.
> 

>From what I know, a value of 0x00010000 for timers (WDT or DMTIMERs)
indicates that the iclk is gated but the fclk is running. In fact,
if the IP supports swakeup mechanism this is the value expected in the
*_CLKCTRL registers of the timers for the swakeup to work.

Sounds like on OMAP4 the WDT needs to be stopped first and then the
PRCM idle request sent otherwise SYSCLK gating will be 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.

But the current driver doesn't make use of any interrupts, right?

If the WDT was never started, runtime PM handling for the WDT should be
able to get the IP to a "disabled" state. Is the issue over here due
to the WDT counter incrementing and still the PRCM idle request being
sent for disabling it? If so, perhaps a better solution would be have
a custom runtime PM handling for WDT which checks if the counter
is incrementing or not. If it is not incrementing then it can just
go ahead and disable the clocks. However, if the counter is incrementing
then the runtime PM activities on the driver should be forbidden till
an entry to a low power state where SYSCLK needs to be gated is required.

Regards,
Vaibhav B.

> 
> 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 <lokeshvutla@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Wim Van Sebroeck <wim@iguana.be>
> ---
> Tested on OMAP4430SDP.
> 
> Issue #1 can be easily reproduced on mainline kernel.
> - Take latest mainline kernel and create uImage using omap2plus_defconfig
> - Write a program to open watchdog,like
> void main(void)
> {
> 	int fd = open("/dev/watchdog", O_WRONLY);
> 
> 	if (fd == -1) {
> 		perror("Watchdog device interface is not available!\n");
> 	}
> }  
> - Build with arm compiler and copy it to your file syatem
> - Boot the image and run the executable.
> 
> 
>  drivers/watchdog/omap_wdt.c |   17 -----------------
>  1 files changed, 0 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> index 8285d65..27ab8db 100644
> --- a/drivers/watchdog/omap_wdt.c
> +++ b/drivers/watchdog/omap_wdt.c
> @@ -126,8 +126,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
>  	u32 pre_margin = GET_WLDR_VAL(timer_margin);
>  	void __iomem *base = wdev->base;
>  
> -	pm_runtime_get_sync(wdev->dev);
> -
>  	/* just count up at 32 KHz */
>  	while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
>  		cpu_relax();
> @@ -135,8 +133,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
>  	__raw_writel(pre_margin, base + OMAP_WATCHDOG_LDR);
>  	while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
>  		cpu_relax();
> -
> -	pm_runtime_put_sync(wdev->dev);
>  }
>  
>  /*
> @@ -166,8 +162,6 @@ static int omap_wdt_open(struct inode *inode, struct file *file)
>  	omap_wdt_ping(wdev); /* trigger loading of new timeout value */
>  	omap_wdt_enable(wdev);
>  
> -	pm_runtime_put_sync(wdev->dev);
> -
>  	return nonseekable_open(inode, file);
>  }
>  
> @@ -179,8 +173,6 @@ static int omap_wdt_release(struct inode *inode, struct file *file)
>  	 *      Shut off the timer unless NOWAYOUT is defined.
>  	 */
>  #ifndef CONFIG_WATCHDOG_NOWAYOUT
> -	pm_runtime_get_sync(wdev->dev);
> -
>  	omap_wdt_disable(wdev);
>  
>  	pm_runtime_put_sync(wdev->dev);
> @@ -199,11 +191,9 @@ static ssize_t omap_wdt_write(struct file *file, const char __user *data,
>  
>  	/* Refresh LOAD_TIME. */
>  	if (len) {
> -		pm_runtime_get_sync(wdev->dev);
>  		spin_lock(&wdt_lock);
>  		omap_wdt_ping(wdev);
>  		spin_unlock(&wdt_lock);
> -		pm_runtime_put_sync(wdev->dev);
>  	}
>  	return len;
>  }
> @@ -236,18 +226,15 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
>  					(int __user *)arg);
>  		return put_user(0, (int __user *)arg);
>  	case WDIOC_KEEPALIVE:
> -		pm_runtime_get_sync(wdev->dev);
>  		spin_lock(&wdt_lock);
>  		omap_wdt_ping(wdev);
>  		spin_unlock(&wdt_lock);
> -		pm_runtime_put_sync(wdev->dev);
>  		return 0;
>  	case WDIOC_SETTIMEOUT:
>  		if (get_user(new_margin, (int __user *)arg))
>  			return -EFAULT;
>  		omap_wdt_adjust_timeout(new_margin);
>  
> -		pm_runtime_get_sync(wdev->dev);
>  		spin_lock(&wdt_lock);
>  		omap_wdt_disable(wdev);
>  		omap_wdt_set_timeout(wdev);
> @@ -255,7 +242,6 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
>  
>  		omap_wdt_ping(wdev);
>  		spin_unlock(&wdt_lock);
> -		pm_runtime_put_sync(wdev->dev);
>  		/* Fall */
>  	case WDIOC_GETTIMEOUT:
>  		return put_user(timer_margin, (int __user *)arg);
> @@ -363,7 +349,6 @@ static void omap_wdt_shutdown(struct platform_device *pdev)
>  	struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
>  
>  	if (wdev->omap_wdt_users) {
> -		pm_runtime_get_sync(wdev->dev);
>  		omap_wdt_disable(wdev);
>  		pm_runtime_put_sync(wdev->dev);
>  	}
> @@ -403,7 +388,6 @@ static int omap_wdt_suspend(struct platform_device *pdev, pm_message_t state)
>  	struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
>  
>  	if (wdev->omap_wdt_users) {
> -		pm_runtime_get_sync(wdev->dev);
>  		omap_wdt_disable(wdev);
>  		pm_runtime_put_sync(wdev->dev);
>  	}
> @@ -419,7 +403,6 @@ static int omap_wdt_resume(struct platform_device *pdev)
>  		pm_runtime_get_sync(wdev->dev);
>  		omap_wdt_enable(wdev);
>  		omap_wdt_ping(wdev);
> -		pm_runtime_put_sync(wdev->dev);
>  	}
>  
>  	return 0;
> -- 
> 1.7.5.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
  2012-07-05 14:36 ` Bedia, Vaibhav
  2012-07-06  7:21     ` Shilimkar, Santosh
@ 2012-07-06  7:21     ` Shilimkar, Santosh
  0 siblings, 0 replies; 22+ messages in thread
From: Shilimkar, Santosh @ 2012-07-06  7:21 UTC (permalink / raw)
  To: Bedia, Vaibhav
  Cc: Vutla, Lokesh, linux-arm-kernel, Wim Van Sebroeck, linux-omap,
	linux-watchdog

(+ linux-omap, linux-watchdog)

Vaibhav,

On Thu, Jul 5, 2012 at 8:06 PM, Bedia, Vaibhav <vaibhav.bedia@ti.com> wrote:
> Hi,
>
> On Mon, Jun 18, 2012 at 10:53:16, Vutla, Lokesh 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.
>>
>
> A few questions based on the description given in the commit message.
>
>> 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 0x00010000 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.
>>
>
> From what I know, a value of 0x00010000 for timers (WDT or DMTIMERs)
> indicates that the iclk is gated but the fclk is running. In fact,
> if the IP supports swakeup mechanism this is the value expected in the
> *_CLKCTRL registers of the timers for the swakeup to work.
>
Nope. That case will be 0x00020000

Read 0x1: Module is performing transition: wakeup, or
sleep, or sleep abortion
Read 0x2: Module is in idle mode (only INTRCONN part).
It is functional if using separate functional clock
Read 0x3: Module is disabled and cannot be accessed

> Sounds like on OMAP4 the WDT needs to be stopped first and then the
> PRCM idle request sent otherwise SYSCLK gating will be blocked.
>
Any module stuck in-transition will get the clock-domain from idle.

>> 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.
>
> But the current driver doesn't make use of any interrupts, right?
>
How is the interrupt related. You enable that when you enable WDT
petting using delay_interrupt()

> If the WDT was never started, runtime PM handling for the WDT should be
> able to get the IP to a "disabled" state. Is the issue over here due
> to the WDT counter incrementing and still the PRCM idle request being
> sent for disabling it? If so, perhaps a better solution would be have
> a custom runtime PM handling for WDT which checks if the counter
> is incrementing or not. If it is not incrementing then it can just
> go ahead and disable the clocks. However, if the counter is incrementing
> then the runtime PM activities on the driver should be forbidden till
> an entry to a low power state where SYSCLK needs to be gated is required.
>
If you look at the test case mentioned, the watchdong is started. Your
first observation is not as per the hardware behavior, so other points
becomes not relevant.

Regards
Santosh

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
@ 2012-07-06  7:21     ` Shilimkar, Santosh
  0 siblings, 0 replies; 22+ messages in thread
From: Shilimkar, Santosh @ 2012-07-06  7:21 UTC (permalink / raw)
  To: Bedia, Vaibhav
  Cc: Vutla, Lokesh, Wim Van Sebroeck, linux-omap, linux-watchdog,
	linux-arm-kernel

(+ linux-omap, linux-watchdog)

Vaibhav,

On Thu, Jul 5, 2012 at 8:06 PM, Bedia, Vaibhav <vaibhav.bedia@ti.com> wrote:
> Hi,
>
> On Mon, Jun 18, 2012 at 10:53:16, Vutla, Lokesh 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.
>>
>
> A few questions based on the description given in the commit message.
>
>> 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 0x00010000 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.
>>
>
> From what I know, a value of 0x00010000 for timers (WDT or DMTIMERs)
> indicates that the iclk is gated but the fclk is running. In fact,
> if the IP supports swakeup mechanism this is the value expected in the
> *_CLKCTRL registers of the timers for the swakeup to work.
>
Nope. That case will be 0x00020000

Read 0x1: Module is performing transition: wakeup, or
sleep, or sleep abortion
Read 0x2: Module is in idle mode (only INTRCONN part).
It is functional if using separate functional clock
Read 0x3: Module is disabled and cannot be accessed

> Sounds like on OMAP4 the WDT needs to be stopped first and then the
> PRCM idle request sent otherwise SYSCLK gating will be blocked.
>
Any module stuck in-transition will get the clock-domain from idle.

>> 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.
>
> But the current driver doesn't make use of any interrupts, right?
>
How is the interrupt related. You enable that when you enable WDT
petting using delay_interrupt()

> If the WDT was never started, runtime PM handling for the WDT should be
> able to get the IP to a "disabled" state. Is the issue over here due
> to the WDT counter incrementing and still the PRCM idle request being
> sent for disabling it? If so, perhaps a better solution would be have
> a custom runtime PM handling for WDT which checks if the counter
> is incrementing or not. If it is not incrementing then it can just
> go ahead and disable the clocks. However, if the counter is incrementing
> then the runtime PM activities on the driver should be forbidden till
> an entry to a low power state where SYSCLK needs to be gated is required.
>
If you look at the test case mentioned, the watchdong is started. Your
first observation is not as per the hardware behavior, so other points
becomes not relevant.

Regards
Santosh

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
@ 2012-07-06  7:21     ` Shilimkar, Santosh
  0 siblings, 0 replies; 22+ messages in thread
From: Shilimkar, Santosh @ 2012-07-06  7:21 UTC (permalink / raw)
  To: linux-arm-kernel

(+ linux-omap, linux-watchdog)

Vaibhav,

On Thu, Jul 5, 2012 at 8:06 PM, Bedia, Vaibhav <vaibhav.bedia@ti.com> wrote:
> Hi,
>
> On Mon, Jun 18, 2012 at 10:53:16, Vutla, Lokesh 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.
>>
>
> A few questions based on the description given in the commit message.
>
>> 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 0x00010000 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.
>>
>
> From what I know, a value of 0x00010000 for timers (WDT or DMTIMERs)
> indicates that the iclk is gated but the fclk is running. In fact,
> if the IP supports swakeup mechanism this is the value expected in the
> *_CLKCTRL registers of the timers for the swakeup to work.
>
Nope. That case will be 0x00020000

Read 0x1: Module is performing transition: wakeup, or
sleep, or sleep abortion
Read 0x2: Module is in idle mode (only INTRCONN part).
It is functional if using separate functional clock
Read 0x3: Module is disabled and cannot be accessed

> Sounds like on OMAP4 the WDT needs to be stopped first and then the
> PRCM idle request sent otherwise SYSCLK gating will be blocked.
>
Any module stuck in-transition will get the clock-domain from idle.

>> 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.
>
> But the current driver doesn't make use of any interrupts, right?
>
How is the interrupt related. You enable that when you enable WDT
petting using delay_interrupt()

> If the WDT was never started, runtime PM handling for the WDT should be
> able to get the IP to a "disabled" state. Is the issue over here due
> to the WDT counter incrementing and still the PRCM idle request being
> sent for disabling it? If so, perhaps a better solution would be have
> a custom runtime PM handling for WDT which checks if the counter
> is incrementing or not. If it is not incrementing then it can just
> go ahead and disable the clocks. However, if the counter is incrementing
> then the runtime PM activities on the driver should be forbidden till
> an entry to a low power state where SYSCLK needs to be gated is required.
>
If you look at the test case mentioned, the watchdong is started. Your
first observation is not as per the hardware behavior, so other points
becomes not relevant.

Regards
Santosh

^ permalink raw reply	[flat|nested] 22+ messages in thread

* RE: [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
  2012-07-06  7:21     ` Shilimkar, Santosh
  (?)
@ 2012-07-06 12:29       ` Bedia, Vaibhav
  -1 siblings, 0 replies; 22+ messages in thread
From: Bedia, Vaibhav @ 2012-07-06 12:29 UTC (permalink / raw)
  To: Shilimkar, Santosh
  Cc: Vutla, Lokesh, linux-arm-kernel, Wim Van Sebroeck, linux-omap,
	linux-watchdog

Hi Santosh,

On Fri, Jul 06, 2012 at 12:51:03, Shilimkar, Santosh wrote:
[...]
> >
> > A few questions based on the description given in the commit message.
> >
> >> 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 0x00010000 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.
> >>
> >
> > From what I know, a value of 0x00010000 for timers (WDT or DMTIMERs)
> > indicates that the iclk is gated but the fclk is running. In fact,
> > if the IP supports swakeup mechanism this is the value expected in the
> > *_CLKCTRL registers of the timers for the swakeup to work.
> >
> Nope. That case will be 0x00020000
> 
> Read 0x1: Module is performing transition: wakeup, or
> sleep, or sleep abortion
> Read 0x2: Module is in idle mode (only INTRCONN part).
> It is functional if using separate functional clock
> Read 0x3: Module is disabled and cannot be accessed
> 

What you mentioned is obviously correct :)
I somehow recall seeing something else but mostly likely I am wrong here.

> > Sounds like on OMAP4 the WDT needs to be stopped first and then the
> > PRCM idle request sent otherwise SYSCLK gating will be blocked.
> >
> Any module stuck in-transition will get the clock-domain from idle.
> 

Yes agreed.

> >> 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.
> >
> > But the current driver doesn't make use of any interrupts, right?
> >
> How is the interrupt related. You enable that when you enable WDT
> petting using delay_interrupt()
> 

Even I don't understand the interrupt part here.

> > If the WDT was never started, runtime PM handling for the WDT should be
> > able to get the IP to a "disabled" state. Is the issue over here due
> > to the WDT counter incrementing and still the PRCM idle request being
> > sent for disabling it? If so, perhaps a better solution would be have
> > a custom runtime PM handling for WDT which checks if the counter
> > is incrementing or not. If it is not incrementing then it can just
> > go ahead and disable the clocks. However, if the counter is incrementing
> > then the runtime PM activities on the driver should be forbidden till
> > an entry to a low power state where SYSCLK needs to be gated is required.
> >
> If you look at the test case mentioned, the watchdong is started. Your
> first observation is not as per the hardware behavior, so other points
> becomes not relevant.
> 

Ok. I'll double-check my observations on AM335x on Monday.

Regards,
Vaibhav B.
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 22+ messages in thread

* RE: [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
@ 2012-07-06 12:29       ` Bedia, Vaibhav
  0 siblings, 0 replies; 22+ messages in thread
From: Bedia, Vaibhav @ 2012-07-06 12:29 UTC (permalink / raw)
  To: Shilimkar, Santosh
  Cc: Vutla, Lokesh, linux-arm-kernel, Wim Van Sebroeck, linux-omap,
	linux-watchdog

Hi Santosh,

On Fri, Jul 06, 2012 at 12:51:03, Shilimkar, Santosh wrote:
[...]
> >
> > A few questions based on the description given in the commit message.
> >
> >> 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 0x00010000 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.
> >>
> >
> > From what I know, a value of 0x00010000 for timers (WDT or DMTIMERs)
> > indicates that the iclk is gated but the fclk is running. In fact,
> > if the IP supports swakeup mechanism this is the value expected in the
> > *_CLKCTRL registers of the timers for the swakeup to work.
> >
> Nope. That case will be 0x00020000
> 
> Read 0x1: Module is performing transition: wakeup, or
> sleep, or sleep abortion
> Read 0x2: Module is in idle mode (only INTRCONN part).
> It is functional if using separate functional clock
> Read 0x3: Module is disabled and cannot be accessed
> 

What you mentioned is obviously correct :)
I somehow recall seeing something else but mostly likely I am wrong here.

> > Sounds like on OMAP4 the WDT needs to be stopped first and then the
> > PRCM idle request sent otherwise SYSCLK gating will be blocked.
> >
> Any module stuck in-transition will get the clock-domain from idle.
> 

Yes agreed.

> >> 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.
> >
> > But the current driver doesn't make use of any interrupts, right?
> >
> How is the interrupt related. You enable that when you enable WDT
> petting using delay_interrupt()
> 

Even I don't understand the interrupt part here.

> > If the WDT was never started, runtime PM handling for the WDT should be
> > able to get the IP to a "disabled" state. Is the issue over here due
> > to the WDT counter incrementing and still the PRCM idle request being
> > sent for disabling it? If so, perhaps a better solution would be have
> > a custom runtime PM handling for WDT which checks if the counter
> > is incrementing or not. If it is not incrementing then it can just
> > go ahead and disable the clocks. However, if the counter is incrementing
> > then the runtime PM activities on the driver should be forbidden till
> > an entry to a low power state where SYSCLK needs to be gated is required.
> >
> If you look at the test case mentioned, the watchdong is started. Your
> first observation is not as per the hardware behavior, so other points
> becomes not relevant.
> 

Ok. I'll double-check my observations on AM335x on Monday.

Regards,
Vaibhav B.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
@ 2012-07-06 12:29       ` Bedia, Vaibhav
  0 siblings, 0 replies; 22+ messages in thread
From: Bedia, Vaibhav @ 2012-07-06 12:29 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Santosh,

On Fri, Jul 06, 2012 at 12:51:03, Shilimkar, Santosh wrote:
[...]
> >
> > A few questions based on the description given in the commit message.
> >
> >> 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 0x00010000 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.
> >>
> >
> > From what I know, a value of 0x00010000 for timers (WDT or DMTIMERs)
> > indicates that the iclk is gated but the fclk is running. In fact,
> > if the IP supports swakeup mechanism this is the value expected in the
> > *_CLKCTRL registers of the timers for the swakeup to work.
> >
> Nope. That case will be 0x00020000
> 
> Read 0x1: Module is performing transition: wakeup, or
> sleep, or sleep abortion
> Read 0x2: Module is in idle mode (only INTRCONN part).
> It is functional if using separate functional clock
> Read 0x3: Module is disabled and cannot be accessed
> 

What you mentioned is obviously correct :)
I somehow recall seeing something else but mostly likely I am wrong here.

> > Sounds like on OMAP4 the WDT needs to be stopped first and then the
> > PRCM idle request sent otherwise SYSCLK gating will be blocked.
> >
> Any module stuck in-transition will get the clock-domain from idle.
> 

Yes agreed.

> >> 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.
> >
> > But the current driver doesn't make use of any interrupts, right?
> >
> How is the interrupt related. You enable that when you enable WDT
> petting using delay_interrupt()
> 

Even I don't understand the interrupt part here.

> > If the WDT was never started, runtime PM handling for the WDT should be
> > able to get the IP to a "disabled" state. Is the issue over here due
> > to the WDT counter incrementing and still the PRCM idle request being
> > sent for disabling it? If so, perhaps a better solution would be have
> > a custom runtime PM handling for WDT which checks if the counter
> > is incrementing or not. If it is not incrementing then it can just
> > go ahead and disable the clocks. However, if the counter is incrementing
> > then the runtime PM activities on the driver should be forbidden till
> > an entry to a low power state where SYSCLK needs to be gated is required.
> >
> If you look at the test case mentioned, the watchdong is started. Your
> first observation is not as per the hardware behavior, so other points
> becomes not relevant.
> 

Ok. I'll double-check my observations on AM335x on Monday.

Regards,
Vaibhav B.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
  2012-07-04 16:02     ` Shilimkar, Santosh
  (?)
@ 2012-07-07 12:27     ` Wim Van Sebroeck
  2012-07-07 12:28         ` Shilimkar, Santosh
  -1 siblings, 1 reply; 22+ messages in thread
From: Wim Van Sebroeck @ 2012-07-07 12:27 UTC (permalink / raw)
  To: Shilimkar, Santosh, Lokesh Vutla
  Cc: linux-arm-kernel, linux-omap, linux-watchdog

Hi All,

> > On Mon, Jun 18, 2012 at 10:53 AM, Lokesh Vutla <lokeshvutla@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 0x00010000 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 <lokeshvutla@ti.com>
> >> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >> Cc: Wim Van Sebroeck <wim@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.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
  2012-07-07 12:27     ` Wim Van Sebroeck
@ 2012-07-07 12:28         ` Shilimkar, Santosh
  0 siblings, 0 replies; 22+ messages in thread
From: Shilimkar, Santosh @ 2012-07-07 12:28 UTC (permalink / raw)
  To: Wim Van Sebroeck
  Cc: Lokesh Vutla, linux-arm-kernel, linux-omap, linux-watchdog

On Sat, Jul 7, 2012 at 5:57 PM, Wim Van Sebroeck <wim@iguana.be> wrote:
>
> Hi All,
>
> > > On Mon, Jun 18, 2012 at 10:53 AM, Lokesh Vutla <lokeshvutla@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 0x00010000 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 <lokeshvutla@ti.com>
> > >> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > >> Cc: Wim Van Sebroeck <wim@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.
>
Thanks Wim.

Regards
Santosh

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
@ 2012-07-07 12:28         ` Shilimkar, Santosh
  0 siblings, 0 replies; 22+ messages in thread
From: Shilimkar, Santosh @ 2012-07-07 12:28 UTC (permalink / raw)
  To: linux-arm-kernel

On Sat, Jul 7, 2012 at 5:57 PM, Wim Van Sebroeck <wim@iguana.be> wrote:
>
> Hi All,
>
> > > On Mon, Jun 18, 2012 at 10:53 AM, Lokesh Vutla <lokeshvutla@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 0x00010000 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 <lokeshvutla@ti.com>
> > >> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > >> Cc: Wim Van Sebroeck <wim@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.
>
Thanks Wim.

Regards
Santosh

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
  2012-06-18  5:23 [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state Lokesh Vutla
  2012-06-18  5:41   ` Shilimkar, Santosh
  2012-07-05 14:36 ` Bedia, Vaibhav
@ 2012-07-08  7:49 ` Zumeng Chen
       [not found]   ` <20120708092612.GA735@spo001.leaseweb.com>
  2 siblings, 1 reply; 22+ messages in thread
From: Zumeng Chen @ 2012-07-08  7:49 UTC (permalink / raw)
  To: linux-arm-kernel

? 2012?06?18? 13:23, Lokesh Vutla ??:
> 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 0x00010000 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<lokeshvutla@ti.com>
> Acked-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
> Cc: Wim Van Sebroeck<wim@iguana.be>
> ---
> Tested on OMAP4430SDP.
>
> Issue #1 can be easily reproduced on mainline kernel.
> - Take latest mainline kernel and create uImage using omap2plus_defconfig
> - Write a program to open watchdog,like
> void main(void)
> {
> 	int fd = open("/dev/watchdog", O_WRONLY);
>
> 	if (fd == -1) {
> 		perror("Watchdog device interface is not available!\n");
> 	}
> }
Hello, Lokesh,

One question: Does "echo 1 > /dev/watchdog" work well?

Regards,
Zumeng
> - Build with arm compiler and copy it to your file syatem
> - Boot the image and run the executable.
>
>
>   drivers/watchdog/omap_wdt.c |   17 -----------------
>   1 files changed, 0 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> index 8285d65..27ab8db 100644
> --- a/drivers/watchdog/omap_wdt.c
> +++ b/drivers/watchdog/omap_wdt.c
> @@ -126,8 +126,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
>   	u32 pre_margin = GET_WLDR_VAL(timer_margin);
>   	void __iomem *base = wdev->base;
>
> -	pm_runtime_get_sync(wdev->dev);
> -
>   	/* just count up at 32 KHz */
>   	while (__raw_readl(base + OMAP_WATCHDOG_WPS)&  0x04)
>   		cpu_relax();
> @@ -135,8 +133,6 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
>   	__raw_writel(pre_margin, base + OMAP_WATCHDOG_LDR);
>   	while (__raw_readl(base + OMAP_WATCHDOG_WPS)&  0x04)
>   		cpu_relax();
> -
> -	pm_runtime_put_sync(wdev->dev);
>   }
>
>   /*
> @@ -166,8 +162,6 @@ static int omap_wdt_open(struct inode *inode, struct file *file)
>   	omap_wdt_ping(wdev); /* trigger loading of new timeout value */
>   	omap_wdt_enable(wdev);
>
> -	pm_runtime_put_sync(wdev->dev);
> -
>   	return nonseekable_open(inode, file);
>   }
>
> @@ -179,8 +173,6 @@ static int omap_wdt_release(struct inode *inode, struct file *file)
>   	 *      Shut off the timer unless NOWAYOUT is defined.
>   	 */
>   #ifndef CONFIG_WATCHDOG_NOWAYOUT
> -	pm_runtime_get_sync(wdev->dev);
> -
>   	omap_wdt_disable(wdev);
>
>   	pm_runtime_put_sync(wdev->dev);
> @@ -199,11 +191,9 @@ static ssize_t omap_wdt_write(struct file *file, const char __user *data,
>
>   	/* Refresh LOAD_TIME. */
>   	if (len) {
> -		pm_runtime_get_sync(wdev->dev);
>   		spin_lock(&wdt_lock);
>   		omap_wdt_ping(wdev);
>   		spin_unlock(&wdt_lock);
> -		pm_runtime_put_sync(wdev->dev);
>   	}
>   	return len;
>   }
> @@ -236,18 +226,15 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
>   					(int __user *)arg);
>   		return put_user(0, (int __user *)arg);
>   	case WDIOC_KEEPALIVE:
> -		pm_runtime_get_sync(wdev->dev);
>   		spin_lock(&wdt_lock);
>   		omap_wdt_ping(wdev);
>   		spin_unlock(&wdt_lock);
> -		pm_runtime_put_sync(wdev->dev);
>   		return 0;
>   	case WDIOC_SETTIMEOUT:
>   		if (get_user(new_margin, (int __user *)arg))
>   			return -EFAULT;
>   		omap_wdt_adjust_timeout(new_margin);
>
> -		pm_runtime_get_sync(wdev->dev);
>   		spin_lock(&wdt_lock);
>   		omap_wdt_disable(wdev);
>   		omap_wdt_set_timeout(wdev);
> @@ -255,7 +242,6 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd,
>
>   		omap_wdt_ping(wdev);
>   		spin_unlock(&wdt_lock);
> -		pm_runtime_put_sync(wdev->dev);
>   		/* Fall */
>   	case WDIOC_GETTIMEOUT:
>   		return put_user(timer_margin, (int __user *)arg);
> @@ -363,7 +349,6 @@ static void omap_wdt_shutdown(struct platform_device *pdev)
>   	struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
>
>   	if (wdev->omap_wdt_users) {
> -		pm_runtime_get_sync(wdev->dev);
>   		omap_wdt_disable(wdev);
>   		pm_runtime_put_sync(wdev->dev);
>   	}
> @@ -403,7 +388,6 @@ static int omap_wdt_suspend(struct platform_device *pdev, pm_message_t state)
>   	struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
>
>   	if (wdev->omap_wdt_users) {
> -		pm_runtime_get_sync(wdev->dev);
>   		omap_wdt_disable(wdev);
>   		pm_runtime_put_sync(wdev->dev);
>   	}
> @@ -419,7 +403,6 @@ static int omap_wdt_resume(struct platform_device *pdev)
>   		pm_runtime_get_sync(wdev->dev);
>   		omap_wdt_enable(wdev);
>   		omap_wdt_ping(wdev);
> -		pm_runtime_put_sync(wdev->dev);
>   	}
>
>   	return 0;

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
       [not found]   ` <20120708092612.GA735@spo001.leaseweb.com>
@ 2012-07-09  1:16     ` Zumeng Chen
  2012-07-09  3:49       ` Vutla, Lokesh
  0 siblings, 1 reply; 22+ messages in thread
From: Zumeng Chen @ 2012-07-09  1:16 UTC (permalink / raw)
  To: linux-arm-kernel

? 2012?07?08? 17:26, Wim Van Sebroeck ??:
> Hi All,
>
>> Hello, Lokesh,
>>
>> One question: Does "echo 1>  /dev/watchdog" work well?
>>
>> Regards,
>> Zumeng
> Please note hat "echo 1>  /dev/watchdog" for drivers that have the WDIOF_MAGICCLOSE
> flag set, reboots the system. This is because it opens the watchdog device ; then
> writes the characters "1" to it and then closes the watchdog. So the watchdog keeps
> running (because it didn't see the magic char "V" written to it).
Yes, this is _absolutely_ right.
>
> In this case (omap_wdt) it opens the watchdog device (and starts the watchdog) then
> it writes a "1" to the watchdog (so basically the watchdog is being pinged) and then
> closes the watchdog device (which stops the watchdog if NOWAYOUT was not set).
Wim,

Agreed for all above, sorry for jumping in:

I just have a little question about this patch:


we have enable pm_runtime_enable(wdev->dev) in probe,
and do ret = misc_register(&(wdev->omap_wdt_miscdev));

Then this patch wants to remove pm_runtime_get_sync
in file operation function, is that right?

Regards,
Zumeng

>
> Kind regards,
> Wim.
>

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
  2012-07-09  1:16     ` Zumeng Chen
@ 2012-07-09  3:49       ` Vutla, Lokesh
  0 siblings, 0 replies; 22+ messages in thread
From: Vutla, Lokesh @ 2012-07-09  3:49 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jul 9, 2012 at 6:46 AM, Zumeng Chen <zumeng.chen@windriver.com> wrote:
> ? 2012?07?08? 17:26, Wim Van Sebroeck ??:
>
>> Hi All,
>>
>>> Hello, Lokesh,
>>>
>>> One question: Does "echo 1>  /dev/watchdog" work well?
>>>
>>> Regards,
>>> Zumeng
>>
>> Please note hat "echo 1>  /dev/watchdog" for drivers that have the
>> WDIOF_MAGICCLOSE
>> flag set, reboots the system. This is because it opens the watchdog device
>> ; then
>> writes the characters "1" to it and then closes the watchdog. So the
>> watchdog keeps
>> running (because it didn't see the magic char "V" written to it).
>
> Yes, this is _absolutely_ right.
>
>>
>> In this case (omap_wdt) it opens the watchdog device (and starts the
>> watchdog) then
>> it writes a "1" to the watchdog (so basically the watchdog is being
>> pinged) and then
>> closes the watchdog device (which stops the watchdog if NOWAYOUT was not
>> set).
>
> Wim,
>
> Agreed for all above, sorry for jumping in:
>
> I just have a little question about this patch:
>
>
> we have enable pm_runtime_enable(wdev->dev) in probe,
> and do ret = misc_register(&(wdev->omap_wdt_miscdev));
>
> Then this patch wants to remove pm_runtime_get_sync
> in file operation function, is that right?

Yes, this patch removes pm_runtime_get/put_sync when we
know that watchdog is running.

>
> Regards,
> Zumeng
>
>>
>> Kind regards,
>> Wim.
>>
>

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2012-07-09  3:49 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-18  5:23 [PATCH] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state Lokesh Vutla
2012-06-18  5:41 ` Shilimkar, Santosh
2012-06-18  5:41   ` Shilimkar, Santosh
2012-06-30  7:23   ` Vutla, Lokesh
2012-06-30  7:23     ` Vutla, Lokesh
2012-07-02  5:19   ` Vutla, Lokesh
2012-07-02  5:19     ` Vutla, Lokesh
2012-07-04 16:02   ` Shilimkar, Santosh
2012-07-04 16:02     ` Shilimkar, Santosh
2012-07-07 12:27     ` Wim Van Sebroeck
2012-07-07 12:28       ` Shilimkar, Santosh
2012-07-07 12:28         ` Shilimkar, Santosh
2012-07-05 14:36 ` Bedia, Vaibhav
2012-07-06  7:21   ` Shilimkar, Santosh
2012-07-06  7:21     ` Shilimkar, Santosh
2012-07-06  7:21     ` Shilimkar, Santosh
2012-07-06 12:29     ` Bedia, Vaibhav
2012-07-06 12:29       ` Bedia, Vaibhav
2012-07-06 12:29       ` Bedia, Vaibhav
2012-07-08  7:49 ` Zumeng Chen
     [not found]   ` <20120708092612.GA735@spo001.leaseweb.com>
2012-07-09  1:16     ` Zumeng Chen
2012-07-09  3:49       ` Vutla, Lokesh

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.