Patched in Tegra support.

4 files changed, 17 insertions, 87 deletions

diff --git a/Documentation/spi/ep93xx_spi b/Documentation/spi/ep93xx_spi
index 832ddce6e5f..d8eb01c15db 100644
--- a/Documentation/spi/ep93xx_spi
+++ b/Documentation/spi/ep93xx_spi
@@ -26,7 +26,7 @@ arch/arm/mach-ep93xx/ts72xx.c:
 #include <linux/gpio.h>
 #include <linux/spi/spi.h>
 
-#include <linux/platform_data/spi-ep93xx.h>
+#include <mach/ep93xx_spi.h>
 
 /* this is our GPIO line used for chip select */
 #define MMC_CHIP_SELECT_GPIO EP93XX_GPIO_LINE_EGPIO9
diff --git a/Documentation/spi/pxa2xx b/Documentation/spi/pxa2xx
index 3352f97430e..00511e08db7 100644
--- a/Documentation/spi/pxa2xx
+++ b/Documentation/spi/pxa2xx
@@ -2,7 +2,7 @@ PXA2xx SPI on SSP driver HOWTO
 ===================================================
 This a mini howto on the pxa2xx_spi driver.  The driver turns a PXA2xx
 synchronous serial port into a SPI master controller
-(see Documentation/spi/spi-summary). The driver has the following features
+(see Documentation/spi/spi_summary). The driver has the following features
 
 - Support for any PXA2xx SSP
 - SSP PIO and SSP DMA data transfers.
@@ -85,7 +85,7 @@ Declaring Slave Devices
 -----------------------
 Typically each SPI slave (chip) is defined in the arch/.../mach-*/board-*.c
 using the "spi_board_info" structure found in "linux/spi/spi.h". See
-"Documentation/spi/spi-summary" for additional information.
+"Documentation/spi/spi_summary" for additional information.
 
 Each slave device attached to the PXA must provide slave specific configuration
 information via the structure "pxa2xx_spi_chip" found in
diff --git a/Documentation/spi/spi-sc18is602 b/Documentation/spi/spi-sc18is602
deleted file mode 100644
index a45702865a3..00000000000
--- a/Documentation/spi/spi-sc18is602
+++ /dev/null
@@ -1,36 +0,0 @@
-Kernel driver spi-sc18is602
-===========================
-
-Supported chips:
-  * NXP SI18IS602/602B/603
-    Datasheet: http://www.nxp.com/documents/data_sheet/SC18IS602_602B_603.pdf
-
-Author:
-        Guenter Roeck <linux@roeck-us.net>
-
-
-Description
------------
-
-This driver provides connects a NXP SC18IS602/603 I2C-bus to SPI bridge to the
-kernel's SPI core subsystem.
-
-The driver does not probe for supported chips, since the SI18IS602/603 does not
-support Chip ID registers. You will have to instantiate the devices explicitly.
-Please see Documentation/i2c/instantiating-devices for details.
-
-
-Usage Notes
------------
-
-This driver requires the I2C adapter driver to support raw I2C messages. I2C
-adapter drivers which can only handle the SMBus protocol are not supported.
-
-The maximum SPI message size supported by SC18IS602/603 is 200 bytes. Attempts
-to initiate longer transfers will fail with -EINVAL. EEPROM read operations and
-similar large accesses have to be split into multiple chunks of no more than
-200 bytes per SPI message (128 bytes of data per message is recommended). This
-means that programs such as "cp" or "od", which automatically use large block
-sizes to access a device, can not be used directly to read data from EEPROM.
-Programs such as dd, where the block size can be specified, should be used
-instead.
diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
index 2331eb21414..4884cb33845 100644
--- a/Documentation/spi/spi-summary
+++ b/Documentation/spi/spi-summary
@@ -1,7 +1,7 @@
 Overview of Linux kernel SPI support
 ====================================
 
-02-Feb-2012
+21-May-2007
 
 What is SPI?
 ------------
@@ -345,7 +345,7 @@ SPI protocol drivers somewhat resemble platform device drivers:
                 },
 
                 .probe          = CHIP_probe,
-                .remove         = CHIP_remove,
+                .remove         = __devexit_p(CHIP_remove),
                 .suspend        = CHIP_suspend,
                 .resume         = CHIP_resume,
         };
@@ -355,7 +355,7 @@ device whose board_info gave a modalias of "CHIP".  Your probe() code
 might look like this unless you're creating a device which is managing
 a bus (appearing under /sys/class/spi_master).
 
-        static int CHIP_probe(struct spi_device *spi)
+        static int __devinit CHIP_probe(struct spi_device *spi)
         {
                 struct CHIP                     *chip;
                 struct CHIP_platform_data       *pdata;
@@ -483,9 +483,9 @@ also initialize its own internal state.  (See below about bus numbering
 and those methods.)
 
 After you initialize the spi_master, then use spi_register_master() to
-publish it to the rest of the system. At that time, device nodes for the
-controller and any predeclared spi devices will be made available, and
-the driver model core will take care of binding them to drivers.
+publish it to the rest of the system.  At that time, device nodes for
+the controller and any predeclared spi devices will be made available,
+and the driver model core will take care of binding them to drivers.
 
 If you need to remove your SPI controller driver, spi_unregister_master()
 will reverse the effect of spi_register_master().
@@ -521,53 +521,21 @@ SPI MASTER METHODS
                 ** When you code setup(), ASSUME that the controller
                 ** is actively processing transfers for another device.
 
+    master->transfer(struct spi_device *spi, struct spi_message *message)
+        This must not sleep.  Its responsibility is arrange that the
+        transfer happens and its complete() callback is issued.  The two
+        will normally happen later, after other transfers complete, and
+        if the controller is idle it will need to be kickstarted.
+
     master->cleanup(struct spi_device *spi)
         Your controller driver may use spi_device.controller_state to hold
         state it dynamically associates with that device.  If you do that,
         be sure to provide the cleanup() method to free that state.
 
-    master->prepare_transfer_hardware(struct spi_master *master)
-        This will be called by the queue mechanism to signal to the driver
-        that a message is coming in soon, so the subsystem requests the
-        driver to prepare the transfer hardware by issuing this call.
-        This may sleep.
-
-    master->unprepare_transfer_hardware(struct spi_master *master)
-        This will be called by the queue mechanism to signal to the driver
-        that there are no more messages pending in the queue and it may
-        relax the hardware (e.g. by power management calls). This may sleep.
-
-    master->transfer_one_message(struct spi_master *master,
-                                 struct spi_message *mesg)
-        The subsystem calls the driver to transfer a single message while
-        queuing transfers that arrive in the meantime. When the driver is
-        finished with this message, it must call
-        spi_finalize_current_message() so the subsystem can issue the next
-        transfer. This may sleep.
-
-    DEPRECATED METHODS
-
-    master->transfer(struct spi_device *spi, struct spi_message *message)
-        This must not sleep. Its responsibility is arrange that the
-        transfer happens and its complete() callback is issued. The two
-        will normally happen later, after other transfers complete, and
-        if the controller is idle it will need to be kickstarted. This
-        method is not used on queued controllers and must be NULL if
-        transfer_one_message() and (un)prepare_transfer_hardware() are
-        implemented.
-
 
 SPI MESSAGE QUEUE
 
-If you are happy with the standard queueing mechanism provided by the
-SPI subsystem, just implement the queued methods specified above. Using
-the message queue has the upside of centralizing a lot of code and
-providing pure process-context execution of methods. The message queue
-can also be elevated to realtime priority on high-priority SPI traffic.
-
-Unless the queueing mechanism in the SPI subsystem is selected, the bulk
-of the driver will be managing the I/O queue fed by the now deprecated
-function transfer().
+The bulk of the driver will be managing the I/O queue fed by transfer().
 
 That queue could be purely conceptual.  For example, a driver used only
 for low-frequency sensor access might be fine using synchronous PIO.
@@ -593,6 +561,4 @@ Stephen Street
 Mark Underwood
 Andrew Victor
 Vitaly Wool
-Grant Likely
-Mark Brown
-Linus Walleij
+