Implementing SPI on an OMAP-based board design
To use DS3234 with PandaBoard, a developer should buy at least two level translators and connect pins MCSPI_SOMI, MCSPI_SIMO, MCSPI_CS0 and MCSPI_CLK from the PandaBoard expansion connector to one side of the level shifters and MISO, MOSI, SS and CLK to another side. The sample schematics are shown in Figure 3 below.
Click on image to enlarge.
SPI drivers stack in Linux
The Linux kernel provides the following pieces of code that relate to the SPI subsystem:
* SPI master drivers
* SPI functional device drivers, often called “protocol masters”
* SPI board information
SPI master drivers are drivers that deal with the SPI controller itself. They know “how” to send bytes to any peripheral device.
Fortunately, the Linux kernel already provides drivers for the OMAP processor’s MCSPI controller, so one will likely not need to create or re-implement this one, unless an error is found or performance needs to be significantly improved.
In either case, however, it’s best to think twice before starting to change it. These kinds of device drivers provide kernel-level API that is visible for and used only by kernel drivers.
SPI functional device drivers, or SPI protocol masters, deal with the peripheral device attached to the SPI bus. These drivers know “what” to send/receive to/from the device. These device drivers usually expose user-level API (like spidev does) or kernel-level API that can be used by another subsystem.
For example, the SPI flash driver creates the MTD (memory-technology device) driver, which is visible as the regular block device (mtdblockN) and character device (mtdN) so the user can utilize MTD utilities to access the flash in a uniform way.
Another example that is discussed later is the real time clock chip DS3243, which is connected to the SPI bus and provides a generic RTC interface to the userspace, so it can be read/written with the hwclock utility.
SPI board information is part of the machine-depended code that performs registration of SPI devices with the SPI subsystem. Because SPI devices are usually hardwired to the board and rarely have an ability to enumerate them, they have to be hardcoded somewhere in the Linux kernel.
One will likely have to add similar code snippet to the board definition file, which in our sample would be to arch/arm/mach-omap2/board-omap4panda.c.
Loading comments... Write a comment