[PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM
Paul Walmsley
paul at pwsan.com
Thu Mar 10 03:54:10 EST 2011
On Thu, 24 Feb 2011, Sricharan R wrote:
> In the case of !CONFIG_PM_RUNTIME and !CONFIG_OMAP_WATCHDOG, if
> the boot loader or hwmod enables the watchdog, then it generates
> an un wanted reset.
>
> So to avoid this in the case of !CONFIG_OMAP_WATCHDOG then the
> watchdog should always be disabled.
>
> So there are two cases:
> Case 1: (!CONFIG_OMAP_WATCHDOG and !CONFIG_PM_RUNTIME)
> Watchdog should be disabled.
>
> Case 2: (!CONFIG_PM_RUNTIME) and ( driver is present and board file
> enables it)
> Watchdog should run.
>
> Solution1:
> Introduce a new hwmod watchdog reset function, by populating
> the .reset entry of the hwmod.
> This function is called during the hwmod init.
> This function resets the watchdog always and also
> disables it if !CONFIG_OMAP_WATCHDOG.
>
> ( or )
>
> Solution2:
> Introduce a state variable to differentiate if
> hwmod post_setup_state is set to enabled by
> by board file or io.c file.
>
> Use this state variable in the reset function as
>
> If it is enabled by io.c then disable watchdog
> Otherwise if it is set to enabled by board file
> then enable watchdog.
>
> The below is the patch for solution1, that I have mentioned.
> Please suggest which would be the right approach ?
I don't think either of these seem right. At this point, I think the best
way is to add a function pointer that can be used to quiesce IP blocks
that become active after being reset, and to add a flag that board files
can set to skip that quiescing process. We're so close to the merge
window opening, though, that I think the best time to deal with this will
be after 2.6.40 is released.
- Paul
More information about the linux-arm-kernel
mailing list