- 19 Mar, 2020 3 commits
-
-
Thomas Gleixner authored
This reverts commit d441dceb due to boot failures. Reported-by:
Qian Cai <cai@lca.pw> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Waiman Long <longman@redhat.com>
-
Ahmed S. Darwish authored
To minimize latency, PREEMPT_RT kernels expires hrtimers in preemptible softirq context by default. This can be overriden by marking the timer's expiry with HRTIMER_MODE_HARD. sched_clock_timer is missing this annotation: if its callback is preempted and the duration of the preemption exceeds the wrap around time of the underlying clocksource, sched clock will get out of sync. Mark the sched_clock_timer for expiry in hard interrupt context. Signed-off-by:
Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by:
-
https://git.linaro.org/people/daniel.lezcano/linuxThomas Gleixner authored
Pull clockevent/clocksource updates from Daniel Lezcano: - Avoid creating dead devices by flagging the driver with OF_POPULATED in order to prevent the platform to create another device (Saravana Kannan) - Remove unused includes from imx family drivers (Anson Huang) - timer-dm-ti rework to prepare for pwm and suspend support (Lokesh Vutla) - Fix the rate for the global clock on the pit64b (Claudiu Beznea) - Fix timer-cs5535 by requesting an irq with non-NULL dev_id (Afzal Mohammed) - Replace setup_irq() by request_irq() (Afzal Mohammed) - Add support for the TCU of X1000 (Zhou Yanjie) - Drop the bogus omap_dm_timer_of_set_source() function (Suman Anna) - Do not update the counter when updating the period in order to prevent a disruption when the pwm is used (Lokesh Vutla) - Improve owl_timer_init() failure messages (Matheus Castello) - Add driver for the Ingenic JZ47xx OST (Maarten ter Huurne) - Pass the interrupt and the shutdown callbacks in the init function for ast2600 support (Joel Stanley) - Add the ast2600 compatible string for the fttmr010 (Joel Stanley)
-
- 17 Mar, 2020 3 commits
-
-
Saravana Kannan authored
Timer initialization is done during early boot way before the driver core starts processing devices and drivers. Timers initialized during this early boot period don't really need or use a struct device. However, for timers represented as device tree nodes, the struct devices are still created and sit around unused and wasting memory. This change avoid this by marking the device tree nodes as "populated" if the corresponding timer is successfully initialized. Signed-off-by:
Saravana Kannan <saravanak@google.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200111052125.238212-1-saravanak@google.com
-
Anson Huang authored
There is nothing in use from of_address.h/of_irq.h, remove them. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Signed-off-by:
-
Anson Huang authored
There is nothing in use from of_address.h/of_irq.h, remove them. Signed-off-by:
-
- 16 Mar, 2020 8 commits
-
-
Daniel Lezcano authored
-
Lokesh Vutla authored
dm timer ops set_load() api allows to configure the load value and to set the auto reload feature. But auto reload feature is independent of load value and should be part of configuring pwm. This way pwm can be disabled by disabling auto reload feature using set_pwm() so that the current pwm cycle will be completed. Else pwm disabling causes the cycle to be stopped abruptly. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Lokesh Vutla authored
omap_dm_timer_ops provide support to configure the pwm but there is no support to get the current status. For configuring pwm it is advised to check the current hw status instead of relying on pwm framework. So implement a new timer ops to get the current status of pwm. Signed-off-by:
-
Lokesh Vutla authored
Write to trigger register(OMAP_TIMER_TRIGGER_REG) will load the value in Load register(OMAP_TIMER_LOAD_REG) into Counter register (OMAP_TIMER_COUNTER_REG). omap_dm_timer_set_load() writes into trigger register every time load register is updated. When timer is configured in pwm mode, this causes disruption in current pwm cycle, which is not expected especially when pwm is used as PPS signal for synchronized PTP clocks. So do not write into trigger register on updating the period. Tested-by:
-
Lokesh Vutla authored
omap_dm_timer_enable() restores the entire context(including counter) based on 2 conditions: - If get_context_loss_count is populated and context is lost. - If get_context_loss_count is not populated update unconditionally. Case2 has a side effect of updating the counter register even though context is not lost. When timer is configured in pwm mode, this is causing undesired behaviour in the pwm period. Instead of using get_context_loss_count call back, implement cpu_pm notifier with context save and restore support. And delete the get_context_loss_count callback all together. Suggested-by:
-
Tony Lindgren authored
Let's add runtime_suspend and resume functions and atomic enabled flag. This way we can use these when converting to use cpuidle for saving and restoring device context. And we need to maintain the driver state in the driver as documented in "9. Autosuspend, or automatically-delayed suspends" in the Documentation/power/runtime_pm.rst document related to using driver private lock and races with runtime_suspend(). Signed-off-by:
-
Lokesh Vutla authored
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by:
-
Claudiu Beznea authored
Generic clock rate needs to be set in case it was selected as timer clock source in mchp_pit64b_init_mode(). Otherwise it will be enabled with wrong rate. Fixes: 625022a5 ("clocksource/drivers/timer-microchip-pit64b: Add Microchip PIT64B support") Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by:
-
- 12 Mar, 2020 1 commit
-
-
afzal mohammed authored
Recently all usages of setup_irq() was replaced by request_irq(). request_irq() does a few sanity checks that were not done in setup_irq(), if they fail irq registration will fail. One of the check is to ensure that non-NULL dev_id is passed in the case of shared irq. Fix it by passing non-NULL dev_id while registering the shared irq. Fixes: cc2550b4 ("clocksource: Replace setup_irq() by request_irq()") Signed-off-by:
afzal mohammed <afzal.mohd.ma@gmail.com> Signed-off-by:
-
- 04 Mar, 2020 5 commits
-
-
Waiman Long authored
The tick_periodic() function is used at the beginning part of the bootup process for time keeping while the other clock sources are being initialized. The current code assumes that all the timer interrupts are handled in a timely manner with no missing ticks. That is not actually true. Some ticks are missed and there are some discrepancies between the tick time (jiffies) and the timestamp reported in the kernel log. Some systems, however, are more prone to missing ticks than the others. In the extreme case, the discrepancy can actually cause a soft lockup message to be printed by the watchdog kthread. For example, on a Cavium ThunderX2 Sabre arm64 system: [ 25.496379] watchdog: BUG: soft lockup - CPU#14 stuck for 22s! On that system, the missing ticks are especially prevalent during the smp_init() phase of the boot process. With an instrumented kernel, it was found that it took about 24s as reported by the timestamp for the tick to accumulate 4s of time. Investigation and bisection done by others seemed to point to the commit 73f38166 ("arm64: Advertise mitigation of Spectre-v2, or lack thereof") as the culprit. It could also be a firmware issue as new firmware was promised that would fix the issue. To properly address this problem, stop assuming that there will be no missing tick in tick_periodic(). Modify it to follow the example of tick_do_update_jiffies64() by using another reference clock to check for missing ticks. Since the watchdog timer uses running_clock(), it is used here as the reference. With this applied, the soft lockup problem in the affected arm64 system is gone and tick time tracks much more closely to the timestamp time. Signed-off-by:
Waiman Long <longman@redhat.com> Signed-off-by:
-
Wen Yang authored
do_div() does a 64-by-32 division at least on 32bit platforms, while the divisor 'div' is explicitly casted to unsigned long, thus 64-bit on 64-bit platforms. The code already ensures that the divisor is less than 2^32. Hence the proper cast type is u32. Signed-off-by:
Wen Yang <wenyang@linux.alibaba.com> Signed-off-by:
-
Wen Yang authored
While unlikely the divisor in scale64_check_overflow() could be >= 32bit in scale64_check_overflow(). do_div() truncates the divisor to 32bit at least on 32bit platforms. Use div64_u64() instead to avoid the truncation to 32-bit. [ tglx: Massaged changelog ] Signed-off-by:
-
Eric W. Biederman authored
The reasons why the extra posix_cpu_timers_exit_group() invocation has been added are not entirely clear from the commit message. Today all that posix_cpu_timers_exit_group() does is stop timers that are tracking the task from firing. Every other operation on those timers is still allowed. The practical implication of this is posix_cpu_timer_del() which could not get the siglock after the thread group leader has exited (because sighand == NULL) would be able to run successfully because the timer was already dequeued. With that locking issue fixed there is no point in disabling all of the timers. So remove this ``tempoary'' hack. Fixes: e0a70217 ("posix-cpu-timers: workaround to suppress the problems with mt exec") Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Eric W. Biederman authored
posix cpu timers do not handle the death of a process well. This is most clearly seen when a multi-threaded process calls exec from a thread that is not the leader of the thread group. The posix cpu timer code continues to pin the old thread group leader and is unable to find the siglock from there. This results in posix_cpu_timer_del being unable to delete a timer, posix_cpu_timer_set being unable to set a timer. Further to compensate for the problems in posix_cpu_timer_del on a multi-threaded exec all timers that point at the multi-threaded task are stopped. The code for the timers fundamentally needs to check if the target process/thread is alive. This needs an extra level of indirection. This level of indirection is already available in struct pid. So replace cpu.task with cpu.pid to get the needed extra layer of indirection. In addition to handling things more cleanly this reduces the amount of memory a timer can pin when a process exits and then is reaped from a task_struct to the vastly smaller struct pid. Fixes: e0a70217 ("posix-cpu-timers: workaround to suppress the problems with mt exec") Signed-off-by:
-
- 01 Mar, 2020 3 commits
-
-
Eric W. Biederman authored
The task has been already computed to take siglock before calling arm_timer. So pass the benefit of that labor into arm_timer(). Signed-off-by:
-
Eric W. Biederman authored
As of e78c3496 ("time, signal: Protect resource use statistics with seqlock") cpu_clock_sample_group no longers needs siglock protection. Unfortunately no one realized it at the time. Remove the extra locking that is for cpu_clock_sample_group and not for cpu_clock_sample. This significantly simplifies the code. Signed-off-by:
-
Eric W. Biederman authored
As of e78c3496 ("time, signal: Protect resource use statistics with seqlock") cpu_clock_sample_group() no longer needs siglock protection so remove the stale comment. Signed-off-by:
-
- 27 Feb, 2020 7 commits
-
-
afzal mohammed authored
request_irq() is preferred over setup_irq(). The early boot setup_irq() invocations happen either via 'init_IRQ()' or 'time_init()', while memory allocators are ready by 'mm_init()'. Per tglx[1], setup_irq() existed in olden days when allocators were not ready by the time early interrupts were initialized. Hence replace setup_irq() by request_irq(). Seldom remove_irq() usage has been observed coupled with setup_irq(), wherever that has been found, it too has been replaced by free_irq(). A build error that was reported by kbuild test robot <lkp@intel.com> in the previous version of the patch also has been fixed. [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanosSigned-off-by:
-
周琰杰 (Zhou Yanjie) authored
X1000 has a different TCU containing OST, since X1000, OST has been independent of TCU. This patch is prepare for later OST driver. Signed-off-by:
周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> Signed-off-by:
-
周琰杰 (Zhou Yanjie) authored
Add the timer bindings for the X1000 Soc from Ingenic. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Suman Anna authored
The function omap_dm_timer_of_set_source() was originally added in commit 31a7448f ("ARM: OMAP: dmtimer: Add clock source from DT"), and is designed to set a clock source from DT using the clocks property of a timer node. This design choice is okay for clk provider nodes but otherwise is a bad design as typically the clocks property is used to specify the functional clocks for a device, and not its parents. The timer nodes now all define a timer functional clock after the conversion to ti-sysc and the new clkctrl layout, and this results in an attempt to set the same functional clock as its parent when a consumer driver attempts to acquire any of these timers in the omap_dm_timer_prepare() function. This was masked and worked around in commit 983a5a43 ("clocksource: timer-ti-dm: Fix pwm dmtimer usage of fck reparenting"). Fix all of this by simply dropping the entire function. Any DT configuration of clock sources should be achieved using assigned-clocks and assigned-clock-parents properties provided by the Common Clock Framework. Cc: Tony Lindgren <tony@atomide.com> Cc: Tero Kristo <t-kristo@ti.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: H. Nikolaus Schaller <hns@goldelico.com> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by:
Suman Anna <s-anna@ti.com> Tested-by:
-
Lokesh Vutla authored
Write to trigger register(OMAP_TIMER_TRIGGER_REG) will load the value in Load register(OMAP_TIMER_LOAD_REG) into Counter register (OMAP_TIMER_COUNTER_REG). omap_dm_timer_set_load() writes into trigger register every time load register is updated. When timer is configured in pwm mode, this causes disruption in current pwm cycle, which is not expected especially when pwm is used as PPS signal for synchronized PTP clocks. So do not write into trigger register on updating the period. Signed-off-by:
-
Matheus Castello authored
Check the return from clocksource_mmio_init, add messages in case of an error and in case of not having a defined clock property. Signed-off-by:
Matheus Castello <matheus@castello.eng.br> Signed-off-by:
-
Maarten ter Huurne authored
OST is the OS Timer, a 64-bit timer/counter with buffered reading. SoCs before the JZ4770 had (if any) a 32-bit OST; the JZ4770 and JZ4780 have a 64-bit OST. This driver will register both a clocksource and a sched_clock to the system. Signed-off-by:
Maarten ter Huurne <maarten@treewalker.org> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Tested-by:
Mathieu Malaterre <malat@debian.org> Tested-by:
Artur Rojek <contact@artur-rojek.eu> Signed-off-by:
-
- 25 Feb, 2020 1 commit
-
-
Vincenzo Frascino authored
The arm_arch_timer requires VDSO_CLOCKMODE_ARCHTIMER to be defined to compile correctly. On ARM the vDSO can be disabled and when this is the case the compilation ends prematurely with an error: $ make ARCH=arm multi_v7_defconfig $ ./scripts/config -d VDSO $ make drivers/clocksource/arm_arch_timer.c:73:44: error: ‘VDSO_CLOCKMODE_ARCHTIMER’ undeclared here (not in a function) static enum vdso_clock_mode vdso_default = VDSO_CLOCKMODE_ARCHTIMER; Make the usage of VDSO_CLOCKMODE_ARCHTIMER depend on the VDSO enablement and initialize the vdso clockmode variable with VDSO_CLOCKMODE_NONE otherwise. [ tglx: Match changelog and patch content. ] Fixes: 5e3c6a31 ("ARM/arm64: vdso: Use common vdso clock mode storage") Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by:
-
- 21 Feb, 2020 3 commits
-
-
Joel Stanley authored
The ast2600 contains a fttmr010 derivative. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
-
Joel Stanley authored
In preparation for supporting the ast2600, pass the shutdown and interrupt functions to the common init callback. Reviewed-by:
Cédric Le Goater <clg@kaod.org> Reviewed-by:
-
Joel Stanley authored
In preparation for supporting the ast2600 which uses a different method to clear bits in the control register, use a callback for performing the shutdown sequence. Reviewed-by:
-
- 17 Feb, 2020 6 commits
-
-
Amol Grover authored
head is traversed using hlist_for_each_entry_rcu outside an RCU read-side critical section but under the protection of hash_lock. Hence, add corresponding lockdep expression to silence false-positive lockdep warnings, and harden RCU lists. [ tglx: Removed the macro and put the condition right where it's used ] Signed-off-by:
Amol Grover <frextrite@gmail.com> Signed-off-by:
-
Alexander Popov authored
When working commit 6dcd5d7a, a mistake was noticed by Linus: schedule_timeout() was called without setting the task state to anything particular. It calls the scheduler, but doesn't delay anything, because the task stays runnable. That happens because sched_submit_work() does nothing for tasks in TASK_RUNNING state. That turned out to be the intended behavior. Adding a WARN() is not useful as the task could be woken up right after setting the state and before reaching schedule_timeout(). Improve the comment about schedule_timeout() and describe that more explicitly. Signed-off-by:
Alexander Popov <alex.popov@linux.com> Signed-off-by:
-
Christophe Leroy authored
On powerpc, __arch_get_vdso_data() clobbers the link register, requiring the caller to save it. As the parent function already has to set a stack frame and saves the link register before calling the C vdso function, retrieving the vdso data pointer there is less overhead. Split out the functional code from the __cvdso.*() interfaces into new static functions which can either be called from the existing interfaces with the vdso data pointer supplied via __arch_get_vdso_data() or directly from ASM code. Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
-
Christophe Leroy authored
On powerpc/32, GCC (8.1) generates pretty bad code for the ns >>= vd->shift operation taking into account that the shift is always <= 32 and the upper part of the result is likely to be zero. GCC makes reversed assumptions considering the shift to be likely >= 32 and the upper part to be like not zero. unsigned long long shift(unsigned long long x, unsigned char s) { return x >> s; } results in: 00000018 <shift>: 18: 35 25 ff e0 addic. r9,r5,-32 1c: 41 80 00 10 blt 2c <shift+0x14> 20: 7c 64 4c 30 srw r4,r3,r9 24: 38 60 00 00 li r3,0 28: 4e 80 00 20 blr 2c: 54 69 08 3c rlwinm r9,r3,1,0,30 30: 21 45 00 1f subfic r10,r5,31 34: 7c 84 2c 30 srw r4,r4,r5 38: 7d 29 50 30 slw r9,r9,r10 3c: 7c 63 2c 30 srw r3,r3,r5 40: 7d 24 23 78 or r4,r9,r4 44: 4e 80 00 20 blr Even when forcing the shift to be smaller than 32 with an &= 31, it still considers the shift as likely >= 32. Move the default shift implementation into an inline which can be redefined in architecture code via a macro. [ tglx: Made the shift argument u32 and removed the __arch prefix ] Signed-off-by: -
Christophe Leroy authored
Some architectures have a fixed clocksource which is known at compile time and cannot be replaced or disabled at runtime, e.g. timebase on PowerPC. For such cases the clock mode check in the VDSO code is pointless. Move the check for a VDSO capable clocksource into an inline function and allow architectures to redefine it via a macro. [ tglx: Removed the #ifdef mess ] Signed-off-by:
-
Thomas Gleixner authored
Move the time namespace indicator clock mode to the other ones for consistency sake. Signed-off-by:
-
