14 Aug, 2007

1 commit


26 Jul, 2007

1 commit


19 Mar, 2007

1 commit

  • Add a missing #define for the platform_kernel_launch_event. Without this
    fix, a call to platform_kernel_launch_event() becomes a noop on generic
    kernels. SN systems require this fix to successfully kdump/kexec from
    certain hardware errors.

    [bwalle@suse.de: fix it]
    Signed-off-by: John Keller
    Cc: Bernhard Walle
    Acked-by: Simon Horman
    Acked-by: Jay Lan
    Acked-by: "Luck, Tony"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    John Keller
     

08 Feb, 2007

1 commit

  • The arch hooks arch_setup_msi_irq and arch_teardown_msi_irq are now
    responsible for allocating and freeing the linux irq in addition to
    setting up the the linux irq to work with the interrupt.

    arch_setup_msi_irq now takes a pci_device and a msi_desc and returns
    an irq.

    With this change in place this code should be useable by all platforms
    except those that won't let the OS touch the hardware like ppc RTAS.

    Signed-off-by: Eric W. Biederman
    Acked-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Eric W. Biederman
     

08 Dec, 2006

1 commit

  • Changes and updates.

    1. Remove fake rendz path and related code according to discuss with Khalid Aziz.
    2. fc.i offset fix in relocate_kernel.S.
    3. iospic shutdown code eoi and mask race fix from Fujitsu.
    4. Warm boot hook in machine_kexec to SN SAL code from Jack Steiner.
    5. Send slave to SAL slave loop patch from Jay Lan.
    6. Kdump on non-recoverable MCA event patch from Jay Lan
    7. Use CTL_UNNUMBERED in kdump_on_init sysctl.

    Signed-off-by: Zou Nan hai
    Signed-off-by: Tony Luck

    Zou Nan hai
     

02 Dec, 2006

1 commit

  • First phase in introducing ACPI support to SN.
    In this phase, when running with an ACPI capable PROM,
    the DSDT will define the root busses and all SN nodes
    (SGIHUB, SGITIO). An ACPI bus driver will be registered
    for the node devices, with the acpi_pci_root_driver being
    used for the root busses. An ACPI vendor descriptor is
    now used to pass platform specific information for both
    nodes and busses, eliminating the need for the current
    SAL calls. Also, with ACPI support, SN fixup code is no longer
    needed to initiate the PCI bus scans, as the acpi_pci_root_driver
    does that.

    However, to maintain backward compatibility with non-ACPI capable
    PROMs, none of the current 'fixup' code can been deleted, though
    much restructuring has been done. For example, the bulk of the code
    in io_common.c is relocated code that is now common regardless
    of what PROM is running, while io_acpi_init.c and io_init.c contain
    routines specific to an ACPI or non ACPI capable PROM respectively.

    A new pci bus fixup platform vector has been created to provide
    a hook for invoking platform specific bus fixup from pcibios_fixup_bus().

    The size of io_space[] has been increased to support systems with
    large IO configurations.

    Signed-off-by: John Keller
    Signed-off-by: Greg Kroah-Hartman

    John Keller
     

05 Oct, 2006

1 commit

  • Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
    of passing regs around manually through all ~1800 interrupt handlers in the
    Linux kernel.

    The regs pointer is used in few places, but it potentially costs both stack
    space and code to pass it around. On the FRV arch, removing the regs parameter
    from all the genirq function results in a 20% speed up of the IRQ exit path
    (ie: from leaving timer_interrupt() to leaving do_IRQ()).

    Where appropriate, an arch may override the generic storage facility and do
    something different with the variable. On FRV, for instance, the address is
    maintained in GR28 at all times inside the kernel as part of general exception
    handling.

    Having looked over the code, it appears that the parameter may be handed down
    through up to twenty or so layers of functions. Consider a USB character
    device attached to a USB hub, attached to a USB controller that posts its
    interrupts through a cascaded auxiliary interrupt controller. A character
    device driver may want to pass regs to the sysrq handler through the input
    layer which adds another few layers of parameter passing.

    I've build this code with allyesconfig for x86_64 and i386. I've runtested the
    main part of the code on FRV and i386, though I can't test most of the drivers.
    I've also done partial conversion for powerpc and MIPS - these at least compile
    with minimal configurations.

    This will affect all archs. Mostly the changes should be relatively easy.
    Take do_IRQ(), store the regs pointer at the beginning, saving the old one:

    struct pt_regs *old_regs = set_irq_regs(regs);

    And put the old one back at the end:

    set_irq_regs(old_regs);

    Don't pass regs through to generic_handle_irq() or __do_IRQ().

    In timer_interrupt(), this sort of change will be necessary:

    - update_process_times(user_mode(regs));
    - profile_tick(CPU_PROFILING, regs);
    + update_process_times(user_mode(get_irq_regs()));
    + profile_tick(CPU_PROFILING);

    I'd like to move update_process_times()'s use of get_irq_regs() into itself,
    except that i386, alone of the archs, uses something other than user_mode().

    Some notes on the interrupt handling in the drivers:

    (*) input_dev() is now gone entirely. The regs pointer is no longer stored in
    the input_dev struct.

    (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
    something different depending on whether it's been supplied with a regs
    pointer or not.

    (*) Various IRQ handler function pointers have been moved to type
    irq_handler_t.

    Signed-Off-By: David Howells
    (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)

    David Howells
     

04 Oct, 2006

1 commit

  • It turns out msi_ops was simply not enough to abstract the architecture
    specific details of msi. So I have moved the resposibility of constructing
    the struct irq_chip to the architectures, and have two architecture specific
    functions arch_setup_msi_irq, and arch_teardown_msi_irq.

    For simple architectures those functions can do all of the work. For
    architectures with platform dependencies they can call into the appropriate
    platform code.

    With this msi.c is finally free of assuming you have an apic, and this
    actually takes less code.

    The helpers for the architecture specific code are declared in the linux/msi.h
    to keep them separate from the msi functions used by drivers in linux/pci.h

    Signed-off-by: Eric W. Biederman
    Cc: Ingo Molnar
    Cc: Tony Luck
    Cc: Andi Kleen
    Cc: Thomas Gleixner
    Cc: Greg KH
    Cc: Benjamin Herrenschmidt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     

22 Jun, 2006

1 commit

  • Abstract portions of the MSI core for platforms that do not use standard
    APIC interrupt controllers. This is implemented through a new arch-specific
    msi setup routine, and a set of msi ops which can be set on a per platform
    basis.

    Signed-off-by: Mark Maule
    Signed-off-by: Greg Kroah-Hartman

    Mark Maule
     

29 Apr, 2006

1 commit


26 Apr, 2006

1 commit


21 Apr, 2006

1 commit

  • This patch removes following compile time warnings:

    drivers/pci/pci-sysfs.c: In function `pci_read_legacy_io':
    drivers/pci/pci-sysfs.c:257: warning: implicit declaration of function `ia64_pci_legacy_read'
    drivers/pci/pci-sysfs.c: In function `pci_write_legacy_io':
    drivers/pci/pci-sysfs.c:280: warning: implicit declaration of function `ia64_pci_legacy_write'

    It also fixes wrong definition of ia64_pci_legacy_write (type of `bus' is not
    `pci_dev', but `pci_bus').

    Signed-Off-By: Satoru Takeuchi
    Signed-off-by: Tony Luck

    Satoru Takeuchi
     

27 Jan, 2006

1 commit

  • On SN2, MMIO writes which are issued from separate processors are not
    guaranteed to arrive in any particular order at the IO hardware. When
    performing such writes from the kernel this is not a problem, as a
    kernel thread will not migrate to another CPU during execution, and
    mmiowb() calls can guarantee write ordering when control of the IO
    resource is allowed to move between threads.

    However, when MMIO writes can be performed from user space (e.g. DRM)
    there are no such guarantees and mechanisms, as the process may
    context-switch at any time, and may migrate to a different CPU as part
    of the switch. For such programs/hardware to operate correctly, it is
    required that the MMIO writes from the old CPU be accepted by the IO
    hardware before subsequent writes from the new CPU can be issued.

    The following patch implements this behavior on SN2 by waiting for a
    Shub register to indicate that these writes have been accepted. This
    is placed in the context switch-in path, and only performs the wait
    when the newly scheduled task changes CPUs.

    Signed-off-by: Prarit Bhargava
    Signed-off-by: Brent Casavant

    Brent Casavant
     

29 Oct, 2005

1 commit


28 Oct, 2005

2 commits

  • ... and related annotations for amd64 - swiotlb code is shared, but
    prototypes are not.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • flush_tlb_all() can be a scaling issue on large SGI Altix systems
    since it uses the global call_lock and always executes on all cpus.
    When a process enters flush_tlb_range() to purge TLBs for another
    process, it is possible to avoid flush_tlb_all() and instead allow
    sn2_global_tlb_purge() to purge TLBs only where necessary.

    This patch modifies flush_tlb_range() so that this case can be handled
    by platform TLB purge functions and updates ia64_global_tlb_purge()
    accordingly. sn2_global_tlb_purge() now calculates the region register
    value from the mm argument introduced with this patch.

    Signed-off-by: Dean Roe
    Signed-off-by: Tony Luck

    Dean Roe
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds