SPI redux ... driver model support

SPI redux ... driver model support

[David Brownell]

The last couple times SPI frameworks came up here, some of the feedback
included "make it use the driver model properly; don't be like I2C".

In hopes that it'll be useful, here's a small SPI core with driver model
support driven from board-specific tables listing devices.  I expect the
I/O call(s) could stand to change; but at least this one starts out right,
based on async I/O.  (There's a synchronous call; it's a trivial wrapper.)

 arch/arm/Kconfig       |    2 
 drivers/Kconfig        |    2 
 drivers/Makefile       |    1 
 drivers/spi/Kconfig    |  302 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/spi/Makefile   |   32 ++++
 drivers/spi/spi_init.c |  233 ++++++++++++++++++++++++++++++++++
 include/linux/spi.h    |  179 ++++++++++++++++++++++++++
 7 files changed, 751 insertions(+)

Here's one instance of the sysfs "spi_host" class:

	[root@argon sys]# cd /sys/class
	[root@argon class]# ls
	i2c-adapter/   misc/          pcmcia_socket/ spi_host/      usb_host/
	input/         mtd/           scsi_device/   tty/           vc/
	mem/           net/           scsi_host/     usb/
	[root@argon class]# ls spi_host
	spi2/
	[root@argon class]# ls -l spi_host/spi2
	drwxr-xr-x    2 root     root            0 Aug 29 18:46 ./
	drwxr-xr-x    3 root     root            0 Dec 31  1969 ../
	lrwxrwxrwx    1 root     root            0 Aug 29 18:46 device -> ../../../devices/platform/omap-uwire/
	[root@argon class]#

Here are the real sysfs objects for that host and its single child
(on chipselect 0).  Notice that the device exists, but is waiting for
driver-modelized ads7846 support (touchscreen and other sensors):

	[root@argon class]# cd /sys/devices/platform/omap-uwire
	[root@argon omap-uwire]# ls
	bus@            driver@         power/          spi2.0-ads7846/
	[root@argon omap-uwire]# ls -l spi*
	lrwxrwxrwx    1 root     root            0 Aug 29 18:46 bus -> ../../../../bus/spi/
	-r--r--r--    1 root     root         4096 Aug 29 18:46 modalias
	drwxr-xr-x    2 root     root            0 Aug 29 18:46 power/
	[root@argon omap-uwire]# cat spi*/modalias
	ads7846
	[root@argon omap-uwire]#

For your viewing pleasure, and without the broadast flag that would
prevent further redistribution, a patch is appended.

- Dave


-----------------------------------------	SNIP!!
This is the start of a small SPI framework that started fresh, so it
doesn't continue the "i2c driver model mess".

  - It needs less than 1KB of codespace.  If we're stuck with a mid-layer
    for something so simple, that's the right size budget.  :)

  - The guts use board-specific SPI master configuration tables to build
    the driver model tree.  (Hardware probing is normally NOT an option.)

  - The Kconfig should be informative about the scope and content of SPI.
    Don't take that set of drivers seriously yet though!

  - Building real drivers into this framework likely means updating the
    I/O "async message" model to include protocol tweaking (like I2C), and
    maybe some RPC-ish calls (integer in/out, not bulk data; like SMBus).

  - No userspace API.  There are several implementations to compare.
    Implement them like any driver, then bind that driver to the device.

An SPI master controller will declare itself to the SPI framework, which
causes any child devices (from those tables) to be created immediately.
New "modalias" style hotplug is supported, for ultra-slim userspace tools.


--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ g26/include/linux/spi.h	2005-08-29 16:00:38.000000000 -0700
@@ -0,0 +1,179 @@
+/*
+ * Copyright (C) 2005 David Brownell
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __LINUX_SPI_H
+#define __LINUX_SPI_H
+
+/*
+ * PROTOTYPE ONLY !!!
+ *
+ * The focus is on driver model support ... enough for SPI mastering
+ * board setups to work.  The I/O model still needs attention.
+ */
+
+/*---------------------------------------------------------------------------*/
+
+/*
+ * INTERFACE between board init code and SPI infrastructure.
+ *
+ * No SPI driver ever sees these device tables, but it's what
+ * builds the SPI driver model tree.
+ */
+
+/* board-specific initialization provides a table of SPI devices */
+struct spi_board_info {
+	/* the device name and module name are coupled, like platform_bus.
+	 * platform_data has things like GPIOs and IRQ assignments.
+	 */
+	const char	*modalias;
+	void		*platform_data;
+
+	/* e.g. slower on noisy or low voltage boards */
+	u32		max_speed_hz;
+
+	/* bus numbering is board specific (except zero means no-bus),
+	 * and chip selects reflect how each controller is wired.
+	 */
+	u16		bus_num;
+	u16		chip_select;
+
+	/* ... may need more standard chip config data ... */
+};
+
+extern int
+spi_register_board_info(struct spi_board_info const *info, unsigned n);
+
+
+/*---------------------------------------------------------------------------*/
+
+/*
+ * INTERFACES between SPI master drivers and infrastructure
+ *
+ * There are two types of master (or slave) driver:  "controller" drivers
+ * usually work on platform devices and touch chip registers; "protocol"
+ * drivers work on an SPI device by asking its controller driver to
+ * transfer the relevant data.
+ *
+ * The "struct device_driver" for an SPI device uses "spi_bus_type" and
+ * will be bound to devices based on their names (much like platform_bus).
+ */
+extern struct bus_type spi_bus_type;
+
+struct spi_device {
+	struct device	dev;
+	struct spi_host	*host;
+	u32		max_speed_hz;
+	u16		chip_select;
+	u8		mode;
+/* low two bits == mode 0/3/... */
+#define	SPI_MODE_READ_FALLING_EDGE	0x00
+#define	SPI_MODE_READ_RISING_EDGE	0x01
+#define	SPI_MODE_WRITE_FALLING_EDGE	0x00
+#define	SPI_MODE_WRITE_RISING_EDGE	0x02
+/* (REVISIT:  check all that!!) */
+};
+
+static inline struct spi_device *to_spi_device(struct device *dev)
+{
+	return container_of(dev, struct spi_device, dev);
+}
+
+
+struct spi_message;
+
+struct spi_host {
+	struct class_device	dev;
+	u16			bus_num;
+
+	/* setup mode and clock, etc */
+	int			(*setup)(struct spi_device *dev);
+
+	/* bidirectional bit transfers
+	 * the optional i/o queue arbitrates hardware access when multiple
+	 * protocol drivers and chipselects are concurrently active.
+	 */
+	int			(*transfer)(struct spi_device *dev,
+						struct spi_message *mesg);
+	struct list_head	queue;
+};
+
+extern int spi_register_host(struct device *host, struct spi_host *spi);
+
+
+/*---------------------------------------------------------------------------*/
+
+/*
+ * I/O INTERFACE between SPI controller and device drivers
+ *
+ * Basically think of a queue of spi_messages, each of which will
+ * transfer data in both directions but to different addresses.
+ * SPI protocol drivers just provide spi_messages.
+ */
+
+struct spi_transfer {
+	/* it's ok if tx_buf == rx_buf
+	 * in SPI, number of bits out == number of bits in
+	 * for MicroWire, one buffer must be null
+	 * buffers must work with dma_*map_single() calls
+	 */
+	u8		*tx_buf, *rx_buf;
+	unsigned	len;
+};
+
+struct spi_message {
+	struct spi_transfer	*transfers;
+	unsigned		n_transfer;
+
+	unsigned		flags;
+#define	SPI_XFER_CS_ON		0x0000	/* CS stays on after this */
+#define	SPI_XFER_CS_OFF		0x0001	/* CS turned off after this */
+
+	/* REVISIT:  Devices may be doing things like 12 bit transfers;
+	 * for now, assume those will be left aligned in 16 bit values.
+	 * wordsize may matter here too.
+	 */
+
+	/* completion is reported this way */
+	// REVISIT make this FASTCALL so we can easily
+	// use complete() from <linux/completion.h>
+	void 			(*complete)(void *context);
+	void			*context;
+	int			status;
+
+	/* controller driver state */
+	struct list_head	queue;
+};
+
+/* before passing messages, setup the SPI mode and clock rate */
+static inline int
+spi_setup(struct spi_device *dev)
+{
+	return dev->host->setup(dev);
+}
+
+/* synchronous SPI transfers; this may sleep */
+extern int spi_sync(struct spi_device *dev, struct spi_message *message);
+
+/* async SPI transfer, can be used in_irq */
+static inline int
+spi_async(struct spi_device *dev, struct spi_message *message)
+{
+	return dev->host->transfer(dev, message);
+}
+
+#endif /* __LINUX_SPI_H */
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ g26/drivers/spi/spi_init.c	2005-08-29 16:00:38.000000000 -0700
@@ -0,0 +1,233 @@
+/* spi-init.c -- prototype of SPI init/core code
+ *
+ * Copyright (C) 2005 David Brownell
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/autoconf.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/spi.h>
+
+
+static struct spi_board_info const *board_info;
+static unsigned n_board_info;
+
+/*
+ * Board init code calls this -- probably during arch_initcall -- to define
+ * the SPI devices found on this board.  The device nodes are created later,
+ * after the relevant parent SPI controller (bus_num) is defined.  We keep
+ * this table of devices forever, so that reloading a controller driver will
+ * not forget about these devices.
+ *
+ * REVISIT this version just records this data, with no copying ... but it's
+ * common to build systems by stacking boards, with SPI being one of the
+ * interfaces on the connector.  For example, i2c eeproms could identify
+ * each board, letting other code infer what spi devices it adds.  That
+ * means we might need to make this call several times...
+ *
+ * We may also want to add a usermode API for this ... it's probably easier
+ * to handle some of those multi-board situations from there.
+ */
+int __init
+spi_register_board_info(struct spi_board_info const *info, unsigned n)
+{
+	if (board_info)
+		return -EBUSY;
+	board_info = info;
+	n_board_info = n;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(spi_register_board_info);
+
+
+/*-------------------------------------------------------------------------*/
+
+/*
+ * Here's how registering an SPI host goes:
+ *   - SPI bustype and spi_host class are registered early
+ *   - SPI controller and driver probably live on the platform_bus
+ *   - controller driver allocates an spi_host
+ *   - end of controller driver's probe() calls spi_register_host()
+ *	+ creates the class device for that SPI controller
+ *	+ creates any pre-declared devices
+ *   - driver model handles hotplug/modalias and probing, as usual
+ *
+ * That way SPI controller and device drivers can be modules, and all
+ * driver model devices are provided without hardware probing.
+ */
+
+static struct class spi_host_class = {
+	.name	= "spi_host",
+	.owner	= THIS_MODULE,
+};
+
+static void spidev_release(struct device *dev)
+{
+	kfree(container_of(dev, struct spi_device, dev));
+}
+
+int spi_register_host(struct device *host, struct spi_host *spi)
+{
+	int		status, i;
+
+	if (!n_board_info) {
+		dev_dbg(host, "spi board info is missing\n");
+		return -EINVAL;
+	}
+	if (spi->bus_num == 0) {
+		dev_dbg(host, "spi bus number not assigned\n");
+		return -EINVAL;
+	}
+
+	spi->dev.class = &spi_host_class;
+	spi->dev.dev = host;
+	snprintf(spi->dev.class_id, sizeof spi->dev.class_id,
+		"spi%d", spi->bus_num);
+
+	status = class_device_register(&spi->dev);
+	if (status < 0)
+		return status;
+	dev_dbg(host, "master %s\n", spi->dev.class_id);
+
+	for (i = 0; i < n_board_info; i++) {
+		struct spi_board_info const	*chip;
+		struct spi_device		*dev;
+
+		chip = &board_info[i];
+		if (chip->bus_num != spi->bus_num)
+			continue;
+
+		dev = kcalloc(1, sizeof *dev, GFP_KERNEL);
+		if (!dev) {
+			dev_err(host, "can't alloc dev for cs%d\n",
+				chip->chip_select);
+			continue;
+		}
+		dev->host = spi;
+		dev->chip_select = chip->chip_select;
+		dev->max_speed_hz = chip->max_speed_hz;
+
+		snprintf(dev->dev.bus_id, sizeof dev->dev.bus_id,
+				"spi%u.%u-%s",
+				chip->bus_num, chip->chip_select,
+				chip->modalias);
+		dev->dev.parent = host;
+		dev->dev.bus = &spi_bus_type;
+		dev->dev.platform_data = chip->platform_data;
+		dev->dev.release = spidev_release;
+
+		/* drivers may modify this default i/o setup */
+		status = spi->setup(dev);
+		if (status < 0) {
+			dev_err(host, "can't setup %s, status %d\n",
+					dev->dev.bus_id, status);
+			goto trynext;
+		}
+
+		status = device_register(&dev->dev);
+		if (status < 0) {
+			dev_err(host, "can't add %s, status %d\n",
+					dev->dev.bus_id, status);
+trynext:
+			kfree(dev);
+			continue;
+		}
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(spi_register_host);
+
+
+/* FIXME add spi_unregister_host() */
+
+
+/*-------------------------------------------------------------------------*/
+
+/* NOTE SIMPLIFICATION:  no "cancel message" operation */
+
+static void spi_sync_complete(void *done)
+{
+	complete(done);
+}
+
+int spi_sync(struct spi_device *dev, struct spi_message *message)
+{
+	DECLARE_COMPLETION(done);
+	int status;
+
+	message->complete = spi_sync_complete;
+	message->context = &done;
+	status = spi_async(dev, message);
+	if (status == 0) {
+		wait_for_completion(&done);
+		status = message->status;
+	}
+	message->context = NULL;
+	return status;
+}
+
+/*-------------------------------------------------------------------------*/
+
+static ssize_t
+modalias_show(struct device *dev, struct device_attribute *a, char *buf)
+{
+	const char *modalias = strchr(dev->bus_id, '-') + 1;
+	return snprintf(buf, BUS_ID_SIZE + 1, "%s\n", modalias);
+}
+
+static struct device_attribute spi_dev_attrs[] = {
+	__ATTR_RO(modalias),
+	__ATTR_NULL,
+};
+
+static int spi_match_device(struct device *dev, struct device_driver *drv)
+{
+	const char *modalias = strchr(dev->bus_id, '-') + 1;
+
+	return strncmp(modalias, drv->name, BUS_ID_SIZE) == 0;
+}
+
+static int spi_hotplug(struct device *dev, char **envp, int num_envp,
+		char *buffer, int buffer_size)
+{
+	const char *modalias = strchr(dev->bus_id, '-') + 1;
+
+	envp[0] = buffer;
+	snprintf(buffer, buffer_size, "MODALIAS=%s", modalias);
+	envp[1] = NULL;
+	return 0;
+}
+
+struct bus_type spi_bus_type = {
+	.name		= "spi",
+	.match		= spi_match_device,
+	.hotplug	= spi_hotplug,
+	.dev_attrs	= spi_dev_attrs,
+};
+EXPORT_SYMBOL_GPL(spi_bus_type);
+
+
+static int __init spi_init(void)
+{
+	bus_register(&spi_bus_type);
+	class_register(&spi_host_class);
+	return 0;
+}
+postcore_initcall(spi_init);
+
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ g26/drivers/spi/Kconfig	2005-08-29 16:02:13.000000000 -0700
@@ -0,0 +1,302 @@
+#
+# This is what Linux SPI might look support after adding drivers for
+# some embedded SPI-capable hardware that's used with Linux.
+#
+# NOTE: over half of the SPI protocol masters mentioned actually exist,
+# and sometimes even on 2.6.  Few of the SPI master controller drivers
+# exist.  None of those drivers use the 2.6 driver model, and they all
+# have different I/O models too.
+#
+
+#
+# SPI device configuration
+#
+menu "Serial Peripheral Interface (SPI)"
+
+config SPI
+	bool "SPI support"
+	depends on SPI_ARCH_HAS_MASTER || SPI_ARCH_HAS_SLAVE
+	help
+	  The "Serial Peripheral Interface" is a low level synchronous
+	  protocol used to talk with sensors, eeprom and flash memory,
+	  codecs and various other controller chips, analog to digital
+	  (and d-to-a) converters, and more.  MMC and SD cards can be
+	  accessed using SPI protocol; and for DataFlash cards used in
+	  MMC sockets, SPI must be used.
+
+	  Chips and controllers that support SPI can have data transfer
+	  rates up to several tens of Mbit/sec, and often support DMA.
+	  Chips are addressed with a controller and (usually) a chipselect.
+	  Most SPI devices don't support dynamic device discovery; some
+	  are even write-only or read-only.
+
+	  SPI is one of a family of similar protocols using a four wire
+	  interface (select, clock, data in, data out) including Microwire
+	  (half duplex), SSP, and PSP.  This driver framework should work
+	  with most of them.
+
+config SPI_DEBUG
+	boolean "Debug messaging for SPI drivers"
+	depends on SPI && DEBUG_KERNEL
+	help
+	  Say "yes" to enable debug messaging (like dev_dbg and pr_debug)
+	  from SPI bus and device drivers.
+
+# someday this stuff should be set using arch/CPU/PLATFORM/Kconfig
+config SPI_ARCH_HAS_MASTER
+	boolean
+	default y if ARCH_OMAP
+	default y if ARCH_PXA
+	default y if ARCH_AT91
+	default y if X86		# DEVEL HACK
+
+config SPI_ARCH_HAS_SLAVE
+	boolean
+	default y if ARCH_OMAP
+	default y if ARCH_PXA
+	default y if ARCH_AT91
+	default y if X86		# DEVEL HACK
+
+#
+# MASTER
+#
+comment "No SPI master hardware is available."
+	depends on SPI && !SPI_ARCH_HAS_MASTER
+
+menuconfig SPI_MASTER
+	boolean "SPI Master support"
+	depends on SPI && SPI_ARCH_HAS_SLAVE
+
+if SPI_MASTER
+
+comment "SPI Master Controller Drivers"
+
+# Atmel AT91rm9200 (and some other AT91 family chips)
+config SPI_AT91
+	tristate "AT91 as SPI master"
+	depends on ARCH_AT91
+	help
+	  This implements SPI master mode using an SPI controller.
+
+# FIXME  bitbangers need arch-specific ways to access the
+# right GPIO pins, probably using platform data and maybe
+# using platform-specific minidrivers.
+config SPI_BITBANG
+	tristate "Bitbanging SPI master"
+	help
+	  You can implement SPI using GPIO pins, as this driver
+	  eventually should do.
+
+# Motorola Coldfire (m68k)
+config SPI_COLDFIRE
+	tristate "Coldfire QSPI as SPI master"
+	depends on COLDFIRE
+	help
+	  This implements SPI master mode using the QSPI controller.
+
+# Motorola MPC (PPC)
+config SPI_MPC
+	tristate "MPC SPI master"
+	depends on PPC && MPC
+	help
+	  This implements SPI master mode using the MPC SPI controller.
+
+# TI OMAP (ARM)
+config SPI_OMAP
+	tristate "OMAP SPI controller as master"
+	depends on ARCH_OMAP
+	help
+	  This implements SPI master mode using the dedicated SPI
+	  controller.
+
+config SPI_OMAP_MCBSP
+	tristate "OMAP MCBSP as SPI master"
+	depends on ARCH_OMAP
+	help
+	  This implements master mode SPI using a McBSP controller.
+
+config SPI_OMAP_UWIRE
+	tristate "OMAP MicroWire as SPI master"
+	depends on ARCH_OMAP
+	select OMAP_UWIRE
+	help
+	  This implements master mode SPI using the MicroWire controller.
+
+config SPI_OMAP_MMC
+	tristate "OMAP MMC as SPI master"
+	depends on ARCH_OMAP
+	help
+	  This implements master mode SPI using an MMC controller.
+
+
+# Intel PXA (ARM)
+config SPI_PXA_SSP
+	tristate "PXA SSP controller as SPI master"
+	depends on ARCH_PXA
+	help
+	  This implements SPI master mode using an SSP controller.
+
+config SPI_PXA_NSSP
+	tristate "PXA NSSP (or ASSP) controller as SPI master"
+	depends on ARCH_PXA
+	help
+	  This implements SPI master mode using the NSSP controller, which
+	  is available with PXA 255 and PXA 26x processors.
+
+config SPI_PXA_MMC
+	tristate "PXA MMC as SPI master"
+	depends on ARCH_PXA
+	help
+	  This implements master mode SPI using an MMC controller.
+
+
+#
+# Add new SPI master controllers in alphabetical order above this line
+#
+
+
+#
+# There are lots of SPI device types, with sensors and memory
+# being probably the most widely used ones.
+#
+comment "SPI Protocol Masters"
+
+config SPI_ADS7864
+	tristate "ADS 7864 touchscreen and sensors"
+	help
+	  This chip has touchscreen, voltage, and temperature sensors.
+	  The driver packages the touchscreen as an input device,
+	  and publishes the sensor values in sysfs.
+
+config SPI_DATAFLASH
+	tristate "DataFlash -- MTD support"
+	depends on MTD
+	help
+	  This driver provides an MTD interface to Atmel's DataFlash.
+	  It probes the device to see what size chip is present.
+	  Some MCUs can boot directly from DataFlash.
+
+config SPI_EEPROM
+	tristate "EEPROM -- sysfs support"
+	depends on SYSFS
+	help
+	  This provides a read/write "eeprom" file in sysfs for the
+	  specified device.  Platform data identifies the EEPROM type.
+
+config SPI_ETHERNET
+	tristate "Ethernet Master"
+	depends on NET
+	help
+	  Uses SPI to exchange Ethernet packets with some SPI
+	  protocol slave.  No Ethernet adapter hardware is used.
+
+config SPI_FLASH
+	tristate "FLASH -- MTD support"
+	depends on MTD
+	help
+	  This provides an MTD interface to SPI flash chips like the
+	  AT25 or M25 series.  Platform data identifies the FLASH type.
+
+config SPI_M41T94
+	tristate "M41T94 RTC/WDT support"
+	help
+	  This supports the ST M41T94 chips, providing the conventional
+	  miscdev files for the real-time clock and watchdog timer.
+
+config SPI_MCP320x
+	tristate "MPC 320x ADC support"
+	help
+	  These are multi-channel 12-bit A/D converters with sample-and-hold.
+
+config SPI_TC77
+	tristate "TC77 temperature sensor"
+	depends on SENSORS
+	help
+	  This is a 12-bit (plus sign) temperature sensor.
+
+config SPI_TSC2101
+	tristate "TSC 2101 touchscreen, sensors, and audio"
+	help
+	  This chip has touchscreen, voltage, and temperature sensors
+	  along with audio i/O for microphone, headphone, and speaker.
+	  The driver packages the touchscreen as an input device,
+	  publishes the sensor values in sysfs, and packages the audio
+	  through the ALSA driver stack.
+
+# USB:  n9604_udc, cy7c67200_hcd, ...
+
+#
+# Add new SPI protocol masters in alphabetical order above this line
+#
+
+endif # "SPI Master Implementations"
+
+
+#
+# SLAVE
+#
+comment "No SPI slave hardware is available."
+	depends on SPI && !SPI_ARCH_HAS_SLAVE
+
+menuconfig SPI_SLAVE
+	boolean "SPI Slave support"
+	depends on SPI && SPI_ARCH_HAS_SLAVE
+
+if SPI_SLAVE
+
+comment "SPI Slave Controller Drivers"
+
+config SPI_AT91_SLAVE
+	tristate "AT91 as SPI slave"
+	depends on ARCH_AT91
+	help
+	  This implements SPI slave mode using an SPI controller.
+
+config SPI_OMAP_SLAVE
+	tristate "OMAP SPI controller as slave"
+	depends on ARCH_OMAP
+	help
+	  This implements SPI slave mode using the dedicated SPI
+	  controller.
+
+config SPI_OMAP_MCBSP_SLAVE
+	tristate "OMAP MCBSP as SPI slave"
+	depends on ARCH_OMAP
+	help
+	  This implements slave mode SPI using a McBSP controller.
+
+config SPI_PXA_SSP_SLAVE
+	tristate "PXA SSP controller as SPI slave"
+	depends on ARCH_PXA
+	help
+	  This implements SPI slave mode using an SSP controller.
+
+config SPI_PXA_NSSP_SLAVE
+	tristate "PXA NSSP (or ASSP) controller as SPI slave"
+	depends on ARCH_PXA
+	help
+	  This implements SPI slave mode using the NSSP controller, which
+	  is available with PXA 255 and PXA 26x processors.
+
+#
+# Add new SPI slave controllers in alphabetical order above this line
+#
+
+
+comment "SPI Protocol Slaves"
+
+config SPI_ETHERNET_SLAVE
+	tristate "Ethernet Slave"
+	depends on NET
+	help
+	  Uses SPI to exchange Ethernet packets with some SPI
+	  protocol master.
+
+#
+# Add new SPI protocol slaves in alphabetical order above this line
+#
+
+endif # "SPI Slave Implementations"
+
+endmenu # "SPI support"
+
--- g26.orig/drivers/Kconfig	2005-08-27 01:55:10.000000000 -0700
+++ g26/drivers/Kconfig	2005-08-29 16:00:38.000000000 -0700
@@ -58,6 +58,8 @@ source "drivers/usb/Kconfig"
 
 source "drivers/mmc/Kconfig"
 
+source "drivers/spi/Kconfig"
+
 source "drivers/infiniband/Kconfig"
 
 source "drivers/sn/Kconfig"
--- g26.orig/arch/arm/Kconfig	2005-08-23 23:48:00.000000000 -0700
+++ g26/arch/arm/Kconfig	2005-08-29 16:05:50.000000000 -0700
@@ -762,6 +762,8 @@ source "drivers/usb/Kconfig"
 
 source "drivers/mmc/Kconfig"
 
+source "drivers/spi/Kconfig"
+
 endmenu
 
 source "fs/Kconfig"
--- g26.orig/drivers/Makefile	2005-08-29 15:51:01.000000000 -0700
+++ g26/drivers/Makefile	2005-08-29 16:00:38.000000000 -0700
@@ -61,6 +61,7 @@ obj-$(CONFIG_MCA)		+= mca/
 obj-$(CONFIG_EISA)		+= eisa/
 obj-$(CONFIG_CPU_FREQ)		+= cpufreq/
 obj-$(CONFIG_MMC)		+= mmc/
+obj-$(CONFIG_SPI)		+= spi/
 obj-$(CONFIG_INFINIBAND)	+= infiniband/
 obj-$(CONFIG_SGI_IOC4)		+= sn/
 obj-y				+= firmware/
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ g26/drivers/spi/Makefile	2005-08-29 16:00:38.000000000 -0700
@@ -0,0 +1,32 @@
+#
+# Makefile for kernel SPI drivers.
+#
+
+ifeq ($(CONFIG_SPI_DEBUG),y)
+EXTRA_CFLAGS += -DDEBUG
+endif
+
+# small core, mostly translating board-specific
+# config declarations into driver model code
+obj-$(CONFIG_SPI_MASTER)		+= spi_init.o
+
+
+# SPI master controller drivers (bus)
+obj-$(CONFIG_SPI_BITBANG)		+= spi_bitbang.o
+#obj-$(CONFIG_SPI_OMAP)			+= omap_spi.o
+#obj-$(CONFIG_SPI_OMAP_MMC)		+= omap_spi_mmc.o
+#obj-$(CONFIG_SPI_PXA_SSP)		+= pxa_ssp.o
+#obj-$(CONFIG_SPI_PXA_MMC)		+= pxa_spi_mmc.o
+
+# SPI protocol drivers (device/link on bus)
+# obj-$(CONFIG_SPI_DATAFLASH)		+= dataflash.o
+# obj-$(CONFIG_SPI_EEPROM)		+= at25c.o
+# obj-$(CONFIG_SPI_ETHERNET)		+= spi_ether.o
+
+
+# SPI slave controller drivers (upstream link)
+obj-$(CONFIG_SPI_OMAP_SLAVE)		+= omap_spi_slave.o
+obj-$(CONFIG_SPI_PXA_SSP_SLAVE)		+= pxa_ssp_slave.o
+
+# SPI slave drivers (protocol for that link)
+# obj-$(CONFIG_SPI_ETHERNET_SLAVE)	+= spi_ether_slave.o

Re: SPI redux ... driver model support

[Mark Underwood]

--- David Brownell <david-b@pacbell.net> wrote:

> The last couple times SPI frameworks came up here,
> some of the feedback
> included "make it use the driver model properly;
> don't be like I2C".
> 
> In hopes that it'll be useful, here's a small SPI
> core with driver model
> support driven from board-specific tables listing
> devices.  I expect the
> I/O call(s) could stand to change; but at least this
> one starts out right,
> based on async I/O.  (There's a synchronous call;
> it's a trivial wrapper.)
> 
>  arch/arm/Kconfig       |    2 
>  drivers/Kconfig        |    2 
>  drivers/Makefile       |    1 
>  drivers/spi/Kconfig    |  302
> +++++++++++++++++++++++++++++++++++++++++++++
>  drivers/spi/Makefile   |   32 ++++
>  drivers/spi/spi_init.c |  233
> ++++++++++++++++++++++++++++++++++
>  include/linux/spi.h    |  179
> ++++++++++++++++++++++++++
>  7 files changed, 751 insertions(+)
> 
> Here's one instance of the sysfs "spi_host" class:
> 
> 	[root@argon sys]# cd /sys/class
> 	[root@argon class]# ls
> 	i2c-adapter/   misc/          pcmcia_socket/
> spi_host/      usb_host/
> 	input/         mtd/           scsi_device/   tty/  
>         vc/
> 	mem/           net/           scsi_host/     usb/
> 	[root@argon class]# ls spi_host
> 	spi2/
> 	[root@argon class]# ls -l spi_host/spi2
> 	drwxr-xr-x    2 root     root            0 Aug 29
> 18:46 ./
> 	drwxr-xr-x    3 root     root            0 Dec 31 
> 1969 ../
> 	lrwxrwxrwx    1 root     root            0 Aug 29
> 18:46 device ->
> ../../../devices/platform/omap-uwire/
> 	[root@argon class]#
> 
> Here are the real sysfs objects for that host and
> its single child
> (on chipselect 0).  Notice that the device exists,
> but is waiting for
> driver-modelized ads7846 support (touchscreen and
> other sensors):
> 
> 	[root@argon class]# cd
> /sys/devices/platform/omap-uwire
> 	[root@argon omap-uwire]# ls
> 	bus@            driver@         power/         
> spi2.0-ads7846/
> 	[root@argon omap-uwire]# ls -l spi*
> 	lrwxrwxrwx    1 root     root            0 Aug 29
> 18:46 bus -> ../../../../bus/spi/
> 	-r--r--r--    1 root     root         4096 Aug 29
> 18:46 modalias
> 	drwxr-xr-x    2 root     root            0 Aug 29
> 18:46 power/
> 	[root@argon omap-uwire]# cat spi*/modalias
> 	ads7846
> 	[root@argon omap-uwire]#
> 
> For your viewing pleasure, and without the broadast
> flag that would
> prevent further redistribution, a patch is appended.
> 
> - Dave
> 
> 
> -----------------------------------------	SNIP!!
> This is the start of a small SPI framework that
> started fresh, so it
> doesn't continue the "i2c driver model mess".

-= snip =-

Well I guess great minds think alike ;-). After
looking though my SPI core layer I released that it in
no way reflected the new driver model (not surprising
as it was a copy of i2c-core.c) and I would probably
get laughed off the kernel mailing list if I sent it
as was ;-).  
I am now writing a new spi-core.c which uses the new
driver model.

For registering an adapter:
1) Register an adapter that has a cs table showing
where devices sit on the adapter.
2) This causes spi-core to enumerate the devices on
the cs table and register them.

For un-registering an adapter:
1) Unregister an adapter
2) This causes spi-core to remove all the children of
the adapter

I have a test adapter and a couple of test devices and
am currently debugging a usage count problem. I will
send a patch once I have a working system.

Mark




		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Re: SPI redux ... driver model support

[David Brownell]

> Date: Wed, 31 Aug 2005 08:59:44 +0100 (BST)
> From: Mark Underwood <basicmark@yahoo.com>
>
> --- David Brownell wrote:
>
> > The last couple times SPI frameworks came up here, some of the feedback
> > included "make it use the driver model properly; don't be like I2C".
> > 
> > In hopes that it'll be useful, here's a small SPI core with driver model
> > support driven from board-specific tables listing devices.  I expect the
> > I/O call(s) could stand to change; but at least this one starts out right,
> > based on async I/O.  (There's a synchronous call; it's a trivial wrapper.)
> > 
> > 	...
>
> Well I guess great minds think alike ;-). After
> looking though my SPI core layer I released that it in
> no way reflected the new driver model (not surprising
> as it was a copy of i2c-core.c) and I would probably
> get laughed off the kernel mailing list if I sent it
> as was ;-).  

That usually doesn't happen.  You'd just be told "make it use the driver
model properly; don't be like I2C."  Though maybe there'd be a fiew
other criticisms mixed in.  :)


> I am now writing a new spi-core.c which uses the new
> driver model.

How about just merging the code I sent?  It's not large, and it solves
that problem.  I don't much care about the I/O model issues quite yet,
though requirements for quick sensor captures (RPC-ish) would seem
different from ones like reading bulk SPI flash data.


> For registering an adapter:
> 1) Register an adapter that has a cs table showing
> where devices sit on the adapter.

But how is the adapter driver itself supposed to know that?

That's what I addressed with my patch:  the need for the config tables
to be **independent** of controller (and protocol) code.  It decouples
all the board-specific tables from the drivers.

(Example shown below.)

The nightmare to avoid is this:  EVERY time someone adds a new
SPI-equipped board, working/debugged/stable drivers need to change,
because the board-specific config data was never separated from the
drivers.  (And we know it can be, as shown in the patch I posted...)

Ideally adding a new board means adding a source file for just that one
board, with the relevent implementation parameters.  Only when hardware
guys do something funky should any driver need to change.


> 2) This causes spi-core to enumerate the devices on
> the cs table and register them.
>
> For un-registering an adapter:
> 1) Unregister an adapter
> 2) This causes spi-core to remove all the children of
> the adapter

Right, that's all exactly as in the patch I posted, though I punted
on the "unregister" path -- an exercise for the reader! -- because I
wanted to focus on (a) the driver model structure, like where things
land in sysfs, and (b) how to keep board-specific initialization code
out of controller and protocol drivers.

- Dave


--- o26.orig/arch/arm/mach-omap1/board-osk.c	2005-08-27 02:11:45.000000000 -0700
+++ o26/arch/arm/mach-omap1/board-osk.c	2005-08-27 18:44:20.000000000 -0700
@@ -193,6 +193,34 @@ static struct omap_board_config_kernel o
 
 #ifdef	CONFIG_OMAP_OSK_MISTRAL
 
+#include <linux/spi.h>
+
+struct ads7864_info {		/* FIXME put in standard header */
+	u16	pen_irq, busy;		/* GPIO lines */
+	u16	x_ohms, y_ohms;
+};
+
+static struct ads7864_info mistral_ts_info = {
+	.pen_irq	= OMAP_GPIO_IRQ(4),
+	.busy		= /* GPIO */ 6,
+	.x_ohms		= 419,
+	.y_ohms		= 486,
+};
+
+static const struct spi_board_info mistral_boardinfo[] = {
+{
+	/* MicroWire CS0 has an ads7846e with touchscreen and
+	 * other sensors.  It's currently glued into some OMAP
+	 * touchscreen support that ignores the driver model.
+	 */
+	.driver_name	= "ads7846",
+	.platform_data	= &mistral_ts_info,
+	.max_speed_hz	= 2000000,
+	.bus_num	= 2, 		/* spi2 == microwire */
+	.chip_select	= 0,
+},
+};
+
 #ifdef	CONFIG_PM
 static irqreturn_t
 osk_mistral_wake_interrupt(int irq, void *ignored, struct pt_regs *regs)
@@ -211,6 +239,9 @@ static void __init osk_mistral_init(void
 	 * But this is too early for that...
 	 */
 
+	spi_register_board_info(mistral_boardinfo,
+			ARRAY_SIZE(mistral_boardinfo));
+
 	/* the sideways button (SW1) is for use as a "wakeup" button */
 	omap_cfg_reg(N15_1610_MPUIO2);
 	if (omap_request_gpio(OMAP_MPUIO(2)) == 0) {

Re: SPI redux ... driver model support

[Mark Underwood]

--- David Brownell <david-b@pacbell.net> wrote:

> > Date: Wed, 31 Aug 2005 08:59:44 +0100 (BST)
> > From: Mark Underwood <basicmark@yahoo.com>
> >
> > --- David Brownell wrote:
> >
> > > The last couple times SPI frameworks came up
> here, some of the feedback
> > > included "make it use the driver model properly;
> don't be like I2C".
> > > 
> > > In hopes that it'll be useful, here's a small
> SPI core with driver model
> > > support driven from board-specific tables
> listing devices.  I expect the
> > > I/O call(s) could stand to change; but at least
> this one starts out right,
> > > based on async I/O.  (There's a synchronous
> call; it's a trivial wrapper.)
> > > 
> > > 	...
> >
> > Well I guess great minds think alike ;-). After
> > looking though my SPI core layer I released that
> it in
> > no way reflected the new driver model (not
> surprising
> > as it was a copy of i2c-core.c) and I would
> probably
> > get laughed off the kernel mailing list if I sent
> it
> > as was ;-).  
> 
> That usually doesn't happen.  You'd just be told
> "make it use the driver
> model properly; don't be like I2C."  Though maybe
> there'd be a fiew
> other criticisms mixed in.  :)
> 
> 
> > I am now writing a new spi-core.c which uses the
> new
> > driver model.
> 
> How about just merging the code I sent?  It's not
> large, and it solves
> that problem.  I don't much care about the I/O model
> issues quite yet,
> though requirements for quick sensor captures
> (RPC-ish) would seem
> different from ones like reading bulk SPI flash
> data.
> 
> 
> > For registering an adapter:
> > 1) Register an adapter that has a cs table showing
> > where devices sit on the adapter.
> 
> But how is the adapter driver itself supposed to
> know that?

It gets passed the cs table as part of its platform
data.

> 
> That's what I addressed with my patch:  the need for
> the config tables
> to be **independent** of controller (and protocol)
> code.  It decouples
> all the board-specific tables from the drivers.
> 
> (Example shown below.)
> 
> The nightmare to avoid is this:  EVERY time someone
> adds a new
> SPI-equipped board, working/debugged/stable drivers
> need to change,
> because the board-specific config data was never
> separated from the
> drivers.  (And we know it can be, as shown in the
> patch I posted...)

Now I've fixed my version I'll have a more detailed
look.

> 
> Ideally adding a new board means adding a source
> file for just that one
> board, with the relevent implementation parameters. 
> Only when hardware
> guys do something funky should any driver need to
> change.
> 

That's what happens in my SPI subsystem. The adapter
driver only knows how the driver the adapter. When a
adapter gets probed it has platform data passed to it
which contains a pointer to the cs table, the number
of entry’s in the cs table and the pointer to a
function to control some GPIO(s) as cs for adapters
that don’t have any built in.

> 
> > 2) This causes spi-core to enumerate the devices
> on
> > the cs table and register them.
> >
> > For un-registering an adapter:
> > 1) Unregister an adapter
> > 2) This causes spi-core to remove all the children
> of
> > the adapter
> 
> Right, that's all exactly as in the patch I posted,
> though I punted
> on the "unregister" path -- an exercise for the
> reader! -- because I
> wanted to focus on (a) the driver model structure,
> like where things
> land in sysfs, and (b) how to keep board-specific
> initialization code
> out of controller and protocol drivers.

OK. If you want I could do the same, that is send the
un/registration and sysfs code before I put the
transfer methods in. I have some dummy devices so you
can see what happens in sysfs.

> 
> - Dave
> 
> 
> --- o26.orig/arch/arm/mach-omap1/board-osk.c
> 2005-08-27 02:11:45.000000000 -0700
> +++ o26/arch/arm/mach-omap1/board-osk.c	2005-08-27
> 18:44:20.000000000 -0700
> @@ -193,6 +193,34 @@ static struct
> omap_board_config_kernel o
>  
>  #ifdef	CONFIG_OMAP_OSK_MISTRAL
>  
> +#include <linux/spi.h>
> +
> +struct ads7864_info {		/* FIXME put in standard
> header */
> +	u16	pen_irq, busy;		/* GPIO lines */
> +	u16	x_ohms, y_ohms;
> +};
> +
> +static struct ads7864_info mistral_ts_info = {
> +	.pen_irq	= OMAP_GPIO_IRQ(4),
> +	.busy		= /* GPIO */ 6,
> +	.x_ohms		= 419,
> +	.y_ohms		= 486,
> +};
> +
> +static const struct spi_board_info
> mistral_boardinfo[] = {
> +{
> +	/* MicroWire CS0 has an ads7846e with touchscreen
> and
> +	 * other sensors.  It's currently glued into some
> OMAP
> +	 * touchscreen support that ignores the driver
> model.
> +	 */
> +	.driver_name	= "ads7846",
> +	.platform_data	= &mistral_ts_info,
> +	.max_speed_hz	= 2000000,
> +	.bus_num	= 2, 		/* spi2 == microwire */

I did think about doing this but the problem is how do
you know bus 2 is the bus you think it is? This would
work for SPI adapters that are platform devices, but
what about hot-plug devices like PCI and USB (we are
thinking of actually making a USB to SPI converter so
customers can try out some of our SPI devices on a PC
:).

Mark

> +	.chip_select	= 0,
> +},
> +};
> +
>  #ifdef	CONFIG_PM
>  static irqreturn_t
>  osk_mistral_wake_interrupt(int irq, void *ignored,
> struct pt_regs *regs)
> @@ -211,6 +239,9 @@ static void __init
> osk_mistral_init(void
>  	 * But this is too early for that...
>  	 */
>  
> +	spi_register_board_info(mistral_boardinfo,
> +			ARRAY_SIZE(mistral_boardinfo));
> +
>  	/* the sideways button (SW1) is for use as a
> "wakeup" button */
>  	omap_cfg_reg(N15_1610_MPUIO2);
>  	if (omap_request_gpio(OMAP_MPUIO(2)) == 0) {
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Re: SPI redux ... driver model support

[Leeds United Fan]

Hi Mark,
you've mentioned the code that you're working on several times, but no 
one in LKML has ever seen a single line of code from you. Will you 
please be so kind to share a piece of you SPI subsystem?

TIA!

Mark Underwood wrote:

>--- David Brownell <david-b@pacbell.net> wrote:
>
>  
>
>>>Date: Wed, 31 Aug 2005 08:59:44 +0100 (BST)
>>>From: Mark Underwood <basicmark@yahoo.com>
>>>
>>>--- David Brownell wrote:
>>>
>>>      
>>>
>>>>The last couple times SPI frameworks came up
>>>>        
>>>>
>>here, some of the feedback
>>    
>>
>>>>included "make it use the driver model properly;
>>>>        
>>>>
>>don't be like I2C".
>>    
>>
>>>>In hopes that it'll be useful, here's a small
>>>>        
>>>>
>>SPI core with driver model
>>    
>>
>>>>support driven from board-specific tables
>>>>        
>>>>
>>listing devices.  I expect the
>>    
>>
>>>>I/O call(s) could stand to change; but at least
>>>>        
>>>>
>>this one starts out right,
>>    
>>
>>>>based on async I/O.  (There's a synchronous
>>>>        
>>>>
>>call; it's a trivial wrapper.)
>>    
>>
>>>>	...
>>>>        
>>>>
>>>Well I guess great minds think alike ;-). After
>>>looking though my SPI core layer I released that
>>>      
>>>
>>it in
>>    
>>
>>>no way reflected the new driver model (not
>>>      
>>>
>>surprising
>>    
>>
>>>as it was a copy of i2c-core.c) and I would
>>>      
>>>
>>probably
>>    
>>
>>>get laughed off the kernel mailing list if I sent
>>>      
>>>
>>it
>>    
>>
>>>as was ;-).  
>>>      
>>>
>>That usually doesn't happen.  You'd just be told
>>"make it use the driver
>>model properly; don't be like I2C."  Though maybe
>>there'd be a fiew
>>other criticisms mixed in.  :)
>>
>>
>>    
>>
>>>I am now writing a new spi-core.c which uses the
>>>      
>>>
>>new
>>    
>>
>>>driver model.
>>>      
>>>
>>How about just merging the code I sent?  It's not
>>large, and it solves
>>that problem.  I don't much care about the I/O model
>>issues quite yet,
>>though requirements for quick sensor captures
>>(RPC-ish) would seem
>>different from ones like reading bulk SPI flash
>>data.
>>
>>
>>    
>>
>>>For registering an adapter:
>>>1) Register an adapter that has a cs table showing
>>>where devices sit on the adapter.
>>>      
>>>
>>But how is the adapter driver itself supposed to
>>know that?
>>    
>>
>
>It gets passed the cs table as part of its platform
>data.
>
>  
>
>>That's what I addressed with my patch:  the need for
>>the config tables
>>to be **independent** of controller (and protocol)
>>code.  It decouples
>>all the board-specific tables from the drivers.
>>
>>(Example shown below.)
>>
>>The nightmare to avoid is this:  EVERY time someone
>>adds a new
>>SPI-equipped board, working/debugged/stable drivers
>>need to change,
>>because the board-specific config data was never
>>separated from the
>>drivers.  (And we know it can be, as shown in the
>>patch I posted...)
>>    
>>
>
>Now I've fixed my version I'll have a more detailed
>look.
>
>  
>
>>Ideally adding a new board means adding a source
>>file for just that one
>>board, with the relevent implementation parameters. 
>>Only when hardware
>>guys do something funky should any driver need to
>>change.
>>
>>    
>>
>
>That's what happens in my SPI subsystem. The adapter
>driver only knows how the driver the adapter. When a
>adapter gets probed it has platform data passed to it
>which contains a pointer to the cs table, the number
>of entry▓s in the cs table and the pointer to a
>function to control some GPIO(s) as cs for adapters
>that don▓t have any built in.
>
>  
>
>>>2) This causes spi-core to enumerate the devices
>>>      
>>>
>>on
>>    
>>
>>>the cs table and register them.
>>>
>>>For un-registering an adapter:
>>>1) Unregister an adapter
>>>2) This causes spi-core to remove all the children
>>>      
>>>
>>of
>>    
>>
>>>the adapter
>>>      
>>>
>>Right, that's all exactly as in the patch I posted,
>>though I punted
>>on the "unregister" path -- an exercise for the
>>reader! -- because I
>>wanted to focus on (a) the driver model structure,
>>like where things
>>land in sysfs, and (b) how to keep board-specific
>>initialization code
>>out of controller and protocol drivers.
>>    
>>
>
>OK. If you want I could do the same, that is send the
>un/registration and sysfs code before I put the
>transfer methods in. I have some dummy devices so you
>can see what happens in sysfs.
>
>  
>
>>- Dave
>>
>>
>>--- o26.orig/arch/arm/mach-omap1/board-osk.c
>>2005-08-27 02:11:45.000000000 -0700
>>+++ o26/arch/arm/mach-omap1/board-osk.c	2005-08-27
>>18:44:20.000000000 -0700
>>@@ -193,6 +193,34 @@ static struct
>>omap_board_config_kernel o
>> 
>> #ifdef	CONFIG_OMAP_OSK_MISTRAL
>> 
>>+#include <linux/spi.h>
>>+
>>+struct ads7864_info {		/* FIXME put in standard
>>header */
>>+	u16	pen_irq, busy;		/* GPIO lines */
>>+	u16	x_ohms, y_ohms;
>>+};
>>+
>>+static struct ads7864_info mistral_ts_info = {
>>+	.pen_irq	= OMAP_GPIO_IRQ(4),
>>+	.busy		= /* GPIO */ 6,
>>+	.x_ohms		= 419,
>>+	.y_ohms		= 486,
>>+};
>>+
>>+static const struct spi_board_info
>>mistral_boardinfo[] = {
>>+{
>>+	/* MicroWire CS0 has an ads7846e with touchscreen
>>and
>>+	 * other sensors.  It's currently glued into some
>>OMAP
>>+	 * touchscreen support that ignores the driver
>>model.
>>+	 */
>>+	.driver_name	= "ads7846",
>>+	.platform_data	= &mistral_ts_info,
>>+	.max_speed_hz	= 2000000,
>>+	.bus_num	= 2, 		/* spi2 == microwire */
>>    
>>
>
>I did think about doing this but the problem is how do
>you know bus 2 is the bus you think it is? This would
>work for SPI adapters that are platform devices, but
>what about hot-plug devices like PCI and USB (we are
>thinking of actually making a USB to SPI converter so
>customers can try out some of our SPI devices on a PC
>:).
>
>Mark
>
>  
>
>>+	.chip_select	= 0,
>>+},
>>+};
>>+
>> #ifdef	CONFIG_PM
>> static irqreturn_t
>> osk_mistral_wake_interrupt(int irq, void *ignored,
>>struct pt_regs *regs)
>>@@ -211,6 +239,9 @@ static void __init
>>osk_mistral_init(void
>> 	 * But this is too early for that...
>> 	 */
>> 
>>+	spi_register_board_info(mistral_boardinfo,
>>+			ARRAY_SIZE(mistral_boardinfo));
>>+
>> 	/* the sideways button (SW1) is for use as a
>>"wakeup" button */
>> 	omap_cfg_reg(N15_1610_MPUIO2);
>> 	if (omap_request_gpio(OMAP_MPUIO(2)) == 0) {
>>-
>>To unsubscribe from this list: send the line
>>"unsubscribe linux-kernel" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at 
>>http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at  http://www.tux.org/lkml/
>>
>>    
>>
>
>
>
>	
>	
>		
>___________________________________________________________ 
>Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>
>  
>

Re: SPI redux ... driver model support

[David Brownell]

> > @@ -193,6 +193,34 @@
> >  
> >  #ifdef	CONFIG_OMAP_OSK_MISTRAL
> >  
> > +#include <linux/spi.h>
> > +
> > +struct ads7864_info {		/* FIXME put in standard header */
> > +	u16	pen_irq, busy;		/* GPIO lines */
> > +	u16	x_ohms, y_ohms;
> > +};
> > +
> > +static struct ads7864_info mistral_ts_info = {
> > +	.pen_irq	= OMAP_GPIO_IRQ(4),
> > +	.busy		= /* GPIO */ 6,
> > +	.x_ohms		= 419,
> > +	.y_ohms		= 486,
> > +};
> > +
> > +static const struct spi_board_info mistral_boardinfo[] = {
> > +{
> > +	/* MicroWire CS0 has an ads7846e with touchscreen and
> > +	 * other sensors.  It's currently glued into some OMAP
> > +	 * touchscreen support that ignores the driver model.
> > +	 */
> > +	.driver_name	= "ads7846",
> > +	.platform_data	= &mistral_ts_info,
> > +	.max_speed_hz	= 2000000,
> > +	.bus_num	= 2, 		/* spi2 == microwire */
>
> I did think about doing this but the problem is how do
> you know bus 2 is the bus you think it is?

The numbering is board-specific, but in most cases that can be simplified
to being SOC-specific.  In this case I numbered the SPI-capable controllers
(from 1..7, not included in this patch) and this one came out "2".  The
consistency matters, not the actual (nonzero) numbers.

Hotpluggable SPI controllers are not common, but that's where that sysfs
API to define new devices would really hit the spot.  That would be how the
kernel learns about "struct spi_board_info" structures associated with some
dynamically assigned bus_num.  Likely some convention for dynamically
assigned IDs would help, like "they're all negative".

(What I've seen a bit more often is that expansion cards will be wired
for SPI, so the thing that's vaguely hotplug-ish is that once you know
what card's hooked up, you'll know the SPI devices it has.  Then the
question is how to tell the kernel about them ... same solution, which
again must work without hardware probing.)


>		This would
> work for SPI adapters that are platform devices, but
> what about hot-plug devices like PCI and USB (we are
> thinking of actually making a USB to SPI converter so
> customers can try out some of our SPI devices on a PC

Some of the microcontrollers that talk both USB (slave) and SPI (master)
will even run Linux for you.  :)

- Dave

Re: SPI redux ... driver model support

[Mark Underwood]

--- David Brownell <david-b@pacbell.net> wrote:

> > > @@ -193,6 +193,34 @@
> > >  
> > >  #ifdef	CONFIG_OMAP_OSK_MISTRAL
> > >  
> > > +#include <linux/spi.h>
> > > +
> > > +struct ads7864_info {		/* FIXME put in standard
> header */
> > > +	u16	pen_irq, busy;		/* GPIO lines */
> > > +	u16	x_ohms, y_ohms;
> > > +};
> > > +
> > > +static struct ads7864_info mistral_ts_info = {
> > > +	.pen_irq	= OMAP_GPIO_IRQ(4),
> > > +	.busy		= /* GPIO */ 6,
> > > +	.x_ohms		= 419,
> > > +	.y_ohms		= 486,
> > > +};
> > > +
> > > +static const struct spi_board_info
> mistral_boardinfo[] = {
> > > +{
> > > +	/* MicroWire CS0 has an ads7846e with
> touchscreen and
> > > +	 * other sensors.  It's currently glued into
> some OMAP
> > > +	 * touchscreen support that ignores the driver
> model.
> > > +	 */
> > > +	.driver_name	= "ads7846",
> > > +	.platform_data	= &mistral_ts_info,
> > > +	.max_speed_hz	= 2000000,
> > > +	.bus_num	= 2, 		/* spi2 == microwire */
> >
> > I did think about doing this but the problem is
> how do
> > you know bus 2 is the bus you think it is?
> 
> The numbering is board-specific, but in most cases
> that can be simplified
> to being SOC-specific.  In this case I numbered the
> SPI-capable controllers
> (from 1..7, not included in this patch) and this one
> came out "2".  The
> consistency matters, not the actual (nonzero)
> numbers.
> 
> Hotpluggable SPI controllers are not common, but
> that's where that sysfs
> API to define new devices would really hit the spot.
>  That would be how the
> kernel learns about "struct spi_board_info"
> structures associated with some
> dynamically assigned bus_num.  Likely some
> convention for dynamically
> assigned IDs would help, like "they're all
> negative".
> 
> (What I've seen a bit more often is that expansion
> cards will be wired
> for SPI, so the thing that's vaguely hotplug-ish is
> that once you know
> what card's hooked up, you'll know the SPI devices
> it has.  Then the
> question is how to tell the kernel about them ...
> same solution, which
> again must work without hardware probing.)
> 

This is why I decided to pass the cs table as platform
data when an adapter is registered. This way you don't
have to try to find out an adapters bus number as the
adapter has the cs table in it, but because it was
passed in as platform data it still abstracts that
from the adapter driver. Simple, yet effective :)

Have you looked at the patch which I sent?
http://www.ussg.iu.edu/hypermail/linux/kernel/0509.0/0817.html

I would appreciate any comments on this approach.

> 
> >		This would
> > work for SPI adapters that are platform devices,
> but
> > what about hot-plug devices like PCI and USB (we
> are
> > thinking of actually making a USB to SPI converter
> so
> > customers can try out some of our SPI devices on a
> PC
> 
> Some of the microcontrollers that talk both USB
> (slave) and SPI (master)
> will even run Linux for you.  :)

Yes, but not on a 8051 bassed Cypress USB chip ;)

> 
> - Dave
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Re: SPI redux ... driver model support

[David Brownell]

> > > I did think about doing this but the problem is how do
> > > you know bus 2 is the bus you think it is?
> > 
> > The numbering is board-specific, but in most cases
> > that can be simplified to being SOC-specific.  ...
> > 
> > Hotpluggable SPI controllers are not common, but
> > that's where that sysfs API to define new devices
> > would really hit the spot. ...
> > 
> > (What I've seen a bit more often is that expansion
> > cards will be wired for SPI, so the thing that's
> > vaguely hotplug-ish is that once you know what
> > card's hooked up, you'll know the SPI devices it
> > has.  Then the question is how to tell the kernel
> > about them ...  same solution, which again must work
> > without hardware probing.)
>
> This is why I decided to pass the cs table as platform
> data when an adapter is registered. This way you don't
> have to try to find out an adapters bus number as the
> adapter has the cs table in it, but because it was
> passed in as platform data it still abstracts that
> from the adapter driver. Simple, yet effective :)

Except that it doesn't work in that primary case, where the SPI devices
are physically decoupled from any given SPI (master) controller.
One expansion card uses CS1 for a touchscreen; another uses CS3 for
SPI flash ... the same "cs table" can't handle both configurations.
It's got to be segmented, with devices separated from controllers.

Plus, that depends on standardizing platform_data between platforms.
That's really not the model for platform_data!  And "struct clk" is
ARM-only for now, too ... 


> Have you looked at the patch which I sent?
> http://www.ussg.iu.edu/hypermail/linux/kernel/0509.0/0817.html
>
> I would appreciate any comments on this approach.

Yes, I plan to follow up to that with comments.  As with Dmitry's
proposal, it's modeled closely on I2C, and is in consequence larger
than needed for what it does.

One reason I posted this driver-model-only patch was to highlight how
minimal an SPI core can be if it reuses the driver model core.  I'm
not a fan of much "mid-layer" infrastructure in driver stacks.

- Dave

Re: SPI redux ... driver model support

[Mark Underwood]

--- David Brownell <david-b@pacbell.net> wrote:

> > > > I did think about doing this but the problem
> is how do
> > > > you know bus 2 is the bus you think it is?
> > > 
> > > The numbering is board-specific, but in most
> cases
> > > that can be simplified to being SOC-specific. 
> ...
> > > 
> > > Hotpluggable SPI controllers are not common, but
> > > that's where that sysfs API to define new
> devices
> > > would really hit the spot. ...
> > > 
> > > (What I've seen a bit more often is that
> expansion
> > > cards will be wired for SPI, so the thing that's
> > > vaguely hotplug-ish is that once you know what
> > > card's hooked up, you'll know the SPI devices it
> > > has.  Then the question is how to tell the
> kernel
> > > about them ...  same solution, which again must
> work
> > > without hardware probing.)
> >
> > This is why I decided to pass the cs table as
> platform
> > data when an adapter is registered. This way you
> don't
> > have to try to find out an adapters bus number as
> the
> > adapter has the cs table in it, but because it was
> > passed in as platform data it still abstracts that
> > from the adapter driver. Simple, yet effective :)
> 
> Except that it doesn't work in that primary case,
> where the SPI devices
> are physically decoupled from any given SPI (master)
> controller.
> One expansion card uses CS1 for a touchscreen;
> another uses CS3 for
> SPI flash ... the same "cs table" can't handle both
> configurations.
> It's got to be segmented, with devices separated
> from controllers.

With my subsystem that would look like:

static const struct spi_cs_table
platform_spi1_cs_table[] = {
 {
  .name  = "touchscreen",
  .cs_no  = 1,
  .platform_data = NULL,
  .flags  = SPI_CS_IDLE_HIGH,
  .cs_data = 0,
 },
 {
  .name  = "flash",
  .cs_no  = 3,
  .platform_data = NULL,
  .flags  = SPI_CS_IDLE_HIGH,
  .cs_data = 0,
 },
};

As far as I can see most SPI devices have fixed
wirering to an adapter as SPI is not really a hotplug
bus.
The subsystem does allow you to add extra devices that
aren't in the cs table if you want by calling
spi_device_register in which case you have to setup
the spi_device with the correct information.

> 
> Plus, that depends on standardizing platform_data
> between platforms.
> That's really not the model for platform_data!  And
> "struct clk" is
> ARM-only for now, too ... 

The struct clk should have been removed, I missed it
on that tidy up.
Why not pass platform data through the platform_data
pointer? I have now provided an extra field now which
lets you pass in any other platform data. 

> 
> 
> > Have you looked at the patch which I sent?
> >
>
http://www.ussg.iu.edu/hypermail/linux/kernel/0509.0/0817.html
> >
> > I would appreciate any comments on this approach.
> 
> Yes, I plan to follow up to that with comments.  As
> with Dmitry's
> proposal, it's modeled closely on I2C, and is in
> consequence larger
> than needed for what it does.

I hope not, I spent a long time learning about the
features of the 2.6 driver model. I'm happy to trim
down any fat.

> 
> One reason I posted this driver-model-only patch was
> to highlight how
> minimal an SPI core can be if it reuses the driver
> model core.  I'm
> not a fan of much "mid-layer" infrastructure in
> driver stacks.
> 

This is what my SPI core tries to do. I would like to
make at 'as small as possible and no smaller'

Mark

> - Dave
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


Send instant messages to your online friends http://uk.messenger.yahoo.com 

Re: SPI redux ... driver model support

[David Brownell]

> With my subsystem that would look like:
>
> static const struct spi_cs_table
> platform_spi1_cs_table[] = {
>  {
>   .name  = "touchscreen",
>   .cs_no  = 1,
>   .platform_data = NULL,
>   .flags  = SPI_CS_IDLE_HIGH,
>   .cs_data = 0,
>  },
>  {
>   .name  = "flash",
>   .cs_no  = 3,
>   .platform_data = NULL,
>   .flags  = SPI_CS_IDLE_HIGH,
>   .cs_data = 0,
>  },
> };

The problem scenario was that only one configuration
is valid at a time ... it would have been clearer if
both the add-on boards used CS1, so that device would
be either ads7864 _or_ at25640a, but not both.



> As far as I can see most SPI devices have fixed
> wirering to an adapter as SPI is not really a hotplug
> bus.

That wiring can be through an expansion connector though, which
is what I meant when I wrote that it's "vaguely hotplug-ish".
Example, the mainboard could have some SPI devices hard-wired,
on CS0 and CS2, while each different plugin board might add very
different devices on CS1 and/or CS3.

In any case, you were the one who also wanted to ship sample USB
peripherals that acted as adapters to various SPI chips... so that
bus adapters would really need to hotplug! :)


> The subsystem does allow you to add extra devices that
> aren't in the cs table if you want by calling
> spi_device_register in which case you have to setup
> the spi_device with the correct information.

Right, but as I had explained, the scenario is that the
SPI devices are on some easily-swapped add-on card.
That's a common physical arrangement for small embeddable
boards, because it takes so few wires per device.

Swapping those SPI connectors shouldn't involve changing
the declaration of the controller on the mainboard ...


> > One reason I posted this driver-model-only patch was
> > to highlight how
> > minimal an SPI core can be if it reuses the driver
> > model core.  I'm
> > not a fan of much "mid-layer" infrastructure in
> > driver stacks.
> > 
>
> This is what my SPI core tries to do. I would like to
> make at 'as small as possible and no smaller'

I'll post a refresh of my patch that seems to me to be
a much better match for those goals.  The refresh includes
some tweaks based on what you sent, but it's still just
one KByte of overhead in the target ROM.  :)

- Dave

Re: SPI redux ... driver model support

[Mark Underwood]

--- David Brownell <david-b@pacbell.net> wrote:

> > With my subsystem that would look like:
> >
> > static const struct spi_cs_table
> > platform_spi1_cs_table[] = {
> >  {
> >   .name  = "touchscreen",
> >   .cs_no  = 1,
> >   .platform_data = NULL,
> >   .flags  = SPI_CS_IDLE_HIGH,
> >   .cs_data = 0,
> >  },
> >  {
> >   .name  = "flash",
> >   .cs_no  = 3,
> >   .platform_data = NULL,
> >   .flags  = SPI_CS_IDLE_HIGH,
> >   .cs_data = 0,
> >  },
> > };
> 
> The problem scenario was that only one configuration
> is valid at a time ... it would have been clearer if
> both the add-on boards used CS1, so that device
> would
> be either ads7864 _or_ at25640a, but not both.
> 
> 
> 
> > As far as I can see most SPI devices have fixed
> > wirering to an adapter as SPI is not really a
> hotplug
> > bus.
> 
> That wiring can be through an expansion connector
> though, which
> is what I meant when I wrote that it's "vaguely
> hotplug-ish".
> Example, the mainboard could have some SPI devices
> hard-wired,
> on CS0 and CS2, while each different plugin board
> might add very
> different devices on CS1 and/or CS3.
> 
> In any case, you were the one who also wanted to
> ship sample USB
> peripherals that acted as adapters to various SPI
> chips... so that
> bus adapters would really need to hotplug! :)
>

I see several posabiltiys of how SPI devices could be
connected to an adapter.

1) All SPI devices are hardwired to the adapter. I
think this would be the most common. In this case you
would register a cs table as part of the platform data
of the SPI adapter like in the example platform in my
patch. Note: this is even the case with a PCI or usb
based device as it is the adapter that is hotpluged
and not the SPI devices on that device.

2) Some SPI devices are hardwired and some are
removable. In this case these the hardwired ones would
be put in the cs table and the other SPI devices would
be registered by calling spi_device_register. I would
add a call in my core layer to which you could pass
the bus_id and it would pass back the adapters pointer
to put in the spi_device structure.

3) All SPI devices are removable. An empty cs table
would be used and SPI devices would be registered by
calling spi_device_register.
 
> 
> > The subsystem does allow you to add extra devices
> that
> > aren't in the cs table if you want by calling
> > spi_device_register in which case you have to
> setup
> > the spi_device with the correct information.
> 
> Right, but as I had explained, the scenario is that
> the
> SPI devices are on some easily-swapped add-on card.
> That's a common physical arrangement for small
> embeddable
> boards, because it takes so few wires per device.
> 
> Swapping those SPI connectors shouldn't involve
> changing
> the declaration of the controller on the mainboard
> ...

Your not when you use spi_device_register /
spi_device_unregister. You can register an adapter
with an empty cs table if you don't have any hardwired
SPI devices. When you plug a card in you use
spi_device_register to add that device to the system
and when you remove the card you call
spi_device_unregister. You can then do the same for a
different card and at no time have you changed the
declaration of the controller.

> 
> 
> > > One reason I posted this driver-model-only patch
> was
> > > to highlight how
> > > minimal an SPI core can be if it reuses the
> driver
> > > model core.  I'm
> > > not a fan of much "mid-layer" infrastructure in
> > > driver stacks.
> > > 
> >
> > This is what my SPI core tries to do. I would like
> to
> > make at 'as small as possible and no smaller'
> 
> I'll post a refresh of my patch that seems to me to
> be
> a much better match for those goals.  The refresh
> includes
> some tweaks based on what you sent, but it's still
> just
> one KByte of overhead in the target ROM.  :)

OK. I will post an updated version of my SPI subsystem
within the next few days with the transfer stuff added
and maybe the interrupt and GPO abstraction as well.

I haven't seen any replies to my SPI patch :( did you
reply to it?

Mark

> 
> - Dave
> 
> 



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Re: SPI redux ... driver model support

[David Brownell]

> Date: Wed, 7 Sep 2005 19:38:43 +0100 (BST)
> From: Mark Underwood <basicmark@yahoo.com>
> ...
>
> I see several posabiltiys of how SPI devices could be
> connected to an adapter.

Certainly, and all are addressed cleanly by the kind of
configuration scheme I showed.


> 1) All SPI devices are hardwired to the adapter. I
> think this would be the most common.

For custom hardware, not designed for expansion, yes.  Zaurus Corgi
models, for example, keep three SPI devices busy.

But in that category I'd also include custom hardware that happens to
be packaged by connecting boards, which is also the territory of #2 or
#3 below.  "Hard wired" can include connectors that are removable by
breaking the warranty.  :)


> 2) Some SPI devices are hardwired and some are
> removable.

Development/Evaluation boards -- the reference implementations in most
environments, not just Linux -- seem to all but universally choose this
option (or, more rarely, #3).  There might be some domain-specific chips
hardwired (touchscreen or CAN controller, ADC/DAC, etc), but expansion
connectors WILL expose SPI.

That makes sense; one goal is to support system prototyping, and it's
hard to do that if for any reason one of the major hardware connectivity
options is hard to get at!


> 3) All SPI devices are removable.

This is common for the sort of single board computers that get sold
to run Linux (or whatever) as part of semicustom hardware:  maybe not
much more than a few square inches packed with an SOC CPU, FLASH, RAM,
and expansion connectors providing access to a few dozen SOC peripherals.
(There might be 250 or so SOC pins, with expansion connectors providing
access to some big portion of those pins ... including some for SPI.)

It'd be nice to be able to support those SBCs with a core Linux port,
and then just layer support for addon boards on top of that without
needing to touch a line of arch code.  And convenient for folk who
are adding value through those addons.  :)



> 	 When you plug a card in you use
> spi_device_register to add that device to the system
> and when you remove the card you call
> spi_device_unregister. You can then do the same for a
> different card and at no time have you changed the
> declaration of the controller.

That implies whoever is registering is actually going and creating the
SPI devices ... and doing it AFTER the controller driver is registered.
I actually have issues with each of those implications.

However, I was also aiming to support the model where the controller
drivers are modular, and the "add driver" and "declare hardware" steps
can go in any order.  That way things can work "just like other busses"
when you load the controller drivers ... and the approach is like the
familiar "boot firmware gives hardware description tables to the OS"
approach used by lots of _other_ hardware that probes poorly.  (Except
that Linux is likely taking over lots of that "boot firmware" role.)


> > I'll post a refresh of my patch that seems to me to be
> > a much better match for those goals.  The refresh includes
> > some tweaks based on what you sent, but it's still just
> > one KByte of overhead in the target ROM.  :)

Grr.  I added sysfs attributes and an I/O utility function,
and now it's a bit bigger than 1KByte.  Especially with
debugging enabled, it's nearer 1.5KB.  The curse of actually
trying to hook up to hardware and its quirks.  :(


> OK. I will post an updated version of my SPI subsystem
> within the next few days with the transfer stuff added
> and maybe the interrupt and GPO abstraction as well.

OK.


> I haven't seen any replies to my SPI patch :( did you
> reply to it?

No, I was going to sent it when I sent that refresh; it's helped
focus my thoughts a bit.  :)

Several of the comments (like "get rid of algorithm layer!") you'll have
heard before in response to the RFC from MontaVista.  It seems both
approaches are still trying to make SPI seem like I2C, and not taking
the opportunity to _fix_ very much of the I2C oddness.

- Dave

Re: SPI redux ... driver model support

[Mark Underwood]

--- David Brownell <david-b@pacbell.net> wrote:

> > Date: Wed, 7 Sep 2005 19:38:43 +0100 (BST)
> > From: Mark Underwood <basicmark@yahoo.com>
> > ...
> >
> > I see several posabiltiys of how SPI devices could
> be
> > connected to an adapter.
> 
> Certainly, and all are addressed cleanly by the kind
> of
> configuration scheme I showed.

And by my scheme :)

> 
> 
> > 1) All SPI devices are hardwired to the adapter. I
> > think this would be the most common.
> 
> For custom hardware, not designed for expansion,
> yes.  Zaurus Corgi
> models, for example, keep three SPI devices busy.
> 
> But in that category I'd also include custom
> hardware that happens to
> be packaged by connecting boards, which is also the
> territory of #2 or
> #3 below.  "Hard wired" can include connectors that
> are removable by
> breaking the warranty.  :)
> 
> 
> > 2) Some SPI devices are hardwired and some are
> > removable.
> 
> Development/Evaluation boards -- the reference
> implementations in most
> environments, not just Linux -- seem to all but
> universally choose this
> option (or, more rarely, #3).  There might be some
> domain-specific chips
> hardwired (touchscreen or CAN controller, ADC/DAC,
> etc), but expansion
> connectors WILL expose SPI.
> 
> That makes sense; one goal is to support system
> prototyping, and it's
> hard to do that if for any reason one of the major
> hardware connectivity
> options is hard to get at!
> 
> 
> > 3) All SPI devices are removable.
> 
> This is common for the sort of single board
> computers that get sold
> to run Linux (or whatever) as part of semicustom
> hardware:  maybe not
> much more than a few square inches packed with an
> SOC CPU, FLASH, RAM,
> and expansion connectors providing access to a few
> dozen SOC peripherals.
> (There might be 250 or so SOC pins, with expansion
> connectors providing
> access to some big portion of those pins ...
> including some for SPI.)
> 
> It'd be nice to be able to support those SBCs with a
> core Linux port,
> and then just layer support for addon boards on top
> of that without
> needing to touch a line of arch code.  And
> convenient for folk who
> are adding value through those addons.  :)
> 

And with my subsystem you don't can to change any arch
code, yay again! :)

> 
> 
> > 	 When you plug a card in you use
> > spi_device_register to add that device to the
> system
> > and when you remove the card you call
> > spi_device_unregister. You can then do the same
> for a
> > different card and at no time have you changed the
> > declaration of the controller.
> 
> That implies whoever is registering is actually
> going and creating the
> SPI devices ... and doing it AFTER the controller
> driver is registered.
> I actually have issues with each of those
> implications.

But how can you have a device that has no connection
to the system (i.e. no registered adapter) :(. Why
would you want to add SPI devices to adapters which
aren't yet in the system?

> 
> However, I was also aiming to support the model
> where the controller
> drivers are modular, and the "add driver" and
> "declare hardware" steps
> can go in any order.  That way things can work "just
> like other busses"

My subsystem does that. Once you have registered the
core layer you can add SPI device drivers before or
after registering SPI devices the only restriction is
the you have to register a SPI adapter before
registering any SPI devices which use that adapter. I
think this is sensible as otherwise you have to keep a
list of all SPI devices that have been registered and
didn't have an adapter at that time and go through
this list every time you register an adapter. This
sounds like putting the cart before the horse ;).

> when you load the controller drivers ... and the
> approach is like the
> familiar "boot firmware gives hardware description
> tables to the OS"
> approach used by lots of _other_ hardware that
> probes poorly.  (Except
> that Linux is likely taking over lots of that "boot
> firmware" role.)
> 
> 
> > > I'll post a refresh of my patch that seems to me
> to be
> > > a much better match for those goals.  The
> refresh includes
> > > some tweaks based on what you sent, but it's
> still just
> > > one KByte of overhead in the target ROM.  :)
> 
> Grr.  I added sysfs attributes and an I/O utility
> function,
> and now it's a bit bigger than 1KByte.  Especially
> with
> debugging enabled, it's nearer 1.5KB.  The curse of
> actually
> trying to hook up to hardware and its quirks.  :(
> 

I have built your spi_init.c for an ARM946EJS and I
get a .ko object of 5.1K this compares to my spi_core,
with transfer routines, of 10.6. I think there is
still some fat to trim from my core layer so I might
be able to get it smaller :).

> 
> > OK. I will post an updated version of my SPI
> subsystem
> > within the next few days with the transfer stuff
> added
> > and maybe the interrupt and GPO abstraction as
> well.
> 
> OK.
> 
> 
> > I haven't seen any replies to my SPI patch :( did
> you
> > reply to it?
> 
> No, I was going to sent it when I sent that refresh;
> it's helped
> focus my thoughts a bit.  :)

Glad to help :).

> 
> Several of the comments (like "get rid of algorithm
> layer!") you'll have
> heard before in response to the RFC from MontaVista.
>  It seems both
> approaches are still trying to make SPI seem like
> I2C, and not taking
> the opportunity to _fix_ very much of the I2C
> oddness.

OK. The only reason I had keept the algo layer is for
bitbashing, but thinking about it the pin set/clear
routines could be passed in as platform data. So I'll
remove the lago layer, cheers for the input.

Just to let you know I have been, my testing my
subsystem with a simple eeprom driver and a SPI
network device. So my subsystem is being tested under
heavy loads with transfers in size from 32K to 2
bytes!

Mark

> 
> - Dave
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Re: SPI redux ... driver model support

[David Brownell]

> Date: Fri, 9 Sep 2005 11:33:52 +0100 (BST)
> From: Mark Underwood <basicmark@yahoo.com>
>
> ...
> > That implies whoever is registering is actually
> > going and creating the
> > SPI devices ... and doing it AFTER the controller
> > driver is registered.
> > I actually have issues with each of those
> > implications.
>
> But how can you have a device that has no connection
> to the system (i.e. no registered adapter) :(. Why
> would you want to add SPI devices to adapters which
> aren't yet in the system?

The devices and adapters certainly are in the system;
that's hardware!  Do you maybe mean "before the driver
for an SPI adapter is bound to its device", and are
you maybe talking about driver model data structures?

The thing which exists before the SPI adapter driver is
bound to its device node is just a table.  It lists the
SPI devices, and holds information needed later to set
up the hardware.  Way simpler than ACPI or BIOS tables.


> > However, I was also aiming to support the model
> > where the controller
> > drivers are modular, and the "add driver" and
> > "declare hardware" steps
> > can go in any order.  That way things can work "just
> > like other busses"
>
> My subsystem does that. Once you have registered the
> core layer you can add SPI device drivers before or
> after registering SPI devices the only restriction is
> the you have to register a SPI adapter before
> registering any SPI devices which use that adapter.

That "only restriction" is the one I was talking about!!

It contorts the normal roles and responsiblities of the
adapter drivers; and it's not necessary.


> I think this is sensible as otherwise you have to keep a
> list of all SPI devices that have been registered and
> didn't have an adapter at that time and go through
> this list every time you register an adapter.

Lots of systems have their earliest boot code provide a
table of devices that exist (but which can't be probed).
That's how my patch approaches SPI.

As for that "every time" ... I don't know about you, but
the systems I've seen will register at most a handful of
devices and adapters; and adapters register just once.
For those numbers, even linear search is just fine.


> I have built your spi_init.c for an ARM946EJS and I
> get a .ko object of 5.1K

... but the ".text" size is MUCH less; and what I sent
was not built as a ".so", so there's other oddness too.
I got something on the order of 0x04d0 bytes with the
refresh I just posted (call it 1200 bytes text).

- Dave

Re: SPI redux ... driver model support

[Mark Underwood]

--- David Brownell <david-b@pacbell.net> wrote:

> > Date: Fri, 9 Sep 2005 11:33:52 +0100 (BST)
> > From: Mark Underwood <basicmark@yahoo.com>
> >
> > ...
> > > That implies whoever is registering is actually
> > > going and creating the
> > > SPI devices ... and doing it AFTER the
> controller
> > > driver is registered.
> > > I actually have issues with each of those
> > > implications.
> >
> > But how can you have a device that has no
> connection
> > to the system (i.e. no registered adapter) :(. Why
> > would you want to add SPI devices to adapters
> which
> > aren't yet in the system?
> 
> The devices and adapters certainly are in the
> system;
> that's hardware!  Do you maybe mean "before the
> driver
> for an SPI adapter is bound to its device", and are
> you maybe talking about driver model data
> structures?

Yes

> 
> The thing which exists before the SPI adapter driver
> is
> bound to its device node is just a table.  It lists
> the
> SPI devices, and holds information needed later to
> set
> up the hardware.  Way simpler than ACPI or BIOS
> tables.
> 
> 
> > > However, I was also aiming to support the model
> > > where the controller
> > > drivers are modular, and the "add driver" and
> > > "declare hardware" steps
> > > can go in any order.  That way things can work
> "just
> > > like other busses"
> >
> > My subsystem does that. Once you have registered
> the
> > core layer you can add SPI device drivers before
> or
> > after registering SPI devices the only restriction
> is
> > the you have to register a SPI adapter before
> > registering any SPI devices which use that
> adapter.
> 
> That "only restriction" is the one I was talking
> about!!
> 
> It contorts the normal roles and responsiblities of
> the
> adapter drivers; and it's not necessary.
> 
> 
> > I think this is sensible as otherwise you have to
> keep a
> > list of all SPI devices that have been registered
> and
> > didn't have an adapter at that time and go through
> > this list every time you register an adapter.
> 
> Lots of systems have their earliest boot code
> provide a
> table of devices that exist (but which can't be
> probed).
> That's how my patch approaches SPI.
> 
> As for that "every time" ... I don't know about you,
> but
> the systems I've seen will register at most a
> handful of
> devices and adapters; and adapters register just
> once.
> For those numbers, even linear search is just fine.
> 

OK. Perhaps it's time to lay out the arguments so far
and see where we go from there :).

I want to pass a cs table in as platform data because
it means you don't have to know what bus number the
adapter is (which you can't easily tell for
hotplugable devices) and for most cases I think the
SPI devices will be hardwire to the adapter. This
approach of defining a structure to be used in
platform_data seems to be used by some serial drivers
so I think it's OK, but your not so sure.
How else could I do it? I could use driver_data but
that seems an even worse solution :(.

You want to pass in SPI devices in a table that gets
registered with the subsystem and when the adapter
that they sit on gets registered (known by the bus
number) all the devices in that table get registered
in the core. I like this solution for registering
hotplug'ish devices :), although I would prefer to use
the bus_id then a bus number. This solution doesn't
work very well for hotplug adapters as you don't know
what bus number they will be given (you would have to
do some undefined sysfs magic). 

So how would you feel about the core supporting both
cs tables as platform data and SPI device tables?

> 
> > I have built your spi_init.c for an ARM946EJS and
> I
> > get a .ko object of 5.1K
> 
> ... but the ".text" size is MUCH less; and what I
> sent
> was not built as a ".so", so there's other oddness
> too.

Sorry, I must be missing something here but isn't a
".so" a shared library not a kernel module? Or where
you only building it as a ".so" to find the text size?

Mark

> I got something on the order of 0x04d0 bytes with
> the
> refresh I just posted (call it 1200 bytes text).
> 
> - Dave
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Re: SPI redux ... driver model support

[David Brownell]

> OK. Perhaps it's time to lay out the arguments so far
> and see where we go from there :).

I'd rather see a bit more feedback from other folk about what they
need and want.  For one example, Dmitry (dpervushin@ru.mvista.com)
posted some SPI code a while back, but we've not heard from him...

Then there are other developers who need or want SPI APIs that are
less chip-specific than linux/arch/arm/mach-pxa/ssp.c (or even
linux/drivers/char/at91_spi.c, interesting since it uses DMA and
handles root-on-DataFlash) and can support development of reusable
drivers for SPI slave devices (Flash, sensors, etc) that aren't
hardwired to a given SOC or board.


> I want to pass a cs table in as platform data because
> it means you don't have to know what bus number the
> adapter is (which you can't easily tell for
> hotplugable devices)

But as you observed earlier, SPI doesn't need to handle
hotplug ... just different common arrangements of boards.

However:  Linux uses bus numbers lots of places, even when
the bus can be hotplugged.  So that argument's not a win.


>	and for most cases I think the
> SPI devices will be hardwire to the adapter. This
> approach of defining a structure to be used in
> platform_data seems to be used by some serial drivers
> so I think it's OK, but your not so sure.
> How else could I do it?

Reread my patches; they ought to even run on x86, though of course
"Real Hardware" is typically embedded.  (The folk who've contacted me
run Linux on SOC boards based on ARM, MIPS, and PPC CPUs.)

The basic model is widely used:  give the operating system tables that
describe the devices that can't be probed.


> You want to pass in SPI devices in a table that gets
> registered with the subsystem and when the adapter
> that they sit on gets registered (known by the bus
> number) all the devices in that table get registered
> in the core.

Actually there can be several such tables; initialization for each board
in the system might declare a few entries.  Those tables are sufficient
to describe the system setup.

That's a difference I'll highlight again:  the tables you're talking about
MUST be grouped by adapter.  Which means that when the hardware groups
them differently ("by board") your API needs to add another solution.
Why have two, when (as in my patch) just one could suffice?


>	I like this solution for registering
> hotplug'ish devices :), although I would prefer to use
> the bus_id then a bus number.

Numbers are just one kind of ID, so I don't see what you're trying to
say here.  The kernel uses numbers to identify other bootable devices;
why would you object to using them here?


>	This solution doesn't
> work very well for hotplug adapters as you don't know
> what bus number they will be given (you would have to
> do some undefined sysfs magic). 

Anyone trying to develop "SPI hotplug" is going to have a wide variety
of problems to solve!  There's not even a standard for SPI connectors,
much less cable quality standards or dynamic device identification.
I refuse to consider such a long list of "maybes" in a design.

The scenario you mentioned was development platforms (contrast to
production hardware...) with 8 bit microcontrollers and SPI, connected
over USB.  I can think of several ways to implement such devices using
the approach I posted.


> So how would you feel about the core supporting both
> cs tables as platform data and SPI device tables?

I'm not a fan of duplication of function, or code managing platform_data
that's not platform-specific code.  (After all, that's why it's called
"platform" data.)


> > > I get a .ko object of 5.1K
> > 
> > ... but the ".text" size is MUCH less [1K]; and what I
> > sent was not built as a ".so", so there's other oddness
> > too.
>
> Sorry, I must be missing something here but isn't a
> ".so" a shared library not a kernel module? Or where
> you only building it as a ".so" to find the text size?

Typo; they're both just dynamic linking.  My point was that if you built
that core (vs a driver) to get a ".ko", you've played some strange games
already -- and broke at least one thing.

Not that size is the top concern, but on the other hand the folk using
SPI do care about it more than the folk who find bugs like "hardware
DMA fails on memory addresses over 2GB".  :)

- Dave

Re: SPI redux ... driver model support

[Grant Likely]

On 9/8/05, David Brownell <david-b@pacbell.net> wrote:
> That implies whoever is registering is actually going and creating the
> SPI devices ... and doing it AFTER the controller driver is registered.
> I actually have issues with each of those implications.
> 
> However, I was also aiming to support the model where the controller
> drivers are modular, and the "add driver" and "declare hardware" steps
> can go in any order.  That way things can work "just like other busses"
> when you load the controller drivers ... and the approach is like the
> familiar "boot firmware gives hardware description tables to the OS"
> approach used by lots of _other_ hardware that probes poorly.  (Except
> that Linux is likely taking over lots of that "boot firmware" role.)
To clarify/confirm what your saying:

(I'm going to make liberal use of  stars to hilight "devices" and
"drivers" just to make sure that a critical word doesn't get
transposed)

There should be four parts to the SPI model:
1. SPI bus controller *devices*; attached to another bus *instance*
(ie. platform, PCI, etc)
2. SPI bus controller *drivers*; registered with the other bus
*subsystem* (platform, PCI, etc)
3. SPI slave *devices*; attached to a specifiec SPI bus *instance*
4. SPI slave *drivers*; registered with the SPI *subsystem*

a. SPI bus controller *drivers* and slave *drivers* can be registered
at any time in any order
b. SPI bus controller *devices* can be attached to the bus subsystem at any time
c. SPI bus controller *drivers* attach to bus controller *devices* to
create new spi bus instances whenever the driver model makes a 'match'
d. SPI slave devices can be attached to an SPI bus instance only after
that bus instance is created.
e. SPI slave *drivers* attach to SPI slave *devices* when the driver
model makes a match.  (let's call it an SPI slave instance)
f. Unregistration of any SPI bus controller *driver* or *device* will
cause attached SPI bus instance(s) and any attached devices to go away
g. Unregistration of any SPI slave *driver* or *device* will cause SPI
slave instance to go away.

[pretty much exactly how the driver model is supposed to work I guess  :)  ]

Ideally controller drivers, controller devices, slave drivers and
slave devices are all independent of each other.  The board setup code
will probably take care of attaching devices to busses independent of
the bus controller drivers and spi slave drivers.  Driver code is
responsible for registering itself with the SPI subsystem.

If this is what your saying, then I *strongly* second that opinion. 
If not, then what is your view?

I've been dealing with the same problems on my project.  Just for
kicks, here's another implementation to look at.

http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019259.html
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019260.html
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019261.html
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019262.html

It also is not based on i2c in any way and it tries ot follow the
device model.  It solves my problem, but I've held off active work on
it while looking at the other options being discussed here.

Thanks,
g.

Re: SPI redux ... driver model support

[Mark Underwood]

--- Grant Likely <glikely@gmail.com> wrote:

> On 9/8/05, David Brownell <david-b@pacbell.net>
> wrote:
> > That implies whoever is registering is actually
> going and creating the
> > SPI devices ... and doing it AFTER the controller
> driver is registered.
> > I actually have issues with each of those
> implications.
> > 
> > However, I was also aiming to support the model
> where the controller
> > drivers are modular, and the "add driver" and
> "declare hardware" steps
> > can go in any order.  That way things can work
> "just like other busses"
> > when you load the controller drivers ... and the
> approach is like the
> > familiar "boot firmware gives hardware description
> tables to the OS"
> > approach used by lots of _other_ hardware that
> probes poorly.  (Except
> > that Linux is likely taking over lots of that
> "boot firmware" role.)
> To clarify/confirm what your saying:
> 
> (I'm going to make liberal use of  stars to hilight
> "devices" and
> "drivers" just to make sure that a critical word
> doesn't get
> transposed)
> 
> There should be four parts to the SPI model:
> 1. SPI bus controller *devices*; attached to another
> bus *instance*
> (ie. platform, PCI, etc)
> 2. SPI bus controller *drivers*; registered with the
> other bus
> *subsystem* (platform, PCI, etc)
> 3. SPI slave *devices*; attached to a specifiec SPI
> bus *instance*
> 4. SPI slave *drivers*; registered with the SPI
> *subsystem*
> 
> a. SPI bus controller *drivers* and slave *drivers*
> can be registered
> at any time in any order
> b. SPI bus controller *devices* can be attached to
> the bus subsystem at any time
> c. SPI bus controller *drivers* attach to bus
> controller *devices* to
> create new spi bus instances whenever the driver
> model makes a 'match'
> d. SPI slave devices can be attached to an SPI bus
> instance only after
> that bus instance is created.
> e. SPI slave *drivers* attach to SPI slave *devices*
> when the driver
> model makes a match.  (let's call it an SPI slave
> instance)
> f. Unregistration of any SPI bus controller *driver*
> or *device* will
> cause attached SPI bus instance(s) and any attached
> devices to go away
> g. Unregistration of any SPI slave *driver* or
> *device* will cause SPI
> slave instance to go away.
> 
> [pretty much exactly how the driver model is
> supposed to work I guess  :)  ]
> 
> Ideally controller drivers, controller devices,
> slave drivers and
> slave devices are all independent of each other. 
> The board setup code
> will probably take care of attaching devices to
> busses independent of
> the bus controller drivers and spi slave drivers. 
> Driver code is
> responsible for registering itself with the SPI
> subsystem.
> 
> If this is what your saying, then I *strongly*
> second that opinion. 
> If not, then what is your view?
> 
> I've been dealing with the same problems on my
> project.  Just for
> kicks, here's another implementation to look at.
> 
>
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019259.html
>
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019260.html
>
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019261.html
>
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019262.html
> 
> It also is not based on i2c in any way and it tries
> ot follow the
> device model.  It solves my problem, but I've held
> off active work on
> it while looking at the other options being
> discussed here.

Another interesting proposal :), although it doesn't
address the platform abstraction issue along with some
others which people have raised in reply to your
posts. It's good to see other people interested in
this, if we can get up enough people then maybe we can
push a SPI subsystem into the kernel :).

Mark

> 
> Thanks,
> g.
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


Send instant messages to your online friends http://uk.messenger.yahoo.com 

Re: SPI redux ... driver model support

[David Brownell]

> Date: Fri, 9 Sep 2005 11:40:39 -0600
> From: Grant Likely <glikely@gmail.com>
>
> On 9/8/05, David Brownell <david-b@pacbell.net> wrote:
> > That implies whoever is registering is actually going and creating the
> > SPI devices ... and doing it AFTER the controller driver is registered.
> > I actually have issues with each of those implications.
> > 
> > However, I was also aiming to support the model where the controller
> > drivers are modular, and the "add driver" and "declare hardware" steps
> > can go in any order.  That way things can work "just like other busses"
> > when you load the controller drivers ... and the approach is like the
> > familiar "boot firmware gives hardware description tables to the OS"
> > approach used by lots of _other_ hardware that probes poorly.  (Except
> > that Linux is likely taking over lots of that "boot firmware" role.)
>
> To clarify/confirm what your saying:
>
> (I'm going to make liberal use of  stars to hilight "devices" and
> "drivers" just to make sure that a critical word doesn't get
> transposed)

And given that you're not using quite the same terminology I am, I think
we agree here.  Good!  :)

In my terminology, which should be clear in the Kconfig:
 
   - There are two types of SPI bus controller: master (issues clock)
     and slave (receives clock).  Linux should plan to handle both.

   - On top of either type of controller driver would be a "protocol driver"
     that processes messages.  (Is there a better name to use for these?)
 
What you've called a "slave driver" is what I've called a "protocol master"
driver, talking to a slave device/chip.  What I'd call a "slave driver"
would be either a controller driver or a protocol driver; but in any case
it'd run on hardware that _receives_ the SPI clock.

A slave protocol driver for the EEPROM protocol could be tricky in Linux,
given the single bit turnaround between request and response; but the
master protocol driver would be simple.  Linux should easily be able to
implement data streaming protocol slaves, including things like exchanging
network packets as well as the more conventional streams of sensor data.


> There should be four parts to the SPI model:
> 1. SPI bus controller *devices*; attached to another bus *instance*
> (ie. platform, PCI, etc)
> 2. SPI bus controller *drivers*; registered with the other bus
> *subsystem* (platform, PCI, etc)
> 3. SPI slave *devices*; attached to a specifiec SPI bus *instance*
> 4. SPI slave *drivers*; registered with the SPI *subsystem*

Yes, with the proviso above:  "slave driver" here mean the thing that
talks to the slave through the SPI master controller driver.  (As you
noted in the PPC patches you sent, you were not addressing SPI slave
side support.)


> a. SPI bus controller *drivers* and slave *drivers* can be registered
> at any time in any order
> b. SPI bus controller *devices* can be attached to the bus subsystem at any time
> c. SPI bus controller *drivers* attach to bus controller *devices* to
> create new spi bus instances whenever the driver model makes a 'match'
> d. SPI slave devices can be attached to an SPI bus instance only after
> that bus instance is created.

Yes, where the "slave device" in this case is the Linux driver model
thing representing a software proxy for the physical slave hardware;
it's never a discrete chip I could point to on a board.


> e. SPI slave *drivers* attach to SPI slave *devices* when the driver
> model makes a match.  (let's call it an SPI slave instance)

I'd call that just another "struct device" that happens to be bound to
some "struct device_driver".  Being bound is optional in Linux, though
of course a device has limited utility until it's bound (since it's
not accessible to user or kernel code).


> f. Unregistration of any SPI bus controller *driver* or *device* will
> cause attached SPI bus instance(s) and any attached devices to go away

Right.  Modulo the usual sysfs/kobject reference counting and memory
management issues; the memory may linger for a while, though things
will not be visible in sysfs any more.


> g. Unregistration of any SPI slave *driver* or *device* will cause SPI
> slave instance to go away.
>
> [pretty much exactly how the driver model is supposed to work I guess  :)  ]

Exactly so!  Except actually for (g) ... unregistering a master protocol
driver (for an SPI slave chip) just leaves an unbound device.  Removing
the device implies first unbinding its driver though.


The goal here is that -- unlike I2C -- an SPI driver framework should
leverage the driver model and the "Principle of Least Astonishment", so
that driver concepts (and developer skills!!) from elsewhere in Linux will
transfer as directly as practical.


> Ideally controller drivers, controller devices, slave drivers and
> slave devices are all independent of each other.  The board setup code
> will probably take care of attaching devices to busses independent of
> the bus controller drivers and spi slave drivers.  Driver code is
> responsible for registering itself with the SPI subsystem.
>
> If this is what your saying, then I *strongly* second that opinion. 

Modulo the provisos above, yes -- that's exactly what I'm saying.

(As well as: let's get terminology settled.  I didn't make a big deal
of it in my original post, and am not deeply attached to what I used,
but it's important to remember that Linux can handle both master and
slave controllers, and that the drivers talking to each will not be
quite the same ... there are four types of SPI driver involved.)


> I've been dealing with the same problems on my project.  Just for
> kicks, here's another implementation to look at.
>
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019259.html
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019260.html
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019261.html
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019262.html
>
> It also is not based on i2c in any way and it tries ot follow the
> device model.  It solves my problem, but I've held off active work on
> it while looking at the other options being discussed here.

I noticed that.  Also the way your second patch needed some "board
specific hacks" that you didn't much like!  :)

Yet another SPI stack, linked from one of those threads, is I2C-ish:

  http://www.katix.org/spi.php

For me I think the high order bits involve "normal" driver model support
(which implies avoidng most borrowing from I2C); being sure that both
master and slave sides stay in the picture, and ensuring that the "SPI
master protocol drivers" can issue transfer requests from IRQ handlers
and any other contexts which happen to notice one is needed.

- Dave