1. 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
  2. 04 10月, 2008 3 次提交
  3. 26 6月, 2008 1 次提交
    • J
      mips: convert to generic helpers for IPI function calls · 2f304c0a
      Jens Axboe 提交于
      This converts mips to use the new helpers for smp_call_function() and
      friends, and adds support for smp_call_function_single(). Not tested,
      but it compiles.
      
      mips shares the same IPI for smp_call_function() and
      smp_call_function_single(), since not all mips platforms have enough
      available IPIs to support seperate setups.
      
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      2f304c0a
  4. 29 4月, 2008 2 次提交
  5. 03 2月, 2008 1 次提交
  6. 29 1月, 2008 1 次提交
  7. 30 10月, 2007 1 次提交
    • K
      [MIPS] SMTC: Allow control over TC assignment to vpe0. · be5f1f21
      Kevin D. Kissell 提交于
      Modify the SMTC initialization code to allow boot-time specification not
      only of how many VPEs and TCs to use, but also how many TCs out of the
      allowed pool are to be bound to VPE 0.  The new boot option is "vpe0tcs=N",
      where N is an integer.  Using it in combination with the existing options
      allows arbitrary assignments across the 2 VPEs of a 34K.  e.g. "maxtcs=3
       vpe0tcs=1" forces VPE0 to have 1 TC, while VPE1 has 2, and "maxtcs=4
      vpe0tcs=3" forces VPE0 to have 3 TCs, while VPE1 gets 1.  If no vpe0tcs
      option is specified, the traditional algorithm of evenly dividing TCs
      between available VPEs, with the odd "slop" going to VPE0, is retained.
      
      The reason for doing this is to allow a finer balancing of TCs which can
      handle I/O interrupts on Malta (those on VPE 0) and those which cannot.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      be5f1f21
  8. 12 10月, 2007 8 次提交
  9. 25 9月, 2007 1 次提交
  10. 27 8月, 2007 1 次提交
  11. 01 8月, 2007 5 次提交
  12. 11 7月, 2007 1 次提交
  13. 27 6月, 2007 1 次提交
  14. 21 6月, 2007 1 次提交
  15. 12 6月, 2007 1 次提交
  16. 10 5月, 2007 1 次提交
  17. 30 3月, 2007 3 次提交
  18. 27 2月, 2007 1 次提交
  19. 07 2月, 2007 4 次提交
  20. 25 1月, 2007 2 次提交