[PATCH] spi-gpio: Implement spidelay() for busses that need it.

[PATCH] spi-gpio: Implement spidelay() for busses that need it.

[Michael Buesch]

Implement the SPI-GPIO delay function for busses that need speed limitation.
If the special all-inline API is used, the delay is disabled at compiletime.
Otherwise it's an unlikely condition that can be disabled via max_speed_hz.
So it should have minimal or zero impact on the speed of implementations without delay.

Signed-off-by: Michael Buesch <mb@bu3sch.de>

---

I need this delay when using a slow microcontroller attached via SPI-GPIO
to a fast embedded router device.

Index: linux-2.6/drivers/spi/spi_gpio.c
===================================================================
--- linux-2.6.orig/drivers/spi/spi_gpio.c	2009-02-15 16:27:16.000000000 +0100
+++ linux-2.6/drivers/spi/spi_gpio.c	2009-02-15 19:19:36.000000000 +0100
@@ -21,6 +21,7 @@
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/gpio.h>
+#include <linux/delay.h>
 
 #include <linux/spi/spi.h>
 #include <linux/spi/spi_bitbang.h>
@@ -69,6 +70,7 @@ struct spi_gpio {
  *		#define	SPI_MOSI_GPIO	120
  *		#define	SPI_SCK_GPIO	121
  *		#define	SPI_N_CHIPSEL	4
+ *		#undef NEED_SPIDELAY
  *		#include "spi_gpio.c"
  */
 
@@ -76,6 +78,7 @@ struct spi_gpio {
 #define DRIVER_NAME	"spi_gpio"
 
 #define GENERIC_BITBANG	/* vs tight inlines */
+#define NEED_SPIDELAY	1
 
 /* all functions referencing these symbols must define pdata */
 #define SPI_MISO_GPIO	((pdata)->miso)
@@ -120,12 +123,20 @@ static inline int getmiso(const struct s
 #undef pdata
 
 /*
- * NOTE:  this clocks "as fast as we can".  It "should" be a function of the
- * requested device clock.  Software overhead means we usually have trouble
- * reaching even one Mbit/sec (except when we can inline bitops), so for now
- * we'll just assume we never need additional per-bit slowdowns.
+ * NOTE:  to clock "as fast as we can", set spi_device.max_speed_hz
+ * and spi_transfer.speed_hz to 0.
+ * Otherwise this is a function of the requested device clock.
+ * Software overhead means we usually have trouble
+ * reaching even one Mbit/sec (except when we can inline bitops). So on small
+ * embedded devices with fast SPI slaves you usually don't need a delay.
  */
-#define spidelay(nsecs)	do {} while (0)
+static inline void spidelay(unsigned nsecs)
+{
+#ifdef NEED_SPIDELAY
+	if (unlikely(nsecs))
+		ndelay(nsecs);
+#endif /* NEED_SPIDELAY */
+}
 
 #define	EXPAND_BITBANG_TXRX
 #include <linux/spi/spi_bitbang.h>

-- 
Greetings, Michael.

Re: [PATCH] spi-gpio: Implement spidelay() for busses that need it.

[David Brownell]

[
  NOTE:  removed openwrt from the cc list, it rejects posts
  from non-subscribers.  Please don't cc such lists.
]

On Sunday 15 February 2009, Michael Buesch wrote:
> + * NOTE:  to clock "as fast as we can", set spi_device.max_speed_hz
> + * and spi_transfer.speed_hz to 0.

Won't work; if spi->max_speed_hz is zero, spi_async() and
friends will refuse to queue any messages.

I'm not averse to a solution that lets some boards use a
slowed-down bitbang loop.  But it would be a lot easier
if you kept the default the way it is, and just added
that slowdown as an option for the existing customization
case (currently oriented towards speedup, not slowdown).

- Dave

Re: [PATCH] spi-gpio: Implement spidelay() for busses that need it.

[Michael Buesch]

On Monday 16 February 2009 21:42:27 David Brownell wrote:
> [
>   NOTE:  removed openwrt from the cc list, it rejects posts
>   from non-subscribers.  Please don't cc such lists.
> ]

I'm sorry, I didn't know that it bounces nonsubscribers.

> On Sunday 15 February 2009, Michael Buesch wrote:
> > + * NOTE:  to clock "as fast as we can", set spi_device.max_speed_hz
> > + * and spi_transfer.speed_hz to 0.
> 
> Won't work; if spi->max_speed_hz is zero, spi_async() and
> friends will refuse to queue any messages.

Well, why would they do this? Any special reason?

> I'm not averse to a solution that lets some boards use a
> slowed-down bitbang loop.  But it would be a lot easier
> if you kept the default the way it is, and just added
> that slowdown as an option for the existing customization
> case (currently oriented towards speedup, not slowdown).

Tell me how to. This patch works for me and I'm only going to change it
if you tell me how to. I'm not so involved in the SPI subsystem that I can
see another obvious way to do this. So I need some advise, please.

-- 
Greetings, Michael.