redonkable
/
remarkable-linux
1
0
Fork 0
Code Releases Activity

spi: Document SPI slave controller support 

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
zero-colors
Geert Uytterhoeven 2017-05-22 15:11:42 +02:00 committed by Mark Brown
parent 6c364062bf
commit aa2ea9115b
1 changed files with 20 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
Documentation/spi/spi-summary
View File

@ -62,8 +62,8 @@ chips described as using "three wire" signaling: SCK, data, nCSx.
(That data line is sometimes called MOMI or SISO.) (That data line is sometimes called MOMI or SISO.)
Microcontrollers often support both master and slave sides of the SPI Microcontrollers often support both master and slave sides of the SPI
protocol. This document (and Linux) currently only supports the master protocol. This document (and Linux) supports both the master and slave
side of SPI interactions. sides of SPI interactions.
Who uses it? On what kinds of systems? Who uses it? On what kinds of systems?
@ -154,9 +154,8 @@ control audio interfaces, present touchscreen sensors as input interfaces,
or monitor temperature and voltage levels during industrial processing. or monitor temperature and voltage levels during industrial processing.
And those might all be sharing the same controller driver. And those might all be sharing the same controller driver.
A "struct spi_device" encapsulates the master-side interface between A "struct spi_device" encapsulates the controller-side interface between
those two types of driver. At this writing, Linux has no slave side those two types of drivers.
programming interface.
There is a minimal core of SPI programming interfaces, focussing on There is a minimal core of SPI programming interfaces, focussing on
using the driver model to connect controller and protocol drivers using using the driver model to connect controller and protocol drivers using
@ -177,10 +176,24 @@ shows up in sysfs in several locations:
/sys/bus/spi/drivers/D ... driver for one or more spi*.* devices /sys/bus/spi/drivers/D ... driver for one or more spi*.* devices
/sys/class/spi_master/spiB ... symlink (or actual device node) to /sys/class/spi_master/spiB ... symlink (or actual device node) to
a logical node which could hold class related state for the a logical node which could hold class related state for the SPI
controller managing bus "B". All spiB.* devices share one master controller managing bus "B". All spiB.* devices share one
physical SPI bus segment, with SCLK, MOSI, and MISO. physical SPI bus segment, with SCLK, MOSI, and MISO.
/sys/devices/.../CTLR/slave ... virtual file for (un)registering the
slave device for an SPI slave controller.
Writing the driver name of an SPI slave handler to this file
registers the slave device; writing "(null)" unregisters the slave
device.
Reading from this file shows the name of the slave device ("(null)"
if not registered).
/sys/class/spi_slave/spiB ... symlink (or actual device node) to
a logical node which could hold class related state for the SPI
slave controller on bus "B". When registered, a single spiB.*
device is present here, possible sharing the physical SPI bus
segment with other SPI slave devices.
Note that the actual location of the controller's class state depends Note that the actual location of the controller's class state depends
on whether you enabled CONFIG_SYSFS_DEPRECATED or not. At this time, on whether you enabled CONFIG_SYSFS_DEPRECATED or not. At this time,
the only class-specific state is the bus number ("B" in "spiB"), so the only class-specific state is the bus number ("B" in "spiB"), so