]> www.pilppa.org Git - linux-2.6-omap-h63xx.git/commit
ARM: OMAP: sched_clock() corrected
authorAaro Koskinen <Aaro.Koskinen@nokia.com>
Tue, 17 Feb 2009 18:21:15 +0000 (18:21 +0000)
committerTony Lindgren <tony@atomide.com>
Wed, 18 Feb 2009 23:32:34 +0000 (15:32 -0800)
commit9509566544da8617ba4e130686b6010dd0e82157
treec04eab68b692fbe6e9a1dc99b39b57dbc85f7123
parent1809173fbd1d17951fe697e3f705398ee8eaf7d2
ARM: OMAP: sched_clock() corrected

After my OMAP3 board has been running for a while, I'm seeing weird
latency traces like this:

      sh-1574    0d.h2  153us : do_timer (tick_do_update_jiffies64)
      sh-1574    0d.h2  153us : update_wall_time (do_timer)
      sh-1574    0d.h2  153us!: omap_32k_read (update_wall_time)
      sh-1574    0d.h2 1883us : update_xtime_cache (update_wall_time)
      sh-1574    0d.h2 1883us : clocksource_get_next (update_wall_time)
      sh-1574    0d.h2 1883us+: _spin_lock_irqsave (clocksource_get_next)

and after a while:

      sh-17818   0d.h3  153us : do_timer (tick_do_update_jiffies64)
      sh-17818   0d.h3  153us : update_wall_time (do_timer)
      sh-17818   0d.h3  153us!: omap_32k_read (update_wall_time)
      sh-17818   0d.h3 1915us : update_xtime_cache (update_wall_time)
      sh-17818   0d.h3 1915us+: clocksource_get_next (update_wall_time)
      sh-17818   0d.h3 1945us : _spin_lock_irqsave (clocksource_get_next)

Turns out that sched_clock() is using cyc2ns(), which returns NTP
adjusted time. The sched_clock() frequency should not be adjusted. The
patch deletes omap_32k_ticks_to_nsecs() and rewrites sched_clock()
to do the conversion using the constant multiplier.

Signed-off-by: Aaro Koskinen <Aaro.Koskinen@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
arch/arm/plat-omap/common.c