max6875: Discard obsolete detect method

[safe/jmp/linux-2.6] / Documentation / spi / spi-summary

diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
index 8861e47..deab51d 100644 (file)
--- a/Documentation/spi/spi-summary
+++ b/Documentation/spi/spi-summary
@@ -116,6 +116,13 @@ low order bit.  So when a chip's timing diagram shows the clock
 starting low (CPOL=0) and data stabilized for sampling during the
 trailing clock edge (CPHA=1), that's SPI mode 1.
 
+Note that the clock mode is relevant as soon as the chipselect goes
+active.  So the master must set the clock to inactive before selecting
+a slave, and the slave can tell the chosen polarity by sampling the
+clock level when its select line goes active.  That's why many devices
+support for example both modes 0 and 3:  they don't care about polarity,
+and alway clock data in/out on rising clock edges.
+
 
 How do these driver programming interfaces work?
 ------------------------------------------------
@@ -203,12 +210,12 @@ board should normally be set up and registered.
 
 So for example arch/.../mach-*/board-*.c files might have code like:
 
-       #include <asm/arch/spi.h>       /* for mysoc_spi_data */
+       #include <mach/spi.h>   /* for mysoc_spi_data */
 
        /* if your mach-* infrastructure doesn't support kernels that can
         * run on multiple boards, pdata wouldn't benefit from "__init".
         */
-       static struct mysoc_spi_data __init pdata = { ... };
+       static struct mysoc_spi_data __initdata pdata = { ... };
 
        static __init board_init(void)
        {
@@ -220,7 +227,7 @@ So for example arch/.../mach-*/board-*.c files might have code like:
 
 And SOC-specific utility code might look something like:
 
-       #include <asm/arch/spi.h>
+       #include <mach/spi.h>
 
        static struct platform_device spi2 = { ... };
 
@@ -343,7 +350,7 @@ SPI protocol drivers somewhat resemble platform device drivers:
                .resume         = CHIP_resume,
        };
 
-The driver core will autmatically attempt to bind this driver to any SPI
+The driver core will automatically attempt to bind this driver to any SPI
 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).
@@ -379,8 +386,14 @@ any more such messages.
       + when bidirectional reads and writes start ... by how its
         sequence of spi_transfer requests is arranged;
 
+      + which I/O buffers are used ... each spi_transfer wraps a
+        buffer for each transfer direction, supporting full duplex
+        (two pointers, maybe the same one in both cases) and half
+        duplex (one pointer is NULL) transfers;
+
       + optionally defining short delays after transfers ... using
-        the spi_transfer.delay_usecs setting;
+        the spi_transfer.delay_usecs setting (this delay can be the
+        only protocol effect, if the buffer length is zero);
 
       + whether the chipselect becomes inactive after a transfer and
         any delay ... by using the spi_transfer.cs_change flag;
@@ -498,10 +511,16 @@ SPI MASTER METHODS
        This sets up the device clock rate, SPI mode, and word sizes.
        Drivers may change the defaults provided by board_info, and then
        call spi_setup(spi) to invoke this routine.  It may sleep.
+
        Unless each SPI slave has its own configuration registers, don't
        change them right away ... otherwise drivers could corrupt I/O
        that's in progress for other SPI devices.
 
+               ** BUG ALERT:  for some reason the first version of
+               ** many spi_master drivers seems to get this wrong.
+               ** 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