STRUCT RMI_DEVICE_PLATFORM_DATA_SPI(9)

💅 NAME 💅

Okay bestie, so struct rmi_device_platform_data_spi — it provides parameters used in SPI communications 🫶. That's the whole vibe. This page lives in the Kernel API Manual and the page itself is literally called struct rmi_...orm_data_spi(9), iykyk.

Real talk though: all Synaptics SPI products support a standard SPI interface ✨. Some of them also support what is called SPI V2 mode, depending on firmware and/or ASIC limitations. In V2 mode, the touch sensor can support shorter delays during certain operations, and these are specified separately from the standard mode delays. So there's standard-mode delays and V2-mode delays and they do NOT mix, periodt 💀.

✨ SYNOPSIS ✨

struct rmi_device_platform_data_spi {
    u32 block_delay_us;
    u32 split_read_block_delay_us;
    u32 read_delay_us;
    u32 write_delay_us;
    u32 split_read_byte_delay_us;
    u32 pre_delay_us;
    u32 post_delay_us;
    u8 bits_per_word;
    u16 mode;
    void *cs_assert_data;
    int (*cs_assert)(const void *cs_assert_data, const bool assert);
};

🎀 Members 🎀

It's giving "the lineup" — every field is right up there in the synopsis 👑. The Description below is where the actual lore drops 🌸.

🦋 Description 🦋

• block_delay_us — for standard SPI transactions consisting of both a read and write operation, this is the delay (in microseconds) between the read and write operations ⏳.
• split_read_block_delay_us — same idea but for V2 SPI transactions consisting of both a read and write operation: the delay (in microseconds) between the read and write operations ✨.
• read_delay_us — the delay between each byte of a read operation in normal SPI mode 🍓.
• write_delay_us — the delay between each byte of a write operation in normal SPI mode 🍓.
• split_read_byte_delay_us — the delay between each byte of a read operation in V2 mode 💜.
• pre_delay_us — the delay before the start of a SPI transaction. This is typically useful in conjunction with custom chip select assertions (see below) 👀.
• post_delay_us — the delay after the completion of an SPI transaction. This is typically useful in conjunction with custom chip select assertions (see below) 👀.
• cs_assert — For systems where the SPI subsystem does not control the CS/SSB line, or where such control is broken, you can provide a custom routine to handle a GPIO as CS/SSB 🔥. This routine will be called at the beginning and end of each SPI transaction. The RMI SPI implementation will wait pre_delay_us after this routine returns before starting the SPI transfer; and post_delay_us after completion of the SPI transfer(s) before calling it with assert==FALSE 😭.

Ngl the "such control is broken" line is doing a LOT of emotional heavy lifting here 💀 — but that's literally what it says, so.

🌈 SEE ALSO 🌈

Kernel file ./include/linux/rmi.h and the whole friend group: struct rmi_2d_axis_alignment(9), struct rmi_gpio_data(9), struct rmi_f01_power_management(9), struct rmi_device_platform_data(9), struct rmi_function_descriptor(9), struct rmi_transport_dev(9), struct rmi_transport_ops(9), struct rmi_driver(9), struct rmi_device(9) 🫶🦋

Okay that's the whole page, you ate that 💅✨ — this lil gem comes from ./include/linux, dated October 2026, and it's filed under struct rmi_...orm_data_spi(9). Go forth and delay responsibly 🎀