[PATCH] tick-broadcast: Register for hrtimer based broadcast as the default broadcast mode
Preeti U Murthy
preeti at linux.vnet.ibm.com
Sun Dec 7 21:29:31 PST 2014
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
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
More information about the linux-arm-kernel