SPI Configuration and Limitations
This NVIDIA DRIVE™ product provides SPI drivers that can interface with devices and memory attached to the embedded baseboard. Those drivers support master and slave roles, both of which include IOCTLS and read/write operations. For more information on these interfaces, see the kernel documentation at:
kernel/Documentation/spi/spidev
The SPI drivers are:
• spi-tegra114—Supports master roles.
• spi-tegra124-slave—Supports slave roles.
Note: | Despite the appearance of Tegra version numbers in the driver names, these drivers support later NVIDIA® Tegra® VCMs. |
SPI Device Roles
The following shows the default SPI device instance configurations defined in the DTSI for the VCM, depending on the platform (below).
DRIVE PX 2 (P3407)
SPI Device Instance | VCM3.1 | Role |
/dev/spidev1.0 | SPIA | Slave (connected to AURIX) |
/dev/spidev2.0 | SPID | Master (connected to AURIX) |
DRIVE PX 2 (P2379)
SPI Device Instance | VCM3.1 | Role |
/dev/spidev1.0 | SPIA | Slave (connected to AURIX) |
SPI Driver Limitations
SPI drivers do not support some SPI settings that are available in the SPI hardware interface. For information on the SPI hardware interface, see the Tegra Technical Reference Manual (TRM) for your chip.
BPW Support Limited to Modulo-8
Although the SPI hardware interface supports different SPI bits per word (BPW) settings, the SPI driver supports only these BPW settings: 8, 16, 24, and 32.
No Support for “Both Enable Byte/Bit” Settings
The SPI hardware interface provides the following settings, which specify the form of the data FIFO-transmitted or received on the MISO and MOSI lines:
• Both enable bit
• Both enable byte
These settings specify both transmit and receive on a single line. The SPI driver does not support these settings.
Identifying SPI Roles
The SPI role indicates whether the SPI instance is a master or slave.
Note: | To ease testability of SPI, the spi0 controller is configured in slave mode by default for some boards. If you require this controller to be in master mode, you must set it back to master in the device tree. |
To identify master instances
• On the target, enter the following command:
$ ls /sys/bus/platform/drivers/spi-tegra114 | grep spi
You will see a response such as the following. This response indicates that SPI instances 1, 2, and 4 are in master mode.
3230000.spi
To identify slave instances
• On the target, enter the following command:
$ ls /sys/bus/platform/drivers/spi-tegra124-slave | grep spi
You will see a response such as the following.
3240000.spi
Configuring SPI Roles
If a different SPI slave needs to be configured, you must:
• Modify the SPI pinmux properties to enable/disable input/output for require SPI pins and
• Modify the DTSI SPI configuration.
To modify the SPI pinmux properties
Note: | With SPI pins as input, both master and slave roles are possible. |
The various maps can be found from the relevant pinmux configuration settings.
To configure an SPI instance as slave
1. Locate and edit the DTSI file for the VCM and embedded baseboard, for example:
<
top>/hardware/nvidia/platform/t18x/vcm/kernel-dts/vcm-platforms/tegra186-vcm31-p2379-common.dtsi
2. Locate the declarations for the SPI instances. The following is an example:
spi@7000d400 {
status = "okay";
compatible = "nvidia,tegra186-spi-slave";
nvidia,rx-trigger-words = <0>;
};
spi@7000d600 {
status = "okay";
};
spi@7000d800 {
status = "okay";
};
spi@7000dc00 {
status = "okay";
};
Where 7000d600, 7000d800, and 7000dc00 are defined as master SPI instances.
3. Modify the appropriate SPI attribute, as shown below:
spi@<address> {
status = "okay";
compatible = "nvidia,tegra186-spi-slave";
};
4. Use the MB1 Platform to modify the cfg files for the pinmux SPI settings.
For detailed instructions, see the NVIDIA DRIVE™ Foundation SDK Development Guide Board Adaptation, MB1 Platform Configuration (Tegra Parker), Pinmux and GPIO Configuration topic.
The pinmux configuration file is located at:
<
top>/drive-t186ref-foundation/platform-config/bct/t186/pinmux//tegra186-mb1-bct-pinmux-gpio-vcm31-<p3407|p2379>-<board_revision>.cfg
In the following example, the cfg file configures SPI3 as slave and SPI1 as master:
pinmux.0x0243d048 = 0x00000451; # uart5_tx_px4: spi3, tristate-enable, input-enable
pinmux.0x0243d040 = 0x00000401; # uart5_rx_px5: spi3, tristate-disable, input-disable
pinmux.0x0243d050 = 0x00000459; # uart5_rts_px6: spi3, pull-up, tristate-enable, input-enable
pinmux.0x0243d058 = 0x00000451; # uart5_cts_px7: spi3, tristate-enable, input-enable
pinmux.0x0243d018 = 0x00000402; # gpio_wan5_ph0: spi1, tristate-disable, input-disable
pinmux.0x0243d010 = 0x00000452; # gpio_wan6_ph1: spi1, tristate-enable, input-enable
pinmux.0x0243d008 = 0x00000402; # gpio_wan7_ph2: spi1, tristate-disable, input-disable
pinmux.0x0243d000 = 0x00000402; # gpio_wan8_ph3: spi1, tristate-disable, input-disable
SPI Slave
The kernel does not provide a special SPI slave framework. The spi-tegra186-slave.c driver uses the SPI master framework itself to program the SPI device in slave mode and expose a dev node to be used for SPI slave.
For more information, see the documentation for SPI master at:
<kernel>/Documentation/spi/spi-summary
<kernel>/Documentation/spi/spidev_test.c
<kernel>/Documentation/spi/spidev
The ioctls SPI_IOC_WR_MODE, SPI_IOC_WR_BITS_PER_WORD, SPI_IOC_WR_MAX_SPEED_HZ, SPI_IOC_MESSAGE, etc., are supported for SPI slave exactly as they are supported for master mode.
Note: | SPI slave feature supports full duplex operation in modes 1 and 3 only. |
Interrupting an SPI Slave
You can interrupt the un-interruptible sleep of a slave client process by giving a SIGINT to the kernel thread of the corresponding SPI controller.
To interrupt the spidev0.0 (spi0) SPI slave
• Enter:
$ kill -s INT `pgrep spi0`
Note: | The characters surrounding pgrep spi0 are backticks. On most keyboards, the BACKTICK key is the same key as the TILDE (~) key. |
Verifying the SPI Slave is Ready Using GPIO Synchronization
To avoid situations where the SPI master starts a transfer when the slave is not ready, use the provided GPIO-based synchronization mechanism.
The master can poll on the GPIO of the slave,, as specified through the kernel Device Tree, and starts the transfer only after it verifies that the slave GPIO is toggled indicating that the slave is ready.
Transitioning from Driver-Wait to LP0
If your application framework is awaiting a response from the SPI-slave driver, it will be unable to interact with the Tegra device. Such waiting is part of handling transactions with the external bus master.
By giving a SIGINT to the kernel thread of the corresponding SPI controller, you can transition the framework from its waiting state. The SIGINT interrupts the SPI-slave driver. After the SIGINT, the application framework can move the Tegra device into deep-sleep (LP0). For information on raising a SIGINT, see
Interrupting an SPI Slave in this topic.
Addressing CS Deassert Interrupts
There may be gap between the master's last data byte send and the CS deassert. If, during this interval, the SPI slave is re-programmed, it will get a CS deassert interrupt.
To avoid such an interrupt, the SPI slave client driver must provide a delay between two consecutive transfers, depending on the maximum delay between transfer complete and CS de-assert from the respective master.
