- 11 Mar, 2014 15 commits
-
-
Soren Brinkmann authored
The timer frequency of the arm_global_timer depends on the CPU frequency. With cpufreq altering that frequency the arm_global_timer does not maintain a stable time base. Therefore don't enable that timer in case cpufreq is enabled. Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by:
Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by:
Michal Simek <michal.simek@xilinx.com>
-
Soren Brinkmann authored
The currently used method adjusting the clocksource to a changing input frequency does not work on kernels from 3.11 on. The new approach is to keep the timer frequency as constant as possible. I.e. - due to the TTC's prescaler limitations, allow frequency changes only if the frequency scales by a power of 2 - adjust the counter's divider on the fly when a frequency change occurs This limits cpufreq to scale by certain factors only. But we may keep the time base somewhat constant, so that sleep() & co keep working as expected, while supporting cpufreq. Signed-off-by:
-
Soren Brinkmann authored
The timer core takes care of serialization and IRQs. Hence the driver is no longer required to disable interrupts when calling clockevents_update_freq(). Signed-off-by:
-
Magnus Damm authored
Add Kconfig entries for CMT, MTU2, TMU and STI to drivers/clocksource/Kconfig. This will allow us to get rid of duplicated entires in architecture code such as arch/sh and arch/arm/mach-shmobile. Signed-off-by:
Magnus Damm <damm@opensource.se> Signed-off-by:
Wolfram Sang <wsa@sang-engineering.com> Signed-off-by:
-
Magnus Damm authored
Now when drivers/clocksource/Kconfig has been updated with entires for CMT, TMU and MTU2 it is safe to remove these from SH. Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Magnus Damm authored
Now when drivers/clocksource/Kconfig has been updated with entires for CMT, TMU, MTU2, and STI it is safe to remove these from mach-shmobile. Also select timers per SoC via SYS_SUPPORTS_xxx. Signed-off-by:
-
Ezequiel Garcia authored
Replace the driver-specific thread-safe shared register API by the recently introduced atomic_io_clear_set(). Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by:
-
Ezequiel Garcia authored
Replace the driver-specific thread-safe shared register API by the recently introduced atomic_io_clear_set(). Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Tested-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by:
Willy Tarreau <w@1wt.eu> Acked-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Matthias Brugger authored
Commit 438e0bff5257 added the timer-keystone device driver but make use of an unnecessary variable in the init function. This patch deletes this variable. Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
-
Ivan Khoronzhuk authored
Add broadcast clock-event device for the Keystone arch. The timer can be configured as a general-purpose 64-bit timer, dual general-purpose 32-bit timers. When configured as dual 32-bit timers, each half can operate in conjunction (chain mode) or independently (unchained mode) of each other. Reviewed-by:
Stephen Boyd <sboyd@codeaurora.org> Acked-by:
Santosh shilimkar <santosh.shilimkar@ti.com> Signed-off-by:
Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> Signed-off-by:
-
Ivan Khoronzhuk authored
This patch provides bindings for the 64-bit timer in the KeyStone architecture devices. The timer can be configured as a general-purpose 64-bit timer, dual general-purpose 32-bit timers. When configured as dual 32-bit timers, each half can operate in conjunction (chain mode) or independently (unchained mode) of each other. It is global timer is a free running up-counter and can generate interrupt when the counter reaches preset counter values. Documentation: http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdfAcked-by:
Rob Herring <robh@kernel.org> Acked-by:
-
Maxime Ripard authored
Switch the device tree to the new compatibles introduced in the timer driver to have a common pattern accross all Allwinner SoCs. Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Maxime Ripard authored
The Allwinner A10 compatibles were following a slightly different compatible patterns than the rest of the SoCs for historical reasons. Add compatibles matching the other pattern to the timer driver for consistency, and keep the older one for backward compatibility. Signed-off-by:
-
Linus Walleij authored
Move the U300 timer driver down to the clocksource driver subsystem and keep arch/arm clean. Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Stephen Boyd authored
Set the CLOCK_EVT_FEAT_DYNIRQ flag on the memory mapped clockevent so that we save power by waking up the CPU with the next event when this timer is used in broadcast mode. Signed-off-by:
-
- 10 Mar, 2014 1 commit
-
-
git://git.linaro.org/people/john.stultz/linuxThomas Gleixner authored
- support CLOCK_BOOTTIME clock in timerfd - Add missing header file Signed-off-by:Thomas Gleixner <tglx@linutronix.de>
-
- 04 Mar, 2014 2 commits
-
-
Viresh Kumar authored
Currently we are using two lowest bit of base for internal purpose and so they both should be zero in the allocated address. The code was doing the right thing before this patch came in: commit c5f66e99 (timer: Implement TIMER_IRQSAFE) Tejun probably forgot to update this piece of code which checks if the lowest 'n' bits are zero or not and so wasn't updated according to the new flag. Lets use TIMER_FLAG_MASK in the calculations here. [ tglx: Massaged changelog ] Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Cc: linaro-kernel@lists.linaro.org Cc: fweisbec@gmail.com Cc: tj@kernel.org Cc: peterz@infradead.org Link: http://lkml.kernel.org/r/9144e10d7e854a0aa8a673332adec356d81a923c.1393576981.git.viresh.kumar@linaro.orgSigned-off-by:
-
Viresh Kumar authored
timer_cpu_notify() should return NOTIFY_OK and nothing else. Anything else would trigger a BUG_ON(). Return value of this routine is already checked correctly but is done after issuing a call to init_timer_stats(). The right order would be to check the error case first and then call init_timer_stats(). Lets do it. Signed-off-by:
-
- 03 Mar, 2014 1 commit
-
-
Rashika Kheria authored
Include appropriate header file kernel/time/timekeeping_internal.h in kernel/time/timekeeping_debug.c because it has prototype declaration of function defined in kernel/time/timekeeping_debug.c. This eliminates the following warning in kernel/time/timekeeping_debug.c: kernel/time/timekeeping_debug.c:68:6: warning: no previous prototype for ‘tk_debug_account_sleep_time’ [-Wmissing-prototypes] Signed-off-by:
Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
-
- 28 Feb, 2014 1 commit
-
-
Thomas Gleixner authored
Merge branch 'timers.2014.02.25a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into timers/core Signed-off-by:
-
- 25 Feb, 2014 5 commits
-
-
Oleg Nesterov authored
The internal_add_timer() function updates base->next_timer only if timer->expires < base->next_timer. This is correct, but it also makes sense to do the same if we add the first non-deferrable timer. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Reviewed-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by:
Peter Zijlstra <peterz@infradead.org> Tested-by:
Mike Galbraith <bitbucket@online.de>
-
Paul E. McKenney authored
The __run_timers() function currently steps through the list one jiffy at a time in order to update the timer wheel. However, if the timer wheel is empty, no adjustment is needed other than updating ->timer_jiffies. Therefore, just before we add a timer to an empty timer wheel, we should mark the timer wheel as being up to date. This marking will reduce (and perhaps eliminate) the jiffy-stepping that a future __run_timers() call will need to do in response to some future timer posting or migration. This commit therefore updates ->timer_jiffies for this case. Signed-off-by:
-
Paul E. McKenney authored
The __run_timers() function currently steps through the list one jiffy at a time in order to update the timer wheel. However, if the timer wheel is empty, no adjustment is needed other than updating ->timer_jiffies. Therefore, if we just emptied the timer wheel, for example, by deleting the last timer, we should mark the timer wheel as being up to date. This marking will reduce (and perhaps eliminate) the jiffy-stepping that a future __run_timers() call will need to do in response to some future timer posting or migration. This commit therefore catches ->timer_jiffies for this case. Signed-off-by:
-
Paul E. McKenney authored
The __run_timers() function currently steps through the list one jiffy at a time in order to update the timer wheel. However, if the timer wheel is empty, no adjustment is needed other than updating ->timer_jiffies. In this case, which is likely to be common for NO_HZ_FULL kernels, the kernel currently incurs a large latency for no good reason. This commit therefore short-circuits this case. Signed-off-by:
-
Paul E. McKenney authored
Currently, the tvec_base structure's ->active_timers field tracks only the non-deferrable timers, which means that even if ->active_timers is zero, there might well be deferrable timers in the list. This commit therefore adds an ->all_timers field to track all the timers, whether deferrable or not. Signed-off-by:
-
- 14 Feb, 2014 2 commits
-
-
Paul Gortmaker authored
This bit of information is in the Kconfig help text: "Note the boot CPU will still be kept outside the range to handle the timekeeping duty." However neither the variable NO_HZ_FULL_ALL, or the prompt convey this important detail, so lets add it to the prompt to make it more explicitly obvious to the average user. Acked-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1391711781-7466-1-git-send-email-paul.gortmaker@windriver.comSigned-off-by:
Frederic Weisbecker <fweisbec@gmail.com>
-
Viresh Kumar authored
When a timer is enqueued or modified on a remote target, the latter is expected to see and handle this timer on its next tick. However if the target is idle and CONFIG_NO_HZ_IDLE=y, the CPU may be sleeping tickless and the timer may be ignored. wake_up_nohz_cpu() takes care of that by setting TIF_NEED_RESCHED and sending an IPI to idle targets so that the tick is reevaluated on the idle loop through the tick_nohz_idle_*() APIs. Now this is all performed regardless of the power properties of the timer. If the timer is deferrable, idle targets don't need to be woken up. Only the next buzy tick needs to care about it, and no IPI kick is needed for that to happen. So lets spare the IPI on idle targets when the timer is deferrable. Meanwhile we keep the current behaviour on full dynticks targets. We can spare IPIs on idle full dynticks targets as well but some tricky races against idle_cpu() must be dealt all along to make sure that the timer is well handled after idle exit. We can deal with that later since NO_HZ_FULL already has more important powersaving issues. Reported-by:
-
- 09 Feb, 2014 1 commit
-
-
Preeti U Murthy authored
The hrtimer mode of broadcast is supported only when GENERIC_CLOCKEVENTS_BROADCAST and TICK_ONESHOT config options are enabled. Hence compile in the functions for hrtimer mode of broadcast only when these options are selected. Also fix max_delta_ticks value for the pseudo clock device. Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Reported-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Preeti U Murthy <preeti@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/52F719EE.9010304@linux.vnet.ibm.comSigned-off-by:
-
- 07 Feb, 2014 7 commits
-
-
Thomas Gleixner authored
Make the stub function static inline instead of static and move the clockevents related function into the proper ifdeffed section. Reported-by:
-
Preeti U Murthy authored
On some architectures, in certain CPU deep idle states the local timers stop. An external clock device is used to wakeup these CPUs. The kernel support for the wakeup of these CPUs is provided by the tick broadcast framework by using the external clock device as the wakeup source. However not all implementations of architectures provide such an external clock device. This patch includes support in the broadcast framework to handle the wakeup of the CPUs in deep idle states on such systems by queuing a hrtimer on one of the CPUs, which is meant to handle the wakeup of CPUs in deep idle states. This patchset introduces a pseudo clock device which can be registered by the archs as tick_broadcast_device in the absence of a real external clock device. Once registered, the broadcast framework will work as is for these architectures as long as the archs take care of the BROADCAST_ENTER notification failing for one of the CPUs. This CPU is made the stand by CPU to handle wakeup of the CPUs in deep idle and it *must not enter deep idle states*. The CPU with the earliest wakeup is chosen to be this CPU. Hence this way the stand by CPU dynamically moves around and so does the hrtimer which is queued to trigger at the next earliest wakeup time. This is consistent with the case where an external clock device is present. The smp affinity of this clock device is set to the CPU with the earliest wakeup. This patchset handles the hotplug of the stand by CPU as well by moving the hrtimer on to the CPU handling the CPU_DEAD notification. Originally-from: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Preeti U Murthy authored
Some archs set the CPUIDLE_FLAG_TIMER_STOP flag for idle states in which the local timers stop. The cpuidle_idle_call() currently handles such idle states by calling into the broadcast framework so as to wakeup CPUs at their next wakeup event. With the hrtimer mode of broadcast, the BROADCAST_ENTER call into the broadcast frameowork can fail for archs that do not have an external clock device to handle wakeups and the CPU in question has thus to be made the stand by CPU. This patch handles such cases by failing the call into cpuidle so that the arch can take some default action. The arch will certainly not enter a similar idle state because a failed cpuidle call will also implicitly indicate that the broadcast framework has not registered this CPU to be woken up. Hence we are safe if we fail the cpuidle call. In the process move the functions that trace idle statistics just before and after the entry and exit into idle states respectively. In other scenarios where the call to cpuidle fails, we end up not tracing idle entry and exit since a decision on an idle state could not be taken. Similarly when the call to broadcast framework fails, we skip tracing idle statistics because we are in no further position to take a decision on an alternative idle state to enter into. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: linuxppc-dev@lists.ozlabs.org Link: http://lkml.kernel.org/r/20140207080652.17187.66344.stgit@preeti.in.ibm.comSigned-off-by:
-
Preeti U Murthy authored
The broadcast framework can potentially be made use of by archs which do not have an external clock device as well. Then, it is required that one of the CPUs need to handle the broadcasting of wakeup IPIs to the CPUs in deep idle. As a result its local timers should remain functional all the time. For such a CPU, the BROADCAST_ENTER notification has to fail indicating that its clock device cannot be shutdown. To make way for this support, change the return type of tick_broadcast_oneshot_control() and hence clockevents_notify() to indicate such scenarios. Signed-off-by:
-
Soren Brinkmann authored
clockevent devices in periodic mode are not updated when the frequency of the device changes. Issue a dev->set_mode() callback which forces the device to reevaluate the timer settings. Signed-off-by:
-
Thomas Gleixner authored
We can identify the broadcast device in the core and serialize all callers including interrupts on a different CPU against the update. Also, disabling interrupts is moved into the core allowing callers to leave interrutps enabled when calling clockevents_update_freq(). Signed-off-by:
-
Shaibal Dutta authored
For better use of CPU idle time, allow the scheduler to select the CPU on which the CMOS clock sync work would be scheduled. This improves idle residency time and conserver power. This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected. Signed-off-by:
Shaibal Dutta <shaibal.dutta@broadcom.com> [zoran.markovic@linaro.org: Added commit message. Aligned code.] Signed-off-by:
Zoran Markovic <zoran.markovic@linaro.org> Cc: John Stultz <john.stultz@linaro.org> Link: http://lkml.kernel.org/r/1391195904-12497-1-git-send-email-zoran.markovic@linaro.orgSigned-off-by:
-
- 03 Feb, 2014 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linuxLinus Torvalds authored
Pull parisc updates from Helge Deller: "The three major changes in this patchset is a implementation for flexible userspace memory maps, cache-flushing fixes (again), and a long-discussed ABI change to make EWOULDBLOCK the same value as EAGAIN. parisc has been the only platform where we had EWOULDBLOCK != EAGAIN to keep HP-UX compatibility. Since we will probably never implement full HP-UX support, we prefer to drop this compatibility to make it easier for us with Linux userspace programs which mostly never checked for both values. We don't expect major fall-outs because of this change, and if we face some, we will simply rebuild the necessary applications in the debian archives" * 'parisc-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: add flexible mmap memory layout support parisc: Make EWOULDBLOCK be equal to EAGAIN on parisc parisc: convert uapi/asm/stat.h to use native types only parisc: wire up sched_setattr and sched_getattr parisc: fix cache-flushing parisc/sti_console: prefer Linux fonts over built-in ROM fonts
-
Mikulas Patocka authored
HPFS needs to load 4 consecutive 512-byte sectors when accessing the directory nodes or bitmaps. We can't switch to 2048-byte block size because files are allocated in the units of 512-byte sectors. Previously, the driver would allocate a 2048-byte area using kmalloc, copy the data from four buffers to this area and eventually copy them back if they were modified. In the current implementation of the buffer cache, buffers are allocated in the pagecache. That means that 4 consecutive 512-byte buffers are stored in consecutive areas in the kernel address space. So, we don't need to allocate extra memory and copy the content of the buffers there. This patch optimizes the code to avoid copying the buffers. It checks if the four buffers are stored in contiguous memory - if they are not, it falls back to allocating a 2048-byte area and copying data there. Signed-off-by:
Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Mikulas Patocka authored
Previously, hpfs scanned all bitmaps each time the user asked for free space using statfs. This patch changes it so that hpfs scans the bitmaps only once, remembes the free space and on next invocation of statfs it returns the value instantly. New versions of wine are hammering on the statfs syscall very heavily, making some games unplayable when they're stored on hpfs, with load times in minutes. This should be backported to the stable kernels because it fixes user-visible problem (excessive level load times in wine). Signed-off-by:
-
- 02 Feb, 2014 1 commit
-
-
Helge Deller authored
Add support for the flexible mmap memory layout (as described in http://lwn.net/Articles/91829). This is especially very interesting on parisc since we currently only support 32bit userspace (even with a 64bit Linux kernel). Signed-off-by:
Helge Deller <deller@gmx.de>
-
