Difference between revisions of "Category:SPI"
m (Minor wording changes) |
Ashcharles (Talk | contribs) (→Additional Links) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 10: | Line 10: | ||
Gumstix brings out SPI bus 1 chip select pins 0 and 1 on most of the Overo expansion boards. | Gumstix brings out SPI bus 1 chip select pins 0 and 1 on most of the Overo expansion boards. | ||
| + | |||
| + | SPI pins for the OMAP3 are multi-functional and need to be multiplexed for SPI use. The SPI bus 1 MOSI, SIMO, CLK, CS0 and CS1 brought out on the Overo expansion boards are correctly setup for SPI use. This configuration is done in the bootloader U-Boot. | ||
| + | |||
=== Protocol Drivers === | === Protocol Drivers === | ||
| Line 22: | Line 25: | ||
It doesn't matter which order these steps are performed. Most existing SPI drivers do the device registration completely outside the driver code in a board file. If you are writing your own driver, it is probably more convenient to do it in the driver code itself. When both device and driver registration are completed, the probe() function for the protocol driver will be called and SPI communications can start. | It doesn't matter which order these steps are performed. Most existing SPI drivers do the device registration completely outside the driver code in a board file. If you are writing your own driver, it is probably more convenient to do it in the driver code itself. When both device and driver registration are completed, the probe() function for the protocol driver will be called and SPI communications can start. | ||
| − | SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages in the protocol driver. The protocol driver | + | SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages in the protocol driver. The protocol driver submits the SPI messages to the controller driver's I/O queue. These messages are then processed asynchronously by the controller driver in FIFO order. As each message finishes, the controller notifies the protocol driver via a callback function. |
There are some synchronous helper functions exposed by the interface to simplify the asynchronous behaviour of the Linux SPI system for protocol driver writers. | There are some synchronous helper functions exposed by the interface to simplify the asynchronous behaviour of the Linux SPI system for protocol driver writers. | ||
| + | |||
=== Spidev === | === Spidev === | ||
| Line 44: | Line 48: | ||
There are more detailed instructions for getting spidev working on an Overo at the 'Writing a Linux SPI driver' link below. | There are more detailed instructions for getting spidev working on an Overo at the 'Writing a Linux SPI driver' link below. | ||
| − | |||
| − | === | + | === Additional Links === |
| + | |||
| + | [http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57:gumstix-spi-driver-part1&catid=35:gumstix&Itemid=62 Writing a Linux SPI driver] - A series of articles using Gumstix Overo in the examples | ||
| + | |||
| + | [http://elinux.org/BeagleBoard/SPI BeagleBoard/SPI] - Beagleboard SPI section on eLinux.org | ||
| + | |||
| + | [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus Serial Peripheral Interface Bus] - Wikipedia SPI article | ||
| − | + | [http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=search_page&node=558772&query=spidev Gumstix mailing list archives for spidev] | |
Latest revision as of 13:01, 1 April 2016
Overo SPI
Kernel documentation for the SPI framework can be found in the Documentation directory of your linux source tree or here Documentation/spi/spi-summary.
Linux SPI drivers are broken into two parts. A controller driver that handles direct communication with the hardware and a protocol driver to handle the details of the data for a particular device. The interface defined in spi.c/spi.h is the bridge between the two.
For the OMAP3's, the controller driver is omap2_mcspi.c. The OMAP3's have 4 SPI busses which the omap2_mcspi driver handles. The kernel config option to include the omap2_mcspi driver is CONFIG_SPI_OMAP24XX and is already built into standard Gumstix Overo kernels.
The OMAP3 SPI controller has the ability to act as either a SPI master or SPI slave, but the current kernel code only supports the SPI master configuration.
Gumstix brings out SPI bus 1 chip select pins 0 and 1 on most of the Overo expansion boards.
SPI pins for the OMAP3 are multi-functional and need to be multiplexed for SPI use. The SPI bus 1 MOSI, SIMO, CLK, CS0 and CS1 brought out on the Overo expansion boards are correctly setup for SPI use. This configuration is done in the bootloader U-Boot.
Protocol Drivers
A protocol driver is what you need to use the SPI system on Linux.
There are a couple of steps that need to happen.
- Slave devices must be registered for each SPI bus and chip select position used.
- A protocol driver needs to be registered with the system using the same name as the devices it will be handling so the kernel can link the two.
It doesn't matter which order these steps are performed. Most existing SPI drivers do the device registration completely outside the driver code in a board file. If you are writing your own driver, it is probably more convenient to do it in the driver code itself. When both device and driver registration are completed, the probe() function for the protocol driver will be called and SPI communications can start.
SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages in the protocol driver. The protocol driver submits the SPI messages to the controller driver's I/O queue. These messages are then processed asynchronously by the controller driver in FIFO order. As each message finishes, the controller notifies the protocol driver via a callback function.
There are some synchronous helper functions exposed by the interface to simplify the asynchronous behaviour of the Linux SPI system for protocol driver writers.
Spidev
Spidev is a standard Linux module that implements a generic SPI protocol driver while exposing a char device interface to userland.
The documentation for spidev can be found here - Documentation/spi/spidev.
The spidev driver does not register devices so a board file patch like this one spidev-enable.patch is required to use spidev with the Overos. You should customize that patch for the particular device(s) you are using. Things you might want to change are the bus speed and the mode.
The spidev driver is already built into the standard Overo kernels.
Only one protocol driver at a time can manage a particular CS line on a given SPI bus.
As you can see from the above patch, the standard Overo kernels already have devices registering for SPI bus 1 CS0 (ADS7846 touchscreen controller) and SPI bus 1 CS1 (LGPHILIPS LB035Q02 display driver). You will have to disable one or both of these drivers in your kernel config if you want to use those respective CS lines.
If you are using OE, apply the board patch by copying it to the org.openembedded.dev/recipes/linux/linux-omap3-2.6.xx/ directory and then adding a line to include the patch in your kernel recipe org.openembedded.dev/recipes/linux/linux-omap3_2.6.xx.bb
There are more detailed instructions for getting spidev working on an Overo at the 'Writing a Linux SPI driver' link below.
Additional Links
Writing a Linux SPI driver - A series of articles using Gumstix Overo in the examples
BeagleBoard/SPI - Beagleboard SPI section on eLinux.org
Serial Peripheral Interface Bus - Wikipedia SPI article
Gumstix mailing list archives for spidev
This category currently contains no pages or media.
