[PATCH] libata-hp-prep: use __ata_scsi_find_dev()

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

diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
index c6152d1ff2b019b416a0cbc2cc4b2880467d1fd3..068732d32276b1f32bf285c10522b7e103e781e4 100644 (file)
--- a/Documentation/spi/spi-summary
+++ b/Documentation/spi/spi-summary
@@ -115,6 +115,9 @@ shows up in sysfs in several locations:
    /sys/devices/.../CTLR/spiB.C ... spi_device for on bus "B",
        chipselect C, accessed through CTLR.
 
+   /sys/devices/.../CTLR/spiB.C/modalias ... identifies the driver
+       that should be used with this device (for hotplug/coldplug)
+
    /sys/bus/spi/devices/spiB.C ... symlink to the physical
        spiB-C device
 
@@ -247,6 +250,12 @@ driver is registered:
 
 Like with other static board-specific setup, you won't unregister those.
 
+The widely used "card" style computers bundle memory, cpu, and little else
+onto a card that's maybe just thirty square centimeters.  On such systems,
+your arch/.../mach-.../board-*.c file would primarily provide information
+about the devices on the mainboard into which such a card is plugged.  That
+certainly includes SPI devices hooked up through the card connectors!
+
 
 NON-STATIC CONFIGURATIONS
 
@@ -258,6 +267,10 @@ up the spi bus master, and will likely need spi_new_device() to provide the
 board info based on the board that was hotplugged.  Of course, you'd later
 call at least spi_unregister_device() when that board is removed.
 
+When Linux includes support for MMC/SD/SDIO/DataFlash cards through SPI, those
+configurations will also be dynamic.  Fortunately, those devices all support
+basic device identification probes, so that support should hotplug normally.
+
 
 How do I write an "SPI Protocol Driver"?
 ----------------------------------------
@@ -363,6 +376,22 @@ upper boundaries might include sysfs (especially for sensor readings),
 the input layer, ALSA, networking, MTD, the character device framework,
 or other Linux subsystems.
 
+Note that there are two types of memory your driver must manage as part
+of interacting with SPI devices.
+
+  - I/O buffers use the usual Linux rules, and must be DMA-safe.
+    You'd normally allocate them from the heap or free page pool.
+    Don't use the stack, or anything that's declared "static".
+
+  - The spi_message and spi_transfer metadata used to glue those
+    I/O buffers into a group of protocol transactions.  These can
+    be allocated anywhere it's convenient, including as part of
+    other allocate-once driver data structures.  Zero-init these.
+
+If you like, spi_message_alloc() and spi_message_free() convenience
+routines are available to allocate and zero-initialize an spi_message
+with several transfers.
+
 
 How do I write an "SPI Master Controller Driver"?
 -------------------------------------------------
@@ -385,7 +414,33 @@ to get the driver-private data allocated for that device.
 The driver will initialize the fields of that spi_master, including the
 bus number (maybe the same as the platform device ID) and three methods
 used to interact with the SPI core and SPI protocol drivers.  It will
-also initialize its own internal state.
+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.
+
+If you need to remove your SPI controller driver, spi_unregister_master()
+will reverse the effect of spi_register_master().
+
+
+BUS NUMBERING
+
+Bus numbering is important, since that's how Linux identifies a given
+SPI bus (shared SCK, MOSI, MISO).  Valid bus numbers start at zero.  On
+SOC systems, the bus numbers should match the numbers defined by the chip
+manufacturer.  For example, hardware controller SPI2 would be bus number 2,
+and spi_board_info for devices connected to it would use that number.
+
+If you don't have such hardware-assigned bus number, and for some reason
+you can't just assign them, then provide a negative bus number.  That will
+then be replaced by a dynamically assigned number. You'd then need to treat
+this as a non-static configuration (see above).
+
+
+SPI MASTER METHODS
 
     master->setup(struct spi_device *spi)
        This sets up the device clock rate, SPI mode, and word sizes.
@@ -402,6 +457,9 @@ also initialize its own internal state.
        state it dynamically associates with that device.  If you do that,
        be sure to provide the cleanup() method to free that state.
 
+
+SPI MESSAGE QUEUE
+
 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
@@ -411,6 +469,9 @@ But the queue will probably be very real, using message->queue, PIO,
 often DMA (especially if the root filesystem is in SPI flash), and
 execution contexts like IRQ handlers, tasklets, or workqueues (such
 as keventd).  Your driver can be as fancy, or as simple, as you need.
+Such a transfer() method would normally just add the message to a
+queue, and then start some asynchronous transfer engine (unless it's
+already running).
 
 
 THANKS TO