ads7836 uses spi_driver

This updates the ads7846 driver to match the preceding patch (requring spi_driver); and tweaks a handful of comments.

- Dave

This updates the ads7864 driver to use the new "spi_driver" struct, and includes some minor unrelated cleanup.

@@ -1,7 +1,7 @@
 /* linux/spi/ads7846.h */
 
 /* Touchscreen characteristics vary between boards and models.  The
- * platform_data for the device's "struct device" holts this information.
+ * platform_data for the device's "struct device" holds this information.
  *
  * It's OK if the min/max values are zero.
  */

Here's a mostly-working bitbang driver for SPI. It seems to handle SPI mode 0 just fine; I've done a bunch of flash updates through a parport wrapper, and no bits were damaged.

Eventually I hope this will serve as a reference implementation, showing how the various API operations map to bits on the wire. (Contrast it to the I2C bitbangers, also. Simpler...)

Likewise, folk looking at getting more standard SPI support on their hardware could start with this. It's reasonably common for the pins used for SPI controllers to be accessible as GPIOs, so this bitbanger might be used until a real hardware driver was debugged and tuned. (That's assuming there _is_ a dedicated SPI controller to use!)

Comments appreciated. Also testing with other SPI modes, and potentially code tweaks to make the banging go faster.

- Dave

This adds a bitbanging spi master, hooking up to board/adapter-specific glue code which knows how to set and read the signals (gpios etc).

This code kicks in after the glue code creates a platform_device with the right platform_data. That data includes I/O loops, which will usually come from expanding an inline function (provided in the header). One goal is that the I/O loops should be easily optimized down to a few GPIO register accesses, in common cases, for speed and minimized overhead.

This understands all the currently defined protocol tweaking options in the SPI framework, and might eventually serve as as reference implementation.

- different word sizes (1..32 bits)
- differing clock rates
- SPI modes differing by CPOL (affecting chip select and I/O loops)
- SPI modes differing by CPHA (affecting I/O loops)
- delays (usecs) after transfers
- temporarily deselecting chips in mid-transfer

This version is circulating mostly as an RFC. SPI Mode 0 works talking to a Flash chip, but I'm still chasing down some bugs that show up after I rmmod the parport adapter.

@@ -66,6 +66,19 @@ config SPI_MASTER
 comment "SPI Master Controller Drivers"
 	depends on SPI_MASTER
 
+config SPI_BITBANG
+	tristate "Bitbanging SPI master"
+	depends on SPI_MASTER && EXPERIMENTAL
+	help
+	  With a few GPIO pins, your system can bitbang the SPI protocol.
+	  Choose this if you need SPI support through I/O pins (GPIO,
+	  parallel port, etc).
+	  
+	  Make sure you initialize one platform device object for each SPI
+	  master device on your system, using "spi_bitbang" as the device
+	  name with platform_data saying how to use which pins.  That will
+	  often be done using static board-specific tables in board-specific
+	  (or adapter-specific) setup code.
 
 #
 # Add new SPI master controllers in alphabetical order above this line

@@ -11,6 +11,7 @@ endif
 obj-$(CONFIG_SPI_MASTER)		+= spi.o
 
 # SPI master controller drivers (bus)
+obj-$(CONFIG_SPI_BITBANG)		+= spi_bitbang.o
 # 	... add above this line ...
 
 # SPI protocol drivers (device/link on bus)

This patch should *replace* your latest mtd_dataflash patch, instead of applying on top of things like the preceding patches. (Sorry.)

It does the spi_driver conversion mentioned in $SUBJECT, and also includes a couple other updates. There's a bugfix in the READ request (don't count the 8 tx bytes with rx), a performance speedup in ERASE (use block erase, more or less eight times faster for JFFS2), and more probe() cleanups.

- Dave

This is a conversion of the AT91rm9200 DataFlash MTD driver to use the lightweight SPI framework, and no longer be AT91-specific. It compiles down to less than 3KBytes on ARM.

The driver allows board-specific init code to provide platform_data with the relevant MTD partitioning information, and hotplugs.

This version has been lightly tested. Its parent at91_dataflash driver has been pretty well banged on, although kernel.org JFFS2 dataflash support was acting broken the last time I tried it.

@@ -255,5 +255,13 @@ config MTD_DOCPROBE_55AA
 	  LinuxBIOS or if you need to recover a DiskOnChip Millennium on which
 	  you have managed to wipe the first block.
 
+config MTD_DATAFLASH
+	tristate "Support for AT45xxx DataFlash"
+	depends on MTD && SPI_MASTER && EXPERIMENTAL
+	help
+	  This enables access to AT45xxx DataFlash chips, using SPI.
+	  Sometimes DataFlash chips are packaged inside MMC-format
+	  cards; at this writing, the MMC stack won't handle those.
+
 endmenu
 

@@ -0,0 +1,27 @@
+#ifndef LINUX_SPI_FLASH_H
+#define LINUX_SPI_FLASH_H
+
+struct mtd_partition;
+
+/**
+ * struct flash_platform_data: board-specific flash data
+ * @name: optional flash device name (eg, as used with mtdparts=)
+ * @parts: optional array of mtd_partitions for static partitioning
+ * @nr_parts: number of mtd_partitions for static partitoning
+ *
+ * Board init code (in arch/.../mach-xxx/board-yyy.c files) can
+ * provide information about SPI flash parts (such as DataFlash) to
+ * help set up the device and its appropriate default partitioning.
+ *
+ * Note that for DataFlash, sizes for pages, blocks, and sectors are
+ * rarely powers of two; and partitions should be sector-aligned.
+ */
+struct flash_platform_data {
+	char		*name;
+	struct mtd_partition *parts;
+	unsigned int	nr_parts;
+
+	/* we'll likely add more ... use JEDEC IDs, etc */
+};
+
+#endif

@@ -23,3 +23,4 @@ obj-$(CONFIG_MTD_MTDRAM)	+= mtdram.o
 obj-$(CONFIG_MTD_LART)		+= lart.o
 obj-$(CONFIG_MTD_BLKMTD)	+= blkmtd.o
 obj-$(CONFIG_MTD_BLOCK2MTD)	+= block2mtd.o
+obj-$(CONFIG_MTD_DATAFLASH)	+= mtd_dataflash.o