- 03 Apr, 2015 28 commits
-
-
Thomas Gleixner authored
All users converted. Remove the notify leftovers. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/2076318.76XJZ8QYP3@vostro.rjw.lanSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
clockevents_notify() is a leftover from the early design of the clockevents facility. It's really not a notification mechanism, it's a multiplex call. We are way better off to have explicit calls instead of this monstrosity. Split out the broadcast control into a separate function and provide inline helpers. Switch clockevents_notify() over. This will go away once all callers are converted. This also gets rid of the nested locking of clockevents_lock and broadcast_lock. The broadcast control functions do not require clockevents_lock. Only the managing functions (setup/shutdown/suspend/resume of the broadcast device require clockevents_lock. Signed-off-by:
-
Thomas Gleixner authored
While looking through the (ab)use of the clockevents_notify() function I stumbled over the following gem in the acpi_pad code: if (lapic_detected_unstable && !lapic_marked_unstable) { /* LAPIC could halt in idle, so notify users */ for_each_online_cpu(i) clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &i); lapic_marked_unstable = 1; } This code calls on the cpu which detects the lapic unstable condition first clockevents_notify() to tell the core code that the broadcast should be enabled on all online cpus. Brilliant stuff that as it notifies the core code a num_online_cpus() times that the broadcast should be enabled on the current cpu. This probably has never been noticed because that code got never tested with NOHZ=n and HIGHRES_TIMER=n or it just worked by chance because one of the other mechanisms told the core in the right way that the local apic timer is wreckaged. Sigh, this is: - The 4th incarnation of idle drivers which has their own mechanism to detect and deal with X86_FEATURE_ARAT. - The 2nd incarnation of fake idle mechanisms with a different set of brainmelting bugs. - Has been merged against an explicit NAK of the scheduler maintainer with the promise to improve it over time. - Another example of featuritis driven trainwreck engineering. - Another pointless waste of my time. Fix this nonsense by removing that lapic detection and notification logic and simply call into the clockevents code unconditonally. The ARAT feature is marked in the lapic clockevent already so the core code will just ignore the requests and return. Signed-off-by: -
John Stultz authored
Ingo noted that the description of clocks_calc_max_nsecs()'s 50% safety margin was somewhat circular. So this patch tries to improve the comment to better explain what we mean by the 50% safety margin and why we need it. Signed-off-by:
John Stultz <john.stultz@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1427945681-29972-20-git-send-email-john.stultz@linaro.orgSigned-off-by:
-
Xunlei Pang authored
If a system does not provide a persistent_clock(), the time will be updated on resume by rtc_resume(). With the addition of the non-stop clocksources for suspend timing, those systems set the time on resume in timekeeping_resume(), but may not provide a valid persistent_clock(). This results in the rtc_resume() logic thinking no one has set the time and it then will over-write the suspend time again, which is not necessary and only increases clock error. So, fix this for rtc_resume(). This patch also improves the name of persistent_clock_exist to make it more grammatical. Signed-off-by:
Xunlei Pang <pang.xunlei@linaro.org> Signed-off-by:
-
Xunlei Pang authored
When there's no persistent clock, normally timekeeping_suspend_time should always be zero, but this can break in timekeeping_suspend(). At T1, there was a system suspend, so old_delta was assigned T1. After some time, one time adjustment happened, and xtime got the value of T1-dt(0s<dt<2s). Then, there comes another system suspend soon after this adjustment, obviously we will get a small negative delta_delta, resulting in a negative timekeeping_suspend_time. This is problematic, when doing timekeeping_resume() if there is no nonstop clocksource for example, it will hit the else leg and inject the improper sleeptime which is the wrong logic. So, we can solve this problem by only doing delta related code when the persistent clock is existent. Actually the code only makes sense for persistent clock cases. Signed-off-by:
-
Xunlei Pang authored
rtc_read_time() has already judged valid tm by rtc_valid_tm(), so just remove it. Signed-off-by:
-
Xunlei Pang authored
timekeeping_inject_sleeptime64() is only used by RTC suspend/resume, so add build dependencies on the necessary RTC related macros. Signed-off-by:
-
Xunlei Pang authored
Change alpha_rtc_set_mmss() and remote_set_mmss() to use rtc_class_ops's set_mmss64(), to be y2038 safe. Signed-off-by:
Alessandro Zummo <a.zummo@towertech.it> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Richard Henderson <rth@twiddle.net> Link: http://lkml.kernel.org/r/1427945681-29972-15-git-send-email-john.stultz@linaro.orgSigned-off-by:
-
Xunlei Pang authored
This driver has a number of y2038/y2106 issues. This patch resolves them by: - Replacing rtc_time_to_tm() with rtc_time64_to_tm() - Replacing rtc_tm_to_time() with rtc_tm_to_time64() - Changing mxc_rtc_set_mmss() to use rtc_class_ops's set_mmss64() After this patch, the driver should not have any remaining y2038/y2106 issues. Signed-off-by:
-
Xunlei Pang authored
We want to convert mxc_rtc_set_mmss() to use rtc_class_ops's set_mmss64(), but it uses get_alarm_or_time()/set_alarm_or_time() internal interfaces which are y2038 unsafe. So here as a separate patch, it converts these two internal interfaces of "mxc" to use safe time64_t to make some preparations. Signed-off-by:
-
Xunlei Pang authored
rtc_class_ops's set_alarm() shouldn't deal with the alarm date, as this is handled in the rtc core. See rtc_dev_ioctl()'s RTC_ALM_SET and RTC_WKALM_SET cases. Signed-off-by:
-
Xunlei Pang authored
This driver has a number of y2038/y2106 issues. This patch resolves them by: - Replacing rtc_time_to_tm() with rtc_time64_to_tm() - Changing mc13xxx_rtc_set_mmss() to use rtc_class_ops's set_mmss64() After this patch, the driver should not have any remaining y2038/y2106 issues. Signed-off-by:
-
Xunlei Pang authored
This driver has a number of y2038/y2106 issues. This patch resolves them by: - Replacing rtc_tm_to_time() with rtc_tm_to_time64() - Replacing rtc_time_to_tm() with rtc_time64_to_tm() - Changing ab3100_rtc_set_mmss() to use rtc_class_ops's set_mmss64() After this patch, the driver should not have any remaining y2038/y2106 issues. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1427945681-29972-10-git-send-email-john.stultz@linaro.orgSigned-off-by:
-
Xunlei Pang authored
This driver has a number of y2038/y2106 issues. This patch resolves them by: - Replacing get_seconds() with ktime_get_real_seconds() - Replacing rtc_time_to_tm() with rtc_time64_to_tm() Also add test_rtc_set_mmss64() for testing rtc_class_ops's set_mmss64(), which can be activated by "test_mmss64" module parameter. Signed-off-by:
-
Xunlei Pang authored
Currently the rtc_class_op's set_mmss() function takes a 32-bit second value (on 32-bit systems), which is problematic for dates past y2038. This patch provides a safe version named set_mmss64() using y2038 safe time64_t. After this patch, set_mmss() is deprecated and all its users will be fixed to use set_mmss64(), it can be removed when having no users. Signed-off-by:
-
Xunlei Pang authored
As part of addressing "y2038 problem" for in-kernel uses, this patch converts read_boot_clock() to read_boot_clock64() and read_persistent_clock() to read_persistent_clock64() using timespec64 by converting clock_access_fn to use timespec64. Signed-off-by:
-
Xunlei Pang authored
As part of addressing "y2038 problem" for in-kernel uses, this patch adds the y2038-safe tegra_read_persistent_clock64() using timespec64. Because we rely on some subsequent changes to convert arm multiarch support, tegra_read_persistent_clock() will be removed then. Signed-off-by:
Thierry Reding <treding@nvidia.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1427945681-29972-6-git-send-email-john.stultz@linaro.orgSigned-off-by:
-
Xunlei Pang authored
As part of addressing "y2038 problem" for in-kernel uses, this patch adds the y2038-safe omap_read_persistent_clock64() using timespec64. Because we rely on some subsequent changes to convert arm multiarch support, omap_read_persistent_clock() will be removed then. Also remove the needless spinlock, because read_persistent_clock() doesn't run simultaneously. Signed-off-by:
Tony Lindgren <tony@atomide.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1427945681-29972-5-git-send-email-john.stultz@linaro.orgSigned-off-by:
-
Xunlei Pang authored
As part of addressing in-kernel y2038 issues, this patch adds update_persistent_clock64() and replaces all the call sites of update_persistent_clock() with this function. This is a __weak implementation, which simply calls the existing y2038 unsafe update_persistent_clock(). This allows architecture specific implementations to be converted independently, and eventually y2038-unsafe update_persistent_clock() can be removed after all its architecture specific implementations have been converted to update_persistent_clock64(). Suggested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Xunlei Pang authored
As part of addressing in-kernel y2038 issues, this patch adds read_persistent_clock64() and replaces all the call sites of read_persistent_clock() with this function. This is a __weak implementation, which simply calls the existing y2038 unsafe read_persistent_clock(). This allows architecture specific implementations to be converted independently, and eventually the y2038 unsafe read_persistent_clock() can be removed after all its architecture specific implementations have been converted to read_persistent_clock64(). Suggested-by:
-
Xunlei Pang authored
As part of addressing in-kernel y2038 issues, this patch adds read_boot_clock64() and replaces all the call sites of read_boot_clock() with this function. This is a __weak implementation, which simply calls the existing y2038 unsafe read_boot_clock(). This allows architecture specific implementations to be converted independently, and eventually the y2038 unsafe read_boot_clock() can be removed after all its architecture specific implementations have been converted to read_boot_clock64(). Suggested-by:
-
- 02 Apr, 2015 6 commits
-
-
Peter Zijlstra authored
Remove one CONFIG_HOTPLUG_CPU #ifdef in trade for introducing one CONFIG_SMP #ifdef. The CONFIG_SMP ifdef avoids declaring the per-CPU __tvec_bases storage on UP systems since they already have boot_tvec_bases. Also (re)add a runtime check on the base alignment -- for the paranoid amongst us :-) Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/fdd2d35e169bdc554ffa3fe77f77716298c75ada.1427814611.git.viresh.kumar@linaro.orgSigned-off-by:
-
Viresh Kumar authored
There is no need to call init_timers_cpu() on every CPU hotplug event, there is not much we need to reset. - Timer-lists are already empty at the end of migrate_timers(). - timer_jiffies will be refreshed while adding a new timer, after the CPU is online again. - active_timers and all_timers can be reset from migrate_timers(). Signed-off-by:
-
Peter Zijlstra authored
Memory for the 'tvec_base' array is allocated separately for the boot CPU (statically) and non-boot CPUs (dynamically). The reason is because __TIMER_INITIALIZER() needs to set ->base to a valid pointer (because we've made NULL special, hint: lock_timer_base()) and we cannot get a compile time pointer to per-cpu entries because we don't know where we'll map the section, even for the boot cpu. This can be simplified a bit by statically allocating per-cpu memory. The only disadvantage is that memory for one of the structures will stay unused, i.e. for the boot CPU, which uses boot_tvec_bases. This will also guarantee that tvec_base is cacheline aligned. Even though tvec_base has ____cacheline_aligned stuck on, kzalloc_node() does not actually respect that (but guarantees a minimum u64 alignment). Signed-off-by:
-
Preeti U Murthy authored
It was found when doing a hotplug stress test on POWER, that the machine either hit softlockups or rcu_sched stall warnings. The issue was traced to commit: 7cba160a ("powernv/cpuidle: Redesign idle states management") which exposed the cpu_down() race with hrtimer based broadcast mode: 5d1638ac ("tick: Introduce hrtimer based broadcast") The race is the following: Assume CPU1 is the CPU which holds the hrtimer broadcasting duty before it is taken down. CPU0 CPU1 cpu_down() take_cpu_down() disable_interrupts() cpu_die() while (CPU1 != CPU_DEAD) { msleep(100); switch_to_idle(); stop_cpu_timer(); schedule_broadcast(); } tick_cleanup_cpu_dead() take_over_broadcast() So after CPU1 disabled interrupts it cannot handle the broadcast hrtimer anymore, so CPU0 will be stuck forever. Fix this by explicitly taking over broadcast duty before cpu_die(). This is a temporary workaround. What we really want is a callback in the clockevent device which allows us to do that from the dying CPU by pushing the hrtimer onto a different cpu. That might involve an IPI and is definitely more complex than this immediate fix. Changelog was picked up from: https://lkml.org/lkml/2015/2/16/213Suggested-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
Preeti U. Murthy <preeti@linux.vnet.ibm.com> Cc: linuxppc-dev@lists.ozlabs.org Cc: mpe@ellerman.id.au Cc: nicolas.pitre@linaro.org Cc: peterz@infradead.org Cc: rjw@rjwysocki.net Fixes: http://linuxppc.10917.n7.nabble.com/offlining-cpus-breakage-td88619.html Link: http://lkml.kernel.org/r/20150330092410.24979.59887.stgit@preeti.in.ibm.com [ Merged it to the latest timer tree, renamed the callback, tidied up the changelog. ] Signed-off-by:
-
Ingo Molnar authored
Do various cleanups on the clockchips.h file: - indent preprocessor blocks to make it more clear which block we are in, this also makes merge resolution easier - comment larger preprocessor blocks consistently, using the: #if FOO ... #else /* !FOO: */ ... #endif /* !FOO */ notation. - unbreak lines - etc. No change in functionality. Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: -
Ingo Molnar authored
Move the broadcasting related section to the GENERIC_CLOCKEVENTS=y section - this also solves build failures on architectures that don't use generic clockevents yet. Also standardize include file style to make it easier to read, and use nesting depth aware preprocessor directives to make future merges easier. Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
- 01 Apr, 2015 6 commits
-
-
Thomas Gleixner authored
Use the new tick_suspend/resume_local() and get rid of the homebrewn implementation of these in the ARM bL switcher. The check for the cpumask is completely pointless. There is no harm to suspend a per cpu tick device unconditionally. If that's a real issue then we fix it proper at the core level and not with some completely undocumented hacks in some random core code. Move the tick internals to the core code, now that this nuisance is gone. Signed-off-by:
-
Thomas Gleixner authored
Xen calls on every cpu into tick_resume() which is just wrong. tick_resume() is for the syscore global suspend/resume invocation. What XEN really wants is a per cpu local resume function. Provide a tick_resume_local() function and use it in XEN. Also provide a complementary tick_suspend_local() and modify tick_unfreeze() and tick_freeze(), respectively, to use the new local tick resume/suspend functions. Signed-off-by:
-
Thomas Gleixner authored
Solely used in tick-broadcast.c and the return value is hardcoded 0. Make it static and void. Signed-off-by:
-
Thomas Gleixner authored
clockevents_notify() is a leftover from the early design of the clockevents facility. It's really not a notification mechanism, it's a multiplex call. We are way better off to have explicit calls instead of this monstrosity. Split out the suspend/resume() calls and invoke them directly from the call sites. No locking required at this point because these calls happen with interrupts disabled and a single cpu online. Signed-off-by:
-
Thomas Gleixner authored
Called with 'clockevents_lock' held and interrupts disabled already. Signed-off-by:
-
Thomas Gleixner authored
No point to expose everything to the world. People just believe such functions can be abused for whatever purposes. Sigh. Signed-off-by:
-
