1. 18 6月, 2014 2 次提交
  2. 07 6月, 2014 1 次提交
  3. 05 6月, 2014 1 次提交
  4. 31 5月, 2014 1 次提交
    • L
      arm64: kernel: initialize broadcast hrtimer based clock event device · 9358d755
      Lorenzo Pieralisi 提交于
      On platforms implementing CPU power management, the CPUidle subsystem
      can allow CPUs to enter idle states where local timers logic is lost on power
      down. To keep the software timers functional the kernel relies on an
      always-on broadcast timer to be present in the platform to relay the
      interrupt signalling the timer expiries.
      
      For platforms implementing CPU core gating that do not implement an always-on
      HW timer or implement it in a broken way, this patch adds code to initialize
      the kernel hrtimer based clock event device upon boot (which can be chosen as
      tick broadcast device by the kernel).
      It relies on a dynamically chosen CPU to be always powered-up. This CPU then
      relays the timer interrupt to CPUs in deep-idle states through its HW local
      timer device.
      
      Having a CPU always-on has implications on power management platform
      capabilities and makes CPUidle suboptimal, since at least a CPU is kept
      always in a shallow idle state by the kernel to relay timer interrupts,
      but at least leaves the kernel with a functional system with some working
      power management capabilities.
      
      The hrtimer based clock event device is unconditionally registered, but
      has the lowest possible rating such that any broadcast-capable HW clock
      event device present will be chosen in preference as the tick broadcast
      device.
      Reviewed-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      9358d755
  5. 29 5月, 2014 8 次提交
  6. 26 5月, 2014 1 次提交
  7. 23 5月, 2014 8 次提交
  8. 22 5月, 2014 2 次提交
  9. 17 5月, 2014 7 次提交
    • A
      arm64: Fix deadlock scenario with smp_send_stop() · b9acc49e
      Arun KS 提交于
      If one process calls sys_reboot and that process then stops other
      CPUs while those CPUs are within a spin_lock() region we can
      potentially encounter a deadlock scenario like below.
      
      CPU 0                   CPU 1
      -----                   -----
                              spin_lock(my_lock)
      smp_send_stop()
       <send IPI>             handle_IPI()
                               disable_preemption/irqs
                                while(1);
       <PREEMPT>
      spin_lock(my_lock) <--- Waits forever
      
      We shouldn't attempt to run any other tasks after we send a stop
      IPI to a CPU so disable preemption so that this task runs to
      completion. We use local_irq_disable() here for cross-arch
      consistency with x86.
      Based-on-work-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NArun KS <getarunks@gmail.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      b9acc49e
    • A
      arm64: Fix machine_shutdown() definition · 90f51a09
      Arun KS 提交于
      This patch ports most of commit 19ab428f "ARM: 7759/1: decouple CPU
      offlining from reboot/shutdown" by Stephen Warren from arch/arm to
      arch/arm64.
      
      machine_shutdown() is a hook for kexec. Add a comment saying so, since
      it isn't obvious from the function name.
      
      Halt, power-off, and restart have different requirements re: stopping
      secondary CPUs than kexec has. The former simply require the secondary
      CPUs to be quiesced somehow, whereas kexec requires them to be
      completely non-operational, so that no matter where the kexec target
      images are written in RAM, they won't influence operation of the
      secondary CPUS,which could happen if the CPUs were still executing some
      kind of pin loop. To this end, modify machine_halt, power_off, and
      restart to call smp_send_stop() directly, rather than calling
      machine_shutdown().
      
      In machine_shutdown(), replace the call to smp_send_stop() with a call
      to disable_nonboot_cpus(). This completely disables all but one CPU,
      thus satisfying the kexec requirements a couple paragraphs above.
      Signed-off-by: NArun KS <getarunks@gmail.com>
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      90f51a09
    • L
      arm64: Support arch_irq_work_raise() via self IPIs · eb631bb5
      Larry Bassel 提交于
      Support for arch_irq_work_raise() was missing from
      arm64 (a prerequisite for FULL_NOHZ).
      
      This patch is based on the arm32 patch ARM 7872/1.
      
      commit bf18525f
      Author: Stephen Boyd <sboyd@codeaurora.org>
      Date:   Tue Oct 29 20:32:56 2013 +0100
      
          ARM: 7872/1: Support arch_irq_work_raise() via self IPIs
      
          By default, IRQ work is run from the tick interrupt (see
          irq_work_run() in update_process_times()). When we're in full
          NOHZ mode, restarting the tick requires the use of IRQ work and
          if the only place we run IRQ work is in the tick interrupt we
          have an unbreakable cycle. Implement arch_irq_work_raise() via
          self IPIs to break this cycle and get the tick started again.
          Note that we implement this via IPIs which are only available on
          SMP builds. This shouldn't be a problem because full NOHZ is only
          supported on SMP builds anyway.
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Reviewed-by: NKevin Hilman <khilman@linaro.org>
          Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NLarry Bassel <larry.bassel@linaro.org>
      Reviewed-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      eb631bb5
    • M
      arm64: fix pud_huge() for 2-level pagetables · 4797ec2d
      Mark Salter 提交于
      The following happens when trying to run a kvm guest on a kernel
      configured for 64k pages. This doesn't happen with 4k pages:
      
        BUG: failure at include/linux/mm.h:297/put_page_testzero()!
        Kernel panic - not syncing: BUG!
        CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF            3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1
        Call trace:
        [<fffffe0000096034>] dump_backtrace+0x0/0x16c
        [<fffffe00000961b4>] show_stack+0x14/0x1c
        [<fffffe000066e648>] dump_stack+0x84/0xb0
        [<fffffe0000668678>] panic+0xf4/0x220
        [<fffffe000018ec78>] free_reserved_area+0x0/0x110
        [<fffffe000018edd8>] free_pages+0x50/0x88
        [<fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40
        [<fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44
        [<fffffe00000a1854>] kvm_put_kvm+0xf0/0x184
        [<fffffe00000a1938>] kvm_vm_release+0x10/0x1c
        [<fffffe00001edc1c>] __fput+0xb0/0x288
        [<fffffe00001ede4c>] ____fput+0xc/0x14
        [<fffffe00000d5a2c>] task_work_run+0xa8/0x11c
        [<fffffe0000095c14>] do_notify_resume+0x54/0x58
      
      In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page()
      on the stage2 pgd which leads to the BUG in put_page_testzero(). This
      happens because a pud_huge() test in unmap_range() returns true when it
      should always be false with 2-level pages tables used by 64k pages.
      This patch removes support for huge puds if 2-level pagetables are
      being used.
      Signed-off-by: NMark Salter <msalter@redhat.com>
      [catalin.marinas@arm.com: removed #ifndef around PUD_SIZE check]
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: <stable@vger.kernel.org> # v3.11+
      4797ec2d
    • M
      arm64: topology: Add support for topology DT bindings · ebdc9447
      Mark Brown 提交于
      Add support for parsing the explicit topology bindings to discover the
      topology of the system.
      
      Since it is not currently clear how to map multi-level clusters for the
      scheduler all leaf clusters are presented to the scheduler at the same
      level. This should be enough to provide good support for current systems.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      Reviewed-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      ebdc9447
    • M
      arm64: topology: Initialise default topology state immediately · c31bf048
      Mark Brown 提交于
      As a legacy of the way 32 bit ARM did things the topology code uses a null
      topology map by default and then overwrites it by mapping cores with no
      information to a cluster by themselves later. In order to make it simpler
      to reset things as part of recovering from parse failures in firmware
      information directly set this configuration on init. A core will always be
      its own sibling so there should be no risk of confusion with firmware
      provided information.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      Reviewed-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      c31bf048
    • Z
      arm64: sched: Remove unused mc_capable() and smt_capable() · 5dd349ba
      Zi Shen Lim 提交于
      Remove unused and deprecated mc_capable() and smt_capable().
      
      Both were added recently by f6e763b9 ("arm64: topology:
      Implement basic CPU topology support"). Uses of both were removed
      by 8e7fbcbc ("sched: Remove stale power aware scheduling
      remnants and dysfunctional knobs").
      Signed-off-by: NZi Shen Lim <zlim@broadcom.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      5dd349ba
  10. 16 5月, 2014 2 次提交
    • C
      Revert "arm64: Introduce execute-only page access permissions" · 5a0fdfad
      Catalin Marinas 提交于
      This reverts commit bc07c2c6.
      
      While the aim is increased security for --x memory maps, it does not
      protect against kernel level reads. Until SECCOMP is implemented for
      arm64, revert this patch to avoid giving a false idea of execute-only
      mappings.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      5a0fdfad
    • P
      mfd: vexpress: Convert custom func API to regmap · 3b9334ac
      Pawel Moll 提交于
      Components of the Versatile Express platform (configuration
      microcontrollers on motherboard and daughterboards in particular)
      talk to each other over a custom configuration bus. They
      provide miscellaneous functions (from clock generator control
      to energy sensors) which are represented as platform devices
      (and Device Tree nodes). The transactions on the bus can
      be generated by different "bridges" in the system, some
      of which are universal for the whole platform (for the price
      of high transfer latencies), others restricted to a subsystem
      (but much faster).
      
      Until now drivers for such functions were using custom "func"
      API, which is being replaced in this patch by regmap calls.
      This required:
      
      * a rework (and move to drivers/bus directory, as suggested
        by Samuel and Arnd) of the config bus core, which is much
        simpler now and uses device model infrastructure (class)
        to keep track of the bridges; non-DT case (soon to be
        retired anyway) is simply covered by a special device
        registration function
      
      * the new config-bus driver also takes over device population,
        so there is no need for special matching table for
        of_platform_populate nor "simple-bus" hack in the arm64
        model dtsi file (relevant bindings documentation has
        been updated); this allows all the vexpress devices
        fit into normal device model, making it possible
        to remove plenty of early inits and other hacks in
        the near future
      
      * adaptation of the syscfg bridge implementation in the
        sysreg driver, again making it much simpler; there is
        a special case of the "energy" function spanning two
        registers, where they should be both defined in the tree
        now, but backward compatibility is maintained in the code
      
      * modification of the relevant drivers:
      
        * hwmon - just a straight-forward API change
        * power/reset driver - API change
        * regulator - API change plus error handling
          simplification
        * osc clock driver - this one required larger rework
          in order to turn in into a standard platform driver
      Signed-off-by: NPawel Moll <pawel.moll@arm.com>
      Acked-by: NMark Brown <broonie@linaro.org>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Acked-by: NGuenter Roeck <linux@roeck-us.net>
      Acked-by: NMike Turquette <mturquette@linaro.org>
      3b9334ac
  11. 15 5月, 2014 7 次提交