Re: [PATCH] tick-broadcast: Register for hrtimer based broadcast as the default broadcast mode

From: Preeti U Murthy
Date: Mon Dec 08 2014 - 00:29:50 EST

On 12/05/2014 07:09 PM, Mark Rutland wrote:
> Hi Preeti,
> Moving this out of the architecture code looks good to me!
> I have a couple of minor comments below.

>> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
>> index ec1791f..6044a51 100644
>> --- a/kernel/time/timekeeping.c
>> +++ b/kernel/time/timekeeping.c
>> @@ -1016,6 +1016,10 @@ void __init timekeeping_init(void)
>> boot.tv_sec = 0;
>> boot.tv_nsec = 0;
>> }
>> + /* Register for hrtimer based broadcast as the default timekeeping
>> + * mode in deep idle states.
>> + */
> Nit: for code style this should have a newline after the '/*' (and we
> should probably have a newline before that anyway.
>> + tick_setup_hrtimer_broadcast();
> We register the generic dummy timer via an early_initcall, which keeps
> all the logic in the dummy timer driver. Are we able to do the same of
> the broadcast hrtimer? Or is there some ordering constraint we need to
> meet?

Yes this is doable. There are no ordering constraints. Placing it in an
early_initcall() will enable it to run before initializing SMP and
cpuidle, which is perfect (we do not have any per-cpu initializations
and we do not want cpus to begin entering idle states before this
hrtimer is initialized).

It also runs after the hrtimer/clockevents infrastructure has been
initialized, which is good since we need them. The broadcast hrtimer
will thus only get registered as a broadcast device if no other clock
device has managed to register itself as one.

Let me send out a V2.


Preeti U Murthy

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at