triton.c

GNU Mach 微内核源代码, 基于美国卡内基美隆大学的 Mach 研究项目

/*
 *  linux/drivers/block/triton.c	Version 1.13  Aug 12, 1996
 *
 *  Copyright (c) 1995-1996  Mark Lord
 *  May be copied or modified under the terms of the GNU General Public License
 */

/*
 * This module provides support for the Bus Master IDE DMA function
 * of the Intel PCI Triton I/II chipsets (i82371FB or i82371SB).
 *
 * Pretty much the same code will work for the OPTi "Viper" chipset.
 * Look for DMA support for this in linux kernel 2.1.xx, when it appears.
 *
 * DMA is currently supported only for hard disk drives (not cdroms).
 *
 * Support for cdroms will likely be added at a later date,
 * after broader experience has been obtained with hard disks.
 *
 * Up to four drives may be enabled for DMA, and the Triton chipset will
 * (hopefully) arbitrate the PCI bus among them.  Note that the i82371 chip
 * provides a single "line buffer" for the BM IDE function, so performance of
 * multiple (two) drives doing DMA simultaneously will suffer somewhat,
 * as they contest for that resource bottleneck.  This is handled transparently
 * inside the i82371 chip.
 *
 * By default, DMA support is prepared for use, but is currently enabled only
 * for drives which support multi-word DMA mode2 (mword2), or which are
 * recognized as "good" (see table below).  Drives with only mode0 or mode1
 * (single or multi) DMA should also work with this chipset/driver (eg. MC2112A)
 * but are not enabled by default.  Use "hdparm -i" to view modes supported
 * by a given drive.
 *
 * The hdparm-2.4 (or later) utility can be used for manually enabling/disabling
 * DMA support, but must be (re-)compiled against this kernel version or later.
 *
 * To enable DMA, use "hdparm -d1 /dev/hd?" on a per-drive basis after booting.
 * If problems arise, ide.c will disable DMA operation after a few retries.
 * This error recovery mechanism works and has been extremely well exercised.
 *
 * IDE drives, depending on their vintage, may support several different modes
 * of DMA operation.  The boot-time modes are indicated with a "*" in
 * the "hdparm -i" listing, and can be changed with *knowledgeable* use of
 * the "hdparm -X" feature.  There is seldom a need to do this, as drives
 * normally power-up with their "best" PIO/DMA modes enabled.
 *
 * Testing was done with an ASUS P55TP4XE/100 system and the following drives:
 *
 *   Quantum Fireball 1080A (1Gig w/83kB buffer), DMA mode2, PIO mode4.
 *	- DMA mode2 works well (7.4MB/sec), despite the tiny on-drive buffer.
 *	- This drive also does PIO mode4, at about the same speed as DMA mode2.
 *	  An awesome drive for the price!
 *
 *   Fujitsu M1606TA (1Gig w/256kB buffer), DMA mode2, PIO mode4.
 *	- DMA mode2 gives horrible performance (1.6MB/sec), despite the good
 *	  size of the on-drive buffer and a boasted 10ms average access time.
 *	- PIO mode4 was better, but peaked at a mere 4.5MB/sec.
 *
 *   Micropolis MC2112A (1Gig w/508kB buffer), drive pre-dates EIDE and ATA2.
 *	- DMA works fine (2.2MB/sec), probably due to the large on-drive buffer.
 *	- This older drive can also be tweaked for fastPIO (3.7MB/sec) by using
 *	  maximum clock settings (5,4) and setting all flags except prefetch.
 *
 *   Western Digital AC31000H (1Gig w/128kB buffer), DMA mode1, PIO mode3.
 *	- DMA does not work reliably.  The drive appears to be somewhat tardy
 *	  in deasserting DMARQ at the end of a sector.  This is evident in
 *	  the observation that WRITEs work most of the time, depending on
 *	  cache-buffer occupancy, but multi-sector reads seldom work.
 *
 * Testing was done with a Gigabyte GA-586 ATE system and the following drive:
 * (Uwe Bonnes - [e-mail])
 *
 *   Western Digital AC31600H (1.6Gig w/128kB buffer), DMA mode2, PIO mode4.
 *	- much better than its 1Gig cousin, this drive is reported to work
 *	  very well with DMA (7.3MB/sec).
 *
 * Other drives:
 *
 *   Maxtor 7540AV (515Meg w/32kB buffer), DMA modes mword0/sword2, PIO mode3.
 *	- a budget drive, with budget performance, around 3MB/sec.
 *
 *   Western Digital AC2850F (814Meg w/64kB buffer), DMA mode1, PIO mode3.
 *	- another "caviar" drive, similar to the AC31000, except that this one
 *	  worked with DMA in at least one system.  Throughput is about 3.8MB/sec
 *	  for both DMA and PIO.
 *
 *   Conner CFS850A (812Meg w/64kB buffer), DMA mode2, PIO mode4.
 *	- like most Conner models, this drive proves that even a fast interface
 *	  cannot improve slow media.  Both DMA and PIO peak around 3.5MB/sec.
 *
 *   Maxtor 71260AT (1204Meg w/256kB buffer), DMA mword0/sword2, PIO mode3.
 *	- works with DMA, on some systems (but not always on others, eg. Dell),
 *	giving 3-4MB/sec performance, about the same as mode3.
 *
 * If you have any drive models to add, email your results to:  [e-mail]
 * Keep an eye on /var/adm/messages for "DMA disabled" messages.
 *
 * Some people have reported trouble with Intel Zappa motherboards.
 * This can be fixed by upgrading the AMI BIOS to version 1.00.04.BS0,
 * available from ftp://ftp.intel.com/pub/bios/10004bs0.exe
 * (thanks to Glen Morrell <[e-mail]> for researching this).
 *
 * And, yes, Intel Zappa boards really *do* use the Triton IDE ports.
 */
#include <linux/config.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/timer.h>
#include <linux/mm.h>
#include <linux/ioport.h>
#include <linux/interrupt.h>
#include <linux/blkdev.h>
#include <linux/hdreg.h>
#include <linux/pci.h>
#include <linux/bios32.h>

#include <asm/io.h>
#include <asm/dma.h>

#include "ide.h"

#undef DISPLAY_TRITON_TIMINGS	/* define this to display timings */

/*
 * good_dma_drives() lists the model names (from "hdparm -i")
 * of drives which do not support mword2 DMA but which are
 * known to work fine with this interface under Linux.
 */
const char *good_dma_drives[] = {"Micropolis 2112A",
				 "CONNER CTMA 4000",
				 "CONNER CTT8000-A",
				 NULL};

/*
 * Our Physical Region Descriptor (PRD) table should be large enough
 * to handle the biggest I/O request we are likely to see.  Since requests
 * can have no more than 256 sectors, and since the typical blocksize is
 * two sectors, we could get by with a limit of 128 entries here for the
 * usual worst case.  Most requests seem to include some contiguous blocks,
 * further reducing the number of table entries required.
 *
 * The driver reverts to PIO mode for individual requests that exceed
 * this limit (possible with 512 byte blocksizes, eg. MSDOS f/s), so handling
 * 100% of all crazy scenarios here is not necessary.
 *
 * As it turns out though, we must allocate a full 4KB page for this,
 * so the two PRD tables (ide0 & ide1) will each get half of that,
 * allowing each to have about 256 entries (8 bytes each) from this.
 */
#define PRD_BYTES	8
#define PRD_ENTRIES	(PAGE_SIZE / (2 * PRD_BYTES))
#define DEFAULT_BMIBA	0xe800	/* in case BIOS did not init it */

/*
 * dma_intr() is the handler for disk read/write DMA interrupts
 */
static void dma_intr (ide_drive_t *drive)
{
	byte stat, dma_stat;
	int i;
	struct request *rq = HWGROUP(drive)->rq;
	unsigned short dma_base = HWIF(drive)->dma_base;

	dma_stat = inb(dma_base+2);		/* get DMA status */
	outb(inb(dma_base)&~1, dma_base);	/* stop DMA operation */
	stat = GET_STAT();			/* get drive status */
	if (OK_STAT(stat,DRIVE_READY,drive->bad_wstat|DRQ_STAT)) {
		if ((dma_stat & 7) == 4) {	/* verify good DMA status */
			rq = HWGROUP(drive)->rq;
			for (i = rq->nr_sectors; i > 0;) {
				i -= rq->current_nr_sectors;
				ide_end_request(1, HWGROUP(drive));
			}
			return;
		}
		printk("%s: bad DMA status: 0x%02x\n", drive->name, dma_stat);
	}
	sti();
	ide_error(drive, "dma_intr", stat);
}

/*
 * build_dmatable() prepares a dma request.
 * Returns 0 if all went okay, returns 1 otherwise.
 */
static int build_dmatable (ide_drive_t *drive)
{
	struct request *rq = HWGROUP(drive)->rq;
	struct buffer_head *bh = rq->bh;
	unsigned long size, addr, *table = HWIF(drive)->dmatable;
	unsigned int count = 0;

	do {
		/*
		 * Determine addr and size of next buffer area.  We assume that
		 * individual virtual buffers are always composed linearly in
		 * physical memory.  For example, we assume that any 8kB buffer
		 * is always composed of two adjacent physical 4kB pages rather
		 * than two possibly non-adjacent physical 4kB pages.
		 */
		if (bh == NULL) {  /* paging and tape requests have (rq->bh == NULL) */
			addr = virt_to_bus (rq->buffer);
#ifdef CONFIG_BLK_DEV_IDETAPE
			if (drive->media == ide_tape)
				size = drive->tape.pc->request_transfer;
			else
#endif /* CONFIG_BLK_DEV_IDETAPE */	
			size = rq->nr_sectors << 9;
		} else {
			/* group sequential buffers into one large buffer */
			addr = virt_to_bus (bh->b_data);
			size = bh->b_size;
			while ((bh = bh->b_reqnext) != NULL) {
				if ((addr + size) != virt_to_bus (bh->b_data))
					break;
				size += bh->b_size;
			}
		}

		/*
		 * Fill in the dma table, without crossing any 64kB boundaries.
		 * We assume 16-bit alignment of all blocks.
		 */
		while (size) {
			if (++count >= PRD_ENTRIES) {
				printk("%s: DMA table too small\n", drive->name);
				return 1; /* revert to PIO for this request */
			} else {
				unsigned long bcount = 0x10000 - (addr & 0xffff);
				if (bcount > size)
					bcount = size;
				*table++ = addr;
				*table++ = bcount & 0xffff;
				addr += bcount;
				size -= bcount;
			}
		}
	} while (bh != NULL);
	if (count) {
		*--table |= 0x80000000;	/* set End-Of-Table (EOT) bit */
		return 0;
	}
	printk("%s: empty DMA table?\n", drive->name);
	return 1;	/* let the PIO routines handle this weirdness */
}

static int config_drive_for_dma (ide_drive_t *drive)
{
	const char **list;
	struct hd_driveid *id = drive->id;

	if (id && (id->capability & 1)) {
		/* Enable DMA on any drive that has UltraDMA (mode 0/1/2) enabled */
		if (id->field_valid & 4)	/* UltraDMA */
			if  ((id->dma_ultra & (id->dma_ultra >> 8) & 7)) {
				drive->using_dma = 1;
				return 0;	/* dma enabled */
			}
		/* Enable DMA on any drive that has mode2 DMA (multi or single) enabled */
		if (id->field_valid & 2)	/* regular DMA */
			if  ((id->dma_mword & 0x404) == 0x404 || (id->dma_1word & 0x404) == 0x404) {
				drive->using_dma = 1;
				return 0;	/* dma enabled */
			}