On 22/03/10 09:10 +0100, Kauppi Ari (EXT-Ixonos/Oulu) wrote:
> Millisecond resolution is possible and there are use cases for it
> (automatic testing).
>
> Seconds-based interface is preserved for compatibility.
>
> Signed-off-by: Ari Kauppi <[email protected]>
> ---
...
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 3868c76..cd55968 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
...
> @@ -640,20 +640,20 @@ out:
> }
>
> #ifdef CONFIG_SUSPEND
> -static void omap2_pm_wakeup_on_timer(u32 seconds)
> +static void omap2_pm_wakeup_on_timer(u32 milliseconds)
> {
> u32 tick_rate, cycles;
>
> - if (!seconds)
> + if (!milliseconds)
> return;
>
> tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer_wakeup));
> - cycles = tick_rate * seconds;
> + cycles = tick_rate * milliseconds / 1000;
Ari has pointed me here regarding clarification of whether the above
is an overflow risk? At 32768 Hz, the above intermediate will overflow
a u32 if milliseconds >= 131072, e.g. 2 minutes 10+ seconds.
If there is an overflow risk, then something like the following would
work around it:
u32 seconds = milliseconds / 1000;
milliseconds -= seconds * 1000;
cycles = tick_rate * seconds + tick_rate * milliseconds / 1000;
(Alternatively, a u64 could be used for the intermediate, and we could
just let gcc manage the 64 bit / constant 32 bit division.)
Unfortunately, as tick_rate is not a constant, there's no trivial fast-path
check for overflow before it happens. Then again, this looks like it's
only used in debug code, so hopefully that's not an issue.
Phil
--
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
