03 Jul, 2006

1 commit


01 Jul, 2006

1 commit


30 Jun, 2006

1 commit

  • Documention/pci.txt states..
    "The struct pci_driver shouldn't be marked with any of these tags."
    (Referring to __devinit and friends).

    (akpm: good documentation, that. Link this driver into vmlinux with hotplug
    CPU disabled and it'll crash).

    Signed-off-by: Dave Jones
    Cc: Brent Casavant
    Cc: Pat Gefre
    Cc: Jes Sorensen
    Cc: Tony Luck
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Jones
     

28 Jun, 2006

1 commit

  • locking init cleanups:

    - convert " = SPIN_LOCK_UNLOCKED" to spin_lock_init() or DEFINE_SPINLOCK()
    - convert rwlocks in a similar manner

    this patch was generated automatically.

    Motivation:

    - cleanliness
    - lockdep needs control of lock initialization, which the open-coded
    variants do not give
    - it's also useful for -rt and for lock debugging in general

    Signed-off-by: Ingo Molnar
    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

23 Jun, 2006

1 commit

  • There are three different IO cards which an SGI IOC4 controller may find
    itself on. One of these variants does not bring out the IDE and serial
    signals, so we need to disable attaching the corresponding IOC4 subdrivers
    to such cards.

    Cleans up message clutter emitted during device probing.

    Signed-off-by: Brent Casavant
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Brent Casavant
     

04 May, 2006

1 commit

  • Currently loading the ioc3 as a module will cause the ports to be numbered
    in reverse order. This mod maintains the proper order of cards for port
    numbering.

    Signed-off-by: Brent Casavant
    Cc: Pat Gefre
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Brent Casavant
     

02 May, 2006

1 commit

  • Currently loading the ioc3 as a module will cause the ports to be numbered
    in reverse order. This mod maintains the proper order of cards for port
    numbering.

    Signed-off-by: Patrick Gefre
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pat Gefre
     

11 Apr, 2006

1 commit

  • These are the last conversions of pci_set_dma_mask(),
    pci_set_consistent_dma_mask() and pci_dma_supported() to use DMA_xBIT_MASK
    constants from linux/dma-mapping.h

    Signed-off-by: Tobias Klauser
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tobias Klauser
     

22 Mar, 2006

1 commit


01 Mar, 2006

2 commits


28 Feb, 2006

1 commit

  • Adrian> On architectures like i386, the "Multimedia Capabilities Port
    Adrian> drivers" menu is visible, but it can't be visited since it
    Adrian> contains nothing usable for CONFIG_SGI_SN=n.

    Jes> Thats only a third of the patch, if you want to do that, you should
    Jes> remove the redundant SGI_SN checks below.

    Signed-off-by: Tony Luck

    Jes Sorensen
     

08 Feb, 2006

1 commit


02 Feb, 2006

1 commit


27 Jan, 2006

1 commit


15 Jan, 2006

1 commit

  • Add driver support for a 2 port PCI IOC3-based serial card on Altix boxes:

    This is a re-submission. On the original submission I was asked to
    organize the code so that the MIPS ioc3 ethernet and serial parts could be
    used with this driver. Stanislaw Skowronek was kind enough to provide the
    shim layer for this - thanks Stanislaw. This patch includes the shim layer
    and the Altix PCI ioc3 serial driver. The MIPS merged ioc3 ethernet and
    serial support is forthcoming.

    Signed-off-by: Patrick Gefre
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Patrick Gefre
     

22 Jun, 2005

3 commits

  • Several hardware features of SGI's IOC4 I/O controller chip require
    timing-related driver calculations dependent upon the PCI bus speed. This
    patch enables the core IOC4 driver code to detect the actual bus speed and
    store a value that can later be used by the IOC4 subdrivers as needed.

    Signed-off-by: Brent Casavant
    Acked-by: Pat Gefre
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Brent Casavant
     
  • The SGI IOC4 I/O controller chip drivers are currently all configured by
    CONFIG_BLK_DEV_SGIIOC4. This is undesirable as not all IOC4 hardware features
    are needed by all systems.

    This patch adds two configuration variables, CONFIG_SGI_IOC4 for core IOC4
    driver support (see patch 1/3 in this series for further explanation) and
    CONFIG_SERIAL_SGI_IOC4 to independently enable serial port support.

    Signed-off-by: Brent Casavant
    Acked-by: Pat Gefre
    Acked-by: Jeremy Higdon
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Brent Casavant
     
  • This series of patches reworks the configuration and internal structure
    of the SGI IOC4 I/O controller device drivers.

    These changes are motivated by several factors:

    - The IOC4 chip PCI resources are of mixed use between functions (i.e.
    multiple functions are handled in the same address range, sometimes
    within the same register), muddling resource ownership and initialization
    issues. Centralizing this ownership in a core driver is desirable.

    - The IOC4 chip implements multiple functions (serial, IDE, others not
    yet implemented in the mainline kernel) but is not a multifunction
    PCI device. In order to properly handle device addition and removal
    as well as module insertion and deletion, an intermediary IOC4-specific
    driver layer is needed to handle these operations cleanly.

    - All IOC4 drivers are currently enabled by a single CONFIG value. As
    not all systems need all IOC4 functions, it is desireable to enable
    these drivers independently.

    - The current IOC4 core driver will trigger loading of all function-level
    drivers, as it makes direct calls to them. This situation should be
    reversed (i.e. function-level drivers cause loading of core driver)
    in order to maintain a clear and least-surprise driver loading model.

    - IOC4 hardware design necessitates some driver-level dependency on
    the PCI bus clock speed. Current code assumes a 66MHz bus, but the
    speed should be autodetected and appropriate compensation taken.

    This patch series effects the above changes by a newly and better designed
    IOC4 core driver with which the function-level drivers can register and
    deregister themselves upon module insertion/removal. By tracking these
    modules, device addition/removal is also handled properly. PCI resource
    management and ownership issues are centralized in this core driver, and
    IOC4-wide configuration actions such as bus speed detection are also
    handled in this core driver.

    This patch:

    The SGI IOC4 I/O controller chip implements multiple functions, though it is
    not a multi-function PCI device. Additionally, various PCI resources of the
    IOC4 are shared by multiple hardware functions, and thus resource ownership by
    driver is not clearly delineated. Due to the current driver design, all core
    and subordinate drivers must be loaded, or none, which is undesirable if not
    all IOC4 hardware features are being used.

    This patch reorganizes the IOC4 drivers so that the core driver provides a
    subdriver registration service. Through appropriate callbacks the subdrivers
    can now handle device addition and removal, as well as module insertion and
    deletion (though the IOC4 IDE driver requires further work before module
    deletion will work). The core driver now takes care of allocating PCI
    resources and data which must be shared between subdrivers, to clearly
    delineate module ownership of these items.

    Signed-off-by: Brent Casavant
    Acked-by: Pat Gefre
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Brent Casavant
     

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