[U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup()

[U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup()

[Haavard Skinnemoen]

No need to add an extra layer of indirection and externals all over
the place. Just let the board code define two functions,
spi_cs_activate() and spi_cs_deactivate, and use them to do any
board-specific magic with the chipselects.

Not all drivers may need those extra functions however. If that's the
case, the board code may just leave them out (assuming they know what
the driver needs) or rely on the linker to strip them out (assuming
--gc-sections is being used.)

Also introduce a new function, spi_setup(), which must be called to
initialize communications parameters for a given slave. This function
will also check if the given chipselect id is valid. The driver may
call spi_cs_is_valid(), which is defined by the board code if
necessary, to verify that a given chipselect id is valid on the
current board.

Changed in v2:
  - Convert the mpc8xxx_spi driver and the mpc8349emds board to the
    new API.

Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
---
I haven't tested if the boards affected by this patch still work, or
even build, so use with care. I'd very much like some feedback on
whether this API change is a good thing or not though.

 board/amcc/taihu/taihu.c                  |   16 ++++---
 board/freescale/mpc8349emds/mpc8349emds.c |   25 +++++------
 board/sacsng/sacsng.c                     |   35 ++++++---------
 board/ssv/adnpesc1/adnpesc1.c             |   27 ++++++------
 common/cmd_spi.c                          |   22 +++------
 common/soft_spi.c                         |   28 ++++--------
 cpu/nios/spi.c                            |   16 ++++---
 drivers/rtc/ds1306.c                      |   28 ++++++++----
 drivers/spi/mpc8xxx_spi.c                 |   17 +++++--
 include/spi.h                             |   68 +++++++++++++++++++++--------
 10 files changed, 156 insertions(+), 126 deletions(-)

diff --git a/board/amcc/taihu/taihu.c b/board/amcc/taihu/taihu.c
index ea83671..98e7f29 100644
--- a/board/amcc/taihu/taihu.c
+++ b/board/amcc/taihu/taihu.c
@@ -165,16 +165,20 @@ unsigned char spi_read(void)
 	return (unsigned char)gpio_read_out_bit(SPI_DIN_GPIO15);
 }
 
-void taihu_spi_chipsel(int cs)
+int spi_cs_is_valid(int cs)
 {
-	gpio_write_bit(SPI_CS_GPIO0, cs);
+	return cs == 0;
 }
 
-spi_chipsel_type spi_chipsel[]= {
-	taihu_spi_chipsel
-};
+void spi_cs_activate(int cs)
+{
+	gpio_write_bit(SPI_CS_GPIO0, 1);
+}
 
-int spi_chipsel_cnt = sizeof(spi_chipsel) / sizeof(spi_chipsel[0]);
+void spi_cs_deactivate(int cs)
+{
+	gpio_write_bit(SPI_CS_GPIO0, 0);
+}
 
 #ifdef CONFIG_PCI
 static unsigned char int_lines[32] = {
diff --git a/board/freescale/mpc8349emds/mpc8349emds.c b/board/freescale/mpc8349emds/mpc8349emds.c
index 9f4ac8e..f8af162 100644
--- a/board/freescale/mpc8349emds/mpc8349emds.c
+++ b/board/freescale/mpc8349emds/mpc8349emds.c
@@ -259,25 +259,24 @@ void sdram_init(void)
 
 #define SPI_CS_MASK	0x80000000
 
-void spi_eeprom_chipsel(int cs)
+int spi_cs_is_valid(int cs)
+{
+	return cs == 0;
+}
+
+void spi_cs_activate(int cs)
 {
 	volatile gpio83xx_t *iopd = &((immap_t *)CFG_IMMR)->gpio[0];
 
-	if (cs)
-		iopd->dat &= ~SPI_CS_MASK;
-	else
-		iopd->dat |=  SPI_CS_MASK;
+	iopd->dat &= ~SPI_CS_MASK;
 }
 
-/*
- * The SPI command uses this table of functions for controlling the SPI
- * chip selects.
- */
-spi_chipsel_type spi_chipsel[] = {
-	spi_eeprom_chipsel,
-};
-int spi_chipsel_cnt = sizeof(spi_chipsel) / sizeof(spi_chipsel[0]);
+void spi_cs_deactivate(int cs)
+{
+	volatile gpio83xx_t *iopd = &((immap_t *)CFG_IMMR)->gpio[0];
 
+	iopd->dat |=  SPI_CS_MASK;
+}
 #endif /* CONFIG_HARD_SPI */
 
 #if defined(CONFIG_OF_BOARD_SETUP)
diff --git a/board/sacsng/sacsng.c b/board/sacsng/sacsng.c
index 25209e0..c454061 100644
--- a/board/sacsng/sacsng.c
+++ b/board/sacsng/sacsng.c
@@ -842,37 +842,30 @@ void show_boot_progress (int status)
 #define SPI_ADC_CS_MASK	0x00000800
 #define SPI_DAC_CS_MASK	0x00001000
 
-void spi_adc_chipsel(int cs)
+static const u32 cs_mask[] = {
+    SPI_ADC_CS_MASK,
+    SPI_DAC_CS_MASK,
+};
+
+int spi_cs_is_valid(int cs)
+{
+    return cs < sizeof(cs_mask) / sizeof(cs_mask[0]);
+}
+
+void spi_cs_activate(int cs)
 {
     volatile ioport_t *iopd = ioport_addr((immap_t *)CFG_IMMR, 3 /* port D */);
 
-    if(cs)
-	iopd->pdat &= ~SPI_ADC_CS_MASK;	/* activate the chip select */
-    else
-	iopd->pdat |=  SPI_ADC_CS_MASK;	/* deactivate the chip select */
+    iopd->pdat &= ~cs_mask[cs];
 }
 
-void spi_dac_chipsel(int cs)
+void spi_cs_deactivate(int cs)
 {
     volatile ioport_t *iopd = ioport_addr((immap_t *)CFG_IMMR, 3 /* port D */);
 
-    if(cs)
-	iopd->pdat &= ~SPI_DAC_CS_MASK;	/* activate the chip select */
-    else
-	iopd->pdat |=  SPI_DAC_CS_MASK;	/* deactivate the chip select */
+    iopd->pdat |= cs_mask[cs];
 }
 
-/*
- * The SPI command uses this table of functions for controlling the SPI
- * chip selects: it calls the appropriate function to control the SPI
- * chip selects.
- */
-spi_chipsel_type spi_chipsel[] = {
-	spi_adc_chipsel,
-	spi_dac_chipsel
-};
-int spi_chipsel_cnt = sizeof(spi_chipsel) / sizeof(spi_chipsel[0]);
-
 #endif
 
 #endif /* CONFIG_MISC_INIT_R */
diff --git a/board/ssv/adnpesc1/adnpesc1.c b/board/ssv/adnpesc1/adnpesc1.c
index 2ec3a72..834fd17 100644
--- a/board/ssv/adnpesc1/adnpesc1.c
+++ b/board/ssv/adnpesc1/adnpesc1.c
@@ -69,25 +69,24 @@ long int initdram (int board_type)
 
 #define	SPI_RTC_CS_MASK	0x00000001
 
-void spi_rtc_chipsel(int cs)
+int spi_cs_is_valid(int cs)
+{
+	return cs == 0;
+}
+
+void spi_cs_activate(int cs)
 {
 	nios_spi_t *spi = (nios_spi_t *)CFG_NIOS_SPIBASE;
 
-	if (cs)
-		spi->slaveselect = SPI_RTC_CS_MASK;	/* activate (1) */
-	else
-		spi->slaveselect = 0;			/* deactivate (0) */
+	spi->slaveselect = SPI_RTC_CS_MASK;	/* activate (1) */
 }
 
-/*
- * The SPI command uses this table of functions for controlling the SPI
- * chip selects: it calls the appropriate function to control the SPI
- * chip selects.
- */
-spi_chipsel_type spi_chipsel[] = {
-	spi_rtc_chipsel
-};
-int spi_chipsel_cnt = sizeof(spi_chipsel) / sizeof(spi_chipsel[0]);
+void spi_cs_deactivate(int cs)
+{
+	nios_spi_t *spi = (nios_spi_t *)CFG_NIOS_SPIBASE;
+
+	spi->slaveselect = 0;			/* deactivate (0) */
+}
 
 #endif
 
diff --git a/common/cmd_spi.c b/common/cmd_spi.c
index 7604422..cab906f 100644
--- a/common/cmd_spi.c
+++ b/common/cmd_spi.c
@@ -38,13 +38,6 @@
 #endif
 
 /*
- * External table of chip select functions (see the appropriate board
- * support for the actual definition of the table).
- */
-extern spi_chipsel_type spi_chipsel[];
-extern int spi_chipsel_cnt;
-
-/*
  * Values from last command.
  */
 static int   device;
@@ -101,19 +94,20 @@ int do_spi (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 		}
 	}
 
-	if ((device < 0) || (device >=  spi_chipsel_cnt)) {
-		printf("Invalid device %d, giving up.\n", device);
-		return 1;
-	}
 	if ((bitlen < 0) || (bitlen >  (MAX_SPI_BYTES * 8))) {
 		printf("Invalid bitlen %d, giving up.\n", bitlen);
 		return 1;
 	}
 
-	debug ("spi_chipsel[%d] = %08X\n",
-		device, (uint)spi_chipsel[device]);
+	/* FIXME: Make these parameters configurable */
+	if (spi_setup(device, 1000000, SPI_MODE_0)) {
+		printf("Invalid device %d, giving up.\n", device);
+		return 1;
+	}
+
+	debug ("spi chipsel = %08X\n", device);
 
-	if(spi_xfer(spi_chipsel[device], bitlen, dout, din) != 0) {
+	if(spi_xfer(device, bitlen, dout, din) != 0) {
 		printf("Error with the SPI transaction.\n");
 		rcode = 1;
 	} else {
diff --git a/common/soft_spi.c b/common/soft_spi.c
index e425061..251de1a 100644
--- a/common/soft_spi.c
+++ b/common/soft_spi.c
@@ -56,6 +56,11 @@ void spi_init (void)
 #endif
 }
 
+int spi_setup(int cs, unsigned int max_hz, unsigned int mode)
+{
+	/* TODO: Implement the four possible SPI modes */
+	return spi_cs_is_valid(cs) ? 0 : -1;
+}
 
 /*-----------------------------------------------------------------------
  * SPI transfer
@@ -68,16 +73,8 @@ void spi_init (void)
  * and "din" can point to the same memory location, in which case the
  * input data overwrites the output data (since both are buffered by
  * temporary variables, this is OK).
- *
- * If the chipsel() function is not NULL, it is called with a parameter
- * of '1' (chip select active) at the start of the transfer and again with
- * a parameter of '0' at the end of the transfer.
- *
- * If the chipsel() function _is_ NULL, it the responsibility of the
- * caller to make the appropriate chip select active before calling
- * spi_xfer() and making it inactive after spi_xfer() returns.
  */
-int  spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din)
+int  spi_xfer(int cs, int bitlen, uchar *dout, uchar *din)
 {
 #ifdef CFG_IMMR
 	volatile immap_t *immr = (immap_t *)CFG_IMMR;
@@ -86,12 +83,10 @@ int  spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din)
 	uchar tmpdout = 0;
 	int   j;
 
-	PRINTD("spi_xfer: chipsel %08X dout %08X din %08X bitlen %d\n",
-		(int)chipsel, *(uint *)dout, *(uint *)din, bitlen);
+	PRINTD("spi_xfer: chipsel %d dout %08X din %08X bitlen %d\n",
+		cs, *(uint *)dout, *(uint *)din, bitlen);
 
-	if(chipsel != NULL) {
-		(*chipsel)(1);	/* select the target chip */
-	}
+	spi_cs_activate(cs);
 
 	for(j = 0; j < bitlen; j++) {
 		/*
@@ -124,10 +119,7 @@ int  spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din)
 
 	SPI_SCL(0);		/* SPI wants the clock left low for idle */
 
-	if(chipsel != NULL) {
-		(*chipsel)(0);	/* deselect the target chip */
-
-	}
+	spi_cs_deactivate(cs);
 
 	return(0);
 }
diff --git a/cpu/nios/spi.c b/cpu/nios/spi.c
index f37146b..c00ba87 100644
--- a/cpu/nios/spi.c
+++ b/cpu/nios/spi.c
@@ -83,13 +83,19 @@ static void memdump (void *pv, int num)
 #endif  /* DEBUG */
 
 
+int spi_setup(int cs, unsigned int max_hz, unsigned int mode)
+{
+	/* TODO: Add support for different modes and speeds */
+	return spi_cs_is_valid(cs) ? 0 : -1;
+}
+
 /*
  * SPI transfer:
  *
  * See include/spi.h and http://www.altera.com/literature/ds/ds_nios_spi.pdf
  * for more informations.
  */
-int spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din)
+int spi_xfer(int cs, int bitlen, uchar *dout, uchar *din)
 {
 	int j;
 
@@ -98,9 +104,7 @@ int spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din)
 
 	memdump((void*)dout, (bitlen + 7) / 8);
 
-	if(chipsel != NULL) {
-		chipsel(1);	/* select the target chip */
-	}
+	spi_cs_activate(cs);
 
 	if (bitlen > CFG_NIOS_SPIBITS) {	/* leave chip select active */
 		spi->control |= NIOS_SPI_SSO;
@@ -146,9 +150,7 @@ int spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din)
 		spi->control &= ~NIOS_SPI_SSO;
 	}
 
-	if(chipsel != NULL) {
-		chipsel(0);	/* deselect the target chip */
-	}
+	spi_cs_deactivate(cs);
 
 	memdump((void*)din, (bitlen + 7) / 8);
 
diff --git a/drivers/rtc/ds1306.c b/drivers/rtc/ds1306.c
index 89e433d..49f66a9 100644
--- a/drivers/rtc/ds1306.c
+++ b/drivers/rtc/ds1306.c
@@ -62,13 +62,6 @@
 
 #define	RTC_USER_RAM_BASE	0x20
 
-/*
- * External table of chip select functions (see the appropriate board
- * support for the actual definition of the table).
- */
-extern spi_chipsel_type spi_chipsel[];
-extern int spi_chipsel_cnt;
-
 static unsigned int bin2bcd (unsigned int n);
 static unsigned char bcd2bin (unsigned char c);
 
@@ -308,6 +301,15 @@ void rtc_get (struct rtc_time *tmp)
 {
 	unsigned char sec, min, hour, mday, wday, mon, year;
 
+	/*
+	 * Assuming Vcc = 2.0V (lowest speed)
+	 *
+	 * REVISIT: If we add an rtc_init() function we can do this
+	 * step just once.
+	 */
+	if (spi_setup(CFG_SPI_RTC_DEVID, 600000, SPI_MODE_3 | SPI_CS_HIGH))
+		return;
+
 	sec = rtc_read (RTC_SECONDS);
 	min = rtc_read (RTC_MINUTES);
 	hour = rtc_read (RTC_HOURS);
@@ -356,6 +358,10 @@ void rtc_get (struct rtc_time *tmp)
 /* set clock time from *tmp in DS1306 RTC */
 void rtc_set (struct rtc_time *tmp)
 {
+	/* Assuming Vcc = 2.0V (lowest speed) */
+	if (spi_setup(CFG_SPI_RTC_DEVID, 600000, SPI_MODE_3 | SPI_CS_HIGH))
+		return;
+
 	debug ("Set DATE: %4d-%02d-%02d (wday=%d)  TIME: %2d:%02d:%02d\n",
 	       tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
 	       tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
@@ -374,6 +380,10 @@ void rtc_set (struct rtc_time *tmp)
 /* reset the DS1306 */
 void rtc_reset (void)
 {
+	/* Assuming Vcc = 2.0V (lowest speed) */
+	if (spi_setup(CFG_SPI_RTC_DEVID, 600000, SPI_MODE_3 | SPI_CS_HIGH))
+		return;
+
 	/* clear the control register */
 	rtc_write (RTC_CONTROL, 0x00);	/* 1st step: reset WP */
 	rtc_write (RTC_CONTROL, 0x00);	/* 2nd step: reset 1Hz, AIE1, AIE0 */
@@ -398,7 +408,7 @@ static unsigned char rtc_read (unsigned char reg)
 
 	dout[0] = reg;
 
-	if (spi_xfer (spi_chipsel[CFG_SPI_RTC_DEVID], 16, dout, din) != 0) {
+	if (spi_xfer (CFG_SPI_RTC_DEVID, 16, dout, din) != 0) {
 		return 0;
 	} else {
 		return din[1];
@@ -415,7 +425,7 @@ static void rtc_write (unsigned char reg, unsigned char val)
 	dout[0] = 0x80 | reg;
 	dout[1] = val;
 
-	spi_xfer (spi_chipsel[CFG_SPI_RTC_DEVID], 16, dout, din);
+	spi_xfer (CFG_SPI_RTC_DEVID, 16, dout, din);
 }
 
 #endif /* end of code exclusion (see #ifdef CONFIG_SXNI855T above) */
diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index a3d1c95..3c263f7 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -37,6 +37,15 @@
 
 #define SPI_TIMEOUT	1000
 
+int spi_setup(int cs, unsigned int max_hz, unsigned int mode)
+{
+	/*
+	 * TODO: Some of the code in spi_init() should probably move
+	 * here.
+	 */
+	return spi_cs_is_valid(cs) ? 0 : -1;
+}
+
 void spi_init(void)
 {
 	volatile spi8xxx_t *spi = &((immap_t *) (CFG_IMMR))->spi;
@@ -53,7 +62,7 @@ void spi_init(void)
 	spi->com = 0;		/* LST bit doesn't do anything, so disregard */
 }
 
-int spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din)
+int spi_xfer(int cs, int bitlen, uchar *dout, uchar *din)
 {
 	volatile spi8xxx_t *spi = &((immap_t *) (CFG_IMMR))->spi;
 	unsigned int tmpdout, tmpdin, event;
@@ -64,8 +73,7 @@ int spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din)
 	debug("spi_xfer: chipsel %08X dout %08X din %08X bitlen %d\n",
 	      (int)chipsel, *(uint *) dout, *(uint *) din, bitlen);
 
-	if (chipsel != NULL)
-		(*chipsel) (1);	/* select the target chip */
+	spi_cs_activate(cs);
 
 	spi->event = 0xffffffff;	/* Clear all SPI events */
 
@@ -135,8 +143,7 @@ int spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din)
 		debug("*** spi_xfer: transfer ended. Value=%08x\n", tmpdin);
 	}
 
-	if (chipsel != NULL)
-		(*chipsel) (0);	/* deselect the target chip */
+	spi_cs_deactivate(cs);
 
 	return 0;
 }
diff --git a/include/spi.h b/include/spi.h
index 03dc5bc..646f87b 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -24,17 +24,31 @@
 #ifndef _SPI_H_
 #define _SPI_H_
 
-/*
- * The function call pointer type used to drive the chip select.
- */
-typedef void (*spi_chipsel_type)(int cs);
-
-
 /*-----------------------------------------------------------------------
  * Initialization, must be called once on start up.
  */
 void spi_init(void);
 
+#define	SPI_CPHA	0x01			/* clock phase */
+#define	SPI_CPOL	0x02			/* clock polarity */
+#define	SPI_MODE_0	(0|0)			/* (original MicroWire) */
+#define	SPI_MODE_1	(0|SPI_CPHA)
+#define	SPI_MODE_2	(SPI_CPOL|0)
+#define	SPI_MODE_3	(SPI_CPOL|SPI_CPHA)
+#define	SPI_CS_HIGH	0x04			/* CS active high */
+
+/*-----------------------------------------------------------------------
+ * Set up communications parameters for a SPI slave.
+ *
+ * This must be called once for each slave.
+ *   cs:      Chip select ID of the slave chip.
+ *   max_hz:  Maximum SCK rate in Hz.
+ *   mode:    Clock polarity and clock phase.
+ *
+ * Returns: 0 on success, nonzero if one or more of the parameters are
+ * not supported.
+ */
+int  spi_setup(int cs, unsigned int max_hz, unsigned int mode);
 
 /*-----------------------------------------------------------------------
  * SPI transfer
@@ -48,19 +62,8 @@ void spi_init(void);
  * input data overwrites the output data (since both are buffered by
  * temporary variables, this is OK).
  *
- * If the chipsel() function is not NULL, it is called with a parameter
- * of '1' (chip select active) at the start of the transfer and again with
- * a parameter of '0' at the end of the transfer.
- *
- * If the chipsel() function _is_ NULL, it the responsibility of the
- * caller to make the appropriate chip select active before calling
- * spi_xfer() and making it inactive after spi_xfer() returns.
- *
  * spi_xfer() interface:
- *   chipsel: Routine to call to set/clear the chip select:
- *              if chipsel is NULL, it is not used.
- *              if(cs),  make the chip select active (typically '0').
- *              if(!cs), make the chip select inactive (typically '1').
+ *   cs:      Chip select ID of the slave chip.
  *   dout:    Pointer to a string of bits to send out.  The bits are
  *              held in a byte array and are sent MSB first.
  *   din:     Pointer to a string of bits that will be filled in.
@@ -68,6 +71,33 @@ void spi_init(void);
  *
  *   Returns: 0 on success, not 0 on failure
  */
-int  spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din);
+int  spi_xfer(int cs, int bitlen, uchar *dout, uchar *din);
+
+/*-----------------------------------------------------------------------
+ * Determine if a SPI chipselect is valid.
+ * This function is provided by the board if the low-level SPI driver
+ * needs it to determine if a given chipselect is actually valid.
+ *
+ * Returns: 1 if cs identifies a valid chip, 0 otherwise.
+ */
+int  spi_cs_is_valid(int cs);
+
+/*-----------------------------------------------------------------------
+ * Activate a SPI chipselect.
+ * This function is provided by the board code when using a driver
+ * that can't control its chipselects automatically (e.g.
+ * common/soft_spi.c). When called, it should activate the chip select
+ * to the device identified by "cs".
+ */
+void spi_cs_activate(int cs);
+
+/*-----------------------------------------------------------------------
+ * Deactivate a SPI chipselect.
+ * This function is provided by the board code when using a driver
+ * that can't control its chipselects automatically (e.g.
+ * common/soft_spi.c). When called, it should deactivate the chip
+ * select to the device identified by "cs".
+ */
+void spi_cs_deactivate(int cs);
 
 #endif	/* _SPI_H_ */
-- 
1.5.3.8

[U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup()

[Joakim Tjernlund]

On Tue, 2008-02-05 at 13:28 +0100, Haavard Skinnemoen wrote:
> No need to add an extra layer of indirection and externals all over
> the place. Just let the board code define two functions,
> spi_cs_activate() and spi_cs_deactivate, and use them to do any
> board-specific magic with the chipselects.
> 
> Not all drivers may need those extra functions however. If that's the
> case, the board code may just leave them out (assuming they know what
> the driver needs) or rely on the linker to strip them out (assuming
> --gc-sections is being used.)
> 
> Also introduce a new function, spi_setup(), which must be called to
> initialize communications parameters for a given slave. This function
> will also check if the given chipselect id is valid. The driver may
> call spi_cs_is_valid(), which is defined by the board code if
> necessary, to verify that a given chipselect id is valid on the
> current board.
> 
> Changed in v2:
>   - Convert the mpc8xxx_spi driver and the mpc8349emds board to the
>     new API.
> 
> Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
> ---
> I haven't tested if the boards affected by this patch still work, or
> even build, so use with care. I'd very much like some feedback on
> whether this API change is a good thing or not though.

This is a really good change as it fixes a relocation bug. The chipsel
func. ptr isn't relocated by current u-boot so it still points
to FLASH after u-boot has been relocated to RAM.

 Jocke

[U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup()

[Ben Warren]

Haavard Skinnemoen wrote:
> No need to add an extra layer of indirection and externals all over
> the place. Just let the board code define two functions,
> spi_cs_activate() and spi_cs_deactivate, and use them to do any
> board-specific magic with the chipselects.
>
> Not all drivers may need those extra functions however. If that's the
> case, the board code may just leave them out (assuming they know what
> the driver needs) or rely on the linker to strip them out (assuming
> --gc-sections is being used.)
>
> Also introduce a new function, spi_setup(), which must be called to
> initialize communications parameters for a given slave. This function
> will also check if the given chipselect id is valid. The driver may
> call spi_cs_is_valid(), which is defined by the board code if
> necessary, to verify that a given chipselect id is valid on the
> current board.
>
> Changed in v2:
>   - Convert the mpc8xxx_spi driver and the mpc8349emds board to the
>     new API.
>
> Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
> ---
> I haven't tested if the boards affected by this patch still work, or
> even build, so use with care. I'd very much like some feedback on
> whether this API change is a good thing or not though.
>   
Thanks Haavard!  I'll try this out on the MPC8349EMDS some time today or 
tonight.

regards,
Ben

[U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup()

[Mike Frysinger]

so the new SPI interface has this API:
 - void spi_init(void);
 - int spi_setup(int cs, unsigned int max_hz, unsigned int mode);
 - int spi_xfer(int cs, int bitlen, uchar *dout, uchar *din);
 - int spi_cs_is_valid(int cs);
 - void spi_cs_activate(int cs);
 - void spi_cs_deactivate(int cs);

there isnt a function to pair up with spi_setup() ?  for example, the normal 
communication flow with a SPI flash:
 - spi_setup - turn on SPI
 - spi_cs_activate - assert CS
 - spi_xfer -
	- op code (read/write/erase)
	- address
	- actual block data
 - spi_cs_deactivate - deassert CS
 - ??? - turn off SPI
you dont want to have the deactivate func to turn off SPI in case you need to 
toggle the CS during communication ... some SPI peripherals have undefined 
(floating) behavior with pins when it is actually turned off which is bad 
mojo ...

also, what's the deal with spi_xfer() taking a length in # of bits ?  is it 
realistic to transmit anything less tan 8 bits ?  the Linux kernel driver 
does not support this, so it cant be a big need ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080205/47ed3ca7/attachment.pgp 

[U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup()

[Haavard Skinnemoen]

On Tue, 5 Feb 2008 23:34:46 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> so the new SPI interface has this API:
>  - void spi_init(void);
>  - int spi_setup(int cs, unsigned int max_hz, unsigned int mode);
>  - int spi_xfer(int cs, int bitlen, uchar *dout, uchar *din);
>  - int spi_cs_is_valid(int cs);
>  - void spi_cs_activate(int cs);
>  - void spi_cs_deactivate(int cs);

Yes, or at least that's the current API + my proposed patch.

> there isnt a function to pair up with spi_setup() ?  for example, the normal 
> communication flow with a SPI flash:
>  - spi_setup - turn on SPI
>  - spi_cs_activate - assert CS
>  - spi_xfer -
> 	- op code (read/write/erase)
> 	- address
> 	- actual block data
>  - spi_cs_deactivate - deassert CS
>  - ??? - turn off SPI

Right. I thought of spi_setup() more as a function that needs to be
called one time per slave to set up communications parameters, not
really for turning the SPI on as such.

But perhaps it would make sense to combine those two functions. How
about we turn it into

/* Set slave-specific parameters and enable SPI */
int spi_claim_bus(int cs, unsigned int max_hz, unsigned int mode);

/* Disable SPI */
void spi_release_bus(int cs);

The claim/release naming also makes it clear that the SPI device driver
has exclusive access to the bus between those two calls.

> you dont want to have the deactivate func to turn off SPI in case you need to 
> toggle the CS during communication ... some SPI peripherals have undefined 
> (floating) behavior with pins when it is actually turned off which is bad 
> mojo ...

Sure, I didn't mean to suggest that spi_cs_deactivate() should turn off
the whole SPI controller.

Btw, the master driver is currently controlling the chip selects from
spi_xfer(). I suspect we need to give clients greater control of the
chip selects eventually.

> also, what's the deal with spi_xfer() taking a length in # of bits ?  is it 
> realistic to transmit anything less tan 8 bits ?  the Linux kernel driver 
> does not support this, so it cant be a big need ...

I don't know. That's unchanged from the original API. But I certainly
wouldn't object if we turned it into a length in bytes.

Haavard

[U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup()

[Mike Frysinger]

On Wednesday 06 February 2008, Haavard Skinnemoen wrote:
> On Tue, 5 Feb 2008 23:34:46 -0500
>
> Mike Frysinger <vapier@gentoo.org> wrote:
> > so the new SPI interface has this API:
> >  - void spi_init(void);
> >  - int spi_setup(int cs, unsigned int max_hz, unsigned int mode);
> >  - int spi_xfer(int cs, int bitlen, uchar *dout, uchar *din);
> >  - int spi_cs_is_valid(int cs);
> >  - void spi_cs_activate(int cs);
> >  - void spi_cs_deactivate(int cs);
>
> Yes, or at least that's the current API + my proposed patch.
>
> > there isnt a function to pair up with spi_setup() ?  for example, the
> > normal communication flow with a SPI flash:
> >  - spi_setup - turn on SPI
> >  - spi_cs_activate - assert CS
> >  - spi_xfer -
> > 	- op code (read/write/erase)
> > 	- address
> > 	- actual block data
> >  - spi_cs_deactivate - deassert CS
> >  - ??? - turn off SPI
>
> Right. I thought of spi_setup() more as a function that needs to be
> called one time per slave to set up communications parameters, not
> really for turning the SPI on as such.
>
> But perhaps it would make sense to combine those two functions. How
> about we turn it into
>
> /* Set slave-specific parameters and enable SPI */
> int spi_claim_bus(int cs, unsigned int max_hz, unsigned int mode);
>
> /* Disable SPI */
> void spi_release_bus(int cs);
>
> The claim/release naming also makes it clear that the SPI device driver
> has exclusive access to the bus between those two calls.

that makes sense to me ...

> Btw, the master driver is currently controlling the chip selects from
> spi_xfer(). I suspect we need to give clients greater control of the
> chip selects eventually.

i think dropping the cs parameter from spi_xfer() is the way to go since you 
should have claimed/asserted it already by the time you perform the 
transfer ?

> > also, what's the deal with spi_xfer() taking a length in # of bits ?  is
> > it realistic to transmit anything less tan 8 bits ?  the Linux kernel
> > driver does not support this, so it cant be a big need ...
>
> I don't know. That's unchanged from the original API. But I certainly
> wouldn't object if we turned it into a length in bytes.

since we're breaking things, might as well break this as well :)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080206/c984d1ee/attachment.pgp 

[U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup()

[Ben Warren]

Haavard Skinnemoen wrote:
> On Tue, 5 Feb 2008 23:34:46 -0500
> Mike Frysinger <vapier@gentoo.org> wrote:
>
>   
>> so the new SPI interface has this API:
>>  - void spi_init(void);
>>  - int spi_setup(int cs, unsigned int max_hz, unsigned int mode);
>>  - int spi_xfer(int cs, int bitlen, uchar *dout, uchar *din);
>>  - int spi_cs_is_valid(int cs);
>>  - void spi_cs_activate(int cs);
>>  - void spi_cs_deactivate(int cs);
>>     
>
> Yes, or at least that's the current API + my proposed patch.
>
>   
>> there isnt a function to pair up with spi_setup() ?  for example, the normal 
>> communication flow with a SPI flash:
>>  - spi_setup - turn on SPI
>>  - spi_cs_activate - assert CS
>>  - spi_xfer -
>> 	- op code (read/write/erase)
>> 	- address
>> 	- actual block data
>>  - spi_cs_deactivate - deassert CS
>>  - ??? - turn off SPI
>>     
>
> Right. I thought of spi_setup() more as a function that needs to be
> called one time per slave to set up communications parameters, not
> really for turning the SPI on as such.
>
> But perhaps it would make sense to combine those two functions. How
> about we turn it into
>
> /* Set slave-specific parameters and enable SPI */
> int spi_claim_bus(int cs, unsigned int max_hz, unsigned int mode);
>
> /* Disable SPI */
> void spi_release_bus(int cs);
>
> The claim/release naming also makes it clear that the SPI device driver
> has exclusive access to the bus between those two calls.
>
>   
If there really is a need to turn off the controller, or change the 
transfer rate on the fly, then this is good. OTOH, this is a bootloader, 
not an OS, and probably the vast majority of use cases would just be to 
initialize the controller to a speed that all devices can handle, 
transfer some data to/from one or more devices, then boot an OS. Maybe 
some people need to do more, I don't know.
>> you dont want to have the deactivate func to turn off SPI in case you need to 
>> toggle the CS during communication ... some SPI peripherals have undefined 
>> (floating) behavior with pins when it is actually turned off which is bad 
>> mojo ...
>>     
>
> Sure, I didn't mean to suggest that spi_cs_deactivate() should turn off
> the whole SPI controller.
>
> Btw, the master driver is currently controlling the chip selects from
> spi_xfer(). I suspect we need to give clients greater control of the
> chip selects eventually.
>
>   
Decoupling chip select from spi_xfer() is a good idea, since spi_xfer() 
is all about sending and receiving streams of bits from the master point 
of view and is slave-agnostic. We may want to add a wrapper function so 
that the user doesn't have to remember too much. Something like:

int spi_send_receive(int cs, int bitlen, char *inbuf, char *outbuf) {

    spi_cs_activate(cs);

    spi_xfer(bitlen, inbuf, outbuf);

    spi_cs_deactivate(cs);

}


yeah, yeah, should handle return codes too...
>> also, what's the deal with spi_xfer() taking a length in # of bits ?  is it 
>> realistic to transmit anything less tan 8 bits ?  the Linux kernel driver 
>> does not support this, so it cant be a big need ...
>>     
>
> I don't know. That's unchanged from the original API. But I certainly
> wouldn't object if we turned it into a length in bytes.
>
>   
I seem to remember working with a Broadcom device where some of the 
transfers were odd numbers of nibbles (e.g. 12 bits). Not necessarily a 
reason to keep bit granularity, but I don't see a reason to artificially 
limit things either.


nice work,
Ben

[U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup()

[Haavard Skinnemoen]

On Wed, 06 Feb 2008 10:18:51 -0500
Ben Warren <biggerbadderben@gmail.com> wrote:
  
> If there really is a need to turn off the controller, or change the 
> transfer rate on the fly, then this is good. OTOH, this is a bootloader, 
> not an OS, and probably the vast majority of use cases would just be to 
> initialize the controller to a speed that all devices can handle, 
> transfer some data to/from one or more devices, then boot an OS. Maybe 
> some people need to do more, I don't know.

The transfer rate is one thing. We can probably do without that, even
though it means that whoever writes the board code needs to look at all
the devices connected and pick the lowest transfer rate instead of
having the driver set it automatically.

SPI transfer modes (i.e. clock polarity, clock phase), etc. is a whole
different issue since if you get them wrong, you will simply not be
able to talk to the SPI slave, and I don't think it's safe to assume
that the transfer mode is the same for all SPI slaves on a given board.

And again, the SPI device driver should know what mode the slave
requires, so setting it from the driver is the natural thing to do.

If we can do proper power management and catch bus contention through
the same interface, that ought to be a good thing, no?

> > Btw, the master driver is currently controlling the chip selects from
> > spi_xfer(). I suspect we need to give clients greater control of the
> > chip selects eventually.
> >
> >   
> Decoupling chip select from spi_xfer() is a good idea, since spi_xfer() 
> is all about sending and receiving streams of bits from the master point 
> of view and is slave-agnostic. We may want to add a wrapper function so 
> that the user doesn't have to remember too much. Something like:
> 
> int spi_send_receive(int cs, int bitlen, char *inbuf, char *outbuf) {
> 
>     spi_cs_activate(cs);
> 
>     spi_xfer(bitlen, inbuf, outbuf);
> 
>     spi_cs_deactivate(cs);
> 
> }

I don't know...it would be a bit counter-productive with controllers
that can do automatic chip select generation.

How about adding a "flags" parameter to spi_xfer() to control chip
select toggling? That way, you can do multiple transfers without
releasing the chip select like this:

spi_xfer(cs, bitlen, inbuf, outbuf, SPI_XFER_BEGIN);
spi_xfer(cs, bitlen, inbuf, outbuf, 0);
spi_xfer(cs, bitlen, inbuf, outbuf, SPI_XFER_END);

Of course, we can still add the wrapper, doing something like this:

int spi_send_receive(int cs, int bitlen, char *inbuf, char *outbuf)
{
	return spi_xfer(cs, bitlen, inbuf, outbuf, SPI_XFER_BEGIN | SPI_XFER_END);
}

Then again, we could simply ignore the automatic CS capability of those
controllers and just use GPIO anyway.

> >> also, what's the deal with spi_xfer() taking a length in # of bits ?  is it 
> >> realistic to transmit anything less tan 8 bits ?  the Linux kernel driver 
> >> does not support this, so it cant be a big need ...
> >>     
> >
> > I don't know. That's unchanged from the original API. But I certainly
> > wouldn't object if we turned it into a length in bytes.
> >
> >   
> I seem to remember working with a Broadcom device where some of the 
> transfers were odd numbers of nibbles (e.g. 12 bits). Not necessarily a 
> reason to keep bit granularity, but I don't see a reason to artificially 
> limit things either.

Right...it's just that handling odd bit sizes correctly in a general
way may complicate controller drivers a lot. Maybe we could split it up
into "number of bits per transfer" / "number of transfers", which
should be easier to handle?

Haavard

[U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup()

[Mike Frysinger]

On Wednesday 06 February 2008, Ben Warren wrote:
> Haavard Skinnemoen wrote:
> > On Tue, 5 Feb 2008 23:34:46 -0500
> > Mike Frysinger <vapier@gentoo.org> wrote:
> >> there isnt a function to pair up with spi_setup() ?  for example, the
> >> normal communication flow with a SPI flash:
> >>  - spi_setup - turn on SPI
> >>  - spi_cs_activate - assert CS
> >>  - spi_xfer -
> >> 	- op code (read/write/erase)
> >> 	- address
> >> 	- actual block data
> >>  - spi_cs_deactivate - deassert CS
> >>  - ??? - turn off SPI
> >
> > Right. I thought of spi_setup() more as a function that needs to be
> > called one time per slave to set up communications parameters, not
> > really for turning the SPI on as such.
> >
> > But perhaps it would make sense to combine those two functions. How
> > about we turn it into
> >
> > /* Set slave-specific parameters and enable SPI */
> > int spi_claim_bus(int cs, unsigned int max_hz, unsigned int mode);
> >
> > /* Disable SPI */
> > void spi_release_bus(int cs);
> >
> > The claim/release naming also makes it clear that the SPI device driver
> > has exclusive access to the bus between those two calls.
>
> If there really is a need to turn off the controller, or change the
> transfer rate on the fly, then this is good. OTOH, this is a bootloader,
> not an OS, and probably the vast majority of use cases would just be to
> initialize the controller to a speed that all devices can handle,
> transfer some data to/from one or more devices, then boot an OS. Maybe
> some people need to do more, I don't know.

U-Boot's design principles dictates that you get in, do your thing, and get 
out.  getting out means breaking down/releasing/turning off/however you want 
to describe it.  there is also the possibility of slight power savings as 
Haavard points out.  you could also have board functions that reuse the pins 
for some other purpose (say they have muxing in place or something).

> >> also, what's the deal with spi_xfer() taking a length in # of bits ?  is
> >> it realistic to transmit anything less tan 8 bits ?  the Linux kernel
> >> driver does not support this, so it cant be a big need ...
> >
> > I don't know. That's unchanged from the original API. But I certainly
> > wouldn't object if we turned it into a length in bytes.
>
> I seem to remember working with a Broadcom device where some of the
> transfers were odd numbers of nibbles (e.g. 12 bits). Not necessarily a
> reason to keep bit granularity, but I don't see a reason to artificially
> limit things either.

but is there any real spi controllers that can transmit less than a byte at a 
time ?  i guess if you consider gpio-based soft spi ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080206/7afe2d06/attachment.pgp 

[U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup()

[Ben Warren]

Mike Frysinger wrote:
> On Wednesday 06 February 2008, Ben Warren wrote:
>   
>> Haavard Skinnemoen wrote:
>>     
>>> On Tue, 5 Feb 2008 23:34:46 -0500
>>> Mike Frysinger <vapier@gentoo.org> wrote:
>>>       
>>>> there isnt a function to pair up with spi_setup() ?  for example, the
>>>> normal communication flow with a SPI flash:
>>>>  - spi_setup - turn on SPI
>>>>  - spi_cs_activate - assert CS
>>>>  - spi_xfer -
>>>> 	- op code (read/write/erase)
>>>> 	- address
>>>> 	- actual block data
>>>>  - spi_cs_deactivate - deassert CS
>>>>  - ??? - turn off SPI
>>>>         
>>> Right. I thought of spi_setup() more as a function that needs to be
>>> called one time per slave to set up communications parameters, not
>>> really for turning the SPI on as such.
>>>
>>> But perhaps it would make sense to combine those two functions. How
>>> about we turn it into
>>>
>>> /* Set slave-specific parameters and enable SPI */
>>> int spi_claim_bus(int cs, unsigned int max_hz, unsigned int mode);
>>>
>>> /* Disable SPI */
>>> void spi_release_bus(int cs);
>>>
>>> The claim/release naming also makes it clear that the SPI device driver
>>> has exclusive access to the bus between those two calls.
>>>       
>> If there really is a need to turn off the controller, or change the
>> transfer rate on the fly, then this is good. OTOH, this is a bootloader,
>> not an OS, and probably the vast majority of use cases would just be to
>> initialize the controller to a speed that all devices can handle,
>> transfer some data to/from one or more devices, then boot an OS. Maybe
>> some people need to do more, I don't know.
>>     
>
> U-Boot's design principles dictates that you get in, do your thing, and get 
> out.  getting out means breaking down/releasing/turning off/however you want 
> to describe it.  there is also the possibility of slight power savings as 
> Haavard points out.  you could also have board functions that reuse the pins 
> for some other purpose (say they have muxing in place or something).
>
>   
True.  I just want to be careful we don't over-engineer this...
>>>> also, what's the deal with spi_xfer() taking a length in # of bits ?  is
>>>> it realistic to transmit anything less tan 8 bits ?  the Linux kernel
>>>> driver does not support this, so it cant be a big need ...
>>>>         
>>> I don't know. That's unchanged from the original API. But I certainly
>>> wouldn't object if we turned it into a length in bytes.
>>>       
>> I seem to remember working with a Broadcom device where some of the
>> transfers were odd numbers of nibbles (e.g. 12 bits). Not necessarily a
>> reason to keep bit granularity, but I don't see a reason to artificially
>> limit things either.
>>     
>
> but is there any real spi controllers that can transmit less than a byte at a 
> time ?  i guess if you consider gpio-based soft spi ...
> -mike
>   
Sure, the Freescale SPI controller that I wrote a driver for (MPC8xxx) 
can send an arbitrary number of bits.  Not sure exactly where that's 
useful, but my worldview is limited to high-powered telecom/datacom 
equipment.

regards,
Ben

[U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup()

[Ulf Samuelsson]

>> but is there any real spi controllers that can transmit less than a byte at a 
>> time ?  i guess if you consider gpio-based soft spi ...
>> -mike
>>   
> Sure, the Freescale SPI controller that I wrote a driver for (MPC8xxx) 
> can send an arbitrary number of bits.  Not sure exactly where that's 
> useful, but my worldview is limited to high-powered telecom/datacom 
> equipment.
> 

Yes, the Atmel SPI in the AT91 can send 8..16 bits.
I think that typical use would be for ADCs and different kind of RF chips,
but I can't think of any specific examples right now.

Other things supported by the Atmel SPI are 
* Introducing delays during various parts of the transfers.
* Selection whether to terminate the access at the end of the transfer
   or let the chip select remain active
* You can either set the chip select manually, or let the data contain the chip select number.

Since in many AT91 boards, both Linux and the RAM disk is loaded from a dataflash,
you want to set the SPI speed as high as possible for flash access - or you will affect boot time.
33 Mbps will mean that you load a 4 MB RAM disk in about 1 second while 5 Mbps
means you load it in about 6 seconds.

In this user case, the SPI is probably already initialized by the AT91 bootstrap
which loads U-Boot to SDRAM from the dataflash, so any initialization should maybe be optional.

Best Regards
Ulf Samuelsson