BMC/Intel-BMC/linux.git/arch/s390/kernel/time.c, branch dev-4.10

clocksource: Use a plain u64 instead of cycle_t

2016-12-25T10:04:12+00:00

There is no point in having an extra type for extra confusion. u64 is unambiguous. Conversion was done with the following coccinelle script: @rem@ @@ -typedef u64 cycle_t; @fix@ typedef cycle_t; @@ -cycle_t +u64 Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra Cc: John Stultz

Replace with globally

2016-12-24T19:46:01+00:00

This was entirely automated, using the script by Al: PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*' sed -i -e "s!$PATT!#include !" \ $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h) to do the replacement at the end of the merge window. Requested-by: Al Viro Signed-off-by: Linus Torvalds

s390/time: fix clocksource steering for negative clock offsets

2016-11-17T05:56:38+00:00

The TOD clock offset injected by an STP sync check can be negative. If the resulting total tod_steering_delta gets negative the kernel will panic. Change the type of tod_steering_delta to a signed type. Reported-by: Dan Carpenter Fixes: 75c7b6f3f6ba ("s390/time: steer clocksource on STP sync events") Signed-off-by: Martin Schwidefsky

s390/time: steer clocksource on STP sync events

2016-10-28T08:09:02+00:00

On STP sync events the TOD clock will jump in time, either forward or backward. The TOD clocksource claims to be continuous but in case of an STP sync with a negative offset it is not. Subtract the offset injected by the STP sync check from the result of the TOD clocksource to make it continuous again. Add code to drift the offset towards zero with a fixed rate, steering 1 second in ~9 hours. Suggested-by: David Hildenbrand Signed-off-by: Martin Schwidefsky

s390/time: adjust last_update_clock at clock synchronization

2016-10-28T08:09:02+00:00

The last_update_clock time stamp in the lowcore should be adjusted by the TOD clock delta that is created by the clock synchronization. Otherwise the calculation of the steal time will be incorrect. Signed-off-by: Martin Schwidefsky

s390/time: refactor clock sync

2016-10-28T08:09:02+00:00

Merge clock_sync_cpu into stp_sync_clock and split out the update of the global and per-CPU clock fields into clock_sync_global and clock_sync_local. Signed-off-by: Martin Schwidefsky

s390/time: avoid races when updating tb_update_count

2016-08-29T09:04:58+00:00

The increment might not be atomic and we're not holding the timekeeper_lock. Therefore we might lose an update to count, resulting in VDSO being trapped in a loop. As other archs also simply update the values and count doesn't seem to have an impact on reloading of these values in VDSO code, let's just remove the update of tb_update_count. Suggested-by: Martin Schwidefsky Signed-off-by: David Hildenbrand Signed-off-by: Martin Schwidefsky

s390/time: fixup the clock comparator on all cpus

2016-08-29T09:04:56+00:00

By leaving fixup_cc unset, only the clock comparator of the cpu actually doing the sync is fixed up until now. Signed-off-by: David Hildenbrand Signed-off-by: Martin Schwidefsky

s390/time: cleanup etr leftovers

2016-08-29T09:04:54+00:00

There are still some etr leftovers and wrong comments, let's clean that up. Signed-off-by: David Hildenbrand Signed-off-by: Martin Schwidefsky

s390/time: simplify stp time syncs

2016-08-29T09:04:52+00:00

The way we call do_adjtimex() today is broken. It has 0 effect, as ADJ_OFFSET_SINGLESHOT (0x0001) in the kernel maps to !ADJ_ADJTIME (in contrast to user space where it maps to ADJ_OFFSET_SINGLESHOT | ADJ_ADJTIME - 0x8001). !ADJ_ADJTIME will silently ignore all adjustments without STA_PLL being active. We could switch to ADJ_ADJTIME or turn STA_PLL on, but still we would run into some problems: - Even when switching to nanoseconds, we lose accuracy. - Successive calls to do_adjtimex() will simply overwrite any leftovers from the previous call (if not fully handled) - Anything that NTP does using the sysctl heavily interferes with our use. - !ADJ_ADJTIME will silently round stuff > or < than 0.5 seconds Reusing do_adjtimex() here just feels wrong. The whole STP synchronization works right now *somehow* only, as do_adjtimex() does nothing and our TOD clock jumps in time, although it shouldn't. This is especially bad as the clock could jump backwards in time. We will have to find another way to fix this up. As leap seconds are also not properly handled yet, let's just get rid of all this complex logic altogether and use the correct clock_delta for fixing up the clock comparator and keeping the sched_clock monotonic. This change should have 0 effect on the current STP mechanism. Once we know how to best handle sync events and leap second updates, we'll start with a fresh implementation. Signed-off-by: David Hildenbrand Signed-off-by: Martin Schwidefsky