support printk-times by fixing sched_clock to be callable in early boot
Subsystems (3)
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
@@ -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;
[email protected]
reviewerHi,
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 makessched_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 thesched_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