On 3/10/2011 2:08 PM, Paul Walmsley wrote:
Hi BenoƮt,

On Thu, 10 Mar 2011, Cousson, Benoit wrote:

On 3/10/2011 11:28 AM, [email protected] wrote:

From: ext Paul Walmsley [mailto:[email protected]]
Sent: 10. maaliskuuta 2011 11:50

Thanks Kalle for tracking this down,

could you try this patch along with the patch from this message:

    http://www.spinics.net/lists/linux-omap/msg48115.html

I have some question with that patch.
By using pm_runtime API, you are suppose to idle the whole IP.
In this case, just because you cannot idle a wdt that is running, it works,
but the point is that the pm_runtime state will not reflect the HW state.
For pm_runtime point of view, the wdt is supposed to be fully idle (both fclk
and iclk). Whereas in that case, only the iclk will be gated.

Did I miss something?

Looking at it, I don't know how the old driver managed to work at all.
Commit 7ec5ad0f3c1e28b693185c35f768953c5db32291 ("OMAP: WDT: Use PM
runtime APIs instead of clk FW APIs") removed this from omap_wdt_probe():

-       /* autogate OCP interface clock */
-       __raw_writel(0x01, wdev->base + OMAP_WATCHDOG_SYS_CONFIG);

This would put the WDTIMER into force-idle, and nothing ever took it out
of force-idle.  So I don't quite understand why the PRCM wouldn't just
turn off the functional clock to the WDTIMER at this point.  Any thoughts
on this?

The idle definition of the PRCM is just: idle of the ocp clock (iclk). The fclk can be active while the module is "idle" for the PRCM point of view. That's why we have a mismatch in that case with the pm_runtime idle definition, where the module should be fully idle.

In that case, since the WDT is in the wakeup domain, we do not even have to re-enable the iclk since the wakeup domain is always on whenever the MPU is running.

That fact that we have to explicitly do a force idle, probably means that the autoidle is broken in the IP.

Benoit
--
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

Reply via email to