1. 14 10月, 2015 2 次提交
  2. 01 8月, 2015 1 次提交
    • S
      ARM: 8392/3: smp: Only expose /sys/.../cpuX/online if hotpluggable · 787047ee
      Stephen Boyd 提交于
      Writes to /sys/.../cpuX/online fail if we determine the platform
      doesn't support hotplug for that CPU. Furthermore, if the cpu_die
      op isn't specified the system hangs when we try to offline a CPU
      and it comes right back online unexpectedly. Let's figure this
      stuff out before we make the sysfs nodes so that the online file
      doesn't even exist if it isn't (at least sometimes) possible to
      hotplug the CPU.
      
      Add a new 'cpu_can_disable' op and repoint all 'cpu_disable'
      implementations at it because all implementers use the op to
      indicate if a CPU can be hotplugged or not in a static fashion.
      With PSCI we may need to add a 'cpu_disable' op so that the
      secure OS can be migrated off the CPU we're trying to hotplug.
      In this case, the 'cpu_can_disable' op will indicate that all
      CPUs are hotpluggable by returning true, but the 'cpu_disable' op
      will make a PSCI migration call and occasionally fail, denying
      the hotplug of a CPU. This shouldn't be any worse than x86 where
      we may indicate that all CPUs are hotpluggable but occasionally
      we can't offline a CPU due to check_irq_vectors_for_cpu_disable()
      failing to find a CPU to move vectors to.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Nicolas Pitre <nico@linaro.org>
      Cc: Dave Martin <Dave.Martin@arm.com>
      Acked-by: Simon Horman <horms@verge.net.au> [shmobile portion]
      Tested-by: NSimon Horman <horms@verge.net.au>
      Cc: Magnus Damm <magnus.damm@gmail.com>
      Cc: <linux-sh@vger.kernel.org>
      Tested-by: NTyler Baker <tyler.baker@linaro.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      787047ee
  3. 28 7月, 2015 1 次提交
    • R
      ARM: kill off set_irq_flags usage · e8d36d5d
      Rob Herring 提交于
      set_irq_flags is ARM specific with custom flags which have genirq
      equivalents. Convert drivers to use the genirq interfaces directly, so we
      can kill off set_irq_flags. The translation of flags is as follows:
      
      IRQF_VALID -> !IRQ_NOREQUEST
      IRQF_PROBE -> !IRQ_NOPROBE
      IRQF_NOAUTOEN -> IRQ_NOAUTOEN
      
      For IRQs managed by an irqdomain, the irqdomain core code handles clearing
      and setting IRQ_NOREQUEST already, so there is no need to do this in
      .map() functions and we can simply remove the set_irq_flags calls. Some
      users also modify IRQ_NOPROBE and this has been maintained although it
      is not clear that is really needed. There appears to be a great deal of
      blind copy and paste of this code.
      Signed-off-by: NRob Herring <robh@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Sekhar Nori <nsekhar@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Gregory Clement <gregory.clement@free-electrons.com>
      Acked-by: NHans Ulli Kroll <ulli.kroll@googlemail.com>
      Acked-by: NShawn Guo <shawnguo@kernel.org>
      Cc: Sascha Hauer <kernel@pengutronix.de>
      Cc: Imre Kaloz <kaloz@openwrt.org>
      Acked-by: NKrzysztof Halasa <khalasa@piap.pl>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Cc: Roland Stigge <stigge@antcom.de>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Daniel Mack <daniel@zonque.org>
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
      Cc: Robert Jarzmik <robert.jarzmik@free.fr>
      Cc: Simtec Linux Team <linux@simtec.co.uk>
      Cc: Kukjin Kim <kgene@kernel.org>
      Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: NWan ZongShun <mcuos.com@gmail.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-omap@vger.kernel.org
      Cc: linux-samsung-soc@vger.kernel.org
      Tested-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      e8d36d5d
  4. 13 7月, 2015 4 次提交
  5. 18 6月, 2015 1 次提交
  6. 02 6月, 2015 2 次提交
  7. 09 5月, 2015 1 次提交
  8. 07 5月, 2015 1 次提交
  9. 06 5月, 2015 4 次提交
  10. 04 4月, 2015 1 次提交
    • N
      ARM: MCPM: move the algorithmic complexity to the core code · d3a87544
      Nicolas Pitre 提交于
      All backends are reimplementing a variation of the same CPU reference
      count handling. They are also responsible for driving the MCPM special
      low-level locking. This is needless duplication, involving algorithmic
      requirements that are not necessarily obvious to the uninitiated.
      And from past code review experience, those were all initially
      implemented badly.
      
      After 3 years, it is time to refactor as much common code to the core
      MCPM facility to make the backends as simple as possible.  To avoid a
      flag day, the new scheme is introduced in parallel to the existing
      backend interface.  When all backends are converted over, the
      compatibility interface could be removed.
      
      The new MCPM backend interface implements simpler methods addressing
      very platform specific tasks performed under lock protection while
      keeping the algorithmic complexity and race avoidance local to the
      core code.
      Signed-off-by: NNicolas Pitre <nico@linaro.org>
      Tested-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      d3a87544
  11. 01 4月, 2015 1 次提交
  12. 27 3月, 2015 1 次提交
    • V
      clockevents: Manage device's state separately for the core · 77e32c89
      Viresh Kumar 提交于
      'enum clock_event_mode' is used for two purposes today:
      
       - to pass mode to the driver of clockevent device::set_mode().
      
       - for managing state of the device for clockevents core.
      
      For supporting new modes/states we have moved away from the
      legacy set_mode() callback to new per-mode/state callbacks. New
      modes/states shouldn't be exposed to the legacy (now OBSOLOTE)
      callbacks and so we shouldn't add new states to 'enum
      clock_event_mode'.
      
      Lets have separate enums for the two use cases mentioned above.
      Keep using the earlier enum for legacy set_mode() callback and
      mark it OBSOLETE. And add another enum to clearly specify the
      possible states of a clockevent device.
      
      This also renames the newly added per-mode callbacks to reflect
      state changes.
      
      We haven't got rid of 'mode' member of 'struct
      clock_event_device' as it is used by some of the clockevent
      drivers and it would automatically die down once we migrate
      those drivers to the new interface. It ('mode') is only updated
      now for the drivers using the legacy interface.
      Suggested-by: NPeter Zijlstra <peterz@infradead.org>
      Suggested-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com>
      Cc: linaro-kernel@lists.linaro.org
      Cc: linaro-networking@linaro.org
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/b6b0143a8a57bd58352ad35e08c25424c879c0cb.1425037853.git.viresh.kumar@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      77e32c89
  13. 21 11月, 2014 2 次提交
  14. 18 11月, 2014 1 次提交
  15. 06 11月, 2014 1 次提交
  16. 20 10月, 2014 1 次提交
  17. 19 9月, 2014 1 次提交
  18. 26 8月, 2014 1 次提交
  19. 28 7月, 2014 2 次提交
  20. 24 7月, 2014 1 次提交
  21. 18 7月, 2014 1 次提交
    • N
      ARM: 8081/1: MCPM: provide infrastructure to allow for MCPM loopback · 3721924c
      Nicolas Pitre 提交于
      The kernel already has the responsibility to handle resources such as the
      
      CCI when hotplugging CPUs, during the booting of secondary CPUs, and when
      resuming from suspend/idle.  It would be more coherent and less confusing
      if the CCI for the boot CPU (or cluster)  was also initialized by the
      kernel rather than expecting the firmware/bootloader to do it and only in
      that case. After all, the kernel has all the necessary code already and
      the bootloader shouldn't have to care at all.
      
      The CCI may be turned on only when the cache is off. Leveraging the CPU
      suspend code to loop back through the low-level MCPM entry point is all
      that is needed to properly turn on the CCI from the kernel by using the
      same code as during secondary boot.
      
      Let's provide a generic MCPM loopback function that can be invoked by
      backend initialization code to set things (CCI or similar) on the boot
      CPU just as it is done for the other CPUs.
      Signed-off-by: NNicolas Pitre <nico@linaro.org>
      Reviewed-by: NKevin Hilman <khilman@linaro.org>
      Tested-by: NKevin Hilman <khilman@linaro.org>
      Tested-by: NDoug Anderson <dianders@chromium.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3721924c
  22. 25 6月, 2014 1 次提交
  23. 17 6月, 2014 1 次提交
  24. 28 5月, 2014 1 次提交
  25. 26 5月, 2014 1 次提交
  26. 22 5月, 2014 5 次提交