spi: documentation tweaks

Update SPI documentation to clarify some areas of recent confusion: clock
polarity takes effect when chipselect goes active; and zero length buffers are
OK in certain cases.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
David Brownell 2008-04-08 17:41:58 -07:00 committed by Linus Torvalds
parent f9e522caec
commit 6395bee7e9
1 changed files with 14 additions and 1 deletions

View File

@ -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?
------------------------------------------------
@ -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;