1. 03 3月, 2017 1 次提交
  2. 03 8月, 2015 1 次提交
    • A
      MIPS: SMP: Don't increment irq_count multiple times for call function IPIs · 4ace6139
      Alex Smith 提交于
      The majority of SMP platforms handle their IPIs through do_IRQ()
      which calls irq_{enter/exit}(). When a call function IPI is received,
      smp_call_function_interrupt() is called which also calls
      irq_{enter,exit}(), meaning irq_count is raised twice.
      
      When tick broadcasting is used (which is implemented via a call
      function IPI), this incorrectly causes all CPU idle time on the core
      receiving broadcast ticks to be accounted as time spent servicing
      IRQs, as account_process_tick() will account as such if irq_count is
      greater than 1. This results in 100% CPU usage being reported on a
      core which receives its ticks via broadcast.
      
      This patch removes the SMP smp_call_function_interrupt() wrapper which
      calls irq_{enter,exit}(). Platforms which handle their IPIs through
      do_IRQ() now call generic_smp_call_function_interrupt() directly to
      avoid incrementing irq_count a second time. Platforms which don't
      (loongson, sgi-ip27, sibyte) call generic_smp_call_function_interrupt()
      wrapped in irq_{enter,exit}().
      Signed-off-by: NAlex Smith <alex.smith@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/10770/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      4ace6139
  3. 27 5月, 2014 1 次提交
  4. 05 3月, 2014 1 次提交
  5. 15 7月, 2013 1 次提交
    • P
      MIPS: Delete __cpuinit/__CPUINIT usage from MIPS code · 078a55fc
      Paul Gortmaker 提交于
      commit 3747069b25e419f6b51395f48127e9812abc3596 upstream.
      
      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)
      and are flagged as __cpuinit  -- so if we remove the __cpuinit from
      the arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      related content into no-ops as early as possible, since that will get
      rid of these warnings.  In any case, they are temporary and harmless.
      
      Here, we remove all the MIPS __cpuinit from C code and __CPUINIT
      from asm files.  MIPS is interesting in this respect, because there
      are also uasm users hiding behind their own renamed versions of the
      __cpuinit macros.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      [ralf@linux-mips.org: Folded in Paul's followup fix.]
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5494/
      Patchwork: https://patchwork.linux-mips.org/patch/5495/
      Patchwork: https://patchwork.linux-mips.org/patch/5509/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      078a55fc
  6. 29 3月, 2012 1 次提交
    • R
      remove references to cpu_*_map in arch/ · 0b5f9c00
      Rusty Russell 提交于
      This has been obsolescent for a while; time for the final push.
      
      In adjacent context, replaced old cpus_* with cpumask_*.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Acked-by: David S. Miller <davem@davemloft.net> (arch/sparc)
      Acked-by: Chris Metcalf <cmetcalf@tilera.com> (arch/tile)
      Cc: user-mode-linux-devel@lists.sourceforge.net
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: linux-hexagon@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Helge Deller <deller@gmx.de>
      Cc: sparclinux@vger.kernel.org
      0b5f9c00
  7. 14 4月, 2011 1 次提交
  8. 24 9月, 2009 1 次提交
    • R
      cpumask: arch_send_call_function_ipi_mask: mips · 48a048fe
      Rusty Russell 提交于
      We're weaning the core code off handing cpumask's around on-stack.
      This introduces arch_send_call_function_ipi_mask(), and by defining
      it, the old arch_send_call_function_ipi is defined by the core code.
      
      We also take the chance to wean the implementations off the
      obsolescent for_each_cpu_mask(): making send_ipi_mask take the pointer
      seemed the most natural way to ensure all implementations used
      for_each_cpu.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      48a048fe
  9. 15 1月, 2009 1 次提交
    • M
      irq: update all arches for new irq_desc, fix · d2287f5e
      Mike Travis 提交于
      Impact: fix build errors
      
      Since the SPARSE IRQS changes redefined how the kstat irqs are
      organized, arch's must use the new accessor function:
      
      	kstat_incr_irqs_this_cpu(irq, DESC);
      
      If CONFIG_SPARSE_IRQS is set, then DESC is a pointer to the
      irq_desc which has a pointer to the kstat_irqs.  If not, then
      the .irqs field of struct kernel_stat is used instead.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d2287f5e
  10. 13 12月, 2008 1 次提交
    • 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
  11. 29 1月, 2008 1 次提交
  12. 23 10月, 2007 1 次提交
    • R
      [MIPS] time: SMP-proofing of Sibyte clockevent/clocksource code. · d0453365
      Ralf Baechle 提交于
      The BCM148 has 4 cores but there are also just 4 generic timers available
      so use the ZBbus cycle counter instead of it.  In addition the ZBbus
      counter also offers a much higher resolution and 64-bit counting so I'm
      considering a later complete conversion to it once I figure out if all
      members of the Sibyte SOC family support it - the docs seem to agree but
      the headers files seem to disagree ...
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      d0453365
  13. 20 10月, 2007 1 次提交
  14. 08 10月, 2006 1 次提交
  15. 30 10月, 2005 1 次提交
  16. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4