1. 29 1月, 2009 6 次提交
  2. 21 1月, 2009 1 次提交
    • T
      x86: uv cleanup · bdbcdd48
      Tejun Heo 提交于
      Impact: cleanup
      
      Make the following uv related cleanups.
      
      * collect visible uv related definitions and interfaces into uv/uv.h
        and use it.  this cleans up the messy situation where on 64bit, uv
        is defined properly, on 32bit generic it's dummy and on the rest
        undefined.  after this clean up, uv is defined on 64 and dummy on
        32.
      
      * update uv_flush_tlb_others() such that it takes cpumask of
        to-be-flushed cpus as argument, instead of that minus self, and
        returns yet-to-be-flushed cpumask, instead of modifying the passed
        in parameter.  this interface change will ease dummy implementation
        of uv_flush_tlb_others() and makes uv tlb flush related stuff
        defined in tlb_uv proper.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      bdbcdd48
  3. 18 12月, 2008 1 次提交
    • M
      x86: fix cpu_mask_to_apicid_and to include cpu_online_mask · a775a38b
      Mike Travis 提交于
      Impact: fix potential APIC crash
      
      In determining the destination apicid, there are usually three cpumasks
      that are considered: the incoming cpumask arg, cfg->domain and the
      cpu_online_mask.  Since we are just introducing the cpu_mask_to_apicid_and
      function, make sure it includes the cpu_online_mask in it's evaluation.
      [Added with this patch.]
      
      There are two io_apic.c functions that did not previously use the
      cpu_online_mask:  setup_IO_APIC_irq and msi_compose_msg.  Both of these
      simply used cpu_mask_to_apicid(cfg->domain & TARGET_CPUS), and all but
      one arch (NUMAQ[*]) returns only online cpus in the TARGET_CPUS mask,
      so the behavior is identical for all cases.
      
      [*: NUMAQ bug?]
      
      Note that alloc_cpumask_var is only used for the 32-bit cases where
      it's highly likely that the cpumask set size will be small and therefore
      CPUMASK_OFFSTACK=n.  But if that's not the case, failing the allocate
      will cause the same return value as the default.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a775a38b
  4. 17 12月, 2008 5 次提交
  5. 20 11月, 2008 1 次提交
  6. 11 11月, 2008 1 次提交
  7. 28 10月, 2008 1 次提交
  8. 27 10月, 2008 2 次提交
    • C
      x86/uv: memory allocation at initialization · ef020ab0
      Cliff Wickman 提交于
      Impact: on SGI UV platforms, fix boot crash
      
      UV initialization is currently called too late to call alloc_bootmem_pages().
      The current sequence is:
      
       start_kernel()
         mem_init()
           free_all_bootmem()           <--- discard of bootmem
         rest_init()
           kernel_init()
             smp_prepare_cpus()
             native_smp_prepare_cpus()
               uv_system_init()         <--- uses alloc_bootmem_pages()
      
      It should be calling kmalloc().
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ef020ab0
    • M
      x86/uv: provide a System Activity Indicator driver · 7f1baa06
      Mike Travis 提交于
      Impact: start per CPU heartbeat LED timers on SGI UV systems
      
      The SGI UV system has no LEDS but uses one of the system controller
      regs to indicate the online internal state of the cpu.  There is a
      heartbeat bit indicating that the cpu is responding to interrupts,
      and an idle bit indicating whether the cpu is idle when the heartbeat
      interrupt occurs.  The current period is one second.
      
      When a cpu panics, an error code is written by BIOS to this same reg.
      
      This patchset provides the following:
      
        * x86_64: Add base functionality for writing to the specific SCIR's
          for each cpu.
      
        * heartbeat: Invert "heartbeat" bit to indicate the cpu is
          "interruptible".  If the current thread is the idle thread,
          then indicate system is "idle".
      
        * if hotplug enabled, all bits are set (0xff) when the cpu is disabled.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7f1baa06
  9. 22 10月, 2008 2 次提交
  10. 16 10月, 2008 3 次提交
  11. 13 10月, 2008 2 次提交
  12. 22 8月, 2008 1 次提交
    • M
      x86: fix section mismatch warning - uv_cpu_init · c4bd1fda
      Marcin Slusarz 提交于
      WARNING: vmlinux.o(.cpuinit.text+0x3cc4): Section mismatch in reference from the function uv_cpu_init() to the function .init.text:uv_system_init()
      The function __cpuinit uv_cpu_init() references
      a function __init uv_system_init().
      If uv_system_init is only used by uv_cpu_init then
      annotate uv_system_init with a matching annotation.
      
      uv_system_init was ment to be called only once, so do it from codepath
      (native_smp_prepare_cpus) which is called once, right before activation
      of other cpus (smp_init).
      
      Note: old code relied on uv_node_to_blade being initialized to 0,
      but it'a not initialized from anywhere.
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Acked-by: NJack Steiner <steiner@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c4bd1fda
  13. 13 8月, 2008 1 次提交
    • M
      x86: fix 2 section mismatch warnings - map_high() · c9d08f08
      Marcin Slusarz 提交于
      WARNING: vmlinux.o(.text+0x14cf8): Section mismatch in reference from the function map_high() to the function .init.text:init_extra_mapping_uc()
      The function map_high() references
      the function __init init_extra_mapping_uc().
      This is often because map_high lacks a __init
      annotation or the annotation of init_extra_mapping_uc is wrong.
      
      WARNING: vmlinux.o(.text+0x14d05): Section mismatch in reference from the function map_high() to the function .init.text:init_extra_mapping_wb()
      The function map_high() references
      the function __init init_extra_mapping_wb().
      This is often because map_high lacks a __init
      annotation or the annotation of init_extra_mapping_wb is wrong.
      
      map_high is called only from __init functions (map_*_high)
      and calls 2 __init_functions (init_extra_mapping_*)
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c9d08f08
  14. 24 7月, 2008 1 次提交
  15. 23 7月, 2008 1 次提交
  16. 22 7月, 2008 1 次提交
    • Y
      x86: add apic probe for genapic 64bit, v2 · 1b9b89e7
      Yinghai Lu 提交于
      introducing an APIC handling probing abstraction:
      
       static struct genapic *apic_probe[] __initdata = {
      	&apic_x2apic_uv_x,
      	&apic_x2apic_phys,
      	&apic_x2apic_cluster,
      	&apic_physflat,
      	NULL,
       };
      
      This way we can remove UV, x2apic specific code from genapic_64.c and
      move them to their specific genapic files.
      
      [ v2: fix compiling when CONFIG_ACPI is not set ]
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Jack Steiner <steiner@sgi.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1b9b89e7
  17. 20 7月, 2008 1 次提交
  18. 18 7月, 2008 1 次提交
    • R
      x86 BIOS interface for RTC on SGI UV · 7019cc2d
      Russ Anderson 提交于
      Real-time code needs to know the number of cycles per second
      on SGI UV.  The information is provided via a run time BIOS
      call.  This patch provides the linux side of that interface.
      This is the first of several run time BIOS calls to be defined
      in uv/bios.h and bios_uv.c.
      
      Note that BIOS_CALL() is just a stub for now.  The bios
      side is being worked on.
      Signed-off-by: NRuss Anderson <rja@sgi.com>
      Cc: Jack Steiner <steiner@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7019cc2d
  19. 13 7月, 2008 1 次提交
    • Y
      x86: make 64bit have get_apic_id · f910a9dc
      Yinghai Lu 提交于
      generalize the x2apic code some more.
      
      let read_apic_id become a macro (later on a function/inline)
      GET_APIC_ID(apic_read(APIC_ID))
      
        +#define read_apic_id()  (GET_APIC_ID(apic_read(APIC_ID)))
      
      instead of this weird construct:
      
        -#define read_apic_id  (genapic->read_apic_id)
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f910a9dc
  20. 12 7月, 2008 3 次提交
  21. 09 7月, 2008 1 次提交
  22. 02 6月, 2008 1 次提交
  23. 20 4月, 2008 1 次提交
  24. 17 4月, 2008 1 次提交
    • J
      x86: support for new UV apic · ac23d4ee
      Jack Steiner 提交于
      UV supports really big systems. So big, in fact, that the APICID register
      does not contain enough bits to contain an APICID that is unique across all
      cpus.
      
      The UV BIOS supports 3 APICID modes:
      
      	- legacy mode. This mode uses the old APIC mode where
      	  APICID is in bits [31:24] of the APICID register.
      
      	- x2apic mode. This mode is whitebox-compatible. APICIDs
      	  are unique across all cpus. Standard x2apic APIC operations
      	  (Intel-defined) can be used for IPIs. The node identifier
      	  fits within the Intel-defined portion of the APICID register.
      
      	- x2apic-uv mode. In this mode, the APICIDs on each node have
      	  unique IDs, but IDs on different node are not unique. For example,
      	  if each mode has 32 cpus, the APICIDs on each node might be
      	  0 - 31. Every node has the same set of IDs.
      	  The UV hub is used to route IPIs/interrupts to the correct node.
      	  Traditional APIC operations WILL NOT WORK.
      
      In x2apic-uv mode, the ACPI tables all contain a full unique ID (note:
      exact bit layout still changing but the following is close):
      
      	nnnnnnnnnnlc0cch
      		n = unique node number
      		l = socket number on board
      		c = core
      		h = hyperthread
      
      Only the "lc0cch" bits are written to the APICID register. The remaining bits are
      supplied by having the get_apic_id() function "OR" the extra bits into the value
      read from the APICID register. (Hmmm.. why not keep the ENTIRE APICID register
      in per-cpu data....)
      
      The x2apic-uv mode is recognized by the MADT table containing:
      	  oem_id = "SGI"
      	  oem_table_id = "UV-X"
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ac23d4ee