[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