Merge git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6 (fba5c1af) · Commits · 戴 / test

Documentation/ide/ide-tape.txt

+65 −146

Original line number	Diff line number	Diff line
		/*
		* IDE ATAPI streaming tape driver.
		*
		* This driver is a part of the Linux ide driver.
		*
		* The driver, in co-operation with ide.c, basically traverses the
		* request-list for the block device interface. The character device
		* interface, on the other hand, creates new requests, adds them
		* to the request-list of the block device, and waits for their completion.
		*
		* Pipelined operation mode is now supported on both reads and writes.
		*
		* The block device major and minor numbers are determined from the
		* tape's relative position in the ide interfaces, as explained in ide.c.
		*
		* The character device interface consists of the following devices:
		*
		* ht0 major 37, minor 0 first IDE tape, rewind on close.
		* ht1 major 37, minor 1 second IDE tape, rewind on close.
		* ...
		* nht0 major 37, minor 128 first IDE tape, no rewind on close.
		* nht1 major 37, minor 129 second IDE tape, no rewind on close.
		* ...
		*
		* The general magnetic tape commands compatible interface, as defined by
		* include/linux/mtio.h, is accessible through the character device.
		*
		* General ide driver configuration options, such as the interrupt-unmask
		* flag, can be configured by issuing an ioctl to the block device interface,
		* as any other ide device.
		*
		* Our own ide-tape ioctl's can be issued to either the block device or
		* the character device interface.
		*
		* Maximal throughput with minimal bus load will usually be achieved in the
		* following scenario:
		*
		* 1. ide-tape is operating in the pipelined operation mode.
		* 2. No buffering is performed by the user backup program.
		*
		* Testing was done with a 2 GB CONNER CTMA 4000 IDE ATAPI Streaming Tape Drive.
		*
		* Here are some words from the first releases of hd.c, which are quoted
		* in ide.c and apply here as well:
		*
		* \| Special care is recommended. Have Fun!
		*
		*
		* An overview of the pipelined operation mode.
		*
		* In the pipelined write mode, we will usually just add requests to our
		* pipeline and return immediately, before we even start to service them. The
		* user program will then have enough time to prepare the next request while
		* we are still busy servicing previous requests. In the pipelined read mode,
		* the situation is similar - we add read-ahead requests into the pipeline,
		* before the user even requested them.
		*
		* The pipeline can be viewed as a "safety net" which will be activated when
		* the system load is high and prevents the user backup program from keeping up
		* with the current tape speed. At this point, the pipeline will get
		* shorter and shorter but the tape will still be streaming at the same speed.
		* Assuming we have enough pipeline stages, the system load will hopefully
		* decrease before the pipeline is completely empty, and the backup program
		* will be able to "catch up" and refill the pipeline again.
		*
		* When using the pipelined mode, it would be best to disable any type of
		* buffering done by the user program, as ide-tape already provides all the
		* benefits in the kernel, where it can be done in a more efficient way.
		* As we will usually not block the user program on a request, the most
		* efficient user code will then be a simple read-write-read-... cycle.
		* Any additional logic will usually just slow down the backup process.
		*
		* Using the pipelined mode, I get a constant over 400 KBps throughput,
		* which seems to be the maximum throughput supported by my tape.
		*
		* However, there are some downfalls:
		*
		* 1. We use memory (for data buffers) in proportional to the number
		* of pipeline stages (each stage is about 26 KB with my tape).
		* 2. In the pipelined write mode, we cheat and postpone error codes
		* to the user task. In read mode, the actual tape position
		* will be a bit further than the last requested block.
		*
		* Concerning (1):
		*
		* 1. We allocate stages dynamically only when we need them. When
		* we don't need them, we don't consume additional memory. In
		* case we can't allocate stages, we just manage without them
		* (at the expense of decreased throughput) so when Linux is
		* tight in memory, we will not pose additional difficulties.
		*
		* 2. The maximum number of stages (which is, in fact, the maximum
		* amount of memory) which we allocate is limited by the compile
		* time parameter IDETAPE_MAX_PIPELINE_STAGES.
		*
		* 3. The maximum number of stages is a controlled parameter - We
		* don't start from the user defined maximum number of stages
		* but from the lower IDETAPE_MIN_PIPELINE_STAGES (again, we
		* will not even allocate this amount of stages if the user
		* program can't handle the speed). We then implement a feedback
		* loop which checks if the pipeline is empty, and if it is, we
		* increase the maximum number of stages as necessary until we
		* reach the optimum value which just manages to keep the tape
		* busy with minimum allocated memory or until we reach
		* IDETAPE_MAX_PIPELINE_STAGES.
		*
		* Concerning (2):
		*
		* In pipelined write mode, ide-tape can not return accurate error codes
		* to the user program since we usually just add the request to the
		* pipeline without waiting for it to be serviced. In case an error
		* occurs, I will report it on the next user request.
		*
		* In the pipelined read mode, subsequent read requests or forward
		* filemark spacing will perform correctly, as we preserve all blocks
		* and filemarks which we encountered during our excess read-ahead.
		*
		* For accurate tape positioning and error reporting, disabling
		* pipelined mode might be the best option.
		*
		* You can enable/disable/tune the pipelined operation mode by adjusting
		* the compile time parameters below.
		*
		*
		* Possible improvements.
		*
		* 1. Support for the ATAPI overlap protocol.
		*
		* In order to maximize bus throughput, we currently use the DSC
		* overlap method which enables ide.c to service requests from the
		* other device while the tape is busy executing a command. The
		* DSC overlap method involves polling the tape's status register
		* for the DSC bit, and servicing the other device while the tape
		* isn't ready.
		*
		* In the current QIC development standard (December 1995),
		* it is recommended that new tape drives will in addition
		* implement the ATAPI overlap protocol, which is used for the
		* same purpose - efficient use of the IDE bus, but is interrupt
		* driven and thus has much less CPU overhead.
		*
		* ATAPI overlap is likely to be supported in most new ATAPI
		* devices, including new ATAPI cdroms, and thus provides us
		* a method by which we can achieve higher throughput when
		* sharing a (fast) ATA-2 disk with any (slow) new ATAPI device.
		*/
		IDE ATAPI streaming tape driver.

		This driver is a part of the Linux ide driver.

		The driver, in co-operation with ide.c, basically traverses the
		request-list for the block device interface. The character device
		interface, on the other hand, creates new requests, adds them
		to the request-list of the block device, and waits for their completion.

		The block device major and minor numbers are determined from the
		tape's relative position in the ide interfaces, as explained in ide.c.

		The character device interface consists of the following devices:

		ht0 major 37, minor 0 first IDE tape, rewind on close.
		ht1 major 37, minor 1 second IDE tape, rewind on close.
		...
		nht0 major 37, minor 128 first IDE tape, no rewind on close.
		nht1 major 37, minor 129 second IDE tape, no rewind on close.
		...

		The general magnetic tape commands compatible interface, as defined by
		include/linux/mtio.h, is accessible through the character device.

		General ide driver configuration options, such as the interrupt-unmask
		flag, can be configured by issuing an ioctl to the block device interface,
		as any other ide device.

		Our own ide-tape ioctl's can be issued to either the block device or
		the character device interface.

		Maximal throughput with minimal bus load will usually be achieved in the
		following scenario:

		1. ide-tape is operating in the pipelined operation mode.
		2. No buffering is performed by the user backup program.

		Testing was done with a 2 GB CONNER CTMA 4000 IDE ATAPI Streaming Tape Drive.

		Here are some words from the first releases of hd.c, which are quoted
		in ide.c and apply here as well:

		\| Special care is recommended. Have Fun!

		Possible improvements:

		1. Support for the ATAPI overlap protocol.

		In order to maximize bus throughput, we currently use the DSC
		overlap method which enables ide.c to service requests from the
		other device while the tape is busy executing a command. The
		DSC overlap method involves polling the tape's status register
		for the DSC bit, and servicing the other device while the tape
		isn't ready.

		In the current QIC development standard (December 1995),
		it is recommended that new tape drives will in addition
		implement the ATAPI overlap protocol, which is used for the
		same purpose - efficient use of the IDE bus, but is interrupt
		driven and thus has much less CPU overhead.

		ATAPI overlap is likely to be supported in most new ATAPI
		devices, including new ATAPI cdroms, and thus provides us
		a method by which we can achieve higher throughput when
		sharing a (fast) ATA-2 disk with any (slow) new ATAPI device.

Documentation/ide/ide.txt

+40 −67

Original line number	Diff line number	Diff line
		@@ -82,27 +82,26 @@ Drives are normally found by auto-probing and/or examining the CMOS/BIOS data.
		For really weird situations, the apparent (fdisk) geometry can also be specified
		on the kernel "command line" using LILO. The format of such lines is:

		hdx=cyls,heads,sects
		or hdx=cdrom
		ide_core.chs=[interface_number.device_number]:cyls,heads,sects
		or ide_core.cdrom=[interface_number.device_number]

		where hdx can be any of hda through hdh, Three values are required
		(cyls,heads,sects). For example:
		For example:

		hdc=1050,32,64 hdd=cdrom
		ide_core.chs=1.0:1050,32,64 ide_core.cdrom=1.1

		either {hda,hdb} or {hdc,hdd}. The results of successful auto-probing may
		override the physical geometry/irq specified, though the "original" geometry
		may be retained as the "logical" geometry for partitioning purposes (fdisk).
		The results of successful auto-probing may override the physical geometry/irq
		specified, though the "original" geometry may be retained as the "logical"
		geometry for partitioning purposes (fdisk).

		If the auto-probing during boot time confuses a drive (ie. the drive works
		with hd.c but not with ide.c), then an command line option may be specified
		for each drive for which you'd like the drive to skip the hardware
		probe/identification sequence. For example:

		hdb=noprobe
		ide_core.noprobe=0.1
		or
		hdc=768,16,32
		hdc=noprobe
		ide_core.chs=1.0:768,16,32
		ide_core.noprobe=1.0

		Note that when only one IDE device is attached to an interface, it should be
		jumpered as "single" or "master", not "slave". Many folks have had
		@@ -118,9 +117,9 @@ If for some reason your cdrom drive is not found at boot time, you can force
		the probe to look harder by supplying a kernel command line parameter
		via LILO, such as:

		hdc=cdrom /* hdc = "master" on second interface */
		ide_core.cdrom=1.0 /* "master" on second interface (hdc) */
		or
		hdd=cdrom /* hdd = "slave" on second interface */
		ide_core.cdrom=1.1 /* "slave" on second interface (hdd) */

		For example, a GW2000 system might have a hard drive on the primary
		interface (/dev/hda) and an IDE cdrom drive on the secondary interface
		@@ -174,9 +173,7 @@ to /etc/modprobe.conf.

		When ide.c is used as a module, you can pass command line parameters to the
		driver using the "options=" keyword to insmod, while replacing any ',' with
		';'. For example:

		insmod ide.o options="hda=nodma hdb=nodma"
		';'.


		================================================================================
		@@ -184,57 +181,6 @@ driver using the "options=" keyword to insmod, while replacing any ',' with
		Summary of ide driver parameters for kernel command line
		--------------------------------------------------------

		"hdx=" is recognized for all "x" from "a" to "u", such as "hdc".

		"idex=" is recognized for all "x" from "0" to "9", such as "ide1".

		"hdx=noprobe" : drive may be present, but do not probe for it

		"hdx=none" : drive is NOT present, ignore cmos and do not probe

		"hdx=nowerr" : ignore the WRERR_STAT bit on this drive

		"hdx=cdrom" : drive is present, and is a cdrom drive

		"hdx=cyl,head,sect" : disk drive is present, with specified geometry

		"hdx=autotune" : driver will attempt to tune interface speed
		to the fastest PIO mode supported,
		if possible for this drive only.
		Not fully supported by all chipset types,
		and quite likely to cause trouble with
		older/odd IDE drives.

		"hdx=nodma" : disallow DMA

		"idebus=xx" : inform IDE driver of VESA/PCI bus speed in MHz,
		where "xx" is between 20 and 66 inclusive,
		used when tuning chipset PIO modes.
		For PCI bus, 25 is correct for a P75 system,
		30 is correct for P90,P120,P180 systems,
		and 33 is used for P100,P133,P166 systems.
		If in doubt, use idebus=33 for PCI.
		As for VLB, it is safest to not specify it.
		Bigger values are safer than smaller ones.

		"idex=serialize" : do not overlap operations on idex. Please note
		that you will have to specify this option for
		both the respective primary and secondary channel
		to take effect.

		"idex=reset" : reset interface after probe

		"idex=ata66" : informs the interface that it has an 80c cable
		for chipsets that are ATA-66 capable, but the
		ability to bit test for detection is currently
		unknown.

		"ide=doubler" : probe/support IDE doublers on Amiga

		There may be more options than shown -- use the source, Luke!

		Everything else is rejected with a "BAD OPTION" message.

		For legacy IDE VLB host drivers (ali14xx/dtc2278/ht6560b/qd65xx/umc8672)
		you need to explicitly enable probing by using "probe" kernel parameter,
		i.e. to enable probing for ALI M14xx chipsets (ali14xx host driver) use:
		@@ -251,6 +197,33 @@ are detected automatically).
		You also need to use "probe" kernel parameter for ide-4drives driver
		(support for IDE generic chipset with four drives on one port).

		To enable support for IDE doublers on Amiga use "doubler" kernel parameter
		for gayle host driver (i.e. "gayle.doubler" if the driver is built-in).

		To force ignoring cable detection (this should be needed only if you're using
		short 40-wires cable which cannot be automatically detected - if this is not
		a case please report it as a bug instead) use "ignore_cable" kernel parameter:

		* "ide_core.ignore_cable=[interface_number]" boot option if IDE is built-in
		(i.e. "ide_core.ignore_cable=1" to force ignoring cable for "ide1")

		* "ignore_cable=[interface_number]" module parameter (for ide_core module)
		if IDE is compiled as module

		Other kernel parameters for ide_core are:

		* "nodma=[interface_number.device_number]" to disallow DMA for a device

		* "noflush=[interface_number.device_number]" to disable flush requests

		* "noprobe=[interface_number.device_number]" to skip probing

		* "nowerr=[interface_number.device_number]" to ignore the WRERR_STAT bit

		* "cdrom=[interface_number.device_number]" to force device as a CD-ROM

		* "chs=[interface_number.device_number]" to force device as a disk (using CHS)

		================================================================================

		Some Terminology

Documentation/kernel-parameters.txt

+0 −4

Original line number	Diff line number	Diff line
		@@ -772,10 +772,6 @@ and is between 256 and 4096 characters. It is defined in the file
		Format: ide=nodma or ide=doubler
		See Documentation/ide/ide.txt.

		ide?= [HW] (E)IDE subsystem
		Format: ide?=ata66 or chipset specific parameters.
		See Documentation/ide/ide.txt.

		idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
		See Documentation/ide/ide.txt.

drivers/ide/arm/bast-ide.c

+4 −8

Original line number	Diff line number	Diff line
		@@ -35,12 +35,12 @@ static int __init bastide_register(unsigned int base, unsigned int aux, int irq)
		base += BAST_IDE_CS;
		aux += BAST_IDE_CS;

		for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
		hw.io_ports[i] = (unsigned long)base;
		for (i = 0; i <= 7; i++) {
		hw.io_ports_array[i] = (unsigned long)base;
		base += 0x20;
		}

		hw.io_ports[IDE_CONTROL_OFFSET] = aux + (6 * 0x20);
		hw.io_ports.ctl_addr = aux + (6 * 0x20);
		hw.irq = irq;

		hwif = ide_find_port();
		@@ -49,11 +49,7 @@ static int __init bastide_register(unsigned int base, unsigned int aux, int irq)

		i = hwif->index;

		if (hwif->present)
		ide_unregister(i);
		else
		ide_init_port_data(hwif, i);

		ide_init_port_hw(hwif, &hw);
		hwif->port_ops = NULL;

drivers/ide/arm/icside.c

+6 −7

Original line number	Diff line number	Diff line
		@@ -426,11 +426,12 @@ icside_setup(void __iomem base, struct cardinfo info, struct expansion_card *e
		*/
		default_hwif_mmiops(hwif);

		for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
		hwif->io_ports[i] = port;
		for (i = 0; i <= 7; i++) {
		hwif->io_ports_array[i] = port;
		port += 1 << info->stepping;
		}
		hwif->io_ports[IDE_CONTROL_OFFSET] = (unsigned long)base + info->ctrloffset;
		hwif->io_ports.ctl_addr =
		(unsigned long)base + info->ctrloffset;
		hwif->irq = ec->irq;
		hwif->chipset = ide_acorn;
		hwif->gendev.parent = &ec->dev;
		@@ -480,8 +481,7 @@ static const struct ide_port_info icside_v6_port_info __initdata = {
		.init_dma = icside_dma_off_init,
		.port_ops = &icside_v6_no_dma_port_ops,
		.dma_ops = &icside_v6_dma_ops,
		.host_flags = IDE_HFLAG_SERIALIZE \|
		IDE_HFLAG_NO_AUTOTUNE,
		.host_flags = IDE_HFLAG_SERIALIZE,
		.mwdma_mask = ATA_MWDMA2,
		.swdma_mask = ATA_SWDMA2,
		};
		@@ -547,14 +547,13 @@ icside_register_v6(struct icside_state state, struct expansion_card ec)
		hwif->config_data = (unsigned long)ioc_base;
		hwif->select_data = sel;

		mate->maskproc = icside_maskproc;
		mate->hwif_data = state;
		mate->config_data = (unsigned long)ioc_base;
		mate->select_data = sel \| 1;

		if (ec->dma != NO_DMA && !request_dma(ec->dma, hwif->name)) {
		d.init_dma = icside_dma_init;
		d.port_ops = &icside_v6_dma_port_ops;
		d.port_ops = &icside_v6_port_ops;
		d.dma_ops = NULL;
		}

Admin message