linux.git/drivers/clocksource, branch v3.12.61

clocksource/drivers/vt8500: Increase the minimum delta

2016-03-03T11:45:55+00:00

commit f9eccf24615672896dc13251410c3f2f33a14f95 upstream.

The vt8500 clocksource driver declares itself as capable to handle the
minimum delay of 4 cycles by passing the value into
clockevents_config_and_register(). The vt8500_timer_set_next_event()
requires the passed cycles value to be at least 16. The impact is that
userspace hangs in nanosleep() calls with small delay intervals.

This problem is reproducible in Linux 4.2 starting from:
c6eb3f70d448 ('hrtimer: Get rid of hrtimer softirq')

From Russell King, more detailed explanation:

"It's a speciality of the StrongARM/PXA hardware. It takes a certain
number of OSCR cycles for the value written to hit the compare registers.
So, if a very small delta is written (eg, the compare register is written
with a value of OSCR + 1), the OSCR will have incremented past this value
before it hits the underlying hardware. The result is, that you end up
waiting a very long time for the OSCR to wrap before the event fires.

So, we introduce a check in set_next_event() to detect this and return
-ETIME if the calculated delta is too small, which causes the generic
clockevents code to retry after adding the min_delta specified in
clockevents_config_and_register() to the current time value.

min_delta must be sufficient that we don't re-trip the -ETIME check - if
we do, we will return -ETIME, forward the next event time, try to set it,
return -ETIME again, and basically lock the system up. So, min_delta
must be larger than the check inside set_next_event(). A factor of two
was chosen to ensure that this situation would never occur.

The PXA code worked on PXA systems for years, and I'd suggest no one
changes this mechanism without access to a wide range of PXA systems,
otherwise they're risking breakage."

Cc: Russell King 
Acked-by: Alexey Charkov 
Signed-off-by: Roman Volkov 
Signed-off-by: Daniel Lezcano 
Signed-off-by: Jiri Slaby

clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier

2015-08-04T14:52:30+00:00

commit 56a94f13919c0db5958611b388e1581b4852f3c9 upstream.

Whilst testing cpu hotplug events on kernel configured with
DEBUG_PREEMPT and DEBUG_ATOMIC_SLEEP we get following BUG message,
caused by calling request_irq() and free_irq() in the context of
hotplug notification (which is in this case atomic context).

[   40.785859] CPU1: Software reset
[   40.786660] BUG: sleeping function called from invalid context at mm/slub.c:1241
[   40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
[   40.786678] Preemption disabled at:[<  (null)>]   (null)
[   40.786681]
[   40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc4-00024-g7dca860 #36
[   40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   40.786728] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[   40.786747] [] (show_stack) from [] (dump_stack+0x70/0xbc)
[   40.786767] [] (dump_stack) from [] (kmem_cache_alloc+0xd8/0x170)
[   40.786785] [] (kmem_cache_alloc) from [] (request_threaded_irq+0x64/0x128)
[   40.786804] [] (request_threaded_irq) from [] (exynos4_local_timer_setup+0xc0/0x13c)
[   40.786820] [] (exynos4_local_timer_setup) from [] (exynos4_mct_cpu_notify+0x30/0xa8)
[   40.786838] [] (exynos4_mct_cpu_notify) from [] (notifier_call_chain+0x44/0x84)
[   40.786857] [] (notifier_call_chain) from [] (__cpu_notify+0x28/0x44)
[   40.786873] [] (__cpu_notify) from [] (secondary_start_kernel+0xec/0x150)
[   40.786886] [] (secondary_start_kernel) from [<40008764>] (0x40008764)

Interrupts cannot be requested/freed in the CPU_STARTING/CPU_DYING
notifications which run on the hotplugged cpu with interrupts and
preemption disabled.

To avoid the issue, request the interrupts for all possible cpus in
the boot code. The interrupts are marked NO_AUTOENABLE to avoid a racy
request_irq/disable_irq() sequence. The flag prevents the
request_irq() code from enabling the interrupt immediately.

The interrupt is then enabled in the CPU_STARTING notifier of the
hotplugged cpu and again disabled with disable_irq_nosync() in the
CPU_DYING notifier.

[ tglx: Massaged changelog to match the patch ]

Fixes: 7114cd749a12 ("clocksource: exynos_mct: use (request/free)_irq calls for local timer registration")
Reported-by: Krzysztof Kozlowski 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Krzysztof Kozlowski 
Tested-by: Marcin Jabrzyk 
Signed-off-by: Damian Eppel 
Cc: m.szyprowski@samsung.com
Cc: kyungmin.park@samsung.com
Cc: daniel.lezcano@linaro.org
Cc: kgene@kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1435324984-7328-1-git-send-email-d.eppel@samsung.com
Signed-off-by: Thomas Gleixner 
Cc: 
Signed-off-by: Jiri Slaby

clocksource: exynos_mct: Fix bitmask regression for exynos4_mct_write

2015-01-29T14:45:03+00:00

commit 8c38d28ba8da98f7102c31d35359b4dbe9d1f329 upstream.

EXYNOS4_MCT_L_MASK is defined as 0xffffff00, so applying this bitmask
produces a number outside the range 0x00 to 0xff, which always results
in execution of the default switch statement.

Obviously this is wrong and git history shows that the bitmask inversion
was incorrectly set during a refactoring of the MCT code.

Fix this by putting the inversion at the correct position again.

Acked-by: Kukjin Kim 
Reported-by: GP Orcullo 
Reviewed-by: Doug Anderson 
Signed-off-by: Tobias Jakobi 
Signed-off-by: Daniel Lezcano 
Signed-off-by: Jiri Slaby

clockevent: sun4i: Fix race condition in the probe code

2014-12-06T14:14:51+00:00

commit 6bab4a8a1888729f17f4923cc5867e4674f66333 upstream.

The interrupts were activated and the handler registered before the clockevent
was registered in the probe function.

The interrupt handler, however, was making the assumption that the clockevent
device was registered.

That could cause a null pointer dereference if the timer interrupt was firing
during this narrow window.

Fix that by moving the clockevent registration before the interrupt is enabled.

Reported-by: Roman Byshko 
Signed-off-by: Maxime Ripard 
Signed-off-by: Daniel Lezcano 
Signed-off-by: Jiri Slaby

clocksource: Exynos_mct: Register clock event after request_irq()

2014-06-06T09:40:20+00:00

commit 8db6e5104b77de5d0b7002b95069da0992a34be9 upstream.

After hotplugging CPU1 the first call of interrupt handler for CPU1
oneshot timer was called on CPU0 because it fired before setting IRQ
affinity. Affected are SoCs where Multi Core Timer interrupts are
shared (SPI), e.g. Exynos 4210.

During setup of the MCT timers the clock event device should be
registered after setting the affinity for interrupt. This will prevent
starting the timer too early.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Thomas Gleixner 
Cc: Kyungmin Park 
Cc: Marek Szyprowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tomasz Figa ,
Cc: Daniel Lezcano ,
Cc: Kukjin Kim 
Cc: linux-arm-kernel@lists.infradead.org,
Link: http://lkml.kernel.org/r/20140416143316.299247848@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Jiri Slaby

clocksource: Exynos_mct: Use irq_force_affinity() in cpu bringup

2014-06-06T09:40:20+00:00

commit 30ccf03b4a6a2102a2219058bdc6d779dc637dd7 upstream.

The starting cpu is not yet in the online mask so irq_set_affinity()
fails which results in per cpu timers for this cpu ending up on some
other online cpu, ususally cpu 0.

Use irq_force_affinity() which disables the online mask check and
makes things work.

Signed-off-by: Thomas Gleixner 
Tested-by: Krzysztof Kozlowski 
Cc: Kyungmin Park 
Cc: Marek Szyprowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tomasz Figa ,
Cc: Daniel Lezcano ,
Cc: Kukjin Kim 
Cc: linux-arm-kernel@lists.infradead.org,
Link: http://lkml.kernel.org/r/20140416143316.106665251@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Jiri Slaby

clocksource: vf_pit_timer: use complement for sched_clock reading

2014-03-31T12:22:24+00:00

commit 224aa3ed45c8735ae02bb2ecca002409fa6aa772 upstream.

Vybrids PIT register is monitonic decreasing. However, sched_clock
reading needs to be monitonic increasing. Use bitwise not to get
the complement of the clock register. This fixes the clock going
backward. Also, the clock now starts at 0 since we load the
register with the maximum value at start.

Signed-off-by: Stefan Agner 
Acked-by: Shawn Guo 
Cc: daniel.lezcano@linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux@arm.linux.org.uk
Link: http://lkml.kernel.org/r/d25af915993aec1b486be653eb86f748ddef54fe.1394057313.git.stefan@agner.ch
Signed-off-by: Thomas Gleixner 
Signed-off-by: Jiri Slaby

clocksource: dw_apb_timer_of: Fix support for dts binding "snps,dw-apb-timer"

2014-01-09T20:25:15+00:00

commit 9ab4727c1d41e50b67aecde4bf11879560a3ca78 upstream.

In commit 620f5e1cbf (dts: Rename DW APB timer compatible strings), both
"snps,dw-apb-timer-sp" and "snps,dw-apb-timer-osc" were deprecated in place
of "snps,dw-apb-timer". But the driver also needs to be udpated in order to
support this new binding "snps,dw-apb-timer".

Signed-off-by: Dinh Nguyen 
Signed-off-by: Daniel Lezcano 
Signed-off-by: Greg Kroah-Hartman

clocksource: dw_apb_timer_of: Fix read_sched_clock

2014-01-09T20:25:15+00:00

commit 85dc6ee1237c8a4a7742e6abab96a20389b7d682 upstream.

The read_sched_clock should return the ~value because the clock is a
countdown implementation. read_sched_clock() should be the same as
 __apbt_read_clocksource().

Signed-off-by: Dinh Nguyen 
Signed-off-by: Daniel Lezcano 
Signed-off-by: Greg Kroah-Hartman

clocksource: em_sti: Set cpu_possible_mask to fix SMP broadcast

2013-09-26T00:31:04+00:00

Update the STI driver by setting cpu_possible_mask to make EMEV2
SMP work as expected together with the ARM broadcast timer.

This breakage was introduced by:

f7db706 ARM: 7674/1: smp: Avoid dummy clockevent being preferred over real hardware clock-event

Without this fix SMP operation is broken on EMEV2 since no
broadcast timer interrupts trigger on the secondary CPU cores.

Signed-off-by: Magnus Damm 
Tested-by: Simon Horman 
Reviewed-by: Stephen Boyd 
Signed-off-by: Simon Horman 
Signed-off-by: Daniel Lezcano