From a9948b6194b46e489aa3b4d111d6dfd786c39c4b Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sun, 2 Apr 2006 10:37:40 -0800 Subject: [PATCH] SPI: spi bounce buffer has a minimum length Make sure that spi_write_then_read() can always handle at least 32 bytes of transfer (total, both directions), minimizing one portability issue. Signed-off-by: David Brownell Signed-off-by: Greg Kroah-Hartman --- drivers/spi/spi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'drivers/spi/spi.c') diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 94f5e8ed83a7..1168ef015887 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -522,7 +522,8 @@ int spi_sync(struct spi_device *spi, struct spi_message *message) } EXPORT_SYMBOL_GPL(spi_sync); -#define SPI_BUFSIZ (SMP_CACHE_BYTES) +/* portable code must never pass more than 32 bytes */ +#define SPI_BUFSIZ max(32,SMP_CACHE_BYTES) static u8 *buf; -- cgit v1.2.3 From a020ed7521a9737bcf3e34eb880867c60c3c68d0 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Mon, 3 Apr 2006 15:49:04 -0700 Subject: [PATCH] SPI: busnum == 0 needs to work We need to be able to have a "SPI bus 0" matching chip numbering; but that number was wrongly used to flag dynamic allocation of a bus number. This patch resolves that issue; now negative numbers trigger dynamic alloc. It also updates the how-to-write-a-controller-driver overview to mention this stuff. Signed-off-by: David Brownell Signed-off-by: Greg Kroah-Hartman --- Documentation/spi/spi-summary | 34 +++++++++++++++++++++++++++++++++- drivers/spi/spi.c | 4 ++-- include/linux/spi/spi.h | 6 +++--- 3 files changed, 38 insertions(+), 6 deletions(-) (limited to 'drivers/spi/spi.c') diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index a5ffba33a351..068732d32276 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary @@ -414,7 +414,33 @@ to get the driver-private data allocated for that device. The driver will initialize the fields of that spi_master, including the bus number (maybe the same as the platform device ID) and three methods used to interact with the SPI core and SPI protocol drivers. It will -also initialize its own internal state. +also initialize its own internal state. (See below about bus numbering +and those methods.) + +After you initialize the spi_master, then use spi_register_master() to +publish it to the rest of the system. At that time, device nodes for +the controller and any predeclared spi devices will be made available, +and the driver model core will take care of binding them to drivers. + +If you need to remove your SPI controller driver, spi_unregister_master() +will reverse the effect of spi_register_master(). + + +BUS NUMBERING + +Bus numbering is important, since that's how Linux identifies a given +SPI bus (shared SCK, MOSI, MISO). Valid bus numbers start at zero. On +SOC systems, the bus numbers should match the numbers defined by the chip +manufacturer. For example, hardware controller SPI2 would be bus number 2, +and spi_board_info for devices connected to it would use that number. + +If you don't have such hardware-assigned bus number, and for some reason +you can't just assign them, then provide a negative bus number. That will +then be replaced by a dynamically assigned number. You'd then need to treat +this as a non-static configuration (see above). + + +SPI MASTER METHODS master->setup(struct spi_device *spi) This sets up the device clock rate, SPI mode, and word sizes. @@ -431,6 +457,9 @@ also initialize its own internal state. state it dynamically associates with that device. If you do that, be sure to provide the cleanup() method to free that state. + +SPI MESSAGE QUEUE + The bulk of the driver will be managing the I/O queue fed by transfer(). That queue could be purely conceptual. For example, a driver used only @@ -440,6 +469,9 @@ But the queue will probably be very real, using message->queue, PIO, often DMA (especially if the root filesystem is in SPI flash), and execution contexts like IRQ handlers, tasklets, or workqueues (such as keventd). Your driver can be as fancy, or as simple, as you need. +Such a transfer() method would normally just add the message to a +queue, and then start some asynchronous transfer engine (unless it's +already running). THANKS TO diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 1168ef015887..7a3f733051e9 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -395,7 +395,7 @@ EXPORT_SYMBOL_GPL(spi_alloc_master); int __init_or_module spi_register_master(struct spi_master *master) { - static atomic_t dyn_bus_id = ATOMIC_INIT(0); + static atomic_t dyn_bus_id = ATOMIC_INIT((1<<16) - 1); struct device *dev = master->cdev.dev; int status = -ENODEV; int dynamic = 0; @@ -404,7 +404,7 @@ spi_register_master(struct spi_master *master) return -ENODEV; /* convention: dynamically assigned bus IDs count down from the max */ - if (master->bus_num == 0) { + if (master->bus_num < 0) { master->bus_num = atomic_dec_return(&dyn_bus_id); dynamic = 1; } diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 77add901691d..e928c0dcc297 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -172,13 +172,13 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv) struct spi_master { struct class_device cdev; - /* other than zero (== assign one dynamically), bus_num is fully + /* other than negative (== assign one dynamically), bus_num is fully * board-specific. usually that simplifies to being SOC-specific. - * example: one SOC has three SPI controllers, numbered 1..3, + * example: one SOC has three SPI controllers, numbered 0..2, * and one board's schematics might show it using SPI-2. software * would normally use bus_num=2 for that controller. */ - u16 bus_num; + s16 bus_num; /* chipselects will be integral to many controllers; some others * might use board-specific GPIOs. -- cgit v1.2.3 From ba1a051319dc2bec9f43b7cef11c6e5270107fd6 Mon Sep 17 00:00:00 2001 From: dmitry pervushin Date: Sat, 20 May 2006 15:00:14 -0700 Subject: [PATCH] minor SPI doc fix Because several developers asked me about referenced but missing spi_add_master(), I think that this patch should be applied ... it corrects comments so they refer to spi_register_master() instead. Signed-off-by: dmitry pervushin Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- drivers/spi/spi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'drivers/spi/spi.c') diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 7a3f733051e9..1cea4a6799fe 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -338,18 +338,18 @@ static struct class spi_master_class = { * spi_alloc_master - allocate SPI master controller * @dev: the controller, possibly using the platform_bus * @size: how much driver-private data to preallocate; the pointer to this - * memory is in the class_data field of the returned class_device, + * memory is in the class_data field of the returned class_device, * accessible with spi_master_get_devdata(). * * This call is used only by SPI master controller drivers, which are the * only ones directly touching chip registers. It's how they allocate - * an spi_master structure, prior to calling spi_add_master(). + * an spi_master structure, prior to calling spi_register_master(). * * This must be called from context that can sleep. It returns the SPI * master structure on success, else NULL. * * The caller is responsible for assigning the bus number and initializing - * the master's methods before calling spi_add_master(); and (after errors + * the master's methods before calling spi_register_master(); and (after errors * adding the device) calling spi_master_put() to prevent a memory leak. */ struct spi_master * __init_or_module -- cgit v1.2.3