1. 18 6月, 2015 1 次提交
  2. 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
  3. 01 4月, 2015 1 次提交
  4. 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
  5. 21 11月, 2014 2 次提交
  6. 18 11月, 2014 1 次提交
  7. 06 11月, 2014 1 次提交
  8. 20 10月, 2014 1 次提交
  9. 19 9月, 2014 1 次提交
  10. 26 8月, 2014 1 次提交
  11. 28 7月, 2014 2 次提交
  12. 24 7月, 2014 1 次提交
  13. 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
  14. 25 6月, 2014 1 次提交
  15. 17 6月, 2014 1 次提交
  16. 28 5月, 2014 1 次提交
  17. 26 5月, 2014 1 次提交
  18. 22 5月, 2014 7 次提交
  19. 30 4月, 2014 1 次提交
  20. 29 4月, 2014 1 次提交
    • T
      ARM: common: edma: Fix xbar mapping · cf7eb979
      Thomas Gleixner 提交于
      This is another great example of trainwreck engineering:
      
      commit 2646a0e529 (ARM: edma: Add EDMA crossbar event mux support)
      added support for using EDMA on peripherals which have no direct EDMA
      event mapping.
      
      The code compiles and does not explode in your face, but that's it.
      
      1) Reading an u16 array from an u32 device tree array simply does not
         work. Even if the function is named "edma_of_read_u32_to_s16_array".
      
         It merily calls of_property_read_u16_array. So the resulting 16bit
         array will have every other entry = 0.
      
      2) The DT entry for the xbar registers related to xbar has length 0x10
         instead of the real length: 0xfd0 - 0xf90 = 0x40.
      
         Not a real problem as it does not cross a page boundary, but
         wrong nevertheless.
      
      3) But none of this matters as the mapping never happens:
      
         After reading nonsense edma_of_read_u32_to_s16_array() invalidates
         the first array entry pair, so nobody can ever notice the
         braindamage by immediate explosion.
      
      Seems the QA criteria for this code was solely not to explode when
      someone adds edma-xbar-event-map entries to the DT. Goal achieved,
      congratulations!
      
      Not really helpful if someone wants to use edma on a device which
      requires a xbar mapping.
      
      Fix the issues by:
      
      - annotating the device tree entry with "/bits/ 16" as documented in
        the of_property_read_u16_array kernel doc
      
      - make the size of the xbar register mapping correct
      
      - invalidating the end of the array and not the start
      
      This convoluted mess wants to be completely rewritten as there is no
      point to keep the xbar_chan array memory and the iomapping of the xbar
      regs around forever. Marking the xbar mapped channels as used should
      be done right there.
      
      But that's a different issue and this patch is small enough to make it
      work and allows a simple backport for stable.
      
      Cc: stable@vger.kernel.org # v3.12+
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      cf7eb979
  21. 23 4月, 2014 3 次提交
  22. 20 3月, 2014 1 次提交
  23. 19 2月, 2014 1 次提交
    • D
      ARM: 7962/2: Make all mcpm functions notrace · ea36d2ab
      Dave Martin 提交于
      The functions in mcpm_entry.c are mostly intended for use during
      scary cache and coherency disabling sequences, or do other things
      which confuse trace ... like powering a CPU down and not
      returning. Similarly for the backend code.
      
      For simplicity, this patch just makes whole files notrace.
      There should be more than enough traceable points on the paths to
      these functions, but we can be more fine-grained later if there is
      a need for it.
      
      Jon Medhurst:
      Also added spc.o to the list of files as it contains functions used by
      MCPM code which have comments comments like: "might be used in code
      paths where normal cacheable locks are not working"
      Signed-off-by: NDave Martin <dave.martin@linaro.org>
      Signed-off-by: NJon Medhurst <tixy@linaro.org>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ea36d2ab
  24. 13 2月, 2014 1 次提交
  25. 29 12月, 2013 2 次提交
  26. 12 12月, 2013 1 次提交
  27. 22 11月, 2013 1 次提交
  28. 07 11月, 2013 1 次提交
  29. 30 10月, 2013 1 次提交