1. 06 11月, 2013 14 次提交
    • C
      arc: remove '__init' for setup_processor() and arc_init_IRQ() · ef3a661a
      Chen Gang 提交于
      They haven't '__init' in definition, but has '__init' in declaration.
      And normal function start_kernel_secondary() may call setup_processor()
      which will call arc_init_IRQ().
      
      So need remove '__init' for both of them. The related warning (with
      allmodconfig):
      
          MODPOST vmlinux.o
        WARNING: vmlinux.o(.text+0x3084): Section mismatch in reference from the function start_kernel_secondary() to the function .init.text:setup_processor()
        The function start_kernel_secondary() references
        the function __init setup_processor().
        This is often because start_kernel_secondary lacks a __init
        annotation or the annotation of setup_processor is wrong.
      Signed-off-by: NChen Gang <gang.chen@asianux.com>
      ef3a661a
    • C
      arc: kgdb: add default implementation for kgdb_roundup_cpus() · 3d01c1ce
      Chen Gang 提交于
      arc supports kgdb, but need update -- add function kgdb_roundup_cpus(),
      or can not pass compiling. At present, add the simple generic one just
      like other architectures(e.g. tile, mips ...).
      
      The related error (with allmodconfig):
      
        kernel/built-in.o: In function `kgdb_cpu_enter':
        kernel/debug/debug_core.c:580: undefined reference to `kgdb_roundup_cpus'
      Signed-off-by: NChen Gang <gang.chen@asianux.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      3d01c1ce
    • V
      ARC: Fix bogus gcc warning and micro-optimise TLB iteration loop · 0a4c40a3
      Vineet Gupta 提交于
      ```--------------->8----------------------
      arch/arc/mm/tlb.c: In function ‘do_tlb_overlap_fault’:
      arch/arc/mm/tlb.c:688:13: warning: array subscript is above array bounds
      [-Warray-bounds]
               (pd0[n] & PAGE_MASK)) {
                   ^
      ```
      
      --------------->8----------------------
      
      While at it, remove the usless last iteration of outer loop when reading
      a TLB SET for duplicate entries.
      Suggested-by: NMischa Jonker <mjonker@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      0a4c40a3
    • V
      ARC: Add support for irqflags tracing and lockdep · 0dafafc3
      Vineet Gupta 提交于
      Lockdep required a small fix to stacktrace API which was incorrectly
      unwindign out of __switch_to for the current call frame.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      0dafafc3
    • V
      ARC: Reset the value of Interrupt Priority Register · 54c8bff1
      Vineet Gupta 提交于
      In case bootloader has changed the priority of one/more IRQ lines
      Reported-by: NNoam Camus <noamc@ezchip.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      54c8bff1
    • V
      ARC: Reduce #ifdef'ery for unaligned access emulation · 07ba69a4
      Vineet Gupta 提交于
      Emulation not enabled is treated as if the fixup failed, so no need for
      special #ifdef checks.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      07ba69a4
    • V
      ARC: Change calling convention of do_page_fault() · 21a63b56
      Vineet Gupta 提交于
      switch the args (address, pt_regs) to match with all the other "C"
      exception handlers.
      
      This removes the awkwardness in EV_ProtV for page fault vs. unaligned
      access.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      21a63b56
    • V
      ARC: cacheflush optim - PTAG can be loop invariant if V-P is const · d4599baf
      Vineet Gupta 提交于
      Line op needs vaddr (indexing) and paddr (tag match). For page sized
      flushes (V-P const), each line op will need a different index, but the
      tag bits wil remain constant, hence paddr can be setup once outside the
      loop.
      
      This improves select LMBench numbers for Aliasing dcache where we have
      more "preventive" cache flushing.
      
      Processor, Processes - times in microseconds - smaller is better
      ------------------------------------------------------------------------------
      Host                 OS  Mhz null null      open slct sig  sig  fork exec sh
                                   call  I/O stat clos TCP  inst hndl proc proc proc
      --------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
      3.11-rc7- Linux 3.11.0-   80 4.66 8.88 69.7 112. 268. 8.60 28.0 3489 13.K 27.K	# Non alias ARC700
      3.11-rc7- Linux 3.11.0-   80 4.64 8.51 68.6 98.5 271. 8.58 28.1 4160 15.K 32.K	# Aliasing
      3.11-rc7- Linux 3.11.0-   80 4.64 8.51 69.8 99.4 270. 8.73 27.5 3880 15.K 31.K	# PTAG loop Inv
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      d4599baf
    • V
      ARC: cacheflush refactor #3: Unify the {d,i}cache flush leaf helpers · bd12976c
      Vineet Gupta 提交于
      With Line length being constant now, we can fold the 2 helpers into 1.
      This allows applying any optimizations (forthcoming) to single place.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      bd12976c
    • V
      ARC: cacheflush refactor #2: I and D caches lines to have same size · 63d2dfdb
      Vineet Gupta 提交于
      Having them be different seems an obscure configuration.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      63d2dfdb
    • V
      ARC: cacheflush refactor #1: push aux reg ascertaining into leaf routine · f3e4de32
      Vineet Gupta 提交于
      ARC dcache supports 3 ops - Inv, Flush, Flush-n-Inv.
      The programming model however provides 2 commands FLUSH, INV.
      INV will either discard or flush-n-discard (based on DT_CTRL bit)
      
      The leaf helper __dc_line_loop() used to take the AUX register
      (corresponding to the 2 commands). Now we push that to within the
      helper, paving way for code consolidations to follow.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      f3e4de32
    • V
      ARC: use __weak instead of __attribute__((weak)) · 064a6269
      Vineet Gupta 提交于
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      064a6269
    • V
      ARC: Annotate some functions as static · 8e457d6a
      Vineet Gupta 提交于
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      8e457d6a
    • C
      arc: Replace __get_cpu_var uses · 6855e95c
      Christoph Lameter 提交于
      __get_cpu_var() is used for multiple purposes in the kernel source. One of them is
      address calculation via the form &__get_cpu_var(x). This calculates the address for
      the instance of the percpu variable of the current processor based on an offset.
      
      Other use cases are for storing and retrieving data from the current processors percpu area.
      __get_cpu_var() can be used as an lvalue when writing data or on the right side of an assignment.
      
      __get_cpu_var() is defined as :
      
      #define __get_cpu_var(var) (*this_cpu_ptr(&(var)))
      
      __get_cpu_var() always only does an address determination. However, store and retrieve operations
      could use a segment prefix (or global register on other platforms) to avoid the address calculation.
      
      this_cpu_write() and this_cpu_read() can directly take an offset into a percpu area and use
      optimized assembly code to read and write per cpu variables.
      
      This patch converts __get_cpu_var into either an explicit address calculation using this_cpu_ptr()
      or into a use of this_cpu operations that use the offset. Thereby address calcualtions are avoided
      and less registers are used when code is generated.
      
      At the end of the patchset all uses of __get_cpu_var have been removed so the macro is removed too.
      
      The patchset includes passes over all arches as well. Once these operations are used throughout then
      specialized macros can be defined in non -x86 arches as well in order to optimize per cpu access by
      f.e. using a global register that may be set to the per cpu base.
      
      Transformations done to __get_cpu_var()
      
      1. Determine the address of the percpu instance of the current processor.
      
      	DEFINE_PER_CPU(int, y);
      	int *x = &__get_cpu_var(y);
      
          Converts to
      
      	int *x = this_cpu_ptr(&y);
      
      2. Same as #1 but this time an array structure is involved.
      
      	DEFINE_PER_CPU(int, y[20]);
      	int *x = __get_cpu_var(y);
      
          Converts to
      
      	int *x = this_cpu_ptr(y);
      
      3. Retrieve the content of the current processors instance of a per cpu variable.
      
      	DEFINE_PER_CPU(int, u);
      	int x = __get_cpu_var(y)
      
         Converts to
      
      	int x = __this_cpu_read(y);
      
      4. Retrieve the content of a percpu struct
      
      	DEFINE_PER_CPU(struct mystruct, y);
      	struct mystruct x = __get_cpu_var(y);
      
         Converts to
      
      	memcpy(this_cpu_ptr(&x), y, sizeof(x));
      
      5. Assignment to a per cpu variable
      
      	DEFINE_PER_CPU(int, y)
      	__get_cpu_var(y) = x;
      
         Converts to
      
      	this_cpu_write(y, x);
      
      6. Increment/Decrement etc of a per cpu variable
      
      	DEFINE_PER_CPU(int, y);
      	__get_cpu_var(y)++
      
         Converts to
      
      	this_cpu_inc(y)
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      6855e95c
  2. 03 11月, 2013 1 次提交
    • V
      ARC: Incorrect mm reference used in vmalloc fault handler · 9c41f4ee
      Vineet Gupta 提交于
      A vmalloc fault needs to sync up PGD/PTE entry from init_mm to current
      task's "active_mm".  ARC vmalloc fault handler however was using mm.
      
      A vmalloc fault for non user task context (actually pre-userland, from
      init thread's open for /dev/console) caused the handler to deref NULL mm
      (for mm->pgd)
      
      The reasons it worked so far is amazing:
      
      1. By default (!SMP), vmalloc fault handler uses a cached value of PGD.
         In SMP that MMU register is repurposed hence need for mm pointer deref.
      
      2. In pre-3.12 SMP kernel, the problem triggering vmalloc didn't exist in
         pre-userland code path - it was introduced with commit 20bafb3d
         "n_tty: Move buffers into n_tty_data"
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: Gilad Ben-Yossef <gilad@benyossef.com>
      Cc: Noam Camus <noamc@ezchip.com>
      Cc: stable@vger.kernel.org    #3.10 and 3.11
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9c41f4ee
  3. 31 10月, 2013 3 次提交
  4. 30 10月, 2013 3 次提交
    • M
      MIPS: malta: Fix GIC interrupt offsets · 13b7ea63
      Markos Chandras 提交于
      The GIC interrupt offsets are calculated based on the value of NR_CPUS.
      However, this is wrong because NR_CPUS may or may not contain the real
      number of the actual cpus present in the system. We fix that by using
      the 'nr_cpu_ids' variable which contains the real number of cpus in
      the system. Previously, an MT core (eg with 8 VPEs) will fail to boot if
      NR_CPUS was > 8 with the following errors:
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:670 __irq_set_handler+0x15c/0x164()
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W    3.12.0-rc5-00087-gced5633 5
      Stack : 00000006 00000004 00000000 00000000 00000000 00000000 807a4f36 00000053
                807a0000 00000000 80173218 80565aa8 00000000 00000000 00000000 0000000
                00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000
                00000000 00000000 00000000 8054fd00 8054fd94 80500514 805657a7 8016eb4
                807a0000 80500514 00000000 00000000 80565aa8 8079a5d8 80565766 8054fd0
                ...
      Call Trace:
      [<801098c0>] show_stack+0x64/0x7c
      [<8049c6b0>] dump_stack+0x64/0x84
      [<8012efc4>] warn_slowpath_common+0x84/0xb4
      [<8012f00c>] warn_slowpath_null+0x18/0x24
      [<80173218>] __irq_set_handler+0x15c/0x164
      [<80587cf4>] arch_init_ipiirq+0x2c/0x3c
      [<805880c8>] arch_init_irq+0x3c4/0x4bc
      [<80588e28>] init_IRQ+0x3c/0x50
      [<805847e8>] start_kernel+0x230/0x3d8
      
      ---[ end trace 4eaa2a86a8e2da26 ]---
      
      This is now fixed and the Malta board can boot with any NR_CPUS value
      which also helps supporting more processors in a single kernel binary.
      Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/6091/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      13b7ea63
    • T
      KVM: Fix modprobe failure for kvm_intel/kvm_amd · d780a312
      Tim Gardner 提交于
      The x86 specific kvm init creates a new conflicting
      debugfs directory which causes modprobe issues
      with kvm_intel and kvm_amd. For example,
      
      sudo modprobe kvm_amd
      modprobe: ERROR: could not insert 'kvm_amd': Bad address
      
      The simplest fix is to just rename the directory. The following
      KVM config options are set:
      
      CONFIG_KVM_GUEST=y
      CONFIG_KVM_DEBUG_FS=y
      CONFIG_HAVE_KVM=y
      CONFIG_HAVE_KVM_IRQCHIP=y
      CONFIG_HAVE_KVM_IRQ_ROUTING=y
      CONFIG_HAVE_KVM_EVENTFD=y
      CONFIG_KVM_APIC_ARCHITECTURE=y
      CONFIG_KVM_MMIO=y
      CONFIG_KVM_ASYNC_PF=y
      CONFIG_HAVE_KVM_MSI=y
      CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
      CONFIG_KVM=m
      CONFIG_KVM_INTEL=m
      CONFIG_KVM_AMD=m
      CONFIG_KVM_DEVICE_ASSIGNMENT=y
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
      [Change debugfs directory name. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      d780a312
    • D
      MIPS: Perf: Fix 74K cache map · 7f081f17
      Deng-Cheng Zhu 提交于
      According to Software User's Manual, the event of last-level-cache
      read/write misses is mapped to even counters. Odd counters of that
      event number count miss cycles.
      Signed-off-by: NDeng-Cheng Zhu <dengcheng.zhu@imgtec.com>
      Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/6036/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      7f081f17
  5. 29 10月, 2013 1 次提交
    • P
      perf/x86: Fix NMI measurements · e8a923cc
      Peter Zijlstra 提交于
      OK, so what I'm actually seeing on my WSM is that sched/clock.c is
      'broken' for the purpose we're using it for.
      
      What triggered it is that my WSM-EP is broken :-(
      
        [    0.001000] tsc: Fast TSC calibration using PIT
        [    0.002000] tsc: Detected 2533.715 MHz processor
        [    0.500180] TSC synchronization [CPU#0 -> CPU#6]:
        [    0.505197] Measured 3 cycles TSC warp between CPUs, turning off TSC clock.
        [    0.004000] tsc: Marking TSC unstable due to check_tsc_sync_source failed
      
      For some reason it consistently detects TSC skew, even though NHM+
      should have a single clock domain for 'reasonable' systems.
      
      This marks sched_clock_stable=0, which means that we do fancy stuff to
      try and get a 'sane' clock. Part of this fancy stuff relies on the tick,
      clearly that's gone when NOHZ=y. So for idle cpus time gets stuck, until
      it either wakes up or gets kicked by another cpu.
      
      While this is perfectly fine for the scheduler -- it only cares about
      actually running stuff, and when we're running stuff we're obviously not
      idle. This does somewhat break down for perf which can trigger events
      just fine on an otherwise idle cpu.
      
      So I've got NMIs get get 'measured' as taking ~1ms, which actually
      don't last nearly that long:
      
                <idle>-0     [013] d.h.   886.311970: rcu_nmi_enter <-do_nmi
        ...
                <idle>-0     [013] d.h.   886.311997: perf_sample_event_took: HERE!!! : 1040990
      
      So ftrace (which uses sched_clock(), not the fancy bits) only sees
      ~27us, but we measure ~1ms !!
      
      Now since all this measurement stuff lives in x86 code, we can actually
      fix it.
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: mingo@kernel.org
      Cc: dave.hansen@linux.intel.com
      Cc: eranian@google.com
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: jmario@redhat.com
      Cc: acme@infradead.org
      Link: http://lkml.kernel.org/r/20131017133350.GG3364@laptop.programming.kicks-ass.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      e8a923cc
  6. 27 10月, 2013 1 次提交
    • H
      parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM · 54e181e0
      Helge Deller 提交于
      Since the beginning of the parisc-linux port, sometimes 64bit SMP kernels were
      not able to bring up other CPUs than the monarch CPU and instead crashed the
      kernel.  The reason was unclear, esp. since it involved various machines (e.g.
      J5600, J6750 and SuperDome). Testing showed, that those crashes didn't happened
      when less than 4GB were installed, or if a 32bit Linux kernel was booted.
      
      In the end, the fix for those SMP problems is trivial:
      During the early phase of the initialization of the CPUs, including the monarch
      CPU, the PDC_PSW firmware function to enable WIDE (=64bit) mode is called.
      It's documented that this firmware function may clobber various registers, and
      one one of those possibly clobbered registers is %cr30 which holds the task
      thread info pointer.
      
      Now, if %cr30 would always have been clobbered, then this bug would have been
      detected much earlier. But lots of testing finally showed, that - at least for
      %cr30 - on some machines only the upper 32bits of the 64bit register suddenly
      turned zero after the firmware call.
      
      So, after finding the root cause, the explanation for the various crashes
      became clear:
      - On 32bit SMP Linux kernels all upper 32bit were zero, so we didn't faced this
        problem.
      - Monarch CPUs in 64bit mode always booted sucessfully, because the inital task
        thread info pointer was below 4GB.
      - Secondary CPUs booted sucessfully on machines with less than 4GB RAM because
        the upper 32bit were zero anyay.
      - Secondary CPus failed to boot if we had more than 4GB RAM and the task thread
        info pointer was located above the 4GB boundary.
      
      Finally, the patch to fix this problem is trivial by saving the %cr30 register
      before the firmware call and restoring it afterwards.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # 2.6.12+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      54e181e0
  7. 22 10月, 2013 1 次提交
    • M
      s390/time: correct use of store clock fast · 8c071b0f
      Martin Schwidefsky 提交于
      The result of the store-clock-fast (STCKF) instruction is a bit fuzzy.
      It can happen that the value stored on one CPU is smaller than the value
      stored on another CPU, although the order of the stores is the other
      way around. This can cause deltas of get_tod_clock() values to become
      negative when they should not be.
      
      We need to be more careful with store-clock-fast, this patch partially
      reverts git commit e4b7b4238e666682555461fa52eecd74652f36bb "time:
      always use stckf instead of stck if available". The get_tod_clock()
      function now uses the store-clock-extended (STCKE) instruction.
      get_tod_clock_fast() can be used if the fuzziness of store-clock-fast
      is acceptable e.g. for wait loops local to a CPU.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      8c071b0f
  8. 20 10月, 2013 2 次提交
  9. 17 10月, 2013 1 次提交
  10. 16 10月, 2013 2 次提交
  11. 15 10月, 2013 5 次提交
  12. 14 10月, 2013 4 次提交
    • B
      x86/microcode: Correct Kconfig dependencies · 80030e3d
      Borislav Petkov 提交于
      I have a randconfig here which has enabled only
      
        CONFIG_MICROCODE=y
        CONFIG_MICROCODE_OLD_INTERFACE=y
      
      with both
      
        # CONFIG_MICROCODE_INTEL is not set
        # CONFIG_MICROCODE_AMD is not set
      
      off. Which makes building the microcode functionality a little
      pointless. Don't do that in such cases then.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/1381682189-14470-1-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      80030e3d
    • L
      ARM: integrator: deactivate timer0 on the Integrator/CP · 29114fd7
      Linus Walleij 提交于
      This fixes a long-standing Integrator/CP regression from
      commit 870e2928
      "ARM: integrator-cp: convert use CLKSRC_OF for timer init"
      
      When this code was introduced, the both aliases pointing the
      system to use timer1 as primary (clocksource) and timer2
      as secondary (clockevent) was ignored, and the system would
      simply use the first two timers found as clocksource and
      clockevent.
      
      However this made the system timeline accelerate by a
      factor x25, as it turns out that the way the clocking
      actually works (totally undocumented and found after some
      trial-and-error) is that timer0 runs @ 25MHz and timer1
      and timer2 runs @ 1MHz. Presumably this divider setting
      is a boot-on default and configurable albeit the way to
      configure it is not documented.
      
      So as a quick fix to the problem, let's mark timer0 as
      disabled, so the code will chose timer1 and timer2 as it
      used to.
      
      This also deletes the two aliases for the primary and
      secondary timer as they have been superceded by the
      auto-selection
      
      Cc: stable@vger.kernel.org
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      29114fd7
    • A
      ARM: 7851/1: check for number of arguments in syscall_get/set_arguments() · 3c1532df
      AKASHI Takahiro 提交于
      In ftrace_syscall_enter(),
          syscall_get_arguments(..., 0, n, ...)
              if (i == 0) { <handle ORIG_r0> ...; n--;}
              memcpy(..., n * sizeof(args[0]));
      If 'number of arguments(n)' is zero and 'argument index(i)' is also zero in
      syscall_get_arguments(), none of arguments should be copied by memcpy().
      Otherwise 'n--' can be a big positive number and unexpected amount of data
      will be copied. Tracing system calls which take no argument, say sync(void),
      may hit this case and eventually make the system corrupted.
      This patch fixes the issue both in syscall_get_arguments() and
      syscall_set_arguments().
      
      Cc: <stable@vger.kernel.org>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NAKASHI Takahiro <takahiro.akashi@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3c1532df
    • Y
      ARM: exynos: dts: Update 5250 arch timer node with clock frequency · 4d594dd3
      Yuvaraj Kumar C D 提交于
      Without the "clock-frequency" property in arch timer node, could able
      to see the below crash dump.
      
      [<c0014e28>] (unwind_backtrace+0x0/0xf4) from [<c0011808>] (show_stack+0x10/0x14)
      [<c0011808>] (show_stack+0x10/0x14) from [<c036ac1c>] (dump_stack+0x7c/0xb0)
      [<c036ac1c>] (dump_stack+0x7c/0xb0) from [<c01ab760>] (Ldiv0_64+0x8/0x18)
      [<c01ab760>] (Ldiv0_64+0x8/0x18) from [<c0062f60>] (clockevents_config.part.2+0x1c/0x74)
      [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) from [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c)
      [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) from [<c02b8e8c>] (arch_timer_setup+0xa8/0x134)
      [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) from [<c04b47b4>] (arch_timer_init+0x1f4/0x24c)
      [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) from [<c04b40d8>] (clocksource_of_init+0x34/0x58)
      [<c04b40d8>] (clocksource_of_init+0x34/0x58) from [<c049ed8c>] (time_init+0x20/0x2c)
      [<c049ed8c>] (time_init+0x20/0x2c) from [<c049b95c>] (start_kernel+0x1e0/0x39c)
      
      THis is because the Exynos u-boot, for example on the Chromebooks, doesn't set
      up the CNTFRQ register as expected by arch_timer. Instead, we have to specify
      the frequency in the device tree like this.
      Signed-off-by: NYuvaraj Kumar C D <yuvaraj.cd@samsung.com>
      [olof: Changed subject, added comment, elaborated on commit message]
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      4d594dd3
  13. 13 10月, 2013 2 次提交