spi/bfin_spi: redo GPIO CS handling
The common SPI layers take care of detecting CS conflicts and preventing
two devices from claiming the same CS. This causes problems for the GPIO
CS support we currently have as we are using CS0 to mean "GPIO CS". But
if we have multiple devices using a GPIO CS, the common SPI layers see
multiple devices using the virtual "CS0" and reject any such attempts.
To make both work, we introduce an offset define. This represents the
max number of hardware CS values that the SPI peripheral supports. If
the CS is below this limit, we know we can use the hardware CS. If it's
above, we treat it as a GPIO CS. This keeps the CS unique as seen by
the common code and prevents conflicts.
Signed-off-by: Barry Song <barry.song@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
diff --git a/arch/blackfin/include/asm/bfin5xx_spi.h b/arch/blackfin/include/asm/bfin5xx_spi.h
index 126d25e..6f011da 100644
--- a/arch/blackfin/include/asm/bfin5xx_spi.h
+++ b/arch/blackfin/include/asm/bfin5xx_spi.h
@@ -109,6 +109,8 @@
#define CMD_SPI_GET_SYSTEMCLOCK 25
#define CMD_SPI_SET_WRITECONTINUOUS 26
+#define MAX_CTRL_CS 8 /* cs in spi controller */
+
/* device.platform_data for SSP controller devices */
struct bfin5xx_spi_master {
u16 num_chipselect;
@@ -124,7 +126,6 @@
u8 enable_dma;
u8 bits_per_word;
u16 cs_chg_udelay; /* Some devices require 16-bit delays */
- u32 cs_gpio;
/* Value to send if no TX value is supplied, usually 0x0 or 0xFFFF */
u16 idle_tx_val;
u8 pio_interrupt; /* Enable spi data irq */