Paul,
On 3/10/2011 2:54 PM, Cousson, Benoit wrote:
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, kalle.jokiniemi@xxxxxxxxx wrote:
From: ext Paul Walmsley [mailto:paul@xxxxxxxxx]
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.
Meanwhile, this patch is probably the best approach anyway.
I do not like going backward with a clock level management solution.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
