Merge intel.com:/home/lenb/bk/26-latest-ref

into intel.com:/home/lenb/src/26-latest-dev

11 files changed, 495 insertions, 100 deletions

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 8787c4d099a654..6ee3cd6134dfad 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -160,7 +160,7 @@ pci_set_dma_mask(struct pci_device *dev, u64 mask)
 Checks to see if the mask is possible and updates the device
 parameters if it is.
 
-Returns: 1 if successful and 0 if not
+Returns: 0 if successful and a negative error if not.
 
 u64
 dma_get_required_mask(struct device *dev)
diff --git a/Documentation/arm/Sharp-LH/IOBarrier b/Documentation/arm/Sharp-LH/IOBarrier
index bf34e046ea10bf..c0d8853672dc9e 100644
--- a/Documentation/arm/Sharp-LH/IOBarrier
+++ b/Documentation/arm/Sharp-LH/IOBarrier
@@ -5,7 +5,7 @@ Due to an unfortunate oversight when the Card Engines were designed,
 the signals that control access to some peripherals, most notably the
 SMC91C9111 ethernet controller, are not properly handled.
 
-The symptom is that back to back IO with the peripheral returns
+The symptom is that some back to back IO with the peripheral returns
 unreliable data.  With the SMC chip, you'll see errors about the bank
 register being 'screwed'.
 
@@ -13,20 +13,33 @@ The cause is that the AEN signal to the SMC chip does not transition
 for every memory access.  It is driven through the CPLD from the CS7
 line of the CPU's static memory controller which is optimized to
 eliminate unnecessary transitions.  Yet, the SMC requires a transition
-for every access.  The Sharp website has more information on the
-effect of this power conservation feature on peripheral interfacing.
+for every write access.  The Sharp website has more information about
+the effect this power-conserving feature has on peripheral
+interfacing.
 
-The solution is to follow every access to the SMC chip with an access
-to another memory region that will force the CPU to release the chip
-select line.  Note that it is important to guarantee that the access
-will force the CPU off-chip.  We map a page of SDRAM as if it were an
-uncacheable IO device and read from it after every SMC IO operation.
+The solution is to follow every write access to the SMC chip with an
+access to another memory region that will force the CPU to release the
+chip select line.  It is important to guarantee that this access
+forces the CPU off-chip.  We map a page of SDRAM as if it were an
+uncacheable IO device and read from it after every SMC IO write
+operation.
 
   SMC IO
   BARRIER IO
 
-You might be tempted to believe that we must access another device
+Only this sequence is important.  It does not matter that there is no
+BARRIER IO before the access to the SMC chip because the AEN latch
+only needs occurs after the SMC IO write cycle.  The routines that
+implement this work-around make an additional concession which is to
+disable interrupts during the IO sequence.  Other hardware devices
+(the LogicPD CPLD) have registers in the same the physical memory
+region as the SMC chip.  An interrupt might allow an access to one of
+those registers while SMC IO is being performed.
+
+You might be tempted to think that we have to access another device
 attached to the static memory controller, but the empirical evidence
 indicates that this is not so.  Mapping 0x00000000 (flash) and
 0xc0000000 (SDRAM) appear to have the same effect.  Using SDRAM seems
-to be faster.
+to be faster.  Choosing to access an undecoded memory region is not
+desirable as there is no way to know how that chip select will be used
+in the future.
diff --git a/Documentation/dvb/README.dibusb b/Documentation/dvb/README.dibusb
index d6449ec80999da..e3d650b814dcc8 100644
--- a/Documentation/dvb/README.dibusb
+++ b/Documentation/dvb/README.dibusb
@@ -1,43 +1,91 @@
+Documentation for dib3000mb frontend driver and dibusb device driver
+====================================================================
 
+Copyright (C) 2004 Patrick Boettcher (patrick.boettcher@desy.de),
 
-Documentation for dib3000mb frontend driver and dibusb device driver
+dibusb and dib3000mb/mc drivers based on GPL code, which has
+
+Copyright (C) 2004 Amaury Demol for DiBcom (ademol@dibcom.fr)
 
-The drivers should work with
+This program is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License as
+published by the Free Software Foundation, version 2.
 
-- Twinhan VisionPlus VisionDTV USB-Ter DVB-T Device (VP7041)
-	http://www.twinhan.com/
 
-- CTS Portable (Chinese Television System)
-	http://www.2cts.tv/ctsportable/
+Supported devices USB1.1
+========================
 
-- KWorld V-Stream XPERT DTV - DVB-T USB
-	http://www.kworld.com.tw/asp/pindex.asp?id=4&pid=13
+Produced and reselled by Twinhan:
+---------------------------------
+- TwinhanDTV USB-Ter DVB-T Device (VP7041)
+	http://www.twinhan.com/product_terrestrial_3.asp
+
+- TwinhanDTV Magic Box (VP7041e)
+	http://www.twinhan.com/product_terrestrial_4.asp
 
 - HAMA DVB-T USB device
 	http://www.hama.de/portal/articleId*110620/action*2598
 
-- DiBcom USB DVB-T reference device
+- CTS Portable (Chinese Television System)
+	http://www.2cts.tv/ctsportable/
+
+- Unknown USB DVB-T device with vendor ID Hyper-Paltek
+
+
+Produced and reselled by KWorld:
+--------------------------------
+- KWorld V-Stream XPERT DTV DVB-T USB
+	http://www.kworld.com.tw/en/product/DVBT-USB/DVBT-USB.html
+
+- JetWay DTV DVB-T USB
+	http://www.jetway.com.tw/evisn/product/lcd-tv/DVT-USB/dtv-usb.htm
+
+- ADSTech Instant TV DVB-T USB
+	http://www.adstech.com/products/PTV-333/intro/PTV-333_intro.asp?pid=PTV-333
 
-- Ultima Electronic/Artec T1 USB TVBOX
-	http://www.arteceuro.com/products-tvbox.html
+
+Others:
+-------
+- Ultima Electronic/Artec T1 USB TVBOX (AN2135 and AN2235)
+	http://82.161.246.249/products-tvbox.html
 
 - Compro Videomate DVB-U2000 - DVB-T USB
 	http://www.comprousa.com/products/vmu2000.htm
 
-- Unknown USB DVB-T device with vendor ID Hyper-Paltek
+- Grandtec USB DVB-T
+	http://www.grand.com.tw/
 
-Copyright (C) 2004 Patrick Boettcher (patrick.boettcher@desy.de),
+- Avermedia AverTV DVBT USB
+	http://www.avermedia.com/
 
-both drivers based on GPL code, which has
+- DiBcom USB DVB-T reference device (non-public)
 
-Copyright (C) 2004 Amaury Demol for DiBcom (ademol@dibcom.fr)
 
-This program is free software; you can redistribute it and/or
-modify it under the terms of the GNU General Public License as
-published by the Free Software Foundation, version 2.
+Supported devices USB2.0
+========================
+- Twinhan MagicBox II
+	http://www.twinhan.com/product_terrestrial_7.asp
+
+- Yakumo DVB-T mobile
+	http://www.yakumo.de/produkte/index.php?pid=1&ag=DVB-T
+
+- DiBcom USB2.0 DVB-T reference device (non-public)
 
 
-NEWS:
+0. NEWS:
+  2004-12-06 - possibility for demod i2c-address probing
+             - new usb IDs (Compro,Artec)
+  2004-11-23 - merged changes from DiB3000MC_ver2.1
+             - revised the debugging
+             - possibility to deliver the complete TS for USB2.0
+  2004-11-21 - first working version of the dib3000mc/p frontend driver.
+  2004-11-12 - added additional remote control keys. Thanks to Uwe Hanke.
+  2004-11-07 - added remote control support. Thanks to David Matthews.
+  2004-11-05 - added support for a new devices (Grandtec/Avermedia/Artec)
+             - merged my changes (for dib3000mb/dibusb) to the FE_REFACTORING, because it became HEAD
+             - moved transfer control (pid filter, fifo control) from usb driver to frontend, it seems
+               better settled there (added xfer_ops-struct)
+             - created a common files for frontends (mc/p/mb)
   2004-09-28 - added support for a new device (Unkown, vendor ID is Hyper-Paltek)
   2004-09-20 - added support for a new device (Compro DVB-U2000), thanks
                to Amaury Demol for reporting
@@ -49,7 +97,7 @@ NEWS:
 
   (old news for vp7041.c)
   2004-07-15 - found out, by accident, that the device has a TUA6010XS for
-               frequency generator
+               PLL
   2004-07-12 - figured out, that the driver should also work with the
                CTS Portable (Chinese Television System)
   2004-07-08 - firmware-extraction-2.422-problem solved, driver is now working
@@ -67,7 +115,7 @@ NEWS:
 
 1. How to use?
 NOTE: This driver was developed using Linux 2.6.6.,
-it is working with 2.6.7, 2.6.8.1.
+it is working with 2.6.7, 2.6.8.1, 2.6.9 .
 
 Linux 2.4.x support is not planned, but patches are very welcome.
 
@@ -81,8 +129,15 @@ The USB driver needs to download a firmware to start working.
 You can either use "get_dvb_firmware dibusb" to download the firmware or you
 can get it directly via
 
+for USB1.1 (AN2135)
 http://linuxtv.org/cgi-bin/cvsweb.cgi/dvb-kernel/firmware/dvb-dibusb-5.0.0.11.fw?rev=1.1&content-type=text/plain
 
+for USB1.1 (AN2235) (a few Artec T1 devices)
+http://linuxtv.org/cgi-bin/cvsweb.cgi/dvb-kernel/firmware/dvb-dibusb-an2235-1.fw?rev=1.1&content-type=text/plain
+
+for USB2.0 (FX2)
+http://linuxtv.org/cgi-bin/cvsweb.cgi/dvb-kernel/firmware/dvb-dibusb-6.0.0.5.fw?rev=1.1&content-type=text/plain
+
 1.2. Compiling
 
 Since the driver is in the linux kernel, activating the driver in
@@ -94,15 +149,16 @@ to compile the driver as module. Hotplug does the rest.
 Hotplug is able to load the driver, when it is needed (because you plugged
 in the device).
 
-If you want to enable debug output, you have to load the driver manually.
+If you want to enable debug output, you have to load the driver manually and
+from withing the dvb-kernel cvs repository.
 
 first have a look, which debug level are available:
 
-modinfo dvb-dibusb
 modinfo dib3000mb
+modinfo dvb-dibusb
 
-modprobe dvb-dibusb debug=<level> 
 modprobe dib3000mb debug=<level>
+modprobe dvb-dibusb debug=<level>
 
 should do the trick.
 
@@ -118,21 +174,17 @@ as a slave device in vdr, was not working for me. Some work has to be done
 2. Known problems and bugs
 
 TODO:
-- remote control tasklet
 - signal-quality and strength calculations
-- debug messages restructure
-- i2c address probing
-- 
 
 2.1. Adding support for devices 
 
 It is not possible to determine the range of devices based on the DiBcom
-reference design. This is because the reference design of DiBcom can be sold
-to third persons, without telling DiBcom (so done with the Twinhan VP7041 and
+reference designs. This is because the reference design of DiBcom can be sold
+to thirds, without telling DiBcom (so done with the Twinhan VP7041 and
 the HAMA device).
 
 When you think you have a device like this and the driver does not recognizes it,
-please send the ****load.inf and the ****cap.inf of the Windows driver to me.
+please send the ****load*.inf and the ****cap*.inf of the Windows driver to me.
 
 Sometimes the Vendor or Product ID is identical to the ones of Twinhan, even
 though it is not a Twinhan device (e.g. HAMA), then please send me the name
@@ -144,7 +196,29 @@ the dvb-dibusb.h-file and create a patch and send it over to me or to
 the linux-dvb mailing list, _after_ you have tried compiling and modprobing
 it.
 
-2.2. Comments
+2.2. USB1.1 Bandwidth limitation
+
+Most of the current supported devices are USB1.1 and thus they have a
+maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub.
+This is not enough for receiving the complete transport stream of a
+DVB-T channel (which can be about 16 MBit/s). Normally this is not a
+problem, if you only want to watch TV, but watching a channel while
+recording another channel on the same frequency simply does not work.
+This applies to all USB1.1 DVB-T devices.
+
+A special problem of the dibusb for the USB1.1 is, that the USB control
+IC has a problem with write accesses while having MPEG2-streaming
+enabled. When you set another pid while receiving MPEG2-TS it happens, that
+the stream is disturbed and probably data is lost (results in distortions of
+the video or strange beeps within the audio stream). DiBcom is preparing a
+firmware especially for Linux which perhaps solves the problem.
+
+Especially VDR users are victoms of this bug. VDR frequently requests new PIDs
+due the automatic scanning (introduced in 1.3.x, afaik) and epg-scan. Disabling
+these features is maybe a solution. Additionally this behaviour of VDR exceeds
+the USB1.1 bandwidth.
+
+2.3. Comments
 
 Patches, comments and suggestions are very very welcome
 
@@ -153,6 +227,9 @@ Patches, comments and suggestions are very very welcome
 	providing specs, code and help, on which the dvb-dibusb and dib3000mb are
 	based.
 
+   David Matthews for identifying a new device type (Artec T1 with AN2235)
+    and for extending dibusb with remote control event handling. Thank you.
+
    Alex Woods for frequently answering question about usb and dvb
     stuff, a big thank you
 
diff --git a/Documentation/dvb/cards.txt b/Documentation/dvb/cards.txt
index 43e1a8a9788195..efdc4ee9d40c11 100644
--- a/Documentation/dvb/cards.txt
+++ b/Documentation/dvb/cards.txt
@@ -38,7 +38,7 @@ o Frontends drivers:
                		  Comtech DVBT-6k07 (SP5730 PLL)
                		  (NxtWave Communications NXT6000 demodulator)
    - sp887x		: Microtune 7202D
-   - dib3000mb	: DiBcom 3000-MB Frontend
+   - dib3000mb	: DiBcom 3000-MB demodulator
   DVB-S/C/T:
    - dst		: TwinHan DST Frontend
 
@@ -69,7 +69,17 @@ o Technotrend / Hauppauge DVB USB devices:
 
 o DiBcom DVB-T USB based devices:
   - Twinhan VisionPlus VisionDTV USB-Ter DVB-T Device
-  - KWorld V-Stream XPERT DTV - DVB-T USB
   - HAMA DVB-T USB device
+  - CTS Portable (Chinese Television System)
+  - KWorld V-Stream XPERT DTV DVB-T USB
+  - JetWay DTV DVB-T USB
+  - ADSTech Instant TV DVB-T USB
+  - Ultima Electronic/Artec T1 USB TVBOX (AN2135 and AN2235)
+  - Compro Videomate DVB-U2000 - DVB-T USB
+  - Grandtec USB DVB-T
+  - Avermedia AverTV DVBT USB
+  - DiBcom USB DVB-T reference device (non-public)
+  - Yakumo DVB-T mobile USB2.0
+  - DiBcom USB2.0 DVB-T reference device (non-public)
 
 o Experimental support for the analog module of the Siemens DVB-C PCI card
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index f3a8fef9819266..e9964b71e12453 100644
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -21,7 +21,7 @@
 use File::Temp qw/ tempdir /;
 use IO::Handle;
 
-@components = ( "alps_tdlb7", "sp887x", "tda10045", "tda10046", "av7110", "dec2000t", "dec2540t", "dec3000s", "vp7041", "dibusb" );
+@components = ( "sp8870", "sp887x", "tda10045", "tda10046", "av7110", "dec2000t", "dec2540t", "dec3000s", "vp7041", "dibusb" );
 
 # Check args
 syntax() if (scalar(@ARGV) != 1);
@@ -32,7 +32,7 @@ for($i=0; $i < scalar(@components); $i++) {
     if ($cid eq $components[$i]) {
 	$outfile = eval($cid);
 	die $@ if $@;
-	print STDERR "Firmware $outfile extracted successfully. Now copy it to /usr/lib/hotplug/firmware/.\n";
+	print STDERR "Firmware $outfile extracted successfully. Now copy it to either /lib/firmware or /usr/lib/hotplug/firmware/ (depending on your hotplug version).\n";
 	exit(0);
     }
 }
@@ -47,11 +47,11 @@ syntax();
 # ---------------------------------------------------------------
 # Firmware-specific extraction subroutines
 
-sub alps_tdlb7 {
+sub sp8870 {
     my $sourcefile = "tt_Premium_217g.zip";
     my $url = "http://www.technotrend.de/new/217g/$sourcefile";
     my $hash = "53970ec17a538945a6d8cb608a7b3899";
-    my $outfile = "dvb-fe-tdlb7.fw";
+    my $outfile = "dvb-fe-sp8870.fw";
     my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
 
     checkstandard();
diff --git a/Documentation/ia64/serial.txt b/Documentation/ia64/serial.txt
new file mode 100644
index 00000000000000..f51eb4bc2ff1e1
--- /dev/null
+++ b/Documentation/ia64/serial.txt
@@ -0,0 +1,144 @@
+SERIAL DEVICE NAMING
+
+    As of 2.6.10, serial devices on ia64 are named based on the
+    order of ACPI and PCI enumeration.  The first device in the
+    ACPI namespace (if any) becomes /dev/ttyS0, the second becomes
+    /dev/ttyS1, etc., and PCI devices are named sequentially
+    starting after the ACPI devices.
+
+    Prior to 2.6.10, there were confusing exceptions to this:
+
+	- Firmware on some machines (mostly from HP) provides an HCDP
+	  table[1] that tells the kernel about devices that can be used
+	  as a serial console.  If the user specified "console=ttyS0"
+	  or the EFI ConOut path contained only UART devices, the
+	  kernel registered the device described by the HCDP as
+	  /dev/ttyS0.
+
+	- If there was no HCDP, we assumed there were UARTs at the
+	  legacy COM port addresses (I/O ports 0x3f8 and 0x2f8), so
+	  the kernel registered those as /dev/ttyS0 and /dev/ttyS1.
+
+    Any additional ACPI or PCI devices were registered sequentially
+    after /dev/ttyS0 as they were discovered.
+
+    With an HCDP, device names changed depending on EFI configuration
+    and "console=" arguments.  Without an HCDP, device names didn't
+    change, but we registered devices that might not really exist.
+
+    For example, an HP rx1600 with a single built-in serial port
+    (described in the ACPI namespace) plus an MP[2] (a PCI device) has
+    these ports:
+
+                                  pre-2.6.10      pre-2.6.10
+                    MMIO         (EFI console    (EFI console
+                   address        on builtin)     on MP port)    2.6.10
+                  ==========      ==========      ==========     ======
+      builtin     0xff5e0000        ttyS0           ttyS1         ttyS0
+      MP UPS      0xf8031000        ttyS1           ttyS2         ttyS1
+      MP Console  0xf8030000        ttyS2           ttyS0         ttyS2
+      MP 2        0xf8030010        ttyS3           ttyS3         ttyS3
+      MP 3        0xf8030038        ttyS4           ttyS4         ttyS4
+
+CONSOLE SELECTION
+
+    EFI knows what your console devices are, but it doesn't tell the
+    kernel quite enough to actually locate them.  The DIG64 HCDP
+    table[1] does tell the kernel where potential serial console
+    devices are, but not all firmware supplies it.  Also, EFI supports
+    multiple simultaneous consoles and doesn't tell the kernel which
+    should be the "primary" one.
+
+    So how do you tell Linux which console device to use?
+
+	- If your firmware supplies the HCDP, it is simplest to
+	  configure EFI with a single device (either a UART or a VGA
+	  card) as the console.  Then you don't need to tell Linux
+	  anything; the kernel will automatically use the EFI console.
+
+	  (This works only in 2.6.6 or later; prior to that you had
+	  to specify "console=ttyS0" to get a serial console.)
+
+	- Without an HCDP, Linux defaults to a VGA console unless you
+	  specify a "console=" argument.
+
+    NOTE: Don't assume that a serial console device will be /dev/ttyS0.
+    It might be ttyS1, ttyS2, etc.  Make sure you have the appropriate
+    entries in /etc/inittab (for getty) and /etc/securetty (to allow
+    root login).
+
+EARLY SERIAL CONSOLE
+
+    The kernel can't start using a serial console until it knows where
+    the device lives.  Normally this happens when the driver enumerates
+    all the serial devices, which can happen a minute or more after the
+    kernel starts booting.
+
+    2.6.10 and later kernels have an "early uart" driver that works
+    very early in the boot process.  The kernel will automatically use
+    this if the user supplies an argument like "console=uart,io,0x3f8",
+    or if the EFI console path contains only a UART device and the
+    firmware supplies an HCDP.
+
+TROUBLESHOOTING SERIAL CONSOLE PROBLEMS
+
+    No kernel output after elilo prints "Uncompressing Linux... done":
+
+	- You specified "console=ttyS0" but Linux changed the device
+	  to which ttyS0 refers.  Configure exactly one EFI console
+	  device[3] and remove the "console=" option.
+
+	- The EFI console path contains both a VGA device and a UART.
+	  EFI and elilo use both, but Linux defaults to VGA.  Remove
+	  the VGA device from the EFI console path[3].
+
+	- Multiple UARTs selected as EFI console devices.  EFI and
+	  elilo use all selected devices, but Linux uses only one.
+	  Make sure only one UART is selected in the EFI console
+	  path[3].
+
+	- You're connected to an HP MP port[2] but have a non-MP UART
+	  selected as EFI console device.  EFI uses the MP as a
+	  console device even when it isn't explicitly selected.
+	  Either move the console cable to the non-MP UART, or change
+	  the EFI console path[3] to the MP UART.
+
+    Long pause (60+ seconds) between "Uncompressing Linux... done" and
+    start of kernel output:
+
+	- No early console because you used "console=ttyS<n>".  Remove
+	  the "console=" option if your firmware supplies an HCDP.
+
+	- If you don't have an HCDP, the kernel doesn't know where
+	  your console lives until the driver discovers serial
+	  devices.  Use "console=uart, io,0x3f8" (or appropriate
+	  address for your machine).
+
+    Kernel and init script output works fine, but no "login:" prompt:
+
+	- Add getty entry to /etc/inittab for console tty.  Look for
+	  the "Adding console on ttyS<n>" message that tells you which
+	  device is the console.
+
+    "login:" prompt, but can't login as root:
+
+	- Add entry to /etc/securetty for console tty.
+
+
+
+[1] http://www.dig64.org/specifications/DIG64_PCDPv20.pdf
+    The table was originally defined as the "HCDP" for "Headless
+    Console/Debug Port."  The current version is the "PCDP" for
+    "Primary Console and Debug Port Devices."
+
+[2] The HP MP (management processor) is a PCI device that provides
+    several UARTs.  One of the UARTs is often used as a console; the
+    EFI Boot Manager identifies it as "Acpi(HWP0002,700)/Pci(...)/Uart".
+    The external connection is usually a 25-pin connector, and a
+    special dongle converts that to three 9-pin connectors, one of
+    which is labelled "Console."
+
+[3] EFI console devices are configured using the EFI Boot Manager
+    "Boot option maintenance" menu.  You may have to interrupt the
+    boot sequence to use this menu, and you will have to reset the
+    box after changing console configuration.
diff --git a/Documentation/ioctl/cdrom.txt b/Documentation/ioctl/cdrom.txt
index acc8f3a3bac08c..4ccdcc6fe36459 100644
--- a/Documentation/ioctl/cdrom.txt
+++ b/Documentation/ioctl/cdrom.txt
@@ -34,7 +34,7 @@ are as follows:
 				  (struct cdrom_multisession)
 	CDROM_GET_MCN		Obtain the "Universal Product Code"
 				   if available (struct cdrom_mcn)
-	CDROM_GET_UPC		CDROM_GET_MCN  (deprecated)
+	CDROM_GET_UPC		Deprecated, use CDROM_GET_MCN instead.
 	CDROMRESET		hard-reset the drive
 	CDROMVOLREAD		Get the drive's volume setting
 					  (struct cdrom_volctrl)
@@ -44,8 +44,8 @@ are as follows:
 	CDROMSEEK		seek msf address
 	CDROMPLAYBLK		scsi-cd only, (struct cdrom_blk)
 	CDROMREADALL		read all 2646 bytes
-	CDROMGETSPINDOWN
-	CDROMSETSPINDOWN
+	CDROMGETSPINDOWN	return 4-bit spindown value
+	CDROMSETSPINDOWN	set 4-bit spindown value
 	CDROMCLOSETRAY		pendant of CDROMEJECT
 	CDROM_SET_OPTIONS	Set behavior options
 	CDROM_CLEAR_OPTIONS	Clear behavior options
@@ -79,10 +79,12 @@ code.  It is likely that some corrections will be made over time.
 General:
 
 	Unless otherwise specified, all ioctl calls return 0 on success
-	and -1 with errno set to an appropriate value on error.
+	and -1 with errno set to an appropriate value on error.  (Some
+	ioctls return non-negative data values.)
 
-	Unless otherwise specified, all ioctl calls return EFAULT on a
-	failed attempt to copy data to or from user address space.
+	Unless otherwise specified, all ioctl calls return -1 and set
+	errno to EFAULT on a failed attempt to copy data to or from user
+	address space.
 
 	Individual drivers may return error codes not listed here.
 
@@ -136,6 +138,9 @@ CDROMPLAYMSF			Play Audio MSF (struct cdrom_msf)
 	  ENOSYS	cd drive not audio-capable.
 
 	notes:
+	  MSF stands for minutes-seconds-frames
+	  LBA stands for logical block address
+
 	  Segment is described as start and end times, where each time
 	  is described as minutes:seconds:frames.  A frame is 1/75 of
 	  a second.
@@ -196,8 +201,11 @@ CDROMREADTOCENTRY		Read TOC entry (struct cdrom_tocentry)
 	error return:
 	  ENOSYS	cd drive not audio-capable.
 	  EINVAL	entry.cdte_format not CDROM_MSF or CDROM_LBA
+	  EINVAL	requested track out of bounds
+	  EIO		I/O error reading TOC
 
 	notes:
+	  TOC stands for Table Of Contents
 	  MSF stands for minutes-seconds-frames
 	  LBA stands for logical block address
 
@@ -216,6 +224,10 @@ CDROMSTOP			Stop the cdrom drive
 	error return:
 	  ENOSYS	cd drive not audio-capable.
 
+	notes:
+	  Exact interpretation of this ioctl depends on the device,
+	  but most seem to spin the drive down.
+
 
 CDROMSTART			Start the cdrom drive
 
@@ -230,6 +242,11 @@ CDROMSTART			Start the cdrom drive
 	error return:
 	  ENOSYS	cd drive not audio-capable.
 
+	notes:
+	  Exact interpretation of this ioctl depends on the device,
+	  but most seem to spin the drive up and/or close the tray.
+	  Other devices ignore the ioctl completely.
+
 
 CDROMEJECT			Ejects the cdrom media
 
@@ -241,9 +258,12 @@ CDROMEJECT			Ejects the cdrom media
 
 	outputs:	none
 
-	error return:
+	error returns:
 	  ENOSYS	cd drive not capable of ejecting
-	  EBUSY		other processes have drive open or door is locked
+	  EBUSY		other processes are accessing drive, or door is locked
+
+	notes:
+	  See CDROM_LOCKDOOR, below.
 
 
 
@@ -257,9 +277,12 @@ CDROMCLOSETRAY			pendant of CDROMEJECT
 
 	outputs:	none
 
-	error return:
+	error returns:
 	  ENOSYS	cd drive not capable of ejecting
-	  EBUSY		other processes have drive open or door is locked
+	  EBUSY		other processes are accessing drive, or door is locked
+
+	notes:
+	  See CDROM_LOCKDOOR, below.
 
 
 
@@ -577,7 +600,7 @@ CDROM_SET_OPTIONS		Set behavior options
 
 	inputs:
 	  New values for drive options.  The logical 'or' of:
-	    CDO_AUTO_CLOSE	close tray on first open
+	    CDO_AUTO_CLOSE	close tray on first open(2)
 	    CDO_AUTO_EJECT	open tray on last release
 	    CDO_USE_FFLAGS	use O_NONBLOCK information on open
 	    CDO_LOCK		lock tray on open files
@@ -918,6 +941,10 @@ CDROM_NEXT_WRITABLE		get next writable block
 	outputs:
 	  The next writable block.
 
+	notes:
+	  If the device does not support this ioctl directly, the
+	  ioctl will return CDROM_LAST_WRITTEN + 7.
+
 
 
 CDROM_LAST_WRITTEN		get last block written on disc
@@ -925,11 +952,15 @@ CDROM_LAST_WRITTEN		get last block written on disc
 	usage:
 
 	  long last;
-	  ioctl(fd, CDROM_NEXT_WRITABLE, &last);
+	  ioctl(fd, CDROM_LAST_WRITTEN, &last);
 
 	inputs:		none
 
 	outputs:
 	  The last block written on disc
 
-
+	notes:
+	  If the device does not support this ioctl directly, the
+	  result is derived from the disc's table of contents.  If the
+	  table of contents can't be read, this ioctl returns an
+	  error.
diff --git a/Documentation/ioctl/hdio.txt b/Documentation/ioctl/hdio.txt
index f5b8ef98e6e87d..c42d3b68577e70 100644
--- a/Documentation/ioctl/hdio.txt
+++ b/Documentation/ioctl/hdio.txt
@@ -28,7 +28,7 @@ are as follows:
 	HDIO_GET_IDENTITY	get IDE identification info
 	HDIO_GET_WCACHE		get write cache mode on|off
 	HDIO_GET_ACOUSTIC	get acoustic value
-	HDIO_GET_ADDRESS
+	HDIO_GET_ADDRESS	get sector addressing mode
 	HDIO_GET_BUSSTATE	get the bus state of the hwif
 	HDIO_TRISTATE_HWIF	execute a channel tristate
 	HDIO_DRIVE_RESET	execute a device reset
@@ -55,8 +55,8 @@ are as follows:
 	HDIO_SET_QDMA		change use-qdma flag
 	HDIO_SET_ADDRESS	change lba addressing modes
 
-	HDIO_SET_IDE_SCSI
-	HDIO_SET_SCSI_IDE
+	HDIO_SET_IDE_SCSI	Set scsi emulation mode on/off
+	HDIO_SET_SCSI_IDE	not implemented yet
 
 
 The information that follows was determined from reading kernel source
@@ -73,8 +73,9 @@ General:
 	Unless otherwise specified, all ioctl calls return 0 on success
 	and -1 with errno set to an appropriate value on error.
 
-	Unless otherwise specified, all ioctl calls return EFAULT on a
-	failed attempt to copy data to or from user address space.
+	Unless otherwise specified, all ioctl calls return -1 and set
+	errno to EFAULT on a failed attempt to copy data to or from user
+	address space.
 
 	Unless otherwise specified, all data structures and constants
 	are defined in <linux/hdreg.h>
@@ -145,7 +146,7 @@ HDIO_SET_UNMASKINTR		permit other irqs during I/O
 
 	usage:
 
-	  long val;
+	  unsigned long val;
 	  ioctl(fd, HDIO_SET_UNMASKINTR, val);
 
 	inputs:
@@ -204,7 +205,7 @@ HDIO_SET_MULTCOUNT		change IDE blockmode
 
 	    This is tightly woven into the driver->do_special can not
 	    touch.  DON'T do it again until a total personality rewrite
-	    is committed."
+	    is committed.
 
 	  If blockmode has already been set, this ioctl will fail with
 	  EBUSY
@@ -371,14 +372,12 @@ HDIO_SET_NICE			set nice flags
 
 	usage:
 
-	  int nice;
+	  unsigned long nice;
 	  ...
 	  ioctl(fd, HDIO_SET_NICE, nice);
 
 	inputs:
-	  args[0]	io address to probe
-	  args[1]	control address to probe
-	  args[2]	irq number
+	  bitmask of nice flags.
 
 	outputs:	none
 
@@ -392,6 +391,9 @@ HDIO_SET_NICE			set nice flags
 	  This ioctl sets the DSC_OVERLAP and NICE_1 flags from values
 	  provided by the user.
 
+	  Nice flags are listed in <linux/hdreg.h>, starting with
+	  IDE_NICE_DSC_OVERLAP.  These values represent shifts.
+
 
 
 
@@ -509,7 +511,7 @@ HDIO_DRIVE_RESET		execute a device reset
 
 	notes:
 
-	  Aborts any current command, prevent anything else from being
+	  Abort any current command, prevent anything else from being
 	  queued, execute a reset on the device, and issue BLKRRPART
 	  ioctl on the block device.
 
@@ -523,6 +525,10 @@ HDIO_DRIVE_TASKFILE		execute raw taskfile
 	Note:  If you don't have a copy of the ANSI ATA specification
 	handy, you should probably ignore this ioctl.
 
+	Execute an ATA disk command directly by writing the "taskfile"
+	registers of the drive.  Requires ADMIN and RAWIO access
+	privileges.
+
 	usage:
 
 	  struct {
@@ -541,27 +547,27 @@ HDIO_DRIVE_TASKFILE		execute raw taskfile
 
 	  (See below for details on memory area passed to ioctl.)
 
-	  io_ports[]	values to be written to taskfile registers
-	  hob_ports[]	values to be written to taskfile registers
+	  io_ports[8]	values to be written to taskfile registers
+	  hob_ports[8]	high-order bytes, for extended commands.
 	  out_flags	flags indicating which registers are valid
 	  in_flags	flags indicating which registers should be returned
 	  data_phase	see below
 	  req_cmd	command type to be executed
 	  out_size	size of output buffer
 	  outbuf	buffer of data to be transmitted to disk
-	  inbuf		buffer of data to be received from disk
+	  inbuf		buffer of data to be received from disk (see [1])
 
 	outputs:
 
 	  io_ports[]	values returned in the taskfile registers
-	  hob_ports[]	values returned in the taskfile registers
-	  out_flags	flags indicating which registers are valid
+	  hob_ports[]	high-order bytes, for extended commands.
+	  out_flags	flags indicating which registers are valid (see [2])
 	  in_flags	flags indicating which registers should be returned
-	  outbuf	buffer of data to be transmitted to disk
+	  outbuf	buffer of data to be transmitted to disk (see [1])
 	  inbuf		buffer of data to be received from disk
 
 	error returns:
-	  EACCES	CAP_SYS_ADMIN or CAP_SYS_RAWIO privelege not set.
+	  EACCES	CAP_SYS_ADMIN or CAP_SYS_RAWIO privilege not set.
 	  ENOMSG	Device is not a disk drive.
 	  ENOMEM	Unable to allocate memory for task
 	  EFAULT	req_cmd == TASKFILE_IN_OUT (not implemented as of 2.6.8)
@@ -571,9 +577,14 @@ HDIO_DRIVE_TASKFILE		execute raw taskfile
 
 	notes:
 
-	  Execute an ATA disk command directly by writing the "taskfile"
-	  registers of the drive.  Requires ADMIN and RAWIO access
-	  privileges.
+	  [1] Currently (2.6.8), both the input and output buffers are
+	  copied from the user and written back to the user, even when
+	  not used.  This may be a bug.
+
+	  [2] The out_flags and in_flags are returned to the user after
+	  the ioctl completes.	Currently (2.6.8) these are the same
+	  as the input values, unchanged.  In the future, they may have
+	  more significance.
 
 	  Extreme caution should be used with using this ioctl.  A
 	  mistake can easily corrupt data or hang the system.
@@ -590,7 +601,7 @@ HDIO_DRIVE_TASKFILE		execute raw taskfile
 	    hob_ports[8]	high-order bytes, for extended commands
 	    out_flags		flags indicating which entries in the
 	    			io_ports[] and hob_ports[] arrays
-				contain valid values.
+				contain valid values.  Type ide_reg_valid_t.
 	    in_flags		flags indicating which entries in the
 	    			io_ports[] and hob_ports[] arrays
 				are expected to contain valid values
@@ -600,8 +611,11 @@ HDIO_DRIVE_TASKFILE		execute raw taskfile
 	    out_size		output (user->drive) buffer size, bytes
 	    in_size		input (drive->user) buffer size, bytes
 
-	  Unused fields of io_ports[] and hob_ports[] should be set to
-	  zero.
+	  This ioctl does not necessarily respect all flags in the
+	  out_flags and in_flags values -- some taskfile registers
+	  may be written or read even if not requested in the flags.
+	  Unused fields of io_ports[] and hob_ports[] should be set
+	  to zero.
 
 	  The data_phase field describes the data transfer to be
 	  performed.  Value is one of:
@@ -631,10 +645,6 @@ HDIO_DRIVE_TASKFILE		execute raw taskfile
 	    IDE_DRIVE_TASK_OUT
 	    IDE_DRIVE_TASK_RAW_WRITE
 
-	  Currently (2.6.8), both the input and output buffers are
-	  copied from the user and written back to the user, even when
-	  not used.
-
 
 
 
@@ -666,11 +676,17 @@ HDIO_DRIVE_CMD			execute a special drive command
 	    args[0]	status
 	    args[1]	error
 	    args[2]	NSECTOR
+	    args[3]	undefined
+	    args[4+]	NSECTOR * 512 bytes of data returned by the command.
 
 	error returns:
 	  EACCES	Access denied:  requires CAP_SYS_RAWIO
 	  ENOMEM	Unable to allocate memory for task
 
+	notes:
+
+	  Taskfile registers IDE_LCYL, IDE_HCYL, and IDE_SELECT are
+	  set to zero before executing the command.
 
 
 
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 7168ecf167dae5..ed2fbf2da775ef 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -701,6 +701,9 @@ running once the system is up.
 	mem=nn[KMG]	[KNL,BOOT] Force usage of a specific amount of memory
 			Amount of memory to be used when the kernel is not able
 			to see the whole system memory or for test.
+			[IA-32] Use together with memmap= to avoid physical
+			address space collisions. Without memmap= PCI devices
+			could be placed at addresses belonging to unused RAM.
 
 	mem=nopentium	[BUGS=IA-32] Disable usage of 4MB pages for kernel
 			memory.
@@ -1271,11 +1274,6 @@ running once the system is up.
 	specialix=	[HW,SERIAL] Specialix multi-serial port adapter
 			See Documentation/specialix.txt.
 
-	speedstep_coppermine=
-			[HW,IA-32] Take CPU in your notebook as SpeedStep-capable
-			See comment before function speedstep_setup() in
-			arch/i386/kernel/cpu/cpufreq/speedstep.c.
-
 	spia_io_base=	[HW,MTD]
 	spia_fio_base=
 	spia_pedr=
diff --git a/Documentation/memory.txt b/Documentation/memory.txt
index 7af1709e8facbd..2b3dedd39538f0 100644
--- a/Documentation/memory.txt
+++ b/Documentation/memory.txt
@@ -21,6 +21,8 @@ systems.
 All of these problems can be addressed with the "mem=XXXM" boot option
 (where XXX is the size of RAM to use in megabytes).  
 It can also tell Linux to use less memory than is actually installed.
+If you use "mem=" on a machine with PCI, consider using "memmap=" to avoid
+physical address space collisions.
 
 See the documentation of your boot loader (LILO, loadlin, etc.) about
 how to pass options to the kernel.
@@ -44,7 +46,9 @@ Try:
 	* Disabling the cache from the BIOS.
 
 	* Try passing the "mem=4M" option to the kernel to limit
-	  Linux to using a very small amount of memory.
+	  Linux to using a very small amount of memory. Use "memmap="-option
+	  together with "mem=" on systems with PCI to avoid physical address
+	  space collisions.
 
 
 Other tricks:
diff --git a/Documentation/rocket.txt b/Documentation/rocket.txt
index f9345cd14e166d..a1067800445192 100644
--- a/Documentation/rocket.txt
+++ b/Documentation/rocket.txt
@@ -20,8 +20,27 @@ or installing it into kernels which do not have the driver configured
 into them.  Installations instructions for the external module
 are in the included README and HW_INSTALL files.
 
-RocketPort ISA and RocketModem II PCI boards are also supported by this
-driver, but must use the external module driver for configuration reasons.  
+RocketPort ISA and RocketModem II PCI boards currently are only supported by
+this driver in module form.
+
+The RocketPort ISA board requires I/O ports to be configured by the DIP
+switches on the board.  See the section "ISA Rocketport Boards" below for
+information on how to set the DIP switches.
+
+You pass the I/O port to the driver using the following module parameters:
+
+board1 :	I/O port for the first ISA board
+board2 :	I/O port for the second ISA board
+board3 :	I/O port for the third ISA board
+board4 :	I/O port for the fourth ISA board
+
+There is a set of utilities and scripts provided with the external driver
+( downloadable from http://www.comtrol.com ) that ease the configuration and
+setup of the ISA cards.
+
+The RocketModem II PCI boards require firmware to be loaded into the card
+before it will function.  The driver has only been tested as a module for this
+board.
 
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 
@@ -55,12 +74,95 @@ create the RocketPort/RocketModem device names, use the command
 >mknod /dev/ttyR1 c 46 1
 >mknod /dev/ttyR2 c 46 2  
 
-The Linux script MAKEDEV will create the first 16 ttyRx device names (nodes) for you:
+The Linux script MAKEDEV will create the first 16 ttyRx device names (nodes)
+for you:
 
 >/dev/MAKEDEV ttyR
 
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 
+ISA Rocketport Boards
+---------------------
+
+You must assign and configure the I/O addresses used by the ISA Rocketport
+card before installing and using it.  This is done by setting a set of DIP
+switches on the Rocketport board.
+
+
+SETTING THE I/O ADDRESS
+-----------------------
+
+Before installing RocketPort(R) or RocketPort RA boards, you must find
+a range of I/O addresses for it to use. The first RocketPort card
+requires a 68-byte contiguous block of I/O addresses, starting at one
+of the following: 0x100h, 0x140h, 0x180h, 0x200h, 0x240h, 0x280h,
+0x300h, 0x340h, 0x380h.  This I/O address must be reflected in the DIP
+switiches of *all* of the Rocketport cards.
+
+The second, third, and fourth RocketPort cards require a 64-byte
+contiguous block of I/O addresses, starting at one of the following
+I/O addresses: 0x100h, 0x140h, 0x180h, 0x1C0h, 0x200h, 0x240h, 0x280h,
+0x2C0h, 0x300h, 0x340h, 0x380h, 0x3C0h.  The I/O address used by the
+second, third, and fourth Rocketport cards (if present) are set via
+software control.  The DIP switch settings for the I/O address must be
+set to the value of the first Rocketport cards.
+
+In order to destinguish each of the card from the others, each card
+must have a unique board ID set on the dip switches.  The first
+Rocketport board must be set with the DIP switches corresponding to
+the first board, the second board must be set with the DIP switches
+corresponding to the second board, etc.  IMPORTANT: The board ID is
+the only place where the DIP switch settings should differ between the
+various Rocketport boards in a system.
+
+The I/O address range used by any of the RocketPort cards must not
+conflict with any other cards in the system, including other
+RocketPort cards.  Below, you will find a list of commonly used I/O
+address ranges which may be in use by other devices in your system.
+On a Linux system, "cat /proc/ioports" will also be helpful in
+identifying what I/O addresses are being used by devics on your
+system.
+
+Remember, the FIRST RocketPort uses 68 I/O addresses.  So, if you set it
+for 0x100, it will occupy 0x100 to 0x143.  This would mean that you
+CAN NOT set the second, third or fourth board for address 0x140 since
+the first 4 bytes of that range are used by the first board.  You would
+need to set the second, third, or fourth board to one of the next available
+blocks such as 0x180.
+
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+
+RocketPort and RocketPort RA SW1 Settings:
+
+          +-------------------------------+
+          | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
+          +-------+-------+---------------+
+          | Unused| Card  | I/O Port Block|
+          +-------------------------------+
+
+DIP Switches                             DIP Switches
+7    8                                   6    5
+===================                      ===================
+On   On   UNUSED, MUST BE ON.            On   On   First Card    <==== Default
+                                         On   Off  Second Card
+                                         Off  On   Third Card
+                                         Off  Off  Fourth Card
+
+DIP Switches         I/O Address Range
+4    3    2    1     Used by the First Card
+=====================================
+On   Off  On   Off   100-143
+On   Off  Off  On    140-183
+On   Off  Off  Off   180-1C3       <==== Default
+Off  On   On   Off   200-243
+Off  On   Off  On    240-283
+Off  On   Off  Off   280-2C3
+Off  Off  On   Off   300-343
+Off  Off  Off  On    340-383
+Off  Off  Off  Off   380-3C3
+
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+
 REPORTING BUGS
 --------------