Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 1月, 2017 1 次提交
  3. 25 12月, 2016 2 次提交
  5. 16 9月, 2016 1 次提交
  7. 15 7月, 2016 1 次提交
  9. 28 6月, 2016 2 次提交
  11. 25 2月, 2016 1 次提交
  13. 15 10月, 2015 1 次提交
    • A
      clocksource/drivers/exynos_mct: Use container_of() instead of this_cpu_ptr() · 31f79874
      由 Alexey Klimov 提交于 
      Since evt structure is embedded in per-CPU mevt structure it's
definitely faster to use container_of() to get access to mevt
if we have evt (for example as incoming function argument) instead
of more expensive approach with this_cpu_ptr(&percpu_mct_tick).
this_cpu_ptr() on per-CPU mevt structure leads to access to cp15
to get cpu id and arithmetic operations.
Container_of() is cheaper since it's just one asm instruction.
This should work if used evt pointer is correct and owned by
local mevt structure.

For example, before this patch set_state_shutdown() looks like:

 4a4:	e92d4010 	push	{r4, lr}
 4a8:	e3004000 	movw	r4, #0
 4ac:	ebfffffe 	bl	0 <debug_smp_processor_id>
 4b0:	e3003000 	movw	r3, #0
 4b4:	e3404000 	movt	r4, #0
 4b8:	e3403000 	movt	r3, #0
 4bc:	e7933100 	ldr	r3, [r3, r0, lsl #2]
 4c0:	e0844003 	add	r4, r4, r3
 4c4:	e59400c0 	ldr	r0, [r4, #192]	; 0xc0
 4c8:	ebffffd4 	bl	420 <exynos4_mct_tick_stop.isra.1>
 4cc:	e3a00000 	mov	r0, #0
 4d0:	e8bd8010 	pop	{r4, pc}

With this patch:

 4a4:	e92d4010 	push	{r4, lr}
 4a8:	e59000c0 	ldr	r0, [r0, #192]	; 0xc0
 4ac:	ebffffdb 	bl	420 <exynos4_mct_tick_stop.isra.1>
 4b0:	e3a00000 	mov	r0, #0
 4b4:	e8bd8010 	pop	{r4, pc}

Also, for me size of exynos_mct.o decreased from 84588 bytes
to 83956.
Signed-off-by: NAlexey Klimov <alexey.klimov@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      31f79874
  15. 10 8月, 2015 2 次提交
  17. 27 6月, 2015 1 次提交
    • D
      clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier · 56a94f13
      由 Damian Eppel 提交于 
      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] [<c0014a00>] (unwind_backtrace) from [<c0011980>] (show_stack+0x10/0x14)
[   40.786747] [<c0011980>] (show_stack) from [<c0449ba0>] (dump_stack+0x70/0xbc)
[   40.786767] [<c0449ba0>] (dump_stack) from [<c00c6124>] (kmem_cache_alloc+0xd8/0x170)
[   40.786785] [<c00c6124>] (kmem_cache_alloc) from [<c005d6f8>] (request_threaded_irq+0x64/0x128)
[   40.786804] [<c005d6f8>] (request_threaded_irq) from [<c0350b8c>] (exynos4_local_timer_setup+0xc0/0x13c)
[   40.786820] [<c0350b8c>] (exynos4_local_timer_setup) from [<c0350ca8>] (exynos4_mct_cpu_notify+0x30/0xa8)
[   40.786838] [<c0350ca8>] (exynos4_mct_cpu_notify) from [<c003b330>] (notifier_call_chain+0x44/0x84)
[   40.786857] [<c003b330>] (notifier_call_chain) from [<c0022fd4>] (__cpu_notify+0x28/0x44)
[   40.786873] [<c0022fd4>] (__cpu_notify) from [<c0013714>] (secondary_start_kernel+0xec/0x150)
[   40.786886] [<c0013714>] (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: 7114cd74 ("clocksource: exynos_mct: use (request/free)_irq calls for local timer registration")
Reported-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: NMarcin Jabrzyk <m.jabrzyk@samsung.com>
Signed-off-by: NDamian Eppel <d.eppel@samsung.com>
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.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: <stable@vger.kernel.org>
      56a94f13
  19. 02 6月, 2015 3 次提交
  21. 05 1月, 2015 1 次提交
  23. 23 7月, 2014 2 次提交
    • D
      clocksource: exynos_mct: Only use 32-bits where possible · 3252a646
      由 Doug Anderson 提交于 
      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: NDoug Anderson <dianders@chromium.org>
Acked-by Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      3252a646
    • D
      clocksource: exynos_mct: Use readl_relaxed/writel_relaxed · fdb06f66
      由 Doug Anderson 提交于 
      Using the __raw functions is discouraged.  Update the file to
consistently use the proper functions.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      fdb06f66
  25. 05 7月, 2014 2 次提交
    • A
      clocksource: exynos_mct: Register the timer for stable udelay · 8bf13a43
      由 Amit Daniel Kachhap 提交于 
      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: NAmit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      8bf13a43
    • D
      clocksource: exynos_mct: Fix ftrace · 89e6a13b
      由 Doug Anderson 提交于 
      In (93bfb769 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: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      89e6a13b
  27. 16 6月, 2014 1 次提交
  29. 02 5月, 2014 1 次提交
  31. 18 4月, 2014 2 次提交
  33. 12 3月, 2014 1 次提交
  35. 14 2月, 2014 1 次提交
  37. 16 12月, 2013 1 次提交
  39. 26 9月, 2013 1 次提交
    • T
      clocksource: exynos_mct: Set IRQ affinity when the CPU goes online · 5df718d8
      由 Tomasz Figa 提交于 
      Some variants of Exynos MCT, namely exynos4210-mct at the moment, use
normal, shared interrupts for local timers. This means that each
interrupt must have correct affinity set to fire only on CPU
corresponding to given local timer.

However after recent conversion of clocksource drivers to not use the
local timer API for local timer initialization any more, the point of
time when local timers get initialized changed and irq_set_affinity()
fails because the CPU is not marked as online yet.

This patch fixes this by moving the call to irq_set_affinity() to
CPU_ONLINE notification, so the affinity is being set when the CPU goes
online.

This fixes a regression introduced by commit
	ee98d27d ARM: EXYNOS4: Divorce mct from local timer API
which rendered all Exynos4210 based boards unbootable due to
failing irq_set_affinity() making local timers inoperatible.
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      5df718d8
  41. 15 7月, 2013 1 次提交
    • P
      clocksource+irqchip: delete __cpuinit usage from all related files · 8c37bb3a
      由 Paul Gortmaker 提交于 
      The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

This removes all the drivers/clocksource and drivers/irqchip uses of
the __cpuinit macros from all C files.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      8c37bb3a
  43. 25 6月, 2013 1 次提交
  45. 19 6月, 2013 1 次提交
  47. 20 4月, 2013 2 次提交
  49. 04 4月, 2013 2 次提交
  51. 25 3月, 2013 2 次提交
  53. 09 3月, 2013 3 次提交