-
由 Russell King 提交于
Provide common sched_clock() infrastructure for platforms to use to create a 64-bit ns based sched_clock() implementation from a counter running at a non-variable clock rate. This implementation is based upon maintaining an epoch for the counter and an epoch for the nanosecond time. When we desire a sched_clock() time, we calculate the number of counter ticks since the last epoch update, convert this to nanoseconds and add to the epoch nanoseconds. We regularly refresh these epochs within the counter wrap interval. We perform a similar calculation as above, and store the new epochs. We read and write the epochs in such a way that sched_clock() can easily (and locklessly) detect when an update is in progress, and repeat the loading of these constants when they're known not to be stable. The one caveat is that sched_clock() is not called in the middle of an update. We achieve that by disabling IRQs. Finally, if the clock rate is known at compile time, the counter to ns conversion factors can be specified, allowing sched_clock() to be tightly optimized. We ensure that these factors are correct by providing an initialization function which performs a run-time check. Acked-by: NPeter Zijlstra <peterz@infradead.org> Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NWill Deacon <will.deacon@arm.com> Tested-by: NMikael Pettersson <mikpe@it.uu.se> Tested-by: NEric Miao <eric.y.miao@gmail.com> Tested-by: NOlof Johansson <olof@lixom.net> Tested-by: NJamie Iles <jamie@jamieiles.com> Reviewed-by: NNicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
112f38a4