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>

1 files changed, 2 insertions, 1 deletions

diff --git a/arch/blackfin/include/asm/bfin5xx_spi.h b/arch/blackfin/include/asm/bfin5xx_spi.h
index 126d25e2afa8..6f011dac378f 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 @@ struct bfin5xx_spi_chip {
         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 */