aboutsummaryrefslogtreecommitdiff
path: root/drivers/ide/pci/sgiioc4.c
AgeCommit message (Collapse)Author
2006-09-01[PATCH] sgiioc4: fixup use of mmio opsJohn Keller
Fix some bugs in the patch that converted the IOC4 driver from port IO ops to memio ops. http://marc.theaimsgroup.com/?l=linux-ide&m=114895892231438&w=2 Problems fixed are: - Call to default_hwif_mmiops() was not being done until _after_ first IO operation, resulting in the first IO operation being done as a port IO op, instead of memio. - request_region() calls needed to be request_mem_region() - Incomplete error case handling. - Non-usage of ioremap() and __iomem. Signed-off-by: John Keller <jpk@sgi.com> Signed-off-by: Jeremy Higdon <jeremy@sgi.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-23[PATCH] SGI IOC4: Detect IO card variantBrent Casavant
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 <bcasavan@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-05-31[PATCH] sgiioc4: use mmio ops instead of port ioJeremy Higdon
From: Jeremy Higdon <jeremy@sgi.com> This patch fixes a bug in sgiioc4 where it was using the default IDE port I/O operations instead of MMIO. The IDE part of the IOC4 chip uses MMIO to map the chip registers. Unfortunately, the sgiioc4 driver uses the default port IO operations, which happens to have worked for the past few years. That's about to change, however, thus this change from inX/outX to readX/writeX. Signed-off-by: Jeremy Higdon <jeremy@sgi.com> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-15[IA64] remove obsolete corporate addressJes Sorensen
Remove obsolete SGI address Signed-off-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2006-02-02[PATCH] Fix sgiioc4 DMA timeout problem with 64KiB s/g elements.Jeremy Higdon
Problem caused by the fact that the code used to only pick the low 16 bits of the bytecount. That may be how some controllers act on it (byte count of 0 means 0x10000), but not for this particular hardware. Signed-off-by: Jeremy Higdon <jeremy@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-12-15[PATCH] sgiioc4: check for no hwifs availableJeremy Higdon
Add a check to the sgiioc4 driver for the case where all available ide_hwifs structures are in use. Signed-off-by: Jeremy Higdon <jeremy@sgi.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2005-06-21[PATCH] ioc4: Core driver rewriteBrent 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 <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-04-16Linux-2.6.12-rc2Linus Torvalds
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!