Commit graph

15 commits

Author SHA1 Message Date
Brent Casavant
8683dc9990 [PATCH] Altix: correct ioc4 port order
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 <bcasavan@sgi.com>
Cc: Pat Gefre <pfg@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-05-03 20:05:41 -07:00
Pat Gefre
2c43630fb0 [PATCH] Altix: correct ioc3 port order
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 <pfg@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-05-01 18:17:45 -07:00
Tobias Klauser
56b146d36d [PATCH] Last DMA_xBIT_MASK cleanups
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 <tklauser@nuerscht.ch>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11 06:18:44 -07:00
Tony Luck
6a8a8e14be Pull sem2mutex-ioc4 into release branch 2006-03-21 08:17:15 -08:00
Linus Torvalds
77eebf346d Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 2006-02-28 20:56:24 -08:00
Pat Gefre
15b370c95c [PATCH] Altix: more ioc3 cleanups and locking fixes
Some "inline" removing that Andrew suggested, removed some locking on
add/remove at this level - we'll let the callees decide.

Signed-off-by: Patrick Gefre <pfg@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-28 20:53:43 -08:00
Jes Sorensen
50e300dead [IA64] show "SN Devices" menu only if CONFIG_SGI_SN
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 <tony.luck@intel.com>
2006-02-27 15:06:41 -08:00
Al Viro
d656101009 [PATCH] sn3 iomem annotations and fixes
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2006-02-08 01:03:52 -05:00
Pat Gefre
53d8be5c14 [PATCH] Altix ioc3: correct export call
Use EXPORT_SYMBOL_GPL in ioc3 shim layer.

Signed-off-by: Patrick Gefre <pfg@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-01 08:53:25 -08:00
Jes Sorensen
6e586f3293 [IA64-SGI] sem2mutex ioc4.c
Convert to use a single mutex instead of two rwsems as this isn't
performance critical.

Signed-off-by: Jes Sorensen <jes@sgi.com>
Signed-off-by: Brent Casavant <bcasavan@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
2006-01-26 13:13:00 -08:00
Patrick Gefre
2d0cfb5279 [PATCH] Altix: ioc3 serial support
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 <pfg@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-14 18:25:20 -08:00
Brent Casavant
d4c477ca54 [PATCH] ioc4: PCI bus speed detection
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 <bcasavan@sgi.com>
Acked-by: Pat Gefre <pfg@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-21 18:46:32 -07:00
Brent Casavant
e5d310b349 [PATCH] ioc4: CONFIG split
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 <bcasavan@sgi.com>
Acked-by: Pat Gefre <pfg@sgi.com>
Acked-by: Jeremy Higdon <jeremy@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-21 18:46:32 -07:00
Brent Casavant
22329b511a [PATCH] ioc4: Core driver rewrite
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 <bcasavan@sgi.com>
Acked-by: Pat Gefre <pfg@sgi.com
Acked-by: Jeremy Higdon <jeremy@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-21 18:46:32 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00