SPI core refresh
Subsystems (2)
PATCH 1/1 SPI core refresh
Greetings,
This is an updated version of SPI framework developed by Dmitry Pervushin and Vitaly Wool.
The main changes are:
- Matching rmk's 2.6.14-git5+ changes for device_driver suspend and resume calls
- The character device interface was reworked
I still think that we need to continue converging with David Brownell's core, despite some misalignments happening in the email exchange :). Although it's not yet done in our core, I plan to move to
- using chained SPI messages as David does
- maybe rework the SPI device interface more taking David's one as a reference
However, there also are some advantages of our core compared to David's I'd like to mention
- it can be compiled as a module
- it is DMA-safe
- it is priority inversion-free
- it can gain more performance with multiple controllers
- it's more adapted for use in real-time environments
- it's not so lightweight, but it leaves less effort for the bus driver developer.
It's also been proven to work on SPI EEPROMs and SPI WiFi module (the latter was a really good survival test! :)).
arch/arm/Kconfig | 2 drivers/Kconfig | 2 drivers/Makefile | 1 drivers/spi/Kconfig | 33 ++ drivers/spi/Makefile | 14 + drivers/spi/spi-core.c | 650 +++++++++++++++++++++++++++++++++++++++++++++++++ drivers/spi/spi-dev.c | 176 +++++++++++++ include/linux/spi.h | 297 ++++++++++++++++++++++ 8 files changed, 1175 insertions(+)
include/linux/spi.h +297 -0
@@ -0,0 +1,297 @@ +/* +* linux/include/linux/spi/spi.h +* +* Copyright (C) 2005 MontaVista Software, Inc <[email protected]> +* +* 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. +* +* Derived from l3.h by Jamey Hicks +*/ +#ifndef SPI_H +#define SPI_H + +#include <linux/types.h> +#include <linux/device.h> + +#define kzalloc (size,type) kcalloc(1,size,type) + +struct spi_device ; +struct spi_driver ; +struct spi_msg ; +struct spi_bus_driver ; + +extern struct bus_type spi_bus; + +struct spi_bus_data { +struct semaphore lock; +struct list_head msgs; +atomic_t exiting; +struct task_struct *thread; +wait_queue_head_t queue; +struct spi_device *selected_device; +struct spi_bus_driver *bus; +char *id; +}; + +#define TO_SPI_BUS_DRIVER (drv) container_of( drv, struct spi_bus_driver, driver ) +struct spi_bus_driver { +int (*xfer) (struct spi_msg * msg); +void (*select) (struct spi_device * dev); +void (*deselect) (struct spi_device * dev); +void (*set_clock) (struct device * bus_device,u32 clock_hz); +void (*reset) (struct device *bus_device,u32 context); +struct spi_msg * + (*retrieve) (struct spi_bus_driver *bus,struct spi_bus_data *data); +struct device_driver driver; +}; + +#define TO_SPI_DEV (device) container_of( device, struct spi_device, dev ) +struct spi_device { +char name[BUS_ID_SIZE ]; +void *private; +int minor; +struct class_device *cdev; +struct device dev; +}; + +#define TO_SPI_DRIVER (drv) container_of( drv, struct spi_driver, driver ) +struct spi_driver { +void *(*alloc) (size_t ,int ); +void (*free) (const void *); +unsigned char *(*get_buffer) (struct spi_device *,void *); +void (*release_buffer) (struct spi_device *,unsigned char *); +void (*control) (struct spi_device *,int mode,u32 ctl); +struct device_driver driver; +}; + +#define SPI_DEV_DRV ( device ) TO_SPI_DRIVER( (device)->dev.driver ) + +#define spi_device_lock ( dev )/* down( dev->dev.sem ) */ +#define spi_device_unlock ( dev )/* up( dev->dev.sem ) */ + +/* +* struct spi_msg +* +* This structure represent the SPI message internally. You should never use fields of this structure directly +* Please use corresponding functions to create/destroy/access fields +* +*/ +struct spi_msg { +u32 flags; +#define SPI_M_RD 0x00000001 +#define SPI_M_WR 0x00000002/**< Write mode flag */ +#define SPI_M_CSREL 0x00000004/**< CS release level at end of the frame */ +#define SPI_M_CS 0x00000008/**< CS active level at begining of frame ( default low ) */ +#define SPI_M_CPOL 0x00000010/**< Clock polarity */ +#define SPI_M_CPHA 0x00000020/**< Clock Phase */ +#define SPI_M_EXTBUF 0x80000000/** externally allocated buffers */ +#define SPI_M_ASYNC_CB 0x40000000/** use workqueue to deliver callbacks */ +#define SPI_M_DNA 0x20000000/** do not allocate buffers */ + +unsigned short len;/* msg length */ +unsigned long clock; +struct spi_device *device; +void *context; +void *arg; +void *parent;/* in case of complex messages */ +struct list_head link; + +void (*status) (struct spi_msg * msg,int code); + +void *devbuf_rd, *devbuf_wr; +u8 *databuf_rd, *databuf_wr; + +struct work_struct wq_item; +}; + +#ifdef CONFIG_SPI_CHARDEV +extern struct class_device *spi_class_device_create (int minor,struct device *device); +extern void spi_class_device_destroy (int minor); +#else +#define spi_class_device_create (a, b) NULL +#define spi_class_device_destroy (a) do { } while (0) +#endif + +static inline struct spi_msg *spimsg_alloc (struct spi_device *device, +unsigned flags, +unsigned short len, +void (*status) (struct spi_msg *, +int code)) +{ +struct spi_msg *msg; +struct spi_driver *drv =SPI_DEV_DRV (device); +int msgsize =sizeof (struct spi_msg ); + +if (drv->alloc || (flags & (SPI_M_RD |SPI_M_WR )) == (SPI_M_RD |SPI_M_WR ) ) { +pr_debug ("%s: external buffers\n" , __FUNCTION__ ); + flags |=SPI_M_EXTBUF ; + }else { +pr_debug ("%s: no ext buffers, msgsize increased from %d by %d to %d\n" , __FUNCTION__, + msgsize, len, msgsize + len ); + msgsize += len; + } + + msg =kmalloc ( msgsize,GFP_KERNEL ); +if (!msg) +return NULL ; +memset (msg,0 ,sizeof (struct spi_msg )); + msg->len = len; + msg->status = status; + msg->device = device; + msg->flags = flags; +INIT_LIST_HEAD (&msg->link); + +if (flags &SPI_M_DNA ) +return msg; + +/* otherwise, we need to set up pointers */ +if (!(flags &SPI_M_EXTBUF )) { + msg->databuf_rd = msg->databuf_wr = + (u8 *)msg +sizeof (struct spi_msg ); + }else { +if (flags &SPI_M_RD ) { + msg->devbuf_rd = drv->alloc ? + drv->alloc (len,GFP_KERNEL ) :kmalloc (len,GFP_KERNEL ); + msg->databuf_rd = drv->get_buffer ? + drv->get_buffer (device, msg->devbuf_rd) : msg->devbuf_rd; + } +if (flags &SPI_M_WR ) { + msg->devbuf_wr = drv->alloc ? + drv->alloc (len,GFP_KERNEL ) :kmalloc (len,GFP_KERNEL ); + msg->databuf_wr = drv->get_buffer ? + drv->get_buffer (device, msg->devbuf_wr) : msg->devbuf_wr; + } + } +pr_debug ("%s: msg = %p, RD=(%p,%p) WR=(%p,%p). Actual flags = %s+%s\n" , + __FUNCTION__, + msg, + msg->devbuf_rd, msg->databuf_rd, + msg->devbuf_wr, msg->databuf_wr, + msg->flags &SPI_M_RD ?"RD" :"~rd" , + msg->flags &SPI_M_WR ?"WR" :"~wr" ); +return msg; +} + +static inline void spimsg_free (struct spi_msg *msg) +{ +void (*do_free) (const void *) = kfree; +struct spi_driver *drv =SPI_DEV_DRV (msg->device); + +if (msg) { + +if ( !(msg->flags &SPI_M_DNA ) || (msg->flags &SPI_M_EXTBUF ) ) { +if (drv->free) + do_free = drv->free; +if (drv->release_buffer) { +if (msg->databuf_rd) + drv->release_buffer (msg->device, + msg->databuf_rd); +if (msg->databuf_wr) + drv->release_buffer (msg->device, + msg->databuf_wr); + } +if (msg->devbuf_rd) +do_free (msg->devbuf_rd); +if (msg->devbuf_wr) +do_free (msg->devbuf_wr); + } +kfree (msg); + } +} + +static inline u8 *spimsg_buffer_rd (struct spi_msg *msg) +{ +return msg ? msg->databuf_rd :NULL ; +} + +static inline u8 *spimsg_buffer_wr (struct spi_msg *msg) +{ +return msg ? msg->databuf_wr :NULL ; +} + +static inline u8 *spimsg_buffer (struct spi_msg *msg) +{ +if (!msg) +return NULL ; +if ((msg->flags & (SPI_M_RD |SPI_M_WR )) == (SPI_M_RD |SPI_M_WR )) { +printk (KERN_ERR "%s: what buffer do you really want ?\n" , + __FUNCTION__); +return NULL ; + } +if (msg->flags &SPI_M_RD ) +return msg->databuf_rd; +if (msg->flags &SPI_M_WR ) +return msg->databuf_wr; +} + +static inline void spimsg_set_rd (struct spi_msg * msg,void * buf ) +{ + msg->databuf_rd = buf; +} + +static inline void spimsg_set_wr (struct spi_msg *msg,void *buf ) +{ + msg->databuf_wr = buf; +} + + +#define SPIMSG_OK 0x01 +#define SPIMSG_FAILED 0x80 +#define SPIMSG_STARTED 0x02 +#define SPIMSG_DONE 0x04 + +#define SPI_MAJOR 153 + +struct spi_driver ; +struct spi_device ; + +#ifdef CONFIG_SPI_CHARDEV +extern int __init spidev_init (void ); +extern void __exit spidev_cleanup(void); +#else +#define spidev_init () (0) +#define spidev_cleanup () do { } while (0) +#endif + +static inline int spi_bus_driver_register (struct spi_bus_driver *bus_driver) +{ +return driver_register (&bus_driver->driver); +} + +void spi_bus_driver_unregister (struct spi_bus_driver *); +int spi_bus_driver_init (struct spi_bus_driver *driver,struct device *dev); +struct spi_device *spi_device_add (struct device *parent,char *name,void *private); + +static inline int spi_driver_add (struct spi_driver *drv) +{ + drv->driver.bus = &spi_bus; +return driver_register (&drv->driver); +} +static inline void spi_driver_del (struct spi_driver *drv) +{ +driver_unregister (&drv->driver); +} + +extern void spi_bus_reset (struct device * bus,u32 context); +extern int spi_write (struct spi_device *dev,const char *buf,int len); +extern int spi_read (struct spi_device *dev,char *buf,int len); + +extern int spi_queue (struct spi_msg *message); +extern int spi_transfer (struct spi_msg *message, +void (*status) (struct spi_msg *,int )); +extern int spi_bus_populate (struct device *parent,char *device, +void (*assign) (struct device *parent, +struct spi_device *)); +struct spi_device_desc { +char * name; +void * params; +}; +extern int spi_bus_populate2 (struct device *parent, +struct spi_device_desc *devices, +void (*assign) (struct device *parent, +struct spi_device *, +void *)); + +#endif /* SPI_H */
arch/arm/Kconfig +2 -0
@@ -748,6 +748,8 @@ source "drivers/mmc/Kconfig" +source "drivers/spi/Kconfig" + endmenu source "fs/Kconfig"
drivers/Kconfig +2 -0
@@ -44,6 +44,8 @@ source "drivers/i2c/Kconfig" +source "drivers/spi/Kconfig" + source "drivers/w1/Kconfig" source "drivers/hwmon/Kconfig"
drivers/Makefile +1 -0
@@ -69,3 +69,4 @@ obj-y += firmware/ obj-$(CONFIG_CRYPTO) += crypto/ obj-$(CONFIG_SUPERH) += sh/ +obj-$(CONFIG_SPI) += spi/
drivers/spi/Kconfig +33 -0
@@ -0,0 +1,33 @@ +# +# SPI device configuration +# +menu "SPI support" + +config SPI + default Y + tristate "SPI (Serial Peripheral Interface) bus support" + default false + help + Say Y if you need to enable SPI support on your kernel. + Say M if you want to create the spi-core loadable module. + +config SPI_DEBUG + bool "SPI debug output" + depends on SPI + default false + help + Say Y there if you'd like to see debug output from SPI drivers + If unsure, say N + +config SPI_CHARDEV + default Y + tristate "SPI device interface" + depends on SPI + help + Say Y here to use /dev/spiNN device files. They make it possible to have user-space + programs use the SPI bus. + This support is also available as a module. If so, the module + will be called spi-dev. + +endmenu +
drivers/spi/Makefile +14 -0
@@ -0,0 +1,14 @@ +# +# Makefile for the kernel spi bus driver. +# + +obj-$(CONFIG_SPI) += spi-core.o +# bus drivers +# ...functional drivers +# ...and the common spi-dev driver +obj-$(CONFIG_SPI_CHARDEV) += spi-dev.o + +ifeq ($(CONFIG_SPI_DEBUG),y) +EXTRA_CFLAGS += -DDEBUG +endif +
drivers/spi/spi-core.c +650 -0
650 lines not on this page · raw message
drivers/spi/spi-dev.c +176 -0
176 lines not on this page · raw message
Quoted 4 lines · Vitaly Wool
The main changes are:
- Matching rmk's 2.6.14-git5+ changes for
device_driversuspend and resume calls
Although it isn't obvious in this patch, I request that you don't use use struct device_driver function methods directly in your drivers but add suitable function methods in your spi_driver for probe/remove/ shutdown as required, and arrange for the SPI core to convert from the generic device driver function methods to spi_driver function methods.
I'm planning to eliminate all the device_driver function methods entirely - the probe/remove/shutdown methods will eventually be moved to bus_type.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Quoted 15 lines · --- Vitaly Wool
Greetings,
This is an updated version of SPI framework developed by Dmitry Pervushin and Vitaly Wool.
The main changes are:
- Matching rmk's 2.6.14-git5+ changes for
device_driversuspend and resume calls
- The character device interface was reworkedI still think that we need to continue converging with David Brownell's core, despite some misalignments happening in the email exchange :). Although it's not yet done in our core, I plan to move to
- using chained SPI messages as David does
- maybe rework the SPI device interface more taking David's one as a reference
Quoted 3 lines
However, there also are some advantages of our core compared to David's I'd like to mention
- it can be compiled as a module
So can David's. You can use BIOS tables in which case you must compile the SPI core into the kernel but you can also use spi_new_device which allows the SPI core to be built as a module (and is how I am using it).
Quoted 1 line
- it is DMA-safe
To my understanding David's core is DMA-safe. Yes there is a question mark over one of the helper functions, but the _main_ functions _are_ DMA-safe.
Quoted 2 lines
- it is priority inversion-free
- it can gain more performance with multiple controllers
Sorry I'm not sure what you mean here.
Quoted 2 lines
- it's more adapted for use in real-time environments
- it's not so lightweight, but it leaves less effort for the bus driver developer.
But also less flexibility. A core layer shouldn't _force_ a policy
on a bus driver. I am currently developing an adapter driver for David's system and I wouldn't say that the core is making me do things I think the core should do. Please could you provide examples of where you think Davids SPI core requires 'effort'.
Mark
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Quoted 10 lines · Mark Underwood
Quoted 5 lines
However, there also are some advantages of our core compared to David's I'd like to mention
- it can be compiled as a module
So can David's. You can use BIOS tables in which case you must compile the SPI core into the kernel but you can also use
spi_new_devicewhich allows the SPI core to be built as a module (and is how I am using it).
You limit the functionality, so it's not the case.
Quoted 9 lines
Quoted 5 lines
- it is DMA-safe
To my understanding David's core is DMA-safe. Yes there is a question mark over one of the helper functions, but the _main_ functions _are_ DMA-safe.
Yeah, I can agree with this statement. However, as it turns out, the latest David's core eliminates this issue.
Quoted 9 lines
Quoted 6 lines
- it is priority inversion-free
- it can gain more performance with multiple controllersSorry I'm not sure what you mean here.
If there's more than one SPI controller onboard, spi_write_then_read will serialize the transfers related to two different controllers what will have significant negative impact on the transfer speed (so DMA won't help increasing the speed in this case). Moreover, if, say, two kernel threads with different priorities are working with two SPI controllers respectively *priority inversion* will happen. You might also want to learn more about real-time systems characterictics such as priority inversion, BTW.
Quoted 10 lines
Quoted 6 lines
- it's more adapted for use in real-time environments
- it's not so lightweight, but it leaves less effort for the bus driver developer.But also less flexibility. A core layer shouldn't _force_ a policy
Nope, it's just a default policy.
Quoted 5 lines
on a bus driver. I am currently developing an adapter driver for David's system and I wouldn't say that the core is making me do things I think the core should do. Please could you provide examples of where you think Davids SPI core requires 'effort'.
Main are
- the need to call 'complete' in controller driver
- the need to implement policy in controller driver
Vitaly
Quoted 11 lines · Vitaly Wool
Quoted 7 lines · Mark Underwood
Quoted 3 lines
However, there also are some advantages of our core compared to David's I'd like to mention
- it can be compiled as a module
So can David's. You can use BIOS tables in which case you must compile the SPI core into the kernel but you can also use
spi_new_devicewhich allows the SPI core to be built as a module (and is how I am using it).You limit the functionality, so it's not the case.
As noted in my comparison of last week (you're still ignoring that):
- Mine lets board-specific device tables be declared in the relevant arch_setup() thing (board-*.c). Both frameworks allow later board specific code to dynamically declare the devices, with binary (Dave's) or parsed-text (Dmitry's) descriptions.
What Mark said was that in this case he used the "late" init. You seem to be saying he's not allowed to do that. Which is nonsense; there are distinct mechanisms for the good reason that "late" init doesn't work so well without dynamic discovery ... which SPI itself doesn't support. Hence the need for board-specific "this hardware exists" tables.
Quoted 2 lines
If there's more than one SPI controller onboard,
spi_write_then_readwill serialize the transfers ...
Which, as has been pointed out, would be a trivial thing to fix if anyone were actually to have a problem. Sure it'd incur the cost of a kmalloc on at least some paths -- serializing in the slab layer instead! -- but that's one price of using convenience helpers not performance oriented calls.
Quoted 3 lines
Moreover, if, say, two
kernel threads with different priorities are working with two SPI controllers respectively *priority inversion* will happen.
That characteristic being inherited from semaphores (or were they updated with RT_PREEMPT?), and being in common with most I/O queues in the system. Not something to blame on any line of code I wrote.
Oh, and I noticed a priority inversion in your API which shows up with one SPI controller managing two devices. Whoops! I'd far rather have such inversions be implementation artifacts; it's easy to patch an implementation, hard to change all API users.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
- it's more adapted for use in real-time environments
- it's not so lightweight, but it leaves less effort for the bus driver developer.But also less flexibility. A core layer shouldn't _force_ a policy
Nope, it's just a default policy.
One that every driver pays the price for. Allocating a task even when it doesn't need it; every call going through a midlayer that wants to take over queue management policy; and more. (Unless you made a big un-remarked change in a patch you called "refresh"...)
Quoted 6 lines
Quoted 3 lines
on a bus driver. I am currently developing an adapter driver for David's system and I wouldn't say that the core is making me do things I think the core should do. Please could you provide examples of where you think Davids SPI core requires 'effort'.
Main are
- the need to call 'complete' in controller driver
So you think it's better to have consistent semantics be optional?
That seems to be the notion behind your spi_transfer() call, which can't decide whether it's going to be synchronous or asynchronous. Instead, it decided to be error prone and be both. :)
Quoted 1 line
- the need to implement policy in controller driver
The "policy" in question is something that sometimes needs to be board-specific -- priority to THAT device, synch with THIS external signal, etc -- which is why I see it as a drawback that you insist the core implement one policy.
One policy is painfully easy to implement: FIFO, processing the requests in the order they arrive. Easy to implement, even with spinlocks, in a dozen lines of code. If anyone has a hard time writing that, they shouldn't be trying to write a device driver.
- Dave
Quoted 28 lines · David Brownell
Quoted 9 lines · Vitaly Wool
Quoted 5 lines · Mark Underwood
Quoted 5 lines
However, there also are some advantages of our core compared to David's I'd like to mention
- it can be compiled as a module
Quoted 8 lines
Quoted 5 lines
So can David's. You can use BIOS tables in which case you must compile the SPI core into the kernel but you can also use
spi_new_devicewhich allows the SPI core to be built as a module (and is how I am using it).You limit the functionality, so it's not the case.
As noted in my comparison of last week (you're still ignoring that):
- Mine lets board-specific device tables be declared in the relevant
arch_setup()thing (board-*.c). Both frameworks allow later board specific code to dynamically declare the devices, with binary (Dave's) or parsed-text (Dmitry's) descriptions.
Quoted 8 lines
What Mark said was that in this case he used the "late" init. You seem to be saying he's not allowed to do that. Which is nonsense; there are distinct mechanisms for the good reason that "late" init doesn't work so well without dynamic discovery ... which SPI itself doesn't support. Hence the need for board-specific "this hardware exists" tables.
Can you please clarify what you mean here? Better even if Mark describes what he does. The ideal situation would be if he posted a patch.
Quoted 6 lines
Quoted 5 lines
If there's more than one SPI controller onboard,
spi_write_then_readwill serialize the transfers ...
Quoted 7 lines
Which, as has been pointed out, would be a trivial thing to fix if anyone were actually to have a problem. Sure it'd incur the cost of a kmalloc on at least some paths -- serializing in the slab layer instead! -- but that's one price of using convenience helpers not performance oriented calls.
Well, most of the drivers will use that helpers I guess.
The thing however is that if you try to implement this in a "clean" way you will come to a sport of framework we've developed for memeory allocations, as I've saild previously.
Quoted 13 lines
Quoted 7 lines
Moreover, if, say, two
kernel threads with different priorities are working with two SPI controllers respectively *priority inversion* will happen.That characteristic being inherited from semaphores (or were they updated with
RT_PREEMPT?), and being in common with most I/O queues in the system. Not something to blame on any line of code I wrote.
I think they weren't.
The whole thing doesn't seem thought out nicely to me. The solution exists, of course, and that is -- do somthing similar to what we did there.
Quoted 6 lines
Oh, and I noticed a priority inversion in your API which shows up with one SPI controller managing two devices. Whoops! I'd far rather have such inversions be implementation artifacts; it's easy to patch an implementation, hard to change all API users.
Not sure if I understood you. Can you please describe the situation when this prio inversion happens?
What priorities are you talking about? One controller is one thread, so it's _one_ priority, consequently there's nothing to invert.
As for your second statement, I don't argue. The fact however is that if you implement the mehtod which corrects priority inverstion problems your core will not be either so lightweight or so flexible. :)
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 7 lines
- it's more adapted for use in real-time environments
- it's not so lightweight, but it leaves less effort for the bus driver developer.But also less flexibility. A core layer shouldn't _force_ a policy
Quoted 10 lines
Quoted 3 lines
Nope, it's just a default policy.
One that every driver pays the price for. Allocating a task even when it doesn't need it; every call going through a midlayer that wants to take over queue management policy; and more. (Unless you made a big un-remarked change in a patch you called "refresh"...)
It's not obvious that this price is high.
Anyway, it's a point I should agree with; this functionality better be a config option. Feel free to submit a patch, as you like to say.
Quoted 13 lines
Quoted 12 lines
Quoted 8 lines
on a bus driver. I am currently developing an adapter driver for David's system and I wouldn't say that the core is making me do things I think the core should do. Please could you provide examples of where you think Davids SPI core requires 'effort'.
Main are
- the need to call 'complete' in controller driver
Quoted 9 lines
So you think it's better to have consistent semantics be optional?
That seems to be the notion behind your
spi_transfer()call, which can't decide whether it's going to be synchronous or asynchronous. Instead, it decided to be error prone and be both. :)
Not sure if I understood you here, sorry.
Quoted 10 lines
Quoted 3 lines
- the need to implement policy in controller driver
The "policy" in question is something that sometimes needs to be board-specific -- priority to THAT device, synch with THIS external signal, etc -- which is why I see it as a drawback that you insist the core implement one policy.
Again, the policy can be overridden.
Vitaly
Quoted 39 lines · --- Vitaly Wool
Quoted 7 lines · David Brownell
Quoted 4 lines · Vitaly Wool
Mark Underwood wrote:
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
However, there also are some advantages of our core compared to David's I'd like to mention
- it can be compiled as a module
So can David's. You can use BIOS tables in which case you must compile the SPI core into the kernel but you can also use
spi_new_devicewhich allows the SPI core to be built as a module(and
Quoted 14 lines
Quoted 6 lines
Quoted 3 lines
is how I am using it).
You limit the functionality, so it's not the case.
As noted in my comparison of last week (you're still ignoring that):
- Mine lets board-specific device tables be declared in the relevant
arch_setup()thing (board-*.c). Both frameworks allow later board specific code to dynamically declare the devices, with binary (Dave's) or parsed-text (Dmitry's) descriptions.Quoted 8 lines
What Mark said was that in this case he used the "late" init. You seem to be saying he's not allowed to do that. Which is nonsense; there are distinct mechanisms for the good reason that "late" init doesn't work so well without dynamic discovery ... which SPI itself doesn't support. Hence the need for board-specific "this hardware exists" tables.
Quoted 3 lines
Can you please clarify what you mean here? Better even if Mark describes what he does. The ideal situation would be if he posted a patch.
Here it is :)
parport_plat.c new file +66 -0
@@ -0,0 +1,66 @@ +/* +* parport_plat.c - Platfrom file describing the SPI parport adapter +* board that has an eeprom on it. +* +* Copyright (C) 2005 Mark Underwood +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License version 2 as +* published by the Free Software Foundation. +* +*/ + +/* This is an example of how to declare and register SPI devices which +* are not declared at arch init time. +*/ + +#include <linux/device.h> +#include <linux/init.h> +#include <linux/module.h> +#include "../../include/linux/spi/spi.h" + +struct spi_board_info parport_eeprom_board = { + .modalias ="eeprom" , + .max_speed_hz =500000 , + .bus_num =1 , + .chip_select =2 , +}; + +struct spi_device *device; + +static int __init parport_plat_init (void ) +{ +struct spi_master *master; + + master =spi_busnum_to_master (parport_eeprom_board.bus_num); +if (master) + { + device =spi_new_device (master, &parport_eeprom_board); +if (device) +printk ("Registerd to bus %s\n" , device->dev.bus_id); +else + { +printk ("Failed registering %s !\n" , parport_eeprom_board.modalias); +return -ENODEV ; + } + } +else + { +printk ("No master!\n" ); +return -ENODEV ; + } + +return 0 ; +} + +static void __exit parport_plat_cleanup(void) +{ +spi_unregister_device (device); +} + +module_init (parport_plat_init); +module_exit (parport_plat_cleanup); + +MODULE_LICENSE ("GPL" ); +MODULE_AUTHOR ("Mark Underwood basicmark(at)yahoo.com" ); +MODULE_DESCRIPTION ("SPI parport adapter with eeprom platform file" );
Quoted 28 lines
Quoted 7 lines
Quoted 6 lines
If there's more than one SPI controller onboard,
spi_write_then_readwill serialize the transfers ...Quoted 7 lines
Which, as has been pointed out, would be a trivial thing to fix if anyone were actually to have a problem. Sure it'd incur the cost of a kmalloc on at least some paths -- serializing in the slab layer instead! -- but that's one price of using convenience helpers not performance oriented calls.
Well, most of the drivers will use that helpers I guess.
The thing however is that if you try to implement this in a "clean" way you will come to a sport of framework we've developed for memeory allocations, as I've saild previously.Quoted 9 lines
Quoted 8 lines
Moreover, if, say, two
kernel threads with different priorities are working with two SPI controllers respectively *priority inversion* will happen.
Quoted 9 lines
Quoted 5 lines
That characteristic being inherited from semaphores (or were they updated with
RT_PREEMPT?), and being in common with most I/O queues in the system. Not something to blame on any line of code I wrote.I think they weren't.
The whole thing doesn't seem thought out nicely to me. The solution exists, of course, and that is -- do somthing similar to what we did there.
I know what priority inversion is and I can't see where I would happen in Davids SPI core.
I'm sorry but your transfer technique is far more complex then it needs to be. Davids transfer technique follows that of the USB subsystem, why do you think that SPI, which is _much simpler_, requires this amount of complexity?
In your subsystem for every adapter you _force_ and thread and a workqueue on that adapter :(, most adapter drivers will not need either!
Quoted 6 lines
Quoted 6 lines
Oh, and I noticed a priority inversion in your API which shows up with one SPI controller managing two devices. Whoops! I'd far rather have such inversions be implementation artifacts; it's easy to patch an implementation, hard to change all API users.
Quoted 8 lines
Not sure if I understood you. Can you please describe the situation when this prio inversion happens?
What priorities are you talking about? One controller is one thread, so it's _one_ priority, consequently there's nothing to invert. As for your second statement, I don't argue. The fact however is that if you implement the mehtod which corrects priority inverstion problems your core will not be either so lightweight or so flexible. :)
What priority inversion problem is there to fix in Davids core !?!
Quoted 54 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 7 lines
- it's more adapted for use in real-time environments
- it's not so lightweight, but it leaves less effort for the bus driver developer.But also less flexibility. A core layer shouldn't _force_ a policy
Quoted 10 lines
Quoted 3 lines
Nope, it's just a default policy.
One that every driver pays the price for. Allocating a task even when it doesn't need it; every call going through a midlayer that wants to take over queue management policy; and more. (Unless you made a big un-remarked change in a patch you called "refresh"...)
It's not obvious that this price is high.
Anyway, it's a point I should agree with; this functionality better be a config option. Feel free to submit a patch, as you like to say.Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
on a bus driver. I am currently developing an adapter driver for David's system and I
wouldn't say
Quoted 1 line
Quoted 1 line
Quoted 1 line
that the core is making me do things I think the core should do. Please could you provide
examples
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
of where you think Davids SPI core requires 'effort'.
Main are
- the need to call 'complete' in controller driverQuoted 9 lines
So you think it's better to have consistent semantics be optional?
That seems to be the notion behind your
spi_transfer()call, which can't decide whether it's going to be synchronous or asynchronous. Instead, it decided to be error prone and be both. :)Not sure if I understood you here, sorry.
Quoted 4 lines
Quoted 3 lines
- the need to implement policy in controller driver
Quoted 7 lines
Quoted 6 lines
The "policy" in question is something that sometimes needs to be board-specific -- priority to THAT device, synch with THIS external signal, etc -- which is why I see it as a drawback that you insist the core implement one policy.
Again, the policy can be overridden.
I thought in general a device driver should't force a policy on its use surely this goes double (or more) for a driver core.
Mark
Quoted 3 lines
Vitaly
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Quoted 6 lines · Vitaly Wool
Greetings,
This is an updated version of SPI framework developed by Dmitry Pervushin and Vitaly Wool.
The main changes are:
Quoted 8 lines
- Matching rmk's 2.6.14-git5+ changes for
device_driversuspend and resume calls
- The character device interface was reworkedI still think that we need to continue converging with David Brownell's core, despite some misalignments happening in the email exchange :). Although it's not yet done in our core, I plan to move to
- using chained SPI messages as David does
- maybe rework the SPI device interface more taking David's one as a reference
I think you both need to work together to come to some kind of understanding before either one can make it into mainline.
Quoted 4 lines
However, there also are some advantages of our core compared to David's I'd like to mention
- it can be compiled as a module
- it is DMA-safe
What do you mean by this?
Quoted 1 line
- it is priority inversion-free
And David's isn't?
Quoted 1 line
- it can gain more performance with multiple controllers
What do you mean by this?
Quoted 1 line
- it's more adapted for use in real-time environments
Again, more explaination please.
Quoted 1 line
- it's not so lightweight, but it leaves less effort for the bus driver developer.
So bus drivers are smaller than David's? But with what tradeoffs?
Quoted 1 line
+#define
kzalloc(size,type)kcalloc(1,size,type)
kzalloc is already a kernel function, please don't overload it.
include/linux/spi.h line 53
Quoted 4 lines
include/linux/spi.h +4
-0+#define TO_SPI_DEV (device) container_of( device, struct spi_device, dev ) +struct spi_device { +char name[BUS_ID_SIZE ]; +void *private;
struct device already has a private pointer, please use that.
include/linux/spi.h line 55
Quoted 2 lines
include/linux/spi.h +2
-0+int minor; +struct class_device *cdev;
struct class_device has a dev_t, why not use that?
include/linux/spi.h line 72
Quoted 2 lines
include/linux/spi.h +2
-0+#define spi_device_lock ( dev )/* down( dev->dev.sem ) */ +#define spi_device_unlock ( dev )/* up( dev->dev.sem ) */
Um, that doesn't look good...
include/linux/spi.h line 77
Quoted 5 lines
include/linux/spi.h +5
-0+ +/* +* struct spi_msg +* +* This structure represent the SPI message internally. You should never use fields of this structure directly
Proper line lenght please.
And document these structures using kerneldoc, explaining what the different fields are. Especially for new stuff like this.
Quoted 1 line
+ * Please use corresponding functions to create/destroy/access fields
Those functions are?
Quoted 5 lines
+ *
+ */include/linux/spi.h +3
-0+struct spi_msg { +u32 flags; +#define SPI_M_RD 0x00000001
include/linux/spi.h line 93
Quoted 10 lines
include/linux/spi.h +10
-0+#define SPI_M_WR 0x00000002/**< Write mode flag */ +#define SPI_M_CSREL 0x00000004/**< CS release level at end of the frame */ +#define SPI_M_CS 0x00000008/**< CS active level at begining of frame ( default low ) */ +#define SPI_M_CPOL 0x00000010/**< Clock polarity */ +#define SPI_M_CPHA 0x00000020/**< Clock Phase */ +#define SPI_M_EXTBUF 0x80000000/** externally allocated buffers */ +#define SPI_M_ASYNC_CB 0x40000000/** use workqueue to deliver callbacks */ +#define SPI_M_DNA 0x20000000/** do not allocate buffers */ + +unsigned short len;/* msg length */
u16 perhaps?
include/linux/spi.h line 94
Quoted 1 line
include/linux/spi.h +1
-0+unsigned long clock;
Do you really want unsigned long here?
include/linux/spi.h line 98
Quoted 4 lines
include/linux/spi.h +4
-0+struct spi_device *device; +void *context; +void *arg; +void *parent;/* in case of complex messages */
That's a lot of void pointers, not good.
include/linux/spi.h line 103
Quoted 5 lines
include/linux/spi.h +5
-0+struct list_head link; + +void (*status) (struct spi_msg * msg,int code); + +void *devbuf_rd, *devbuf_wr;
What are these for?
include/linux/spi.h line 114
Quoted 11 lines
include/linux/spi.h +11
-0+u8 *databuf_rd, *databuf_wr; + +struct work_struct wq_item; +}; + +#ifdef CONFIG_SPI_CHARDEV +extern struct class_device *spi_class_device_create (int minor,struct device *device); +extern void spi_class_device_destroy (int minor); +#else +#define spi_class_device_create (a, b) NULL +#define spi_class_device_destroy (a) do { } while (0)
Make these inline to get typechecking if the option is disabled.
Quoted 78 lines
include/linux/spi.h +78
-0+#endif + +static inline struct spi_msg *spimsg_alloc (struct spi_device *device, +unsigned flags, +unsigned short len, +void (*status) (struct spi_msg *, +int code)) +{ +struct spi_msg *msg; +struct spi_driver *drv =SPI_DEV_DRV (device); +int msgsize =sizeof (struct spi_msg ); + +if (drv->alloc || (flags & (SPI_M_RD |SPI_M_WR )) == (SPI_M_RD |SPI_M_WR ) ) { +pr_debug ("%s: external buffers\n" , __FUNCTION__ ); + flags |=SPI_M_EXTBUF ; + }else { +pr_debug ("%s: no ext buffers, msgsize increased from %d by %d to %d\n" , __FUNCTION__, + msgsize, len, msgsize + len ); + msgsize += len; + } + + msg =kmalloc ( msgsize,GFP_KERNEL ); +if (!msg) +return NULL ; +memset (msg,0 ,sizeof (struct spi_msg )); + msg->len = len; + msg->status = status; + msg->device = device; + msg->flags = flags; +INIT_LIST_HEAD (&msg->link); + +if (flags &SPI_M_DNA ) +return msg; + +/* otherwise, we need to set up pointers */ +if (!(flags &SPI_M_EXTBUF )) { + msg->databuf_rd = msg->databuf_wr = + (u8 *)msg +sizeof (struct spi_msg ); + }else { +if (flags &SPI_M_RD ) { + msg->devbuf_rd = drv->alloc ? + drv->alloc (len,GFP_KERNEL ) :kmalloc (len,GFP_KERNEL ); + msg->databuf_rd = drv->get_buffer ? + drv->get_buffer (device, msg->devbuf_rd) : msg->devbuf_rd; + } +if (flags &SPI_M_WR ) { + msg->devbuf_wr = drv->alloc ? + drv->alloc (len,GFP_KERNEL ) :kmalloc (len,GFP_KERNEL ); + msg->databuf_wr = drv->get_buffer ? + drv->get_buffer (device, msg->devbuf_wr) : msg->devbuf_wr; + } + } +pr_debug ("%s: msg = %p, RD=(%p,%p) WR=(%p,%p). Actual flags = %s+%s\n" , + __FUNCTION__, + msg, + msg->devbuf_rd, msg->databuf_rd, + msg->devbuf_wr, msg->databuf_wr, + msg->flags &SPI_M_RD ?"RD" :"~rd" , + msg->flags &SPI_M_WR ?"WR" :"~wr" ); +return msg; +} + +static inline void spimsg_free (struct spi_msg *msg) +{ +void (*do_free) (const void *) = kfree; +struct spi_driver *drv =SPI_DEV_DRV (msg->device); + +if (msg) { + +if ( !(msg->flags &SPI_M_DNA ) || (msg->flags &SPI_M_EXTBUF ) ) { +if (drv->free) + do_free = drv->free; +if (drv->release_buffer) { +if (msg->databuf_rd) + drv->release_buffer (msg->device, + msg->databuf_rd); +if (msg->databuf_wr) + drv->release_buffer(msg->device,
include/linux/spi.h line 202
Quoted 10 lines
include/linux/spi.h +10
-0+ msg->databuf_wr); + } +if (msg->devbuf_rd) +do_free (msg->devbuf_rd); +if (msg->devbuf_wr) +do_free (msg->devbuf_wr); + } +kfree (msg); + } +}
These are all pretty big functions to be inline in a .h file, don't you think?
include/linux/spi.h line 295
Quoted 12 lines
include/linux/spi.h +12
-0+extern int spi_bus_populate (struct device *parent,char *device, +void (*assign) (struct device *parent, +struct spi_device *)); +struct spi_device_desc { +char * name; +void * params; +}; +extern int spi_bus_populate2 (struct device *parent, +struct spi_device_desc *devices, +void (*assign) (struct device *parent, +struct spi_device *, +void *));
Where is spi_bus_populate3 and 4? :)
thanks.
greg k-h
And here's what you were comparing it to. I'll post this twice, once inline (here) for inlined followups, and once as an attachment (next) for anyone that wants to apply it ... since I recall "kmail" liking to zealously mangle tabs and line ends.
Oh, and a bitbang/parport driver seems to be limping. :)
- Dave
This is the core of a small SPI framework, implementing the model of a queue of messages which complete asynchronously (with thin synchronous wrappers on top).
- It's still less than 2KB of ".text" (ARM). If there's got to be a mid-layer for something so simple, that's the right size budget. :)
- The guts use board-specific SPI device tables to build the driver model tree. (Hardware probing is rarely an option.)
- This version of Kconfig includes no drivers. At this writing there are two known master controller drivers (PXA/SSP, OMAP MicroWire) and three protocol drivers (CS8415a, ADS7846, DataFlash) with LKML mentions of other drivers in development.
- No userspace API. There are several implementations to compare. Implement them like any other driver, and bind them with sysfs.
The changes from last version posted to LKML (on 11-Nov-2005) are minor, and include:
- One bugfix (removes a FIXME), with the visible effect of making device names be "spiB.C" where B is the bus number and C is the chipselect.
- The "caller provides DMA mappings" mechanism now has kerneldoc, for DMA drivers that want to be fancy.
- Hey, the framework init can be subsys_init. Even though board init logic fires earlier, at arch_init ... since the framework init is for driver support, and the board init support uses static init.
- Various additional spec/doc clarifications based on discussions with other folk. It adds a brief "thank you" at the end, for folk who've helped nudge this framework into existence.
NOTE: The version now in the "mm" tree had to change the "hotplug" callback to be named "uevent"; driver model changes. And of course, for hotplugging to work, /sbin/hotplug should "modprobe $MODALIAS".
include/linux/spi/spi.h new file +542 -0
@@ -0,0 +1,542 @@ +/* +* 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 + +/* +* INTERFACES between SPI master drivers and infrastructure +* (There's no SPI slave support for Linux yet...) +* +* A "struct device_driver" for an spi_device uses "spi_bus_type" and +* needs no special API wrappers (much like platform_bus). These drivers +* are bound to devices based on their names (much like platform_bus), +* and are available in dev->driver. +*/ +extern struct bus_type spi_bus_type; + +/** +* struct spi_device - Master side proxy for an SPI slave device +* @dev: Driver model representation of the device. +* @master: SPI controller used with the device. +* @max_speed_hz: Maximum clock rate to be used with this chip +* (on this board); may be changed by the device's driver. +* @chip-select: Chipselect, distinguishing chips handled by "master". +* @mode: The spi mode defines how data is clocked out and in. +* This may be changed by the device's driver. +* @bits_per_word: Data transfers involve one or more words; word sizes +* like eight or 12 bits are common. In-memory wordsizes are +* powers of two bytes (e.g. 20 bit samples use 32 bits). +* This may be changed by the device's driver. +* @irq: Negative, or the number passed to request_irq() to receive +* interrupts from this device. +* @controller_state: Controller's runtime state +* @controller_data: Static board-specific definitions for controller, such +* as FIFO initialization parameters; from board_info.controller_data +* +* An spi_device is used to interchange data between an SPI slave +* (usually a discrete chip) and CPU memory. +* +* In "dev", the platform_data is used to hold information about this +* device that's meaningful to the device's protocol driver, but not +* to its controller. One example might be an identifier for a chip +* variant with slightly different functionality. +*/ +struct spi_device { +struct device dev; +struct spi_master *master; +u32 max_speed_hz; +u8 chip_select; +u8 mode; +#define SPI_CPHA 0x01/* clock phase */ +#define SPI_CPOL 0x02/* clock polarity */ +#define SPI_MODE_0 (0|0) +#define SPI_MODE_1 (0|SPI_CPHA)/* original MicroWire */ +#define SPI_MODE_2 (SPI_CPOL|0) +#define SPI_MODE_3 (SPI_CPOL|SPI_CPHA) +#define SPI_CS_HIGH 0x04/* chipselect active high? */ +u8 bits_per_word; +int irq; +void *controller_state; +const void *controller_data; +const char *modalias; + +// likely need more hooks for more protocol options affecting how +// the controller talks to its chips, like: +// - bit order (default is wordwise msb-first) +// - memory packing (12 bit samples into low bits, others zeroed) +// - priority +// - chipselect delays +// - ... +}; + +static inline struct spi_device *to_spi_device (struct device *dev) +{ + return container_of(dev, struct spi_device, dev); +} + +/* most drivers won't need to care about device refcounting */ +static inline struct spi_device *spi_dev_get (struct spi_device *spi) +{ +return (spi &&get_device (&spi->dev)) ? spi :NULL ; +} + +static inline void spi_dev_put (struct spi_device *spi) +{ +if (spi) +put_device (&spi->dev); +} + +/* ctldata is for the bus_master driver's runtime state */ +static inline void *spi_get_ctldata (struct spi_device *spi) +{ +return spi->controller_state; +} + +static inline void spi_set_ctldata (struct spi_device *spi,void *state) +{ + spi->controller_state = state; +} + + +struct spi_message ; + + +/** +* struct spi_master - interface to SPI master controller +* @cdev: class interface to this driver +* @bus_num: board-specific (and often SOC-specific) identifier for a +* given SPI controller. +* @num_chipselect: chipselects are used to distinguish individual +* SPI slaves, and are numbered from zero to num_chipselects. +* each slave has a chipselect signal, but it's common that not +* every chipselect is connected to a slave. +* @setup: updates the device mode and clocking records used by a +* device's SPI controller; protocol code may call this. +* @transfer: adds a message to the controller's transfer queue. +* @cleanup: frees controller-specific state +* +* Each SPI master controller can communicate with one or more spi_device +* children. These make a small bus, sharing MOSI, MISO and SCK signals +* but not chip select signals. Each device may be configured to use a +* different clock rate, since those shared signals are ignored unless +* the chip is selected. +* +* The driver for an SPI controller manages access to those devices through +* a queue of spi_message transactions, copyin data between CPU memory and +* an SPI slave device). For each such message it queues, it calls the +* message's completion function when the transaction completes. +*/ +struct spi_master { +struct class_device cdev; + +/* other than zero (== 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, +* and one board's schematics might show it using SPI-2. software +* would normally use bus_num=2 for that controller. +*/ +u16 bus_num; + +/* chipselects will be integral to many controllers; some others +* might use board-specific GPIOs. +*/ +u16 num_chipselect; + +/* setup mode and clock, etc (spi driver may call many times) */ +int (*setup)(struct spi_device *spi); + +/* bidirectional bulk transfers +* +* + The transfer() method may not sleep; its main role is +* just to add the message to the queue. +* + For now there's no remove-from-queue operation, or +* any other request management +* + To a given spi_device, message queueing is pure fifo +* +* + The master's main job is to process its message queue, +* selecting a chip then transferring data +* + If there are multiple spi_device children, the i/o queue +* arbitration algorithm is unspecified (round robin, fifo, +* priority, reservations, preemption, etc) +* +* + Chipselect stays active during the entire message +* (unless modified by spi_transfer.cs_change != 0). +* + The message transfers use clock and SPI mode parameters +* previously established by setup() for this device +*/ +int (*transfer)(struct spi_device *spi, +struct spi_message *mesg); + +/* called on release() to free memory provided by spi_master */ +void (*cleanup)(const struct spi_device *spi); +}; + +/* the spi driver core manages memory for the spi_master classdev */ +extern struct spi_master * +spi_alloc_master (struct device *host,unsigned size); + +extern int spi_register_master (struct spi_master *master); +extern void spi_unregister_master (struct spi_master *master); + +extern struct spi_master *spi_busnum_to_master (u16 busnum); + +/*---------------------------------------------------------------------------*/ + +/* +* I/O INTERFACE between SPI controller and protocol drivers +* +* Protocol drivers use a queue of spi_messages, each transferring data +* between the controller and memory buffers. +* +* The spi_messages themselves consist of a series of read+write transfer +* segments. Those segments always read the same number of bits as they +* write; but one or the other is easily ignored by passing a null buffer +* pointer. (This is unlike most types of I/O API, because SPI hardware +* is full duplex.) +* +* NOTE: Allocation of spi_transfer and spi_message memory is entirely +* up to the protocol driver, which guarantees the integrity of both (as +* well as the data buffers) for as long as the message is queued. +*/ + +/** +* struct spi_transfer - a read/write buffer pair +* @tx_buf: data to be written (dma-safe address), or NULL +* @rx_buf: data to be read (dma-safe address), or NULL +* @tx_dma: DMA address of buffer, if spi_message.is_dma_mapped +* @rx_dma: DMA address of buffer, if spi_message.is_dma_mapped +* @len: size of rx and tx buffers (in bytes) +* @cs_change: affects chipselect after this transfer completes +* @delay_usecs: microseconds to delay after this transfer before +* (optionally) changing the chipselect status, then starting +* the next transfer or completing this spi_message. +* +* SPI transfers always write the same number of bytes as they read. +* Protocol drivers should always provide rx_buf and/or tx_buf. +* In some cases, they may also want to provide DMA addresses for +* the data being transferred; that may reduce overhead, when the +* underlying driver uses dma. +* +* All SPI transfers start with the relevant chipselect active. Drivers +* can change behavior of the chipselect after the transfer finishes +* (including any mandatory delay). The normal behavior is to leave it +* selected, except for the last transfer in a message. Setting cs_change +* allows two additional behavior options: +* +* (i) If the transfer isn't the last one in the message, this flag is +* used to make the chipselect briefly go inactive in the middle of the +* message. Toggling chipselect in this way may be needed to terminate +* a chip command, letting a single spi_message perform all of group of +* chip transactions together. +* +* (ii) When the transfer is the last one in the message, the chip may +* stay selected until the next transfer. This is purely a performance +* hint; the controller driver may need to select a different device +* for the next message. +*/ +struct spi_transfer { +/* it's ok if tx_buf == rx_buf (right?) +* for MicroWire, one buffer must be null +* buffers must work with dma_*map_single() calls +*/ +const void *tx_buf; +void *rx_buf; +unsigned len; + +dma_addr_t tx_dma; +dma_addr_t rx_dma; + +unsigned cs_change:1 ; +u16 delay_usecs; +}; + +/** +* struct spi_message - one multi-segment SPI transaction +* @transfers: the segements of the transaction +* @n_transfer: how many segments +* @spi: SPI device to which the transaction is queued +* @is_dma_mapped: if true, the caller provided both dma and cpu virtual +* addresses for each transfer buffer +* @complete: called to report transaction completions +* @context: the argument to complete() when it's called +* @actual_length: how many bytes were transferd +* @status: zero for success, else negative errno +* @queue: for use by whichever driver currently owns the message +* @state: for use by whichever driver currently owns the message +*/ +struct spi_message { +struct spi_transfer *transfers; +unsigned n_transfer; + +struct spi_device *spi; + +unsigned is_dma_mapped:1 ; + +/* REVISIT: we might want a flag affecting the behavior of the +* last transfer ... allowing things like "read 16 bit length L" +* immediately followed by "read L bytes". Basically imposing +* a specific message scheduling algorithm. +* +* Some controller drivers (message-at-a-time queue processing) +* could provide that as their default scheduling algorithm. But +* others (with multi-message pipelines) could need a flag to +* tell them about such special cases. +*/ + +/* completion is reported through a callback */ + void FASTCALL((*complete)(void *context)); +void *context; +unsigned actual_length; +int status; + +/* for optional use by whatever driver currently owns the +* spi_message ... between calls to spi_async and then later +* complete(), that's the spi_master controller driver. +*/ +struct list_head queue; +void *state; +}; + +/** +* spi_setup -- setup SPI mode and clock rate +* @spi: the device whose settings are being modified +* +* SPI protocol drivers may need to update the transfer mode if the +* device doesn't work with the mode 0 default. They may likewise need +* to update clock rates or word sizes from initial values. This function +* changes those settings, and must be called from a context that can sleep. +*/ +static inline int +spi_setup (struct spi_device *spi) +{ +return spi->master->setup (spi); +} + + +/** +* spi_async -- asynchronous SPI transfer +* @spi: device with which data will be exchanged +* @message: describes the data transfers, including completion callback +* +* This call may be used in_irq and other contexts which can't sleep, +* as well as from task contexts which can sleep. +* +* The completion callback is invoked in a context which can't sleep. +* Before that invocation, the value of message->status is undefined. +* When the callback is issued, message->status holds either zero (to +* indicate complete success) or a negative error code. +* +* Note that although all messages to a spi_device are handled in +* FIFO order, messages may go to different devices in other orders. +* Some device might be higher priority, or have various "hard" access +* time requirements, for example. +*/ +static inline int +spi_async (struct spi_device *spi,struct spi_message *message) +{ + message->spi = spi; +return spi->master->transfer (spi, message); +} + +/*---------------------------------------------------------------------------*/ + +/* All these synchronous SPI transfer routines are utilities layered +* over the core async transfer primitive. Here, "synchronous" means +* they will sleep uninterruptibly until the async transfer completes. +*/ + +extern int spi_sync (struct spi_device *spi,struct spi_message *message); + +/** +* spi_write - SPI synchronous write +* @spi: device to which data will be written +* @buf: data buffer +* @len: data buffer size +* +* This writes the buffer and returns zero or a negative error code. +* Callable only from contexts that can sleep. +*/ +static inline int +spi_write (struct spi_device *spi,const u8 *buf,size_t len) +{ +struct spi_transfer t = { + .tx_buf = buf, + .rx_buf =NULL , + .len = len, + .cs_change =0 , + }; +struct spi_message m = { + .transfers = &t, + .n_transfer =1 , + }; + +return spi_sync (spi, &m); +} + +/** +* spi_read - SPI synchronous read +* @spi: device from which data will be read +* @buf: data buffer +* @len: data buffer size +* +* This writes the buffer and returns zero or a negative error code. +* Callable only from contexts that can sleep. +*/ +static inline int +spi_read (struct spi_device *spi,u8 *buf,size_t len) +{ +struct spi_transfer t = { + .tx_buf =NULL , + .rx_buf = buf, + .len = len, + .cs_change =0 , + }; +struct spi_message m = { + .transfers = &t, + .n_transfer =1 , + }; + +return spi_sync (spi, &m); +} + +extern int spi_write_then_read (struct spi_device *spi, +const u8 *txbuf,unsigned n_tx, +u8 *rxbuf,unsigned n_rx); + +/** +* spi_w8r8 - SPI synchronous 8 bit write followed by 8 bit read +* @spi: device with which data will be exchanged +* @cmd: command to be written before data is read back +* +* This returns the (unsigned) eight bit number returned by the +* device, or else a negative error code. Callable only from +* contexts that can sleep. +*/ +static inline ssize_t spi_w8r8 (struct spi_device *spi,u8 cmd) +{ +ssize_t status; +u8 result; + + status =spi_write_then_read (spi, &cmd,1 , &result,1 ); + +/* return negative errno or unsigned value */ +return (status <0 ) ? status : result; +} + +/** +* spi_w8r16 - SPI synchronous 8 bit write followed by 16 bit read +* @spi: device with which data will be exchanged +* @cmd: command to be written before data is read back +* +* This returns the (unsigned) sixteen bit number returned by the +* device, or else a negative error code. Callable only from +* contexts that can sleep. +* +* The number is returned in wire-order, which is at least sometimes +* big-endian. +*/ +static inline ssize_t spi_w8r16 (struct spi_device *spi,u8 cmd) +{ +ssize_t status; +u16 result; + + status =spi_write_then_read (spi, &cmd,1 , (u8 *) &result,2 ); + +/* return negative errno or unsigned value */ +return (status <0 ) ? status : result; +} + +/*---------------------------------------------------------------------------*/ + +/* +* INTERFACE between board init code and SPI infrastructure. +* +* No SPI driver ever sees these SPI device table segments, but +* it's how the SPI core (or adapters that get hotplugged) grows +* the driver model tree. +* +* As a rule, SPI devices can't be probed. Instead, board init code +* provides a table listing the devices which are present, with enough +* information to bind and set up the device's driver. There's basic +* support for nonstatic configurations too; enough to handle adding +* parport adapters, or microcontrollers acting as USB-to-SPI bridges. +*/ + +/* board-specific information about each SPI device */ +struct spi_board_info { +/* the device name and module name are coupled, like platform_bus; +* "modalias" is normally the driver name. +* +* platform_data goes to spi_device.dev.platform_data, +* controller_data goes to spi_device.platform_data, +* irq is copied too +*/ +char modalias[KOBJ_NAME_LEN ]; +const void *platform_data; +const void *controller_data; +int irq; + +/* slower signaling on noisy or low voltage boards */ +u32 max_speed_hz; + + +/* bus_num is board specific and matches the bus_num of some +* spi_master that will probably be registered later. +* +* chip_select reflects how this chip is wired to that master; +* it's less than num_chipselect. +*/ +u16 bus_num; +u16 chip_select; + +/* ... may need additional spi_device chip config data here. +* avoid stuff protocol drivers can set; but include stuff +* needed to behave without being bound to a driver: +* - chipselect polarity +* - quirks like clock rate mattering when not selected +*/ +}; + +#ifdef CONFIG_SPI +extern int +spi_register_board_info (struct spi_board_info const *info,unsigned n); +#else +/* board init code may ignore whether SPI is configured or not */ +static inline int +spi_register_board_info (struct spi_board_info const *info,unsigned n) + {return 0 ; } +#endif + + +/* If you're hotplugging an adapter with devices (parport, usb, etc) +* use spi_new_device() to describe each device. You can also call +* spi_unregister_device() to get start making that device vanish, +* but normally that would be handled by spi_unregister_master(). +*/ +extern struct spi_device * +spi_new_device (struct spi_master *,struct spi_board_info *); + +static inline void +spi_unregister_device (struct spi_device *spi) +{ +if (spi) +device_unregister (&spi->dev); +} + +#endif /* __LINUX_SPI_H */
drivers/spi/spi.c new file +557 -0
557 lines not on this page · raw message
drivers/spi/Kconfig new file +91 -0
91 lines not on this page · raw message
arch/arm/Kconfig +2 -0
@@ -730,6 +730,8 @@ source "drivers/char/Kconfig" source "drivers/i2c/Kconfig" +source "drivers/spi/Kconfig" + source "drivers/hwmon/Kconfig" #source "drivers/l3/Kconfig"
drivers/Kconfig +2 -0
@@ -44,6 +44,8 @@ source "drivers/char/Kconfig" source "drivers/i2c/Kconfig" +source "drivers/spi/Kconfig" + source "drivers/w1/Kconfig" source "drivers/hwmon/Kconfig"
drivers/Makefile +1 -0
@@ -40,6 +40,7 @@ obj-$(CONFIG_FUSION) += message/ obj-$(CONFIG_IEEE1394) += ieee1394/ obj-y += cdrom/ obj-$(CONFIG_MTD) += mtd/ +obj-$(CONFIG_SPI) += spi/ obj-$(CONFIG_PCCARD) += pcmcia/ obj-$(CONFIG_DIO) += dio/ obj-$(CONFIG_SBUS) += sbus/
drivers/spi/Makefile new file +23 -0
@@ -0,0 +1,23 @@ +# +# 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.o + +# SPI master controller drivers (bus) +# ... add above this line ... + +# SPI protocol drivers (device/link on bus) +# ... add above this line ... + +# SPI slave controller drivers (upstream link) +# ... add above this line ... + +# SPI slave drivers (protocol for that link) +# ... add above this line ...
Documentation/spi/spi-summary new file +416 -0
416 lines not on this page · raw message
Here's the attached "mailer doesn't mangle these" version.
This is the core of a small SPI framework, implementing the model of a queue of messages which complete asynchronously (with thin synchronous wrappers on top).
- It's still less than 2KB of ".text" (ARM). If there's got to be a mid-layer for something so simple, that's the right size budget. :)
- The guts use board-specific SPI device tables to build the driver model tree. (Hardware probing is rarely an option.)
- This version of Kconfig includes no drivers. At this writing there are two known master controller drivers (PXA/SSP, OMAP MicroWire) and three protocol drivers (CS8415a, ADS7846, DataFlash) with LKML mentions of other drivers in development.
- No userspace API. There are several implementations to compare. Implement them like any other driver, and bind them with sysfs.
The changes from last version posted to LKML (on 11-Nov-2005) are minor, and include:
- One bugfix (removes a FIXME), with the visible effect of making device names be "spiB.C" where B is the bus number and C is the chipselect.
- The "caller provides DMA mappings" mechanism now has kerneldoc, for DMA drivers that want to be fancy.
- Hey, the framework init can be subsys_init. Even though board init logic fires earlier, at arch_init ... since the framework init is for driver support, and the board init support uses static init.
- Various additional spec/doc clarifications based on discussions with other folk. It adds a brief "thank you" at the end, for folk who've helped nudge this framework into existence.
NOTE: The version now in the "mm" tree had to change the "hotplug" callback to be named "uevent"; driver model changes. And of course, for hotplugging to work, /sbin/hotplug should "modprobe $MODALIAS".
include/linux/spi/spi.h new file +542 -0
@@ -0,0 +1,542 @@ +/* +* 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 + +/* +* INTERFACES between SPI master drivers and infrastructure +* (There's no SPI slave support for Linux yet...) +* +* A "struct device_driver" for an spi_device uses "spi_bus_type" and +* needs no special API wrappers (much like platform_bus). These drivers +* are bound to devices based on their names (much like platform_bus), +* and are available in dev->driver. +*/ +extern struct bus_type spi_bus_type; + +/** +* struct spi_device - Master side proxy for an SPI slave device +* @dev: Driver model representation of the device. +* @master: SPI controller used with the device. +* @max_speed_hz: Maximum clock rate to be used with this chip +* (on this board); may be changed by the device's driver. +* @chip-select: Chipselect, distinguishing chips handled by "master". +* @mode: The spi mode defines how data is clocked out and in. +* This may be changed by the device's driver. +* @bits_per_word: Data transfers involve one or more words; word sizes +* like eight or 12 bits are common. In-memory wordsizes are +* powers of two bytes (e.g. 20 bit samples use 32 bits). +* This may be changed by the device's driver. +* @irq: Negative, or the number passed to request_irq() to receive +* interrupts from this device. +* @controller_state: Controller's runtime state +* @controller_data: Static board-specific definitions for controller, such +* as FIFO initialization parameters; from board_info.controller_data +* +* An spi_device is used to interchange data between an SPI slave +* (usually a discrete chip) and CPU memory. +* +* In "dev", the platform_data is used to hold information about this +* device that's meaningful to the device's protocol driver, but not +* to its controller. One example might be an identifier for a chip +* variant with slightly different functionality. +*/ +struct spi_device { +struct device dev; +struct spi_master *master; +u32 max_speed_hz; +u8 chip_select; +u8 mode; +#define SPI_CPHA 0x01/* clock phase */ +#define SPI_CPOL 0x02/* clock polarity */ +#define SPI_MODE_0 (0|0) +#define SPI_MODE_1 (0|SPI_CPHA)/* original MicroWire */ +#define SPI_MODE_2 (SPI_CPOL|0) +#define SPI_MODE_3 (SPI_CPOL|SPI_CPHA) +#define SPI_CS_HIGH 0x04/* chipselect active high? */ +u8 bits_per_word; +int irq; +void *controller_state; +const void *controller_data; +const char *modalias; + +// likely need more hooks for more protocol options affecting how +// the controller talks to its chips, like: +// - bit order (default is wordwise msb-first) +// - memory packing (12 bit samples into low bits, others zeroed) +// - priority +// - chipselect delays +// - ... +}; + +static inline struct spi_device *to_spi_device (struct device *dev) +{ + return container_of(dev, struct spi_device, dev); +} + +/* most drivers won't need to care about device refcounting */ +static inline struct spi_device *spi_dev_get (struct spi_device *spi) +{ +return (spi &&get_device (&spi->dev)) ? spi :NULL ; +} + +static inline void spi_dev_put (struct spi_device *spi) +{ +if (spi) +put_device (&spi->dev); +} + +/* ctldata is for the bus_master driver's runtime state */ +static inline void *spi_get_ctldata (struct spi_device *spi) +{ +return spi->controller_state; +} + +static inline void spi_set_ctldata (struct spi_device *spi,void *state) +{ + spi->controller_state = state; +} + + +struct spi_message ; + + +/** +* struct spi_master - interface to SPI master controller +* @cdev: class interface to this driver +* @bus_num: board-specific (and often SOC-specific) identifier for a +* given SPI controller. +* @num_chipselect: chipselects are used to distinguish individual +* SPI slaves, and are numbered from zero to num_chipselects. +* each slave has a chipselect signal, but it's common that not +* every chipselect is connected to a slave. +* @setup: updates the device mode and clocking records used by a +* device's SPI controller; protocol code may call this. +* @transfer: adds a message to the controller's transfer queue. +* @cleanup: frees controller-specific state +* +* Each SPI master controller can communicate with one or more spi_device +* children. These make a small bus, sharing MOSI, MISO and SCK signals +* but not chip select signals. Each device may be configured to use a +* different clock rate, since those shared signals are ignored unless +* the chip is selected. +* +* The driver for an SPI controller manages access to those devices through +* a queue of spi_message transactions, copyin data between CPU memory and +* an SPI slave device). For each such message it queues, it calls the +* message's completion function when the transaction completes. +*/ +struct spi_master { +struct class_device cdev; + +/* other than zero (== 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, +* and one board's schematics might show it using SPI-2. software +* would normally use bus_num=2 for that controller. +*/ +u16 bus_num; + +/* chipselects will be integral to many controllers; some others +* might use board-specific GPIOs. +*/ +u16 num_chipselect; + +/* setup mode and clock, etc (spi driver may call many times) */ +int (*setup)(struct spi_device *spi); + +/* bidirectional bulk transfers +* +* + The transfer() method may not sleep; its main role is +* just to add the message to the queue. +* + For now there's no remove-from-queue operation, or +* any other request management +* + To a given spi_device, message queueing is pure fifo +* +* + The master's main job is to process its message queue, +* selecting a chip then transferring data +* + If there are multiple spi_device children, the i/o queue +* arbitration algorithm is unspecified (round robin, fifo, +* priority, reservations, preemption, etc) +* +* + Chipselect stays active during the entire message +* (unless modified by spi_transfer.cs_change != 0). +* + The message transfers use clock and SPI mode parameters +* previously established by setup() for this device +*/ +int (*transfer)(struct spi_device *spi, +struct spi_message *mesg); + +/* called on release() to free memory provided by spi_master */ +void (*cleanup)(const struct spi_device *spi); +}; + +/* the spi driver core manages memory for the spi_master classdev */ +extern struct spi_master * +spi_alloc_master (struct device *host,unsigned size); + +extern int spi_register_master (struct spi_master *master); +extern void spi_unregister_master (struct spi_master *master); + +extern struct spi_master *spi_busnum_to_master (u16 busnum); + +/*---------------------------------------------------------------------------*/ + +/* +* I/O INTERFACE between SPI controller and protocol drivers +* +* Protocol drivers use a queue of spi_messages, each transferring data +* between the controller and memory buffers. +* +* The spi_messages themselves consist of a series of read+write transfer +* segments. Those segments always read the same number of bits as they +* write; but one or the other is easily ignored by passing a null buffer +* pointer. (This is unlike most types of I/O API, because SPI hardware +* is full duplex.) +* +* NOTE: Allocation of spi_transfer and spi_message memory is entirely +* up to the protocol driver, which guarantees the integrity of both (as +* well as the data buffers) for as long as the message is queued. +*/ + +/** +* struct spi_transfer - a read/write buffer pair +* @tx_buf: data to be written (dma-safe address), or NULL +* @rx_buf: data to be read (dma-safe address), or NULL +* @tx_dma: DMA address of buffer, if spi_message.is_dma_mapped +* @rx_dma: DMA address of buffer, if spi_message.is_dma_mapped +* @len: size of rx and tx buffers (in bytes) +* @cs_change: affects chipselect after this transfer completes +* @delay_usecs: microseconds to delay after this transfer before +* (optionally) changing the chipselect status, then starting +* the next transfer or completing this spi_message. +* +* SPI transfers always write the same number of bytes as they read. +* Protocol drivers should always provide rx_buf and/or tx_buf. +* In some cases, they may also want to provide DMA addresses for +* the data being transferred; that may reduce overhead, when the +* underlying driver uses dma. +* +* All SPI transfers start with the relevant chipselect active. Drivers +* can change behavior of the chipselect after the transfer finishes +* (including any mandatory delay). The normal behavior is to leave it +* selected, except for the last transfer in a message. Setting cs_change +* allows two additional behavior options: +* +* (i) If the transfer isn't the last one in the message, this flag is +* used to make the chipselect briefly go inactive in the middle of the +* message. Toggling chipselect in this way may be needed to terminate +* a chip command, letting a single spi_message perform all of group of +* chip transactions together. +* +* (ii) When the transfer is the last one in the message, the chip may +* stay selected until the next transfer. This is purely a performance +* hint; the controller driver may need to select a different device +* for the next message. +*/ +struct spi_transfer { +/* it's ok if tx_buf == rx_buf (right?) +* for MicroWire, one buffer must be null +* buffers must work with dma_*map_single() calls +*/ +const void *tx_buf; +void *rx_buf; +unsigned len; + +dma_addr_t tx_dma; +dma_addr_t rx_dma; + +unsigned cs_change:1 ; +u16 delay_usecs; +}; + +/** +* struct spi_message - one multi-segment SPI transaction +* @transfers: the segements of the transaction +* @n_transfer: how many segments +* @spi: SPI device to which the transaction is queued +* @is_dma_mapped: if true, the caller provided both dma and cpu virtual +* addresses for each transfer buffer +* @complete: called to report transaction completions +* @context: the argument to complete() when it's called +* @actual_length: how many bytes were transferd +* @status: zero for success, else negative errno +* @queue: for use by whichever driver currently owns the message +* @state: for use by whichever driver currently owns the message +*/ +struct spi_message { +struct spi_transfer *transfers; +unsigned n_transfer; + +struct spi_device *spi; + +unsigned is_dma_mapped:1 ; + +/* REVISIT: we might want a flag affecting the behavior of the +* last transfer ... allowing things like "read 16 bit length L" +* immediately followed by "read L bytes". Basically imposing +* a specific message scheduling algorithm. +* +* Some controller drivers (message-at-a-time queue processing) +* could provide that as their default scheduling algorithm. But +* others (with multi-message pipelines) could need a flag to +* tell them about such special cases. +*/ + +/* completion is reported through a callback */ + void FASTCALL((*complete)(void *context)); +void *context; +unsigned actual_length; +int status; + +/* for optional use by whatever driver currently owns the +* spi_message ... between calls to spi_async and then later +* complete(), that's the spi_master controller driver. +*/ +struct list_head queue; +void *state; +}; + +/** +* spi_setup -- setup SPI mode and clock rate +* @spi: the device whose settings are being modified +* +* SPI protocol drivers may need to update the transfer mode if the +* device doesn't work with the mode 0 default. They may likewise need +* to update clock rates or word sizes from initial values. This function +* changes those settings, and must be called from a context that can sleep. +*/ +static inline int +spi_setup (struct spi_device *spi) +{ +return spi->master->setup (spi); +} + + +/** +* spi_async -- asynchronous SPI transfer +* @spi: device with which data will be exchanged +* @message: describes the data transfers, including completion callback +* +* This call may be used in_irq and other contexts which can't sleep, +* as well as from task contexts which can sleep. +* +* The completion callback is invoked in a context which can't sleep. +* Before that invocation, the value of message->status is undefined. +* When the callback is issued, message->status holds either zero (to +* indicate complete success) or a negative error code. +* +* Note that although all messages to a spi_device are handled in +* FIFO order, messages may go to different devices in other orders. +* Some device might be higher priority, or have various "hard" access +* time requirements, for example. +*/ +static inline int +spi_async (struct spi_device *spi,struct spi_message *message) +{ + message->spi = spi; +return spi->master->transfer (spi, message); +} + +/*---------------------------------------------------------------------------*/ + +/* All these synchronous SPI transfer routines are utilities layered +* over the core async transfer primitive. Here, "synchronous" means +* they will sleep uninterruptibly until the async transfer completes. +*/ + +extern int spi_sync (struct spi_device *spi,struct spi_message *message); + +/** +* spi_write - SPI synchronous write +* @spi: device to which data will be written +* @buf: data buffer +* @len: data buffer size +* +* This writes the buffer and returns zero or a negative error code. +* Callable only from contexts that can sleep. +*/ +static inline int +spi_write (struct spi_device *spi,const u8 *buf,size_t len) +{ +struct spi_transfer t = { + .tx_buf = buf, + .rx_buf =NULL , + .len = len, + .cs_change =0 , + }; +struct spi_message m = { + .transfers = &t, + .n_transfer =1 , + }; + +return spi_sync (spi, &m); +} + +/** +* spi_read - SPI synchronous read +* @spi: device from which data will be read +* @buf: data buffer +* @len: data buffer size +* +* This writes the buffer and returns zero or a negative error code. +* Callable only from contexts that can sleep. +*/ +static inline int +spi_read (struct spi_device *spi,u8 *buf,size_t len) +{ +struct spi_transfer t = { + .tx_buf =NULL , + .rx_buf = buf, + .len = len, + .cs_change =0 , + }; +struct spi_message m = { + .transfers = &t, + .n_transfer =1 , + }; + +return spi_sync (spi, &m); +} + +extern int spi_write_then_read (struct spi_device *spi, +const u8 *txbuf,unsigned n_tx, +u8 *rxbuf,unsigned n_rx); + +/** +* spi_w8r8 - SPI synchronous 8 bit write followed by 8 bit read +* @spi: device with which data will be exchanged +* @cmd: command to be written before data is read back +* +* This returns the (unsigned) eight bit number returned by the +* device, or else a negative error code. Callable only from +* contexts that can sleep. +*/ +static inline ssize_t spi_w8r8 (struct spi_device *spi,u8 cmd) +{ +ssize_t status; +u8 result; + + status =spi_write_then_read (spi, &cmd,1 , &result,1 ); + +/* return negative errno or unsigned value */ +return (status <0 ) ? status : result; +} + +/** +* spi_w8r16 - SPI synchronous 8 bit write followed by 16 bit read +* @spi: device with which data will be exchanged +* @cmd: command to be written before data is read back +* +* This returns the (unsigned) sixteen bit number returned by the +* device, or else a negative error code. Callable only from +* contexts that can sleep. +* +* The number is returned in wire-order, which is at least sometimes +* big-endian. +*/ +static inline ssize_t spi_w8r16 (struct spi_device *spi,u8 cmd) +{ +ssize_t status; +u16 result; + + status =spi_write_then_read (spi, &cmd,1 , (u8 *) &result,2 ); + +/* return negative errno or unsigned value */ +return (status <0 ) ? status : result; +} + +/*---------------------------------------------------------------------------*/ + +/* +* INTERFACE between board init code and SPI infrastructure. +* +* No SPI driver ever sees these SPI device table segments, but +* it's how the SPI core (or adapters that get hotplugged) grows +* the driver model tree. +* +* As a rule, SPI devices can't be probed. Instead, board init code +* provides a table listing the devices which are present, with enough +* information to bind and set up the device's driver. There's basic +* support for nonstatic configurations too; enough to handle adding +* parport adapters, or microcontrollers acting as USB-to-SPI bridges. +*/ + +/* board-specific information about each SPI device */ +struct spi_board_info { +/* the device name and module name are coupled, like platform_bus; +* "modalias" is normally the driver name. +* +* platform_data goes to spi_device.dev.platform_data, +* controller_data goes to spi_device.platform_data, +* irq is copied too +*/ +char modalias[KOBJ_NAME_LEN ]; +const void *platform_data; +const void *controller_data; +int irq; + +/* slower signaling on noisy or low voltage boards */ +u32 max_speed_hz; + + +/* bus_num is board specific and matches the bus_num of some +* spi_master that will probably be registered later. +* +* chip_select reflects how this chip is wired to that master; +* it's less than num_chipselect. +*/ +u16 bus_num; +u16 chip_select; + +/* ... may need additional spi_device chip config data here. +* avoid stuff protocol drivers can set; but include stuff +* needed to behave without being bound to a driver: +* - chipselect polarity +* - quirks like clock rate mattering when not selected +*/ +}; + +#ifdef CONFIG_SPI +extern int +spi_register_board_info (struct spi_board_info const *info,unsigned n); +#else +/* board init code may ignore whether SPI is configured or not */ +static inline int +spi_register_board_info (struct spi_board_info const *info,unsigned n) + {return 0 ; } +#endif + + +/* If you're hotplugging an adapter with devices (parport, usb, etc) +* use spi_new_device() to describe each device. You can also call +* spi_unregister_device() to get start making that device vanish, +* but normally that would be handled by spi_unregister_master(). +*/ +extern struct spi_device * +spi_new_device (struct spi_master *,struct spi_board_info *); + +static inline void +spi_unregister_device (struct spi_device *spi) +{ +if (spi) +device_unregister (&spi->dev); +} + +#endif /* __LINUX_SPI_H */
drivers/spi/spi.c new file +557 -0
557 lines not on this page · raw message
drivers/spi/Kconfig new file +91 -0
91 lines not on this page · raw message
arch/arm/Kconfig +2 -0
@@ -730,6 +730,8 @@ source "drivers/char/Kconfig" source "drivers/i2c/Kconfig" +source "drivers/spi/Kconfig" + source "drivers/hwmon/Kconfig" #source "drivers/l3/Kconfig"
drivers/Kconfig +2 -0
@@ -44,6 +44,8 @@ source "drivers/char/Kconfig" source "drivers/i2c/Kconfig" +source "drivers/spi/Kconfig" + source "drivers/w1/Kconfig" source "drivers/hwmon/Kconfig"
drivers/Makefile +1 -0
@@ -40,6 +40,7 @@ obj-$(CONFIG_FUSION) += message/ obj-$(CONFIG_IEEE1394) += ieee1394/ obj-y += cdrom/ obj-$(CONFIG_MTD) += mtd/ +obj-$(CONFIG_SPI) += spi/ obj-$(CONFIG_PCCARD) += pcmcia/ obj-$(CONFIG_DIO) += dio/ obj-$(CONFIG_SBUS) += sbus/
drivers/spi/Makefile new file +23 -0
@@ -0,0 +1,23 @@ +# +# 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.o + +# SPI master controller drivers (bus) +# ... add above this line ... + +# SPI protocol drivers (device/link on bus) +# ... add above this line ... + +# SPI slave controller drivers (upstream link) +# ... add above this line ... + +# SPI slave drivers (protocol for that link) +# ... add above this line ...
Documentation/spi/spi-summary new file +416 -0
416 lines not on this page · raw message
BTW:
Quoted 9 lines · David Brownell
Documentation/spi/spi-summary new file +7
-0+How do I write an "SPI Master Controller Driver"? +------------------------------------------------- +An SPI controller will probably be registered on the platform_bus; write +a driver to bind to the device, whichever bus is involved. + +The main task of this type of driver is to provide an "spi_master". +Use spi_alloc_master() to allocate the master, and class_get_devdata()
Documentation/spi/spi-summary line 371
Quoted 10 lines
Documentation/spi/spi-summary new file +10
-0+to get the driver-private data allocated for that device. + + struct spi_master *master; + struct CONTROLLER *c; + + master = spi_alloc_master(dev, sizeof *c); + if (!master) + return -ENODEV; + + c = class_get_devdata(&master->cdev);
Here's an example of a mixture of two approaches which leads to misleading code.
If you want to have abstract spi_master, then you have to disallow (or at least discourage) explicit usage of spi_master fields, otherwise 'kzalloc is your friend' and you don't have toadd this spi_alloc_master API as it's basically useless IMHO.
As opposed to this, we use abstract handles where possible (i. e. for spi_message).
I'd have understood your dissatisfaction with that if you were consistently following the approach 'expose everything, forget the extensibility, viva lightwieghtness', but you're mixing things.
Vitaly
Quoted 17 lines · Vitaly Wool
BTW:
Quoted 13 lines · David Brownell
Documentation/spi/spi-summary new file +13
-0+How do I write an "SPI Master Controller Driver"? +------------------------------------------------- +An SPI controller will probably be registered on the platform_bus; write +a driver to bind to the device, whichever bus is involved. + +The main task of this type of driver is to provide an "spi_master". +Use spi_alloc_master() to allocate the master, and class_get_devdata() +to get the driver-private data allocated for that device. + + struct spi_master *master; + struct CONTROLLER *c; + + master = spi_alloc_master(dev, sizeof *c);
Quoted 8 lines
Documentation/spi/spi-summary line 371
Quoted 6 lines
Documentation/spi/spi-summary new file +4
-0+ if (!master) + return -ENODEV; + + c = class_get_devdata(&master->cdev);Here's an example of a mixture of two approaches which leads to misleading code.
I can't see that, myself. I count three things, separated in as close to "the usual way" as I've heard of: the spi_master, which essentially bridges some bus (platform etc) to SPI; the class device, associated one-to-one with the master; and the controller state used to implement the bridging.
Have you ever noticed how alloc_etherdev() works? This is much the same approach as that function (and its siblings) use. Not identical, but that could change. The infrastructure code allocates one block for the publicly visible state (spi_master in this case, "struct netdevice" for alloc_netdev) and the private data. You want something like a "netdev_priv" backed by some different implementation?
Quoted 4 lines
If you want to have abstract
spi_master, then you have to disallow (or at least discourage) explicit usage ofspi_masterfields, otherwise 'kzalloc is your friend' and you don't have toadd thisspi_alloc_masterAPI as it's basically useless IMHO.
Well, it's what ensures that the class device is set up reasonably, and incidentally takes its memory management out of the hands of
the controller driver. Of course, "the Right Way" to handle such
class devices has changed recently, and this code may be a closer match to "the Previous Right Way" than the new one. ;)
Quoted 5 lines
As opposed to this, we use abstract handles where possible (i. e. for
spi_message).
I'd have understood your dissatisfaction with that if you were consistently following the approach 'expose everything, forget the extensibility, viva lightwieghtness', but you're mixing things.
Data abstraction isn't all-or-nothing, especially in C. And in particular, there's a lot to be said for low level APIs not being fully opaque ... abstraction has costs, both in terms of growing conceptual complexity (you're supporting multiple things behind the abstraction, else why even bother?), loss of visibility into what's really going on, and in terms of lines of having more source (and likely object) code to cope with.
The opaque way to access a "struct", as C++ or Java users know, is to have get()/set() functions for every member. And at the end of the day, that's just a lot of code bloat, which tends to slow things down (unless someone inlined it all, rather non-opaquely).
So no, I don't see an inconsistency in wrapping up common code so it doesn't have to be copied/pasted everywhere (adding bugs), and not wrapping up code that boils down to "xfer->buf = ptr" (where funcall style wrappers hide how cheap it is).
- Dave
Quoted 1 line · Vitaly Wool
However, there also are some advantages of our core compared to David's I'd like to mention
I'd also be interested in your responses to the comparison I wrote up last week. (Post dated 23-November to that spi-devel list...)
Quoted 1 line
- it can be compiled as a module
Which as I pointed out would be a rather minor patch to mine. There's a bit of code to manage the board-specific SPI tables, which _can't_ be a module. Then there's something less than 2KB of code (ARM .text) that could live in a module. I can't get excited about making that live in a module, but I'd take a patch to change that.
Quoted 1 line
- it is DMA-safe
Which as I pointed out is incorrect. The core API (async) has always been fully DMA-safe. And a **LOT** lower overhead than yours, which allocates buffers behind the back of drivers, and encourages lots of memcpy rather than just doing DMA directly to/from the buffers that are provided by the SPI protocol drivers.
Quoted 3 lines
- it is priority inversion-free
- it can gain more performance with multiple controllers
- it's more adapted for use in real-time environments
You'd have to explain what you mean by all of these. I could guess based on what you've said before (disagree!), but that won't help.
Quoted 1 line
- it's not so lightweight, but it leaves less effort for the bus driver developer.
Whereas in my previous comments about your framework, I think I've pointed out that imposing needless and restrictive policies on how the controller drivers work is a Bad Thing.
- Dave
Quoted 7 lines · David Brownell
Quoted 1 line
- it is DMA-safe
Which as I pointed out is incorrect. The core API (async) has always been fully DMA-safe. And a **LOT** lower overhead than yours, which allocates buffers behind the back of drivers, and encourages lots of memcpy rather than just doing DMA directly to/from the buffers that are provided by the SPI protocol drivers.
Minimal (or no) core intervention on the DMA code path is a good thing. I need to fix some broken hardware with software and must to move 96 bytes from one SPI device to another on the same SPI bus every for 4ms. Needless memcpy's will cause substantial performance problems in my application. Thinner is definitely better.
-Stephen
Quoted 14 lines · Stephen Street
Quoted 10 lines · David Brownell
Quoted 3 lines
- it is DMA-safe
Which as I pointed out is incorrect. The core API (async) has always been fully DMA-safe. And a **LOT** lower overhead than yours, which allocates buffers behind the back of drivers, and encourages lots of memcpy rather than just doing DMA directly to/from the buffers that are provided by the SPI protocol drivers.
Quoted 7 lines
Minimal (or no) core intervention on the DMA code path is a good thing. I need to fix some broken hardware with software and must to move 96 bytes from one SPI device to another on the same SPI bus every for 4ms. Needless memcpy's will cause substantial performance problems in my application. Thinner is definitely better.
Oh yep, I must agree with you here, thanks.
However, it's not a big thing to change memcpy to spi_memcpy which will copy the data only when necessary. That's what I definitely had been doing but didn't include in the patch sent, oops. :( I'll come up with that shortly.
Vitaly
Quoted 11 lines · David Brownell
Quoted 3 lines
- it can be compiled as a module
Which as I pointed out would be a rather minor patch to mine. There's a bit of code to manage the board-specific SPI tables, which _can't_ be a module. Then there's something less than 2KB of code (ARM .text) that could live in a module. I can't get excited about making that live in a module, but I'd take a patch to change that.
Well, it's a sign of convergence :)
Quoted 7 lines
Quoted 6 lines
- it is DMA-safe
Quoted 7 lines
Which as I pointed out is incorrect. The core API (async) has always been fully DMA-safe. And a **LOT** lower overhead than yours, which allocates buffers behind the back of drivers, and encourages lots of memcpy rather than just doing DMA directly to/from the buffers that are provided by the SPI protocol drivers.
Lower overhead? Lemme absolutely disagree with you. Please be aware that memory allocation routines are abstract, so no necessary memory allocation. Yeah, anyway, your latest core doesn't look DMA-unsafe to me.
Quoted 12 lines
Quoted 7 lines
- it is priority inversion-free
- it can gain more performance with multiple controllers
- it's more adapted for use in real-time environmentsYou'd have to explain what you mean by all of these. I could guess based on what you've said before (disagree!), but that won't help.
Your taking semaphore in spi_write_then_read which all the sync routines are based on may lead to priority inversion and of course is not optimal in terms of overall performance, if there's more than one controller (have you tested your core in this situation BTW?) Suppose you have two kernel threads with different priorities dealing with SPI controller each... Of course you'll get priority inversion when the thread with higher prio will wait for semaphore release!
Quoted 12 lines
Quoted 6 lines
- it's not so lightweight, but it leaves less effort for the bus driver developer.
Whereas in my previous comments about your framework, I think I've pointed out that imposing needless and restrictive policies on how the controller drivers work is a Bad Thing.
It's just a *reasonable* _default_ policy.
Vitaly