Documentation/spi/spi-summary.rst

Source file repositories/reference/linux-study-clean/Documentation/spi/spi-summary.rst

File Facts

System
Linux kernel
Corpus path
Documentation/spi/spi-summary.rst
Extension
.rst
Size
30773 bytes
Lines
715
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

if (n == 2) {
			spi2->dev.platform_data = pdata2;
			register_platform_device(&spi2);

			/* also: set up pin modes so the spi2 signals are
			 * visible on the relevant pins ... bootloaders on
			 * production boards may already have done this, but
			 * developer boards will often need Linux to do it.
			 */
		}
		...
	}

Notice how the platform_data for boards may be different, even if the
same SOC controller is used.  For example, on one board SPI might use
an external clock, where another derives the SPI clock from current
settings of some master clock.

Declare target Devices
^^^^^^^^^^^^^^^^^^^^^^

The second kind of information is a list of what SPI target devices exist
on the target board, often with some board-specific data needed for the
driver to work correctly.

Normally your arch/.../mach-*/board-*.c files would provide a small table
listing the SPI devices on each board.  (This would typically be only a
small handful.)  That might look like::

	static struct ads7846_platform_data ads_info = {
		.vref_delay_usecs	= 100,
		.x_plate_ohms		= 580,
		.y_plate_ohms		= 410,
	};

	static struct spi_board_info spi_board_info[] __initdata = {
	{
		.modalias	= "ads7846",
		.platform_data	= &ads_info,
		.mode		= SPI_MODE_0,
		.irq		= GPIO_IRQ(31),
		.max_speed_hz	= 120000 /* max sample rate at 3V */ * 16,
		.bus_num	= 1,
		.chip_select	= 0,
	},
	};

Again, notice how board-specific information is provided; each chip may need
several types.  This example shows generic constraints like the fastest SPI
clock to allow (a function of board voltage in this case) or how an IRQ pin
is wired, plus chip-specific constraints like an important delay that's
changed by the capacitance at one pin.

(There's also "controller_data", information that may be useful to the
controller driver.  An example would be peripheral-specific DMA tuning
data or chipselect callbacks.  This is stored in spi_device later.)

The board_info should provide enough information to let the system work
without the chip's driver being loaded.  The most troublesome aspect of
that is likely the SPI_CS_HIGH bit in the spi_device.mode field, since
sharing a bus with a device that interprets chipselect "backwards" is
not possible until the infrastructure knows how to deselect it.

Then your board initialization code would register that table with the SPI
infrastructure, so that it's available later when the SPI host controller
driver is registered::

	spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info));

Like with other static board-specific setup, you won't unregister those.

Annotation

Implementation Notes