- 03 Apr, 2015 16 commits
-
-
Xunlei Pang authored
rtc_read_time() has already judged valid tm by rtc_valid_tm(), so just remove it. Signed-off-by:
Xunlei Pang <pang.xunlei@linaro.org> Signed-off-by:
John Stultz <john.stultz@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1427945681-29972-17-git-send-email-john.stultz@linaro.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
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:
Thomas Gleixner <tglx@linutronix.de> Tested-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 9 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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Link: http://lkml.kernel.org/r/1655112.Ws17YsMfN7@vostro.rjw.lanSigned-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:
-
Thomas Gleixner authored
tick-internal.h is pretty confusing as a lot of the stub inlines are there several times. Distangle the maze and make clear functional sections. Signed-off-by:
-
Thomas Gleixner authored
Move clocksource related stuff to timekeeping.h and remove the pointless include from ntp.c Signed-off-by:
-
Thomas Gleixner authored
This option was for simpler migration to the clock events code. Most architectures have been converted and the option has been disfunctional as a standalone option for quite some time. Remove it. Signed-off-by:
-
- 31 Mar, 2015 9 commits
-
-
Maxime Ripard authored
The parent clock of the sun5i timer is the AHB clock, which rate might change because of other devices requirements. This is for example the case on the Allwinner A31, where the DMA controller needs a minimum rate higher than the default, that is enforced after the timer driver has probed. Add clock notifiers to make sure we reflect the clock rate changes in the timer rates. Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1427796746-373-5-git-send-email-daniel.lezcano@linaro.orgSigned-off-by:
-
Maxime Ripard authored
Refactor the code in order to remove the global variables and split the clock source and clock events registration in order to ease the addition of the clock notifiers needed to handle the parent clock rate changes. Signed-off-by:
-
Maxime Ripard authored
of_iomap doesn't do a request_mem_region() on the memory area defined in the DT it maps. Switch to of_io_request_and_map() to make sure we're the only users. Signed-off-by:
-
Maxime Ripard authored
The current code uses setup_irq(), while it could perfectly use the much simpler request_irq(). Switch to that. Signed-off-by:
-
Laurent Pinchart authored
clocksource/drivers/arm_arch_timer: Rename 'arch_timer_probed()' to 'arch_timer_needs_probing()' to reflect behaviour The arch_timer_probed() function returns whether the given time doesn't need to be probed. This can be the case when the timer has been probed already, but also when it has no corresponding enabled node in DT. Rename the function to arch_timer_needs_probing() and invert its return value to better reflect the function's purpose and behaviour. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1427796746-373-1-git-send-email-daniel.lezcano@linaro.orgSigned-off-by:
-
Ben Dooks authored
Fix the use of __raw IO accessor with the readl/writel_relaxed() versions to allow the code to be used on a system running in big endian mode. Signed-off-by:
Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Andrew Victor <linux@maxim.org.za> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Linux ARM Kernel <linux-arm-kernel@lists.infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: digetx@gmail.com Cc: hdegoede@redhat.com Cc: laurent.pinchart+renesas@ideasonboard.com Cc: maxime.ripard@free-electrons.com Cc: viresh.kumar@linaro.org Link: http://lkml.kernel.org/r/1427746633-9137-7-git-send-email-daniel.lezcano@linaro.orgSigned-off-by:
-
Hans de Goede authored
sun6i and newer have an arm arch timer which is a better sched_clock source then the sun4i-timer, and sched_clock does not have priorities, so do not register the sun4i-timer sched_clock at all on sun6i and newer. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Dmitry Osipenko authored
Support big-endian kernel by using endian-aware register access functions. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
-
Ben Dooks authored
The dw_apb_timer_of timer is using __raw_readl() to access the timer register, which is causing issues when the system is running in big endian mode. Fix this by using readl_relaxed() which should account for the endian settings. This fixes issues where the time jumps around in the dmesg output due to returnling __le32 values. For an example, these two console lines show time running backwards: [ 49.882572] CPU1: failed to come online [ 43.282457] Brought up 1 CPUs Signed-off-by:
-
