1. 04 7月, 2014 1 次提交
  2. 18 6月, 2014 15 次提交
  3. 07 6月, 2014 1 次提交
  4. 05 6月, 2014 1 次提交
  5. 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
  6. 29 5月, 2014 8 次提交
  7. 26 5月, 2014 1 次提交
  8. 23 5月, 2014 8 次提交
  9. 22 5月, 2014 2 次提交
  10. 17 5月, 2014 2 次提交
    • 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