Skip to contentSkip to conversation

support printk-times by fixing sched_clock to be callable in early boot

PATCH In review Tim Bird 2 participants 2 messages Aug 23, 2006 – Sep 5, 2006

Subsystems (3)
lore
Share & tools
lore

Tim Bird

author
#0 lore raw

PATCH 1/1 support printk-times by fixing sched_clock to be callable in early boot

Hi all,

This patch has been sitting in my 'to-submit' queue for a long time.

Basically, you can't use the printk times feature on omap, because by default it calls sched_clock() before the timer is set up, which causes the machine to hang. This simplistic fix makes sched_clock() return 0 until the clock has been properly initialized.

The overhead of the flag check is not big, but it's impact could be reduced by moving the test into a separate printk_clock() routine (which would front the sched_clock() function, and is only called by printk when printk timing is active.) Let me know if you would prefer that I rework this patch to use that approach instead.

Regards,
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================

arch/arm/mach-omap1/time.c +8 -1
Index: alp-linux--import-2-6-15--0/arch/arm/mach-omap1/time.c
===================================================================
@@ -196,6 +196,8 @@
 	.handler	= omap_mpu_timer1_interrupt,
 };
 
+static int omap_mpu_timer1_initialized = 0;
+
 static __init void omap_init_mpu_timer(void)
 {
 	set_cyc2ns_scale(MPU_TICKS_PER_SEC / 1000);
@@ -204,6 +206,7 @@
 	setup_irq(INT_TIMER2, &omap_mpu_timer_irq);
 	omap_mpu_timer_start(0, 0xffffffff);
 	omap_mpu_timer_start(1, MPU_TIMER_TICK_PERIOD);
+	omap_mpu_timer1_initialized = 1;
 }
 
 /*
@@ -211,9 +215,13 @@
  */
 unsigned long long sched_clock(void)
 {
-	unsigned long ticks = 0 - omap_mpu_timer_read(0);
+	unsigned long ticks;
 	unsigned long long ticks64;
 
+	if (unlikely(!omap_mpu_timer1_initialized)) return 0;
+
+	ticks = 0 - omap_mpu_timer_read(0);
+
 	ticks64 = omap_mpu_timer1_overflows;
 	ticks64 <<= 32;
 	ticks64 |= ticks;
#1 lore raw

Hi,

Quoted 9 lines · Tim Bird

Hi all,

This patch has been sitting in my 'to-submit' queue for a long time.

Basically, you can't use the printk times feature on omap, because by default it calls sched_clock() before the timer is set up, which causes the machine to hang. This simplistic fix makes sched_clock() return 0 until the clock has been properly initialized.

Quoted 6 lines

The overhead of the flag check is not big, but it's impact could be reduced by moving the test into a separate printk_clock() routine (which would front the sched_clock() function, and is only called by printk when printk timing is active.) Let me know if you would prefer that I rework this patch to use that approach instead.

Sorry for the long delay in replying. Let's rather implement printk_clock() like you suggest as sched_clock is called quite a bit. That should also allow us to remove the current hack e4fb3a282725bc66dc63fd248e9d05e0396ddf95 in kernel/printk.c.

Regards,

Tony