diff options
Diffstat (limited to 'Documentation/spi')
-rw-r--r-- | Documentation/spi/spi-summary | 15 |
1 files changed, 14 insertions, 1 deletions
diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index 8861e47e5a2d..6d5f18143c50 100644 --- 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 | |||
116 | starting low (CPOL=0) and data stabilized for sampling during the | 116 | starting low (CPOL=0) and data stabilized for sampling during the |
117 | trailing clock edge (CPHA=1), that's SPI mode 1. | 117 | trailing clock edge (CPHA=1), that's SPI mode 1. |
118 | 118 | ||
119 | Note that the clock mode is relevant as soon as the chipselect goes | ||
120 | active. So the master must set the clock to inactive before selecting | ||
121 | a slave, and the slave can tell the chosen polarity by sampling the | ||
122 | clock level when its select line goes active. That's why many devices | ||
123 | support for example both modes 0 and 3: they don't care about polarity, | ||
124 | and alway clock data in/out on rising clock edges. | ||
125 | |||
119 | 126 | ||
120 | How do these driver programming interfaces work? | 127 | How do these driver programming interfaces work? |
121 | ------------------------------------------------ | 128 | ------------------------------------------------ |
@@ -379,8 +386,14 @@ any more such messages. | |||
379 | + when bidirectional reads and writes start ... by how its | 386 | + when bidirectional reads and writes start ... by how its |
380 | sequence of spi_transfer requests is arranged; | 387 | sequence of spi_transfer requests is arranged; |
381 | 388 | ||
389 | + which I/O buffers are used ... each spi_transfer wraps a | ||
390 | buffer for each transfer direction, supporting full duplex | ||
391 | (two pointers, maybe the same one in both cases) and half | ||
392 | duplex (one pointer is NULL) transfers; | ||
393 | |||
382 | + optionally defining short delays after transfers ... using | 394 | + optionally defining short delays after transfers ... using |
383 | the spi_transfer.delay_usecs setting; | 395 | the spi_transfer.delay_usecs setting (this delay can be the |
396 | only protocol effect, if the buffer length is zero); | ||
384 | 397 | ||
385 | + whether the chipselect becomes inactive after a transfer and | 398 | + whether the chipselect becomes inactive after a transfer and |
386 | any delay ... by using the spi_transfer.cs_change flag; | 399 | any delay ... by using the spi_transfer.cs_change flag; |