Input: synaptics-rmi4 - add SPI transport driver

Add the transport driver for devices using RMI4 over SPI.

Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This commit is contained in:
Andrew Duggan 2016-03-10 15:58:12 -08:00 committed by Dmitry Torokhov
parent 562b42d3ee
commit 8d99758dee
4 changed files with 608 additions and 0 deletions

View file

@ -149,6 +149,55 @@ struct rmi_f01_power_management {
u8 doze_interval;
};
/**
* struct rmi_device_platform_data_spi - provides parameters used in SPI
* communications. All Synaptics SPI products support a standard SPI
* interface; some 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.
*
* @block_delay - for standard SPI transactions consisting of both a read and
* write operation, the delay (in microseconds) between the read and write
* operations.
* @split_read_block_delay_us - 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.
*/
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);
};
/**
* struct rmi_device_platform_data - system specific configuration info.
*
@ -159,6 +208,8 @@ struct rmi_f01_power_management {
struct rmi_device_platform_data {
int reset_delay_ms;
struct rmi_device_platform_data_spi spi_data;
/* function handler pdata */
struct rmi_2d_sensor_platform_data *sensor_pdata;
struct rmi_f01_power_management power_management;