1. 05 6月, 2014 1 次提交
    • C
      sh: Replace __get_cpu_var uses · c473b2c6
      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 calculations are avoided and less
      registers are used when code is generated.
      
      At the end of the patch set all uses of __get_cpu_var have been removed so
      the macro is removed too.
      
      The patch set 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, y);
      	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(&x, this_cpu_ptr(&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)
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> [compilation only]
      Cc: Paul Mundt <lethal@linux-sh.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c473b2c6
  2. 15 7月, 2013 1 次提交
    • P
      sh: delete __cpuinit usage from all sh files · 4603f53a
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      are flagged as __cpuinit  -- so if we remove the __cpuinit from
      arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      content into no-ops as early as possible, since that will get rid
      of these warnings.  In any case, they are temporary and harmless.
      
      This removes all the arch/sh uses of the __cpuinit macros from
      all C files.  Currently sh does not have any __CPUINIT used in
      assembly files.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: linux-sh@vger.kernel.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      4603f53a
  3. 08 4月, 2013 1 次提交
  4. 01 6月, 2012 1 次提交
  5. 26 4月, 2012 2 次提交
  6. 30 3月, 2012 1 次提交
  7. 29 3月, 2012 1 次提交
  8. 24 2月, 2012 1 次提交
  9. 27 7月, 2011 1 次提交
  10. 14 4月, 2011 1 次提交
  11. 29 4月, 2010 1 次提交
  12. 26 4月, 2010 5 次提交
  13. 21 4月, 2010 1 次提交
  14. 29 3月, 2010 1 次提交
    • M
      sh: Enable the mmu in start_secondary() · 4bea3418
      Matt Fleming 提交于
      For the boot, enable_mmu() is called from setup_arch() but we don't call
      setup_arch() for any of the other cpus. So turn on the non-boot cpu's
      mmu inside of start_secondary().
      
      I noticed this bug on an SMP board when trying to map I/O memory
      (smsc911x registers) into the kernel address space. Since the Address
      Translation bit in MMUCR wasn't set, accessing the virtual address where
      the smsc911x registers were supposedly mapped actually performed a
      physical address access.
      Signed-off-by: NMatt Fleming <matt@console-pimps.org>
      Cc: stable@kernel.org
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      4bea3418
  15. 20 1月, 2010 1 次提交
    • P
      sh: machine_ops based reboot support. · fbb82b03
      Paul Mundt 提交于
      This provides a machine_ops-based reboot interface loosely cloned from
      x86, and converts the native sh32 and sh64 cases over to it.
      
      Necessary both for tying in SMP support and also enabling platforms like
      SDK7786 to add support for their microcontroller-based power managers.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      fbb82b03
  16. 14 10月, 2009 2 次提交
  17. 14 6月, 2009 2 次提交
  18. 13 12月, 2008 2 次提交
    • R
      cpumask: convert struct clock_event_device to cpumask pointers. · 320ab2b0
      Rusty Russell 提交于
      Impact: change calling convention of existing clock_event APIs
      
      struct clock_event_timer's cpumask field gets changed to take pointer,
      as does the ->broadcast function.
      
      Another single-patch change.  For safety, we BUG_ON() in
      clockevents_register_device() if it's not set.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Ingo Molnar <mingo@elte.hu>
      320ab2b0
    • R
      cpumask: centralize cpu_online_map and cpu_possible_map · 98a79d6a
      Rusty Russell 提交于
      Impact: cleanup
      
      Each SMP arch defines these themselves.  Move them to a central
      location.
      
      Twists:
      1) Some archs (m32, parisc, s390) set possible_map to all 1, so we add a
         CONFIG_INIT_ALL_POSSIBLE for this rather than break them.
      
      2) mips and sparc32 '#define cpu_possible_map phys_cpu_present_map'.
         Those archs simply have phys_cpu_present_map replaced everywhere.
      
      3) Alpha defined cpu_possible_map to cpu_present_map; this is tricky
         so I just manipulate them both in sync.
      
      4) IA64, cris and m32r have gratuitous 'extern cpumask_t cpu_possible_map'
         declarations.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Reviewed-by: NGrant Grundler <grundler@parisc-linux.org>
      Tested-by: NTony Luck <tony.luck@intel.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Mike Travis <travis@sgi.com>
      Cc: ink@jurassic.park.msu.ru
      Cc: rmk@arm.linux.org.uk
      Cc: starvik@axis.com
      Cc: tony.luck@intel.com
      Cc: takata@linux-m32r.org
      Cc: ralf@linux-mips.org
      Cc: grundler@parisc-linux.org
      Cc: paulus@samba.org
      Cc: schwidefsky@de.ibm.com
      Cc: lethal@linux-sh.org
      Cc: wli@holomorphy.com
      Cc: davem@davemloft.net
      Cc: jdike@addtoit.com
      Cc: mingo@redhat.com
      98a79d6a
  19. 21 10月, 2008 1 次提交
  20. 09 9月, 2008 1 次提交
    • M
      kernel/cpu.c: create a CPU_STARTING cpu_chain notifier · e545a614
      Manfred Spraul 提交于
      Right now, there is no notifier that is called on a new cpu, before the new
      cpu begins processing interrupts/softirqs.
      Various kernel function would need that notification, e.g. kvm works around
      by calling smp_call_function_single(), rcu polls cpu_online_map.
      
      The patch adds a CPU_STARTING notification. It also adds a helper function
      that sends the message to all cpu_chain handlers.
      
      Tested on x86-64.
      All other archs are untested. Especially on sparc, I'm not sure if I got
      it right.
      Signed-off-by: NManfred Spraul <manfred@colorfullife.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e545a614
  21. 08 9月, 2008 3 次提交
  22. 26 6月, 2008 3 次提交
  23. 21 3月, 2008 1 次提交
  24. 21 9月, 2007 2 次提交
  25. 31 5月, 2007 1 次提交
  26. 02 10月, 2006 1 次提交
  27. 01 7月, 2006 1 次提交