kernel/drivers/clocksource/exynos_mct.c, branch linux-4.1.y

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

2015-08-03T16:29:16Z

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: Greg Kroah-Hartman

clocksource: exynos_mct: Fix bitmask regression for exynos4_mct_write

2015-01-05T13:43:35Z

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. Cc: stable@vger.kernel.org Acked-by: Kukjin Kim Reported-by: GP Orcullo Reviewed-by: Doug Anderson Signed-off-by: Tobias Jakobi Signed-off-by: Daniel Lezcano

clocksource: exynos_mct: Only use 32-bits where possible

2014-07-23T10:02:41Z

The MCT has a nice 64-bit counter. That means that we _can_ register as a 64-bit clocksource and sched_clock. ...but that doesn't mean we should. The 64-bit counter is read by reading two 32-bit registers. That means reading needs to be something like: - Read upper half - Read lower half - Read upper half and confirm that it hasn't changed. That wouldn't be terrible, but: - THe MCT isn't very fast to access (hundreds of nanoseconds). - The clocksource is queried _all the time_. In total system profiles of real workloads on ChromeOS, we've seen exynos_frc_read() taking 2% or more of CPU time even after optimizing the 3 reads above to 2 (see below). The MCT is clocked at ~24MHz on all known systems. That means that the 32-bit half of the counter rolls over every ~178 seconds. This inspired an optimization in ChromeOS to cache the upper half between calls, moving 3 reads to 2. ...but we can do better! Having a 32-bit timer that flips every 178 seconds is more than sufficient for Linux. Let's just use the lower half of the MCT. Times on 5420 to do 1000000 gettimeofday() calls from userspace: * Original code: 1323852 us * ChromeOS cache upper half: 1173084 us * ChromeOS + ldmia to optimize: 1045674 us * Use lower 32-bit only (this code): 1014429 us As you can see, the time used doesn't increase linearly with the number of reads and we can make 64-bit work almost as fast as 32-bit with a bit of assembly code. But since there's no real gain for 64-bit, let's go with the simplest and fastest implementation. Note: with this change roughly half the time for gettimeofday() is spent in exynos_frc_read(). The rest is timer / system call overhead. Also note: this patch disables the use of the MCT on ARM64 systems until we've sorted out how to make "cycles_t" always 32-bit. Really ARM64 systems should be using arch timers anyway. Signed-off-by: Doug Anderson Acked-by Vincent Guittot Signed-off-by: Kukjin Kim Signed-off-by: Daniel Lezcano

clocksource: exynos_mct: Use readl_relaxed/writel_relaxed

2014-07-23T10:02:40Z

Using the __raw functions is discouraged. Update the file to consistently use the proper functions. Signed-off-by: Doug Anderson Signed-off-by: Kukjin Kim Signed-off-by: Daniel Lezcano

clocksource: exynos_mct: Register the timer for stable udelay

2014-07-04T21:40:23Z

This patch registers the exynos mct clocksource as the current timer as it has constant clock rate. This will generate correct udelay for the exynos platform and avoid using unnecessary calibrated jiffies. This change has been tested on exynos5420 based board and udelay is very close to expected. Without this patch udelay() on exynos5400 / exynos5800 is wildly inaccurate due to big.LITTLE not adjusting loops_per_jiffy correctly. Also without this patch udelay() on exynos5250 can be innacruate during transitions between frequencies < 800 MHz (you'll go 200 MHz -> 800 MHz -> 300 MHz and will run at 800 MHz for a time with the wrong loops_per_jiffy). [dianders: reworked and created version 3] Signed-off-by: Amit Daniel Kachhap Signed-off-by: Doug Anderson Signed-off-by: Kukjin Kim

clocksource: exynos_mct: Fix ftrace

2014-07-04T21:38:55Z

In (93bfb76 clocksource: exynos_mct: register sched_clock callback) we supported using the MCT as a scheduler clock. We properly marked exynos4_read_sched_clock() as notrace. However, we then went and called another function that _wasn't_ notrace. That means if you do: cd /sys/kernel/debug/tracing/ echo function_graph > current_tracer You'll get a crash. Fix this (but still let other readers of the MCT be trace-enabled) by adding an extra function. It's important to keep other users of MCT traceable because the MCT is actually quite slow to access and we want exynos4_frc_read() to show up in ftrace profiles if it's the bottleneck. Signed-off-by: Doug Anderson Signed-off-by: Kukjin Kim

clocksource: exynos_mct: Don't reset the counter during boot and resume

2014-06-16T15:23:29Z

Unfortunately on some exynos systems, resetting the mct counter also resets the architected timer counter. This can cause problems if the architected timer driver has already been initialized because the kernel will think that the counter has wrapped around, causing a big jump in printk timestamps and delaying any scheduled clock events until the counter reaches the value it had before it was reset. The kernel code makes no assumptions about the initial value of the mct counter so there is no reason from a software perspective to clear the counter before starting it. This also fixes the problems described in the previous paragraph. Cc: Olof Johansson Cc: Tomasz Figa Signed-off-by: Chirantan Ekbote Reviewed-by: Doug Anderson Tested-by: Doug Anderson Signed-off-by: Kukjin Kim

Merge tag 'samsung-drivers' of http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into next/drivers

2014-05-22T05:32:57Z

Merge "Samsung driver update for 3.16" from Kukjin Kim: exynos_mct update for v3.16 - register sched_clock callback to use clocksource mct-frc * tag 'samsung-drivers' of http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung: clocksource: exynos_mct: register sched_clock callback Signed-off-by: Olof Johansson

clocksource: exynos_mct: register sched_clock callback

2014-05-02T13:27:01Z

Use the clocksource mct-frc for sched_clock Signed-off-by: Vincent Guittot Reviewed-by: Tomasz Figa Acked-by: Daniel Lezcano Signed-off-by: Kukjin Kim

clocksource: Exynos_mct: Register clock event after request_irq()

2014-04-17T21:36:28Z

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, Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20140416143316.299247848@linutronix.de Signed-off-by: Thomas Gleixner