Patched in Tegra support.

11 files changed, 46 insertions, 200 deletions

diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index 157416e78cc..2871fd50034 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -20,8 +20,6 @@ Supported adapters:
   * Intel Patsburg (PCH)
   * Intel DH89xxCC (PCH)
   * Intel Panther Point (PCH)
-  * Intel Lynx Point (PCH)
-  * Intel Lynx Point-LP (PCH)
    Datasheets: Publicly available at the Intel website
 
 On Intel Patsburg and later chipsets, both the normal host SMBus controller
@@ -39,10 +37,9 @@ Module Parameters
 Disable selected features normally supported by the device. This makes it
 possible to work around possible driver or hardware bugs if the feature in
 question doesn't work as intended for whatever reason. Bit values:
- 0x01  disable SMBus PEC
- 0x02  disable the block buffer
- 0x08  disable the I2C block read functionality
- 0x10  don't use interrupts
+  1  disable SMBus PEC
+  2  disable the block buffer
+  8  disable the I2C block read functionality
 
 
 Description
@@ -88,12 +85,6 @@ SMBus 2.0 Support
 The 82801DB (ICH4) and later chips support several SMBus 2.0 features.
 
 
-Interrupt Support
------------------
-
-PCI interrupt support is supported on the 82801EB (ICH5) and later chips.
-
-
 Hidden ICH SMBus
 ----------------
 
diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4
index 1e6634f54c5..475bb4ae072 100644
--- a/Documentation/i2c/busses/i2c-piix4
+++ b/Documentation/i2c/busses/i2c-piix4
@@ -8,11 +8,6 @@ Supported adapters:
     Datasheet: Only available via NDA from ServerWorks
   * ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges
     Datasheet: Not publicly available
-    SB700 register reference available at:
-    http://support.amd.com/us/Embedded_TechDocs/43009_sb7xx_rrg_pub_1.00.pdf
-  * AMD SP5100 (SB700 derivative found on some server mainboards)
-    Datasheet: Publicly available at the AMD website
-    http://support.amd.com/us/Embedded_TechDocs/44413.pdf
   * AMD Hudson-2
     Datasheet: Not publicly available
   * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
@@ -73,10 +68,6 @@ this driver on those mainboards.
 The ServerWorks Southbridges, the Intel 440MX, and the Victory66 are
 identical to the PIIX4 in I2C/SMBus support.
 
-The AMD SB700 and SP5100 chipsets implement two PIIX4-compatible SMBus
-controllers. If your BIOS initializes the secondary controller, it will
-be detected by this driver as an "Auxiliary SMBus Host Controller".
-
 If you own Force CPCI735 motherboard or other OSB4 based systems you may need
 to change the SMBus Interrupt Select register so the SMBus controller uses
 the SMI mode.
diff --git a/Documentation/i2c/busses/i2c-viapro b/Documentation/i2c/busses/i2c-viapro
index b88f91ae580..2e758b0e945 100644
--- a/Documentation/i2c/busses/i2c-viapro
+++ b/Documentation/i2c/busses/i2c-viapro
@@ -20,10 +20,7 @@ Supported adapters:
     Datasheet: available on http://linux.via.com.tw
 
   * VIA Technologies, Inc. VX855/VX875
-    Datasheet: available on http://linux.via.com.tw
-
-  * VIA Technologies, Inc. VX900
-    Datasheet: available on http://linux.via.com.tw
+    Datasheet: Availability unknown
 
 Authors:
         Kyösti Mälkki <kmalkki@cc.hut.fi>,
@@ -60,7 +57,6 @@ Your lspci -n listing must show one of these :
  device 1106:8324   (CX700)
  device 1106:8353   (VX800/VX820)
  device 1106:8409   (VX855/VX875)
- device 1106:8410   (VX900)
 
 If none of these show up, you should look in the BIOS for settings like
 enable ACPI / SMBus or even USB.
diff --git a/Documentation/i2c/busses/scx200_acb b/Documentation/i2c/busses/scx200_acb
index ce83c871fe9..7c07883d4df 100644
--- a/Documentation/i2c/busses/scx200_acb
+++ b/Documentation/i2c/busses/scx200_acb
@@ -28,5 +28,5 @@ If the scx200_acb driver is built into the kernel, add the following
 parameter to your boot command line:
   scx200_acb.base=0x810,0x820
 If the scx200_acb driver is built as a module, add the following line to
-a configuration file in /etc/modprobe.d/ instead:
+the file /etc/modprobe.conf instead:
   options scx200_acb base=0x810,0x820
diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality
index b0ff2ab596c..42c17c1fb3c 100644
--- a/Documentation/i2c/functionality
+++ b/Documentation/i2c/functionality
@@ -18,9 +18,9 @@ For the most up-to-date list of functionality constants, please check
                                   adapters typically can not do these)
   I2C_FUNC_10BIT_ADDR             Handles the 10-bit address extensions
   I2C_FUNC_PROTOCOL_MANGLING      Knows about the I2C_M_IGNORE_NAK,
-                                  I2C_M_REV_DIR_ADDR and I2C_M_NO_RD_ACK
-                                  flags (which modify the I2C protocol!)
-  I2C_FUNC_NOSTART                Can skip repeated start sequence
+                                  I2C_M_REV_DIR_ADDR, I2C_M_NOSTART and
+                                  I2C_M_NO_RD_ACK flags (which modify the
+                                  I2C protocol!)
   I2C_FUNC_SMBUS_QUICK            Handles the SMBus write_quick command
   I2C_FUNC_SMBUS_READ_BYTE        Handles the SMBus read_byte command
   I2C_FUNC_SMBUS_WRITE_BYTE       Handles the SMBus write_byte command
@@ -50,9 +50,6 @@ A few combinations of the above flags are also defined for your convenience:
                                   emulated by a real I2C adapter (using
                                   the transparent emulation layer)
 
-In kernel versions prior to 3.5 I2C_FUNC_NOSTART was implemented as
-part of I2C_FUNC_PROTOCOL_MANGLING.
-
 
 ADAPTER IMPLEMENTATION
 ----------------------
diff --git a/Documentation/i2c/i2c-protocol b/Documentation/i2c/i2c-protocol
index 0b3e62d1f77..10518dd5881 100644
--- a/Documentation/i2c/i2c-protocol
+++ b/Documentation/i2c/i2c-protocol
@@ -49,9 +49,7 @@ a byte read, followed by a byte write:
 Modified transactions
 =====================
 
-The following modifications to the I2C protocol can also be generated,
-with the exception of I2C_M_NOSTART these are usually only needed to
-work around device issues:
+We have found some I2C devices that needs the following modifications:
 
   Flag I2C_M_NOSTART: 
     In a combined transaction, no 'S Addr Wr/Rd [A]' is generated at some
@@ -62,11 +60,6 @@ work around device issues:
     we do not generate Addr, but we do generate the startbit S. This will
     probably confuse all other clients on your bus, so don't try this.
 
-    This is often used to gather transmits from multiple data buffers in
-    system memory into something that appears as a single transfer to the
-    I2C device but may also be used between direction changes by some
-    rare devices.
-
   Flags I2C_M_REV_DIR_ADDR
     This toggles the Rd/Wr flag. That is, if you want to do a write, but
     need to emit an Rd instead of a Wr, or vice versa, you set this
diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices
index 22182660dda..9edb75d8c9b 100644
--- a/Documentation/i2c/instantiating-devices
+++ b/Documentation/i2c/instantiating-devices
@@ -87,11 +87,11 @@ it may have different addresses from one board to the next (manufacturer
 changing its design without notice). In this case, you can call
 i2c_new_probed_device() instead of i2c_new_device().
 
-Example (from the nxp OHCI driver):
+Example (from the pnx4008 OHCI driver):
 
 static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
 
-static int usb_hcd_nxp_probe(struct platform_device *pdev)
+static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev)
 {
         (...)
         struct i2c_adapter *i2c_adap;
@@ -100,7 +100,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
         (...)
         i2c_adap = i2c_get_adapter(2);
         memset(&i2c_info, 0, sizeof(struct i2c_board_info));
-        strlcpy(i2c_info.type, "isp1301_nxp", I2C_NAME_SIZE);
+        strlcpy(i2c_info.type, "isp1301_pnx", I2C_NAME_SIZE);
         isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info,
                                                    normal_i2c, NULL);
         i2c_put_adapter(i2c_adap);
diff --git a/Documentation/i2c/muxes/i2c-mux-gpio b/Documentation/i2c/muxes/i2c-mux-gpio
deleted file mode 100644
index d4d91a53fc3..00000000000
--- a/Documentation/i2c/muxes/i2c-mux-gpio
+++ /dev/null
@@ -1,83 +0,0 @@
-Kernel driver i2c-gpio-mux
-
-Author: Peter Korsgaard <peter.korsgaard@barco.com>
-
-Description
------------
-
-i2c-gpio-mux is an i2c mux driver providing access to I2C bus segments
-from a master I2C bus and a hardware MUX controlled through GPIO pins.
-
-E.G.:
-
-  ----------              ----------  Bus segment 1   - - - - -
- |          | SCL/SDA    |          |-------------- |           |
- |          |------------|          |
- |          |            |          | Bus segment 2 |           |
- |  Linux   | GPIO 1..N  |   MUX    |---------------   Devices
- |          |------------|          |               |           |
- |          |            |          | Bus segment M
- |          |            |          |---------------|           |
-  ----------              ----------                  - - - - -
-
-SCL/SDA of the master I2C bus is multiplexed to bus segment 1..M
-according to the settings of the GPIO pins 1..N.
-
-Usage
------
-
-i2c-gpio-mux uses the platform bus, so you need to provide a struct
-platform_device with the platform_data pointing to a struct
-gpio_i2cmux_platform_data with the I2C adapter number of the master
-bus, the number of bus segments to create and the GPIO pins used
-to control it. See include/linux/i2c-gpio-mux.h for details.
-
-E.G. something like this for a MUX providing 4 bus segments
-controlled through 3 GPIO pins:
-
-#include <linux/i2c-gpio-mux.h>
-#include <linux/platform_device.h>
-
-static const unsigned myboard_gpiomux_gpios[] = {
-        AT91_PIN_PC26, AT91_PIN_PC25, AT91_PIN_PC24
-};
-
-static const unsigned myboard_gpiomux_values[] = {
-        0, 1, 2, 3
-};
-
-static struct gpio_i2cmux_platform_data myboard_i2cmux_data = {
-        .parent         = 1,
-        .base_nr        = 2, /* optional */
-        .values         = myboard_gpiomux_values,
-        .n_values       = ARRAY_SIZE(myboard_gpiomux_values),
-        .gpios          = myboard_gpiomux_gpios,
-        .n_gpios        = ARRAY_SIZE(myboard_gpiomux_gpios),
-        .idle           = 4, /* optional */
-};
-
-static struct platform_device myboard_i2cmux = {
-        .name           = "i2c-gpio-mux",
-        .id             = 0,
-        .dev            = {
-                .platform_data  = &myboard_i2cmux_data,
-        },
-};
-
-If you don't know the absolute GPIO pin numbers at registration time,
-you can instead provide a chip name (.chip_name) and relative GPIO pin
-numbers, and the i2c-gpio-mux driver will do the work for you,
-including deferred probing if the GPIO chip isn't immediately
-available.
-
-Device Registration
--------------------
-
-When registering your i2c-gpio-mux device, you should pass the number
-of any GPIO pin it uses as the device ID. This guarantees that every
-instance has a different ID.
-
-Alternatively, if you don't need a stable device name, you can simply
-pass PLATFORM_DEVID_AUTO as the device ID, and the platform core will
-assign a dynamic ID to your device. If you do not know the absolute
-GPIO pin numbers at registration time, this is even the only option.
diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol
index d1f22618e14..7c19d1a2bea 100644
--- a/Documentation/i2c/smbus-protocol
+++ b/Documentation/i2c/smbus-protocol
@@ -23,12 +23,6 @@ don't match these function names.  For some of the operations which pass a
 single data byte, the functions using SMBus protocol operation names execute
 a different protocol operation entirely.
 
-Each transaction type corresponds to a functionality flag. Before calling a
-transaction function, a device driver should always check (just once) for
-the corresponding functionality flag to ensure that the underlying I2C
-adapter supports the transaction in question. See
-<file:Documentation/i2c/functionality> for the details.
-
 
 Key to symbols
 ==============
@@ -55,8 +49,6 @@ This sends a single bit to the device, at the place of the Rd/Wr bit.
 
 A Addr Rd/Wr [A] P
 
-Functionality flag: I2C_FUNC_SMBUS_QUICK
-
 
 SMBus Receive Byte:  i2c_smbus_read_byte()
 ==========================================
@@ -68,8 +60,6 @@ the previous SMBus command.
 
 S Addr Rd [A] [Data] NA P
 
-Functionality flag: I2C_FUNC_SMBUS_READ_BYTE
-
 
 SMBus Send Byte:  i2c_smbus_write_byte()
 ========================================
@@ -79,8 +69,6 @@ to a device.  See Receive Byte for more information.
 
 S Addr Wr [A] Data [A] P
 
-Functionality flag: I2C_FUNC_SMBUS_WRITE_BYTE
-
 
 SMBus Read Byte:  i2c_smbus_read_byte_data()
 ============================================
@@ -90,8 +78,6 @@ The register is specified through the Comm byte.
 
 S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P
 
-Functionality flag: I2C_FUNC_SMBUS_READ_BYTE_DATA
-
 
 SMBus Read Word:  i2c_smbus_read_word_data()
 ============================================
@@ -102,12 +88,6 @@ byte. But this time, the data is a complete word (16 bits).
 
 S Addr Wr [A] Comm [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P
 
-Functionality flag: I2C_FUNC_SMBUS_READ_WORD_DATA
-
-Note the convenience function i2c_smbus_read_word_swapped is
-available for reads where the two data bytes are the other way
-around (not SMBus compliant, but very popular.)
-
 
 SMBus Write Byte:  i2c_smbus_write_byte_data()
 ==============================================
@@ -118,8 +98,6 @@ the Read Byte operation.
 
 S Addr Wr [A] Comm [A] Data [A] P
 
-Functionality flag: I2C_FUNC_SMBUS_WRITE_BYTE_DATA
-
 
 SMBus Write Word:  i2c_smbus_write_word_data()
 ==============================================
@@ -130,12 +108,6 @@ specified through the Comm byte.
 
 S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] P
 
-Functionality flag: I2C_FUNC_SMBUS_WRITE_WORD_DATA
-
-Note the convenience function i2c_smbus_write_word_swapped is
-available for writes where the two data bytes are the other way
-around (not SMBus compliant, but very popular.)
-
 
 SMBus Process Call:  i2c_smbus_process_call()
 =============================================
@@ -146,8 +118,6 @@ This command selects a device register (through the Comm byte), sends
 S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] 
                              S Addr Rd [A] [DataLow] A [DataHigh] NA P
 
-Functionality flag: I2C_FUNC_SMBUS_PROC_CALL
-
 
 SMBus Block Read:  i2c_smbus_read_block_data()
 ==============================================
@@ -159,8 +129,6 @@ of data is specified by the device in the Count byte.
 S Addr Wr [A] Comm [A] 
            S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
 
-Functionality flag: I2C_FUNC_SMBUS_READ_BLOCK_DATA
-
 
 SMBus Block Write:  i2c_smbus_write_block_data()
 ================================================
@@ -171,8 +139,6 @@ Comm byte. The amount of data is specified in the Count byte.
 
 S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P
 
-Functionality flag: I2C_FUNC_SMBUS_WRITE_BLOCK_DATA
-
 
 SMBus Block Write - Block Read Process Call
 ===========================================
@@ -186,8 +152,6 @@ This command selects a device register (through the Comm byte), sends
 S Addr Wr [A] Comm [A] Count [A] Data [A] ...
                              S Addr Rd [A] [Count] A [Data] ... A P
 
-Functionality flag: I2C_FUNC_SMBUS_BLOCK_PROC_CALL
-
 
 SMBus Host Notify
 =================
@@ -257,7 +221,15 @@ designated register that is specified through the Comm byte.
 S Addr Wr [A] Comm [A] 
            S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
 
-Functionality flag: I2C_FUNC_SMBUS_READ_I2C_BLOCK
+
+I2C Block Read (2 Comm bytes)
+=============================
+
+This command reads a block of bytes from a device, from a 
+designated register that is specified through the two Comm bytes.
+
+S Addr Wr [A] Comm1 [A] Comm2 [A] 
+           S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
 
 
 I2C Block Write:  i2c_smbus_write_i2c_block_data()
@@ -269,5 +241,3 @@ Comm byte. Note that command lengths of 0, 2, or more bytes are
 supported as they are indistinguishable from data.
 
 S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P
-
-Functionality flag: I2C_FUNC_SMBUS_WRITE_I2C_BLOCK
diff --git a/Documentation/i2c/ten-bit-addresses b/Documentation/i2c/ten-bit-addresses
index cdfe13901b9..e9890709c50 100644
--- a/Documentation/i2c/ten-bit-addresses
+++ b/Documentation/i2c/ten-bit-addresses
@@ -1,24 +1,22 @@
 The I2C protocol knows about two kinds of device addresses: normal 7 bit
 addresses, and an extended set of 10 bit addresses. The sets of addresses
 do not intersect: the 7 bit address 0x10 is not the same as the 10 bit
-address 0x10 (though a single device could respond to both of them).
+address 0x10 (though a single device could respond to both of them). You
+select a 10 bit address by adding an extra byte after the address
+byte:
+  S Addr7 Rd/Wr ....
+becomes
+  S 11110 Addr10 Rd/Wr
+S is the start bit, Rd/Wr the read/write bit, and if you count the number
+of bits, you will see the there are 8 after the S bit for 7 bit addresses,
+and 16 after the S bit for 10 bit addresses.
 
-I2C messages to and from 10-bit address devices have a different format.
-See the I2C specification for the details.
+WARNING! The current 10 bit address support is EXPERIMENTAL. There are
+several places in the code that will cause SEVERE PROBLEMS with 10 bit
+addresses, even though there is some basic handling and hooks. Also,
+almost no supported adapter handles the 10 bit addresses correctly.
 
-The current 10 bit address support is minimal. It should work, however
-you can expect some problems along the way:
-* Not all bus drivers support 10-bit addresses. Some don't because the
-  hardware doesn't support them (SMBus doesn't require 10-bit address
-  support for example), some don't because nobody bothered adding the
-  code (or it's there but not working properly.) Software implementation
-  (i2c-algo-bit) is known to work.
-* Some optional features do not support 10-bit addresses. This is the
-  case of automatic detection and instantiation of devices by their,
-  drivers, for example.
-* Many user-space packages (for example i2c-tools) lack support for
-  10-bit addresses.
-
-Note that 10-bit address devices are still pretty rare, so the limitations
-listed above could stay for a long time, maybe even forever if nobody
-needs them to be fixed.
+As soon as a real 10 bit address device is spotted 'in the wild', we
+can and will add proper support. Right now, 10 bit address devices
+are defined by the I2C protocol, but we have never seen a single device
+which supports them.
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index 3a94b0e6f60..5aa53374ea2 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -245,26 +245,11 @@ static int __init foo_init(void)
 {
         return i2c_add_driver(&foo_driver);
 }
-module_init(foo_init);
 
 static void __exit foo_cleanup(void)
 {
         i2c_del_driver(&foo_driver);
 }
-module_exit(foo_cleanup);
-
-The module_i2c_driver() macro can be used to reduce above code.
-
-module_i2c_driver(foo_driver);
-
-Note that some functions are marked by `__init'.  These functions can
-be removed after kernel booting (or module loading) is completed.
-Likewise, functions marked by `__exit' are dropped by the compiler when
-the code is built into the kernel, as they would never be called.
-
-
-Driver Information
-==================
 
 /* Substitute your own name and email address */
 MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
@@ -273,6 +258,14 @@ MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
 /* a few non-GPL license types are also allowed */
 MODULE_LICENSE("GPL");
 
+module_init(foo_init);
+module_exit(foo_cleanup);
+
+Note that some functions are marked by `__init'.  These functions can
+be removed after kernel booting (or module loading) is completed.
+Likewise, functions marked by `__exit' are dropped by the compiler when
+the code is built into the kernel, as they would never be called.
+
 
 Power Management
 ================