Category:SPI - Revision history

Ashcharles: /* Additional Links */

2016-04-01T21:01:00Z

‎Additional Links

Sellis: Added some muxing notes

2011-01-20T15:53:40Z

Added some muxing notes

Sellis: Minor wording changes

2011-01-20T15:39:34Z

Minor wording changes

Sellis: More details

2011-01-20T13:46:45Z

More details

Sellis: Remove old board patch link

2011-01-20T13:40:06Z

Remove old board patch link

Sellis: Better wording

2011-01-20T13:29:02Z

Better wording

Sellis: Clean up SPI description and add link for writing a driver

2011-01-20T12:11:16Z

Clean up SPI description and add link for writing a driver

Sellis: Switched order of sections

2010-03-13T22:08:02Z

Switched order of sections

Sellis: Added spidev doc link

2010-03-13T21:57:03Z

Added spidev doc link

Sellis: spidev notes

2010-03-13T21:51:33Z

spidev notes

← Older revision		Revision as of 21:01, 1 April 2016
Line 57:		Line 57:
	[http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus Serial Peripheral Interface Bus] - Wikipedia SPI article		[http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus Serial Peripheral Interface Bus] - Wikipedia SPI article

−	[http://~~www~~.nabble.com/~~forum~~/~~Search~~.jtp?~~query~~=~~spidev~~&~~sort~~=~~date~~&~~local~~=~~y&forum=22543~~ Gumstix mailing list archives for spidev]	+	[http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=search_page&node=558772&query=spidev Gumstix mailing list archives for spidev]

@@ Line 10: / Line 10: @@
 Gumstix brings out SPI bus 1 chip select pins 0 and 1 on most of the Overo expansion boards.
 === 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.
-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 then 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.
+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 ===
@@ 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.
-=== Custom Driver ===
+=== Additional Links ===
-Here is an article that can get you started writing your own custom SPI driver for Linux using Gumstix Overos as the example board - [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]
+[http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

@@ Line 32: / Line 32: @@
 The documentation for spidev can be found here - [http://www.mjmwired.net/kernel/Documentation/spi/spidev Documentation/spi/spidev].
-The spidev driver does not register devices so a board file patch like this one [https://github.com/scottellis/spike/blob/0d633a22da47022073abd9224ec8709c5b9db932/patches/spidev-enable.patch spidev-enable.patch] is required to use spidev with the Overos. You should customize that patch for the particular device you are using. Things you might want to change are the bus speed and the mode.
+The spidev driver does not register devices so a board file patch like this one [https://github.com/scottellis/spike/blob/0d633a22da47022073abd9224ec8709c5b9db932/patches/spidev-enable.patch 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 built in to the standard Overo kernels.
+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 that respective CS line.
+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 on 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.
 You can also search the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

@@ Line 34: / Line 34: @@
 The spidev driver does not register devices so a board file patch like this one [https://github.com/scottellis/spike/blob/0d633a22da47022073abd9224ec8709c5b9db932/patches/spidev-enable.patch spidev-enable.patch] is required to use spidev with the Overos. You should customize that patch for the particular device you are using. Things you might want to change are the bus speed and the mode.
-The spidev driver is built in to the standard Overo kernels. 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
+The spidev driver is built in to the standard Overo kernels.
 Only one protocol driver at a time can manage a particular CS line on a given SPI bus.
@@ Line 40: / Line 40: @@
 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 that respective CS line.
 You can also search the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

@@ Line 28: / Line 28: @@
 === Spidev ===
-Spidev is a standard Linux module that implements a generic SPI protocol driver while exposing a char device interface to userland via sysfs.
+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 - [http://www.mjmwired.net/kernel/Documentation/spi/spidev Documentation/spi/spidev].
@@ Line 36: / Line 36: @@
 The spidev driver is built in to the standard Overo kernels. 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
-As you can see from the patch, the standard Overo kernels already occupy the SPI bus 1 chip select lines 0 and 1 if either the ADS7846 touchscreen controller (CS0) or the LGPHILIPS LB035Q02 display driver (CS1) are enabled. You will have to disable these drivers in your kernel config if you want to connect your device to either of these lines. Only one protocol driver at a time can manage a particular CS line on a given SPI bus.
+Only one protocol driver at a time can manage a particular CS line on a given SPI bus.
 You can also search the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

@@ Line 13: / Line 13: @@
 === Protocol Drivers ===
-A protocol driver is what you need if you want to use the SPI system.
+A protocol driver is what you need to use the SPI system on Linux.
-There are a couple of steps every SPI protocol driver needs to follow.
+There are a couple of steps that need to happen.
 # Slave devices must be registered for each SPI bus and chip select position used.
-# The SPI 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.
+# 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 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 then submits the SPI messages to the controller driver's I/O queue with calls to spi_async(). These messages are processed in FIFO order asynchronously by the controller driver. As each message finishes, the controller notifies the protocol driver via 'completion' callbacks. The protocol driver can then process the raw data as necessary.
+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 then 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 simple synchronous functions exposed by the spi.h/spi.c interface to simplify the asynchronous behaviour of the Linux SPI system for protocol drivers.
+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 ===

@@ Line 1: / Line 1: @@
 == Overo SPI ==
-Kernel documentation for the SPI framework is excellent and should be your starting point. You can find it under the Documentation directory of your linux source tree or here [http://www.kernel.org/doc/Documentation/spi/spi-summary Documentation/spi/spi-summary].
+Kernel documentation for the SPI framework can be found in the Documentation directory of your linux source tree or here [http://www.kernel.org/doc/Documentation/spi/spi-summary 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.
+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. There are some new checkins to the kernel code indicating that SPI slave functionality might be coming.
+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.
 === Protocol Drivers ===
-There are a couple of steps you need to follow in writing a SPI protocol driver.
+A protocol driver is what you need if you want to use the SPI system.
-# You need to tell the SPI subsystem about the slave device(s) on each SPI bus that you want to use. This gets passed along to the controller driver when it's needed. You can do this during kernel init in a board file like board-overo.c or it can be done at run time in module code.  A device name (modalias) is specified as a key part of this process.
+There are a couple of steps every SPI protocol driver needs to follow.
-# You need to register a SPI protocol driver. This driver should have the same name (modalias) as was specified above. You register a spi_device using the spi_register_driver() call. When this internal mapping connection is made by the SPI subsystem, the result is a probe() call to your protocol driver.
-It doesn't matter which order you perform these steps. But after both are completed and your probe() function returns success, your driver will be ready for SPI communication. You are given a spi_device in the probe() function that you need to hang onto.
+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 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 then submits the SPI messages to the controller driver's I/O queue with calls to spi_async(). These messages are processed in FIFO order asynchronously by the controller driver. As each message finishes, the controller notifies the protocol driver via 'completion' callbacks. The protocol driver can then process the raw data as necessary.
-There is also a simple synchronous interface exposed by spi.h/spi.c. Here the SPI framework puts the caller, a protocol driver, to sleep while the same asynchronous interface to the controller driver is used behind the scenes. When the controller is done, the protocol driver is woken up and can then proceed to process the data.
+There are some simple synchronous functions exposed by the spi.h/spi.c interface to simplify the asynchronous behaviour of the Linux SPI system for protocol drivers.
 === Spidev ===
-Spidev is a stock linux module that implements a generic SPI protocol driver while exposing a char device interface to userland via sysfs.
+Spidev is a standard Linux module that implements a generic SPI protocol driver while exposing a char device interface to userland via sysfs.
-The documentation can be found in the linux source tree. Here is a link [http://www.mjmwired.net/kernel/Documentation/spi/spidev Documentation/spi/spidev].
+The documentation for spidev can be found here - [http://www.mjmwired.net/kernel/Documentation/spi/spidev Documentation/spi/spidev].
-Spidev is not designed to dynamically register itself with the SPI subsystem. You will need to add code to do this in either a kernel module or more likely in the board file, board-overo.c, so registration takes place during boot.
+The spidev driver does not register devices so a board file patch like this one [https://github.com/scottellis/spike/blob/0d633a22da47022073abd9224ec8709c5b9db932/patches/spidev-enable.patch spidev-enable.patch] is required to use spidev with the Overos. You should customize that patch for the particular device you are using. Things you might want to change are the bus speed and the mode.
-Spidev implements its own synchronous interface to the SPI system.
+The spidev driver is built in to the standard Overo kernels. 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
 Here's one Gumstix [http://www.nabble.com/SPI%2C-spidev%2C-et.-al-to24588398.html#a24594755 mailing list thread] posted on 7/21/09, where some users have successfully used spidev with the Overos.
@@ Line 38: / Line 42: @@
 You can also search the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]
-=== Another Example Driver ===
+=== Custom Driver ===
-−
-A simpler OMAP3 linux SPI driver can be found [http://www.github.com/scottellis/overo-adc-mcp3002 here].
-−
-Two inexpensive ADC's are used as the slave devices. The protocol for these devices is sufficiently simple that other devices could be easily swapped in place of them and the code modified appropriately.
-−
-This driver demonstrates how to add SPI devices to a SPI bus at runtime instead of at boot time, which can simplify development.
-−
-The driver also demonstrates how to handle asynchronous I/O with the SPI controller.
-−
-There is no attempt to do anything useful with the ADC data. The driver is just intended to be used to explore the linux SPI framework.
-The driver also exposes a simple character device interface to interact with userland.
+Here is an article that can get you started writing your own custom SPI driver for Linux using Gumstix Overos as the example board - [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]

@@ Line 16: / Line 16: @@
 # You need to tell the SPI subsystem about the slave device(s) on each SPI bus that you want to use. This gets passed along to the controller driver when it's needed. You can do this during kernel init in a board file like board-overo.c or it can be done at run time in module code.  A device name (modalias) is specified as a key part of this process.
 # You need to register a SPI protocol driver. This driver should have the same name (modalias) as was specified above. You register a spi_device using the spi_register_driver() call. When this internal mapping connection is made by the SPI subsystem, the result is a probe() call to your protocol driver.
 It doesn't matter which order you perform these steps. But after both are completed and your probe() function returns success, your driver will be ready for SPI communication. You are given a spi_device in the probe() function that you need to hang onto.
-SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages by you in your driver. You then submit your messages to the controller driver's I/O queue with calls to spi_async(). These messages are processed in FIFO order asynchronously by the controller and your driver is notified via completion callbacks as each message finishes. You can then process the raw data in your 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 then submits the SPI messages to the controller driver's I/O queue with calls to spi_async(). These messages are processed in FIFO order asynchronously by the controller driver. As each message finishes, the controller notifies the protocol driver via 'completion' callbacks. The protocol driver can then process the raw data as necessary.
-There is also a simple synchronous interface exposed by spi.h/spi.c that just halts your driver while the same asynchronous interface to the controller driver is used behind the scenes.
+There is also a simple synchronous interface exposed by spi.h/spi.c. Here the SPI framework puts the caller, a protocol driver, to sleep while the same asynchronous interface to the controller driver is used behind the scenes. When the controller is done, the protocol driver is woken up and can then proceed to process the data.
 === Example Driver ===
@@ Line 33: / Line 34: @@
 The driver exposes a simple character device interface to interact with userland.
-== Using Spidev ==
+(This is just from reading the code. I have never tried to use spidev. Maybe someone who has can elaborate.)
-Check the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]
+Here's one Gumstix [http://www.nabble.com/SPI%2C-spidev%2C-et.-al-to24588398.html#a24594755 mailing list thread] posted on 7/21/09, where some users have successfully used spidev with the Overos.
-In particular, [http://www.nabble.com/SPI%2C-spidev%2C-et.-al-to24588398.html#a24594755 this article on spidev] posted on 7/21/09.
+You can also search the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]