Merge branch 'master' of /pub/scm/linux/kernel/git/torvalds/linux-2.6

	- short blurb on the SGI Visual Workstations.

sh/

	- directory with info on porting Linux to a new architecture.

smart-config.txt

	- description of the Smart Config makefile feature.

sound/

	- directory with info on sound card support.

sparc/

Protocol 2.06:	(Kernel 2.6.22) Added a field that contains the size of

		the boot command line

Protocol 2.09:	(kernel 2.6.26) Added a field of 64-bit physical

		pointer to single linked list of struct	setup_data.

**** MEMORY LAYOUT

0240/8	2.07+	hardware_subarch_data Subarchitecture-specific data

0248/4	2.08+	payload_offset	Offset of kernel payload

024C/4	2.08+	payload_length	Length of kernel payload

0250/8	2.09+	setup_data	64-bit physical pointer to linked list

				of struct setup_data

(1) For backwards compatibility, if the setup_sects field contains 0, the

    real value is 4.

	covered by setup_move_size, so you may need to adjust this

	field.

Field name:	setup_data

Type:		write (obligatory)

Offset/size:	0x250/8

Protocol:	2.09+

  The 64-bit physical pointer to NULL terminated single linked list of

  struct setup_data. This is used to define a more extensible boot

  parameters passing mechanism. The definition of struct setup_data is

  as follow:

  struct setup_data {

	  u64 next;

	  u32 type;

	  u32 len;

	  u8  data[0];

  };

  Where, the next is a 64-bit physical pointer to the next node of

  linked list, the next field of the last node is 0; the type is used

  to identify the contents of data; the len is the length of data

  field; the data holds the real payload.

**** MEMORY LAYOUT OF THE REAL-MODE CODE

Currently, kvm module in EXPERIMENTAL stage on IA64. This means that

interfaces are not stable enough to use. So, plase had better don't run

critical applications in virtual machine. We will try our best to make it

strong in future versions!

				Guide: How to boot up guests on kvm/ia64

This guide is to describe how to enable kvm support for IA-64 systems.

1. Get the kvm source from git.kernel.org.

	Userspace source:

		git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git

	Kernel Source:

		git clone git://git.kernel.org/pub/scm/linux/kernel/git/xiantao/kvm-ia64.git

2. Compile the source code.

	2.1 Compile userspace code:

		(1)cd ./kvm-userspace

		(2)./configure

		(3)cd kernel

		(4)make sync LINUX= $kernel_dir (kernel_dir is the directory of kernel source.)

		(5)cd ..

		(6)make qemu

		(7)cd qemu; make install

	2.2 Compile kernel source code:

		(1) cd ./$kernel_dir

		(2) Make menuconfig

		(3) Enter into virtualization option, and choose kvm.

		(4) make

		(5) Once (4) done, make modules_install

		(6) Make initrd, and use new kernel to reboot up host machine.

		(7) Once (6) done, cd $kernel_dir/arch/ia64/kvm

		(8) insmod kvm.ko; insmod kvm-intel.ko

Note: For step 2, please make sure that host page size == TARGET_PAGE_SIZE of qemu, otherwise, may fail.

3. Get Guest Firmware named as Flash.fd, and put it under right place:

	(1) If you have the guest firmware (binary) released by Intel Corp for Xen, use it directly.

	(2) If you have no firmware at hand, Please download its source from

		hg clone http://xenbits.xensource.com/ext/efi-vfirmware.hg

	    you can get the firmware's binary in the directory of efi-vfirmware.hg/binaries.

	(3) Rename the firware you owned to Flash.fd, and copy it to /usr/local/share/qemu

4. Boot up Linux or Windows guests:

	4.1 Create or install a image for guest boot. If you have xen experience, it should be easy.

	4.2 Boot up guests use the following command.

		/usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image

		(xx is the number of virtual processors for the guest, now the maximum value is 4)

5. Known possibile issue on some platforms with old Firmware.

If meet strange host crashe issues, try to solve it through either of the following ways:

(1): Upgrade your Firmware to the latest one.

(2): Applying the below patch to kernel source.

diff --git a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S

index 0b53344..f02b0f7 100644

--- a/arch/ia64/kernel/pal.S

+++ b/arch/ia64/kernel/pal.S

@@ -84,7 +84,8 @@ GLOBAL_ENTRY(ia64_pal_call_static)

	mov ar.pfs = loc1

	mov rp = loc0

	;;

-	srlz.d				// seralize restoration of psr.l

+	srlz.i			// seralize restoration of psr.l

+	;;

	br.ret.sptk.many b0

 END(ia64_pal_call_static)

6. Bug report:

	If you found any issues when use kvm/ia64, Please post the bug info to kvm-ia64-devel mailing list.

	https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel/

Thanks for your interest! Let's work together, and make kvm/ia64 stronger and stronger!

								Xiantao Zhang <xiantao.zhang@intel.com>

											2008.3.10

/*

 * 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.

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

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

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"

';'.

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

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:

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