2018-09-25 17:42:28 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*
|
2018-09-25 17:42:28 +08:00
|
|
|
* Copyright (C) 2005 David Brownell
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __LINUX_SPI_H
|
|
|
|
#define __LINUX_SPI_H
|
|
|
|
|
2020-12-21 23:29:35 +08:00
|
|
|
#include <linux/bits.h>
|
2009-01-05 04:00:47 +08:00
|
|
|
#include <linux/device.h>
|
2009-09-23 07:46:04 +08:00
|
|
|
#include <linux/mod_devicetable.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2012-02-22 17:05:38 +08:00
|
|
|
#include <linux/kthread.h>
|
2013-10-05 18:50:40 +08:00
|
|
|
#include <linux/completion.h>
|
2014-02-02 21:47:47 +08:00
|
|
|
#include <linux/scatterlist.h>
|
2019-01-07 23:51:50 +08:00
|
|
|
#include <linux/gpio/consumer.h>
|
spi: Add a PTP system timestamp to the transfer structure
SPI is one of the interfaces used to access devices which have a POSIX
clock driver (real time clocks, 1588 timers etc). The fact that the SPI
bus is slow is not what the main problem is, but rather the fact that
drivers don't take a constant amount of time in transferring data over
SPI. When there is a high delay in the readout of time, there will be
uncertainty in the value that has been read out of the peripheral.
When that delay is constant, the uncertainty can at least be
approximated with a certain accuracy which is fine more often than not.
Timing jitter occurs all over in the kernel code, and is mainly caused
by having to let go of the CPU for various reasons such as preemption,
servicing interrupts, going to sleep, etc. Another major reason is CPU
dynamic frequency scaling.
It turns out that the problem of retrieving time from a SPI peripheral
with high accuracy can be solved by the use of "PTP system
timestamping" - a mechanism to correlate the time when the device has
snapshotted its internal time counter with the Linux system time at that
same moment. This is sufficient for having a precise time measurement -
it is not necessary for the whole SPI transfer to be transmitted "as
fast as possible", or "as low-jitter as possible". The system has to be
low-jitter for a very short amount of time to be effective.
This patch introduces a PTP system timestamping mechanism in struct
spi_transfer. This is to be used by SPI device drivers when they need to
know the exact time at which the underlying device's time was
snapshotted. More often than not, SPI peripherals have a very exact
timing for when their SPI-to-interconnect bridge issues a transaction
for snapshotting and reading the time register, and that will be
dependent on when the SPI-to-interconnect bridge figures out that this
is what it should do, aka as soon as it sees byte N of the SPI transfer.
Since spi_device drivers are the ones who'd know best how the peripheral
behaves in this regard, expose a mechanism in spi_transfer which allows
them to specify which word (or word range) from the transfer should be
timestamped.
Add a default implementation of the PTP system timestamping in the SPI
core. This is not going to be satisfactory performance-wise, but should
at least increase the likelihood that SPI device drivers will use PTP
system timestamping in the future.
There are 3 entry points from the core towards the SPI controller
drivers:
- transfer_one: The driver is passed individual spi_transfers to
execute. This is the easiest to timestamp.
- transfer_one_message: The core passes the driver an entire spi_message
(a potential batch of spi_transfers). The core puts the same pre and
post timestamp to all transfers within a message. This is not ideal,
but nothing better can be done by default anyway, since the core has
no insight into how the driver batches the transfers.
- transfer: Like transfer_one_message, but for unqueued drivers (i.e.
the driver implements its own queue scheduling).
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190905010114.26718-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-05 09:01:12 +08:00
|
|
|
#include <linux/ptp_clock_kernel.h>
|
2009-01-05 04:00:47 +08:00
|
|
|
|
2020-12-21 23:29:34 +08:00
|
|
|
#include <uapi/linux/spi/spi.h>
|
|
|
|
|
2014-01-16 20:22:43 +08:00
|
|
|
struct dma_chan;
|
2017-03-01 06:25:18 +08:00
|
|
|
struct property_entry;
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller;
|
2015-06-22 21:00:36 +08:00
|
|
|
struct spi_transfer;
|
2018-04-27 00:18:14 +08:00
|
|
|
struct spi_controller_mem_ops;
|
2009-01-05 04:00:47 +08:00
|
|
|
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
/*
|
2017-05-22 21:11:41 +08:00
|
|
|
* INTERFACES between SPI master-side drivers and SPI slave protocol handlers,
|
|
|
|
* and SPI infrastructure.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*/
|
|
|
|
extern struct bus_type spi_bus_type;
|
|
|
|
|
2015-06-22 21:00:36 +08:00
|
|
|
/**
|
|
|
|
* struct spi_statistics - statistics for spi transfers
|
2015-09-15 19:59:21 +08:00
|
|
|
* @lock: lock protecting this structure
|
2015-06-22 21:00:36 +08:00
|
|
|
*
|
|
|
|
* @messages: number of spi-messages handled
|
|
|
|
* @transfers: number of spi_transfers handled
|
|
|
|
* @errors: number of errors during spi_transfer
|
|
|
|
* @timedout: number of timeouts during spi_transfer
|
|
|
|
*
|
|
|
|
* @spi_sync: number of times spi_sync is used
|
|
|
|
* @spi_sync_immediate:
|
|
|
|
* number of times spi_sync is executed immediately
|
|
|
|
* in calling context without queuing and scheduling
|
|
|
|
* @spi_async: number of times spi_async is used
|
|
|
|
*
|
|
|
|
* @bytes: number of bytes transferred to/from device
|
|
|
|
* @bytes_tx: number of bytes sent to device
|
|
|
|
* @bytes_rx: number of bytes received from device
|
|
|
|
*
|
2015-06-22 21:02:04 +08:00
|
|
|
* @transfer_bytes_histo:
|
|
|
|
* transfer bytes histogramm
|
2015-12-14 23:20:20 +08:00
|
|
|
*
|
|
|
|
* @transfers_split_maxsize:
|
|
|
|
* number of transfers that have been split because of
|
|
|
|
* maxsize limit
|
2015-06-22 21:00:36 +08:00
|
|
|
*/
|
|
|
|
struct spi_statistics {
|
|
|
|
spinlock_t lock; /* lock for the whole structure */
|
|
|
|
|
|
|
|
unsigned long messages;
|
|
|
|
unsigned long transfers;
|
|
|
|
unsigned long errors;
|
|
|
|
unsigned long timedout;
|
|
|
|
|
|
|
|
unsigned long spi_sync;
|
|
|
|
unsigned long spi_sync_immediate;
|
|
|
|
unsigned long spi_async;
|
|
|
|
|
|
|
|
unsigned long long bytes;
|
|
|
|
unsigned long long bytes_rx;
|
|
|
|
unsigned long long bytes_tx;
|
|
|
|
|
2015-06-22 21:02:04 +08:00
|
|
|
#define SPI_STATISTICS_HISTO_SIZE 17
|
|
|
|
unsigned long transfer_bytes_histo[SPI_STATISTICS_HISTO_SIZE];
|
2015-12-14 23:20:20 +08:00
|
|
|
|
|
|
|
unsigned long transfers_split_maxsize;
|
2015-06-22 21:00:36 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
void spi_statistics_add_transfer_stats(struct spi_statistics *stats,
|
|
|
|
struct spi_transfer *xfer,
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr);
|
2015-06-22 21:00:36 +08:00
|
|
|
|
|
|
|
#define SPI_STATISTICS_ADD_TO_FIELD(stats, field, count) \
|
|
|
|
do { \
|
|
|
|
unsigned long flags; \
|
|
|
|
spin_lock_irqsave(&(stats)->lock, flags); \
|
|
|
|
(stats)->field += count; \
|
|
|
|
spin_unlock_irqrestore(&(stats)->lock, flags); \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
#define SPI_STATISTICS_INCREMENT_FIELD(stats, field) \
|
|
|
|
SPI_STATISTICS_ADD_TO_FIELD(stats, field, 1)
|
|
|
|
|
2019-09-26 18:51:30 +08:00
|
|
|
/**
|
|
|
|
* struct spi_delay - SPI delay information
|
|
|
|
* @value: Value for the delay
|
|
|
|
* @unit: Unit for the delay
|
|
|
|
*/
|
|
|
|
struct spi_delay {
|
|
|
|
#define SPI_DELAY_UNIT_USECS 0
|
|
|
|
#define SPI_DELAY_UNIT_NSECS 1
|
|
|
|
#define SPI_DELAY_UNIT_SCK 2
|
|
|
|
u16 value;
|
|
|
|
u8 unit;
|
|
|
|
};
|
|
|
|
|
2019-09-26 18:51:44 +08:00
|
|
|
extern int spi_delay_to_ns(struct spi_delay *_delay, struct spi_transfer *xfer);
|
2019-09-26 18:51:30 +08:00
|
|
|
extern int spi_delay_exec(struct spi_delay *_delay, struct spi_transfer *xfer);
|
|
|
|
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
/**
|
2017-06-13 19:23:52 +08:00
|
|
|
* struct spi_device - Controller side proxy for an SPI slave device
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @dev: Driver model representation of the device.
|
2017-06-13 19:23:52 +08:00
|
|
|
* @controller: SPI controller used with the device.
|
|
|
|
* @master: Copy of controller, for backwards compatibility.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @max_speed_hz: Maximum clock rate to be used with this chip
|
|
|
|
* (on this board); may be changed by the device's driver.
|
2006-02-18 02:02:18 +08:00
|
|
|
* The spi_transfer.speed_hz can override this for each transfer.
|
2017-06-13 19:23:52 +08:00
|
|
|
* @chip_select: Chipselect, distinguishing chips handled by @controller.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @mode: The spi mode defines how data is clocked out and in.
|
|
|
|
* This may be changed by the device's driver.
|
2007-05-08 15:32:21 +08:00
|
|
|
* The "active low" default for chipselect mode can be overridden
|
|
|
|
* (by specifying SPI_CS_HIGH) as can the "MSB first" default for
|
|
|
|
* each word in a transfer (by specifying SPI_LSB_FIRST).
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @bits_per_word: Data transfers involve one or more words; word sizes
|
2006-04-03 02:33:37 +08:00
|
|
|
* like eight or 12 bits are common. In-memory wordsizes are
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* powers of two bytes (e.g. 20 bit samples use 32 bits).
|
2006-04-04 06:46:22 +08:00
|
|
|
* This may be changed by the device's driver, or left at the
|
|
|
|
* default (0) indicating protocol words are eight bit bytes.
|
2006-02-18 02:02:18 +08:00
|
|
|
* The spi_transfer.bits_per_word can override this for each transfer.
|
2019-05-16 00:48:12 +08:00
|
|
|
* @rt: Make the pump thread real time priority.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @irq: Negative, or the number passed to request_irq() to receive
|
2006-04-03 02:33:37 +08:00
|
|
|
* interrupts from this device.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @controller_state: Controller's runtime state
|
2006-01-09 05:34:23 +08:00
|
|
|
* @controller_data: Board-specific definitions for controller, such as
|
2006-04-03 02:33:37 +08:00
|
|
|
* FIFO initialization parameters; from board_info.controller_data
|
2007-05-08 15:32:21 +08:00
|
|
|
* @modalias: Name of the driver to use with this device, or an alias
|
|
|
|
* for that name. This appears in the sysfs "modalias" attribute
|
|
|
|
* for driver coldplugging, and in uevents used for hotplugging
|
2020-03-10 01:16:19 +08:00
|
|
|
* @driver_override: If the name of a driver is written to this attribute, then
|
|
|
|
* the device will bind to the named driver and only the named driver.
|
2019-01-07 23:51:50 +08:00
|
|
|
* @cs_gpio: LEGACY: gpio number of the chipselect line (optional, -ENOENT when
|
|
|
|
* not using a GPIO line) use cs_gpiod in new drivers by opting in on
|
|
|
|
* the spi_master.
|
|
|
|
* @cs_gpiod: gpio descriptor of the chipselect line (optional, NULL when
|
2017-11-30 21:35:08 +08:00
|
|
|
* not using a GPIO line)
|
2019-09-26 18:51:35 +08:00
|
|
|
* @word_delay: delay to be inserted between consecutive
|
2019-01-30 16:40:04 +08:00
|
|
|
* words of a transfer
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*
|
2015-06-22 21:00:36 +08:00
|
|
|
* @statistics: statistics for the spi_device
|
|
|
|
*
|
2007-05-08 15:32:21 +08:00
|
|
|
* A @spi_device is used to interchange data between an SPI slave
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* (usually a discrete chip) and CPU memory.
|
|
|
|
*
|
2007-05-08 15:32:21 +08:00
|
|
|
* In @dev, the platform_data is used to hold information about this
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* device that's meaningful to the device's protocol driver, but not
|
|
|
|
* to its controller. One example might be an identifier for a chip
|
2007-05-08 15:32:21 +08:00
|
|
|
* variant with slightly different functionality; another might be
|
|
|
|
* information about how this particular board wires the chip's pins.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*/
|
|
|
|
struct spi_device {
|
|
|
|
struct device dev;
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *controller;
|
|
|
|
struct spi_controller *master; /* compatibility layer */
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
u32 max_speed_hz;
|
|
|
|
u8 chip_select;
|
2013-12-14 10:27:44 +08:00
|
|
|
u8 bits_per_word;
|
2019-05-16 00:48:12 +08:00
|
|
|
bool rt;
|
2020-12-21 23:29:35 +08:00
|
|
|
#define SPI_NO_TX BIT(31) /* no transmit wire */
|
|
|
|
#define SPI_NO_RX BIT(30) /* no receive wire */
|
|
|
|
/*
|
|
|
|
* All bits defined above should be covered by SPI_MODE_KERNEL_MASK.
|
|
|
|
* The SPI_MODE_KERNEL_MASK has the SPI_MODE_USER_MASK counterpart,
|
|
|
|
* which is defined in 'include/uapi/linux/spi/spi.h'.
|
|
|
|
* The bits defined here are from bit 31 downwards, while in
|
|
|
|
* SPI_MODE_USER_MASK are from 0 upwards.
|
|
|
|
* These bits must not overlap. A static assert check should make sure of that.
|
|
|
|
* If adding extra bits, make sure to decrease the bit index below as well.
|
|
|
|
*/
|
|
|
|
#define SPI_MODE_KERNEL_MASK (~(BIT(30) - 1))
|
2019-04-16 05:30:27 +08:00
|
|
|
u32 mode;
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
int irq;
|
|
|
|
void *controller_state;
|
2006-01-09 05:34:23 +08:00
|
|
|
void *controller_data;
|
2009-09-23 07:46:04 +08:00
|
|
|
char modalias[SPI_NAME_SIZE];
|
2018-09-21 03:18:32 +08:00
|
|
|
const char *driver_override;
|
2019-01-07 23:51:50 +08:00
|
|
|
int cs_gpio; /* LEGACY: chip select gpio */
|
|
|
|
struct gpio_desc *cs_gpiod; /* chip select gpio desc */
|
2019-09-26 18:51:35 +08:00
|
|
|
struct spi_delay word_delay; /* inter-word delay */
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
2015-06-22 21:00:36 +08:00
|
|
|
/* the statistics */
|
|
|
|
struct spi_statistics statistics;
|
|
|
|
|
2007-05-08 15:32:21 +08:00
|
|
|
/*
|
|
|
|
* likely need more hooks for more protocol options affecting how
|
|
|
|
* the controller talks to each chip, like:
|
|
|
|
* - memory packing (12 bit samples into low bits, others zeroed)
|
|
|
|
* - priority
|
|
|
|
* - chipselect delays
|
|
|
|
* - ...
|
|
|
|
*/
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
};
|
|
|
|
|
2020-12-21 23:29:35 +08:00
|
|
|
/* Make sure that SPI_MODE_KERNEL_MASK & SPI_MODE_USER_MASK don't overlap */
|
|
|
|
static_assert((SPI_MODE_KERNEL_MASK & SPI_MODE_USER_MASK) == 0,
|
|
|
|
"SPI_MODE_USER_MASK & SPI_MODE_KERNEL_MASK must not overlap");
|
|
|
|
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
static inline struct spi_device *to_spi_device(struct device *dev)
|
|
|
|
{
|
2006-01-09 05:34:23 +08:00
|
|
|
return dev ? container_of(dev, struct spi_device, dev) : NULL;
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* 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);
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
/* ctldata is for the bus_controller driver's runtime state */
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2007-02-12 16:52:41 +08:00
|
|
|
/* device driver data */
|
|
|
|
|
|
|
|
static inline void spi_set_drvdata(struct spi_device *spi, void *data)
|
|
|
|
{
|
|
|
|
dev_set_drvdata(&spi->dev, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void *spi_get_drvdata(struct spi_device *spi)
|
|
|
|
{
|
|
|
|
return dev_get_drvdata(&spi->dev);
|
|
|
|
}
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
|
|
|
struct spi_message;
|
2013-10-05 18:50:40 +08:00
|
|
|
struct spi_transfer;
|
2006-01-09 05:34:23 +08:00
|
|
|
|
2007-07-31 15:39:44 +08:00
|
|
|
/**
|
|
|
|
* struct spi_driver - Host side "protocol" driver
|
2009-09-23 07:46:04 +08:00
|
|
|
* @id_table: List of SPI devices supported by this driver
|
2007-07-31 15:39:44 +08:00
|
|
|
* @probe: Binds this driver to the spi device. Drivers can verify
|
|
|
|
* that the device is actually present, and may need to configure
|
|
|
|
* characteristics (such as bits_per_word) which weren't needed for
|
|
|
|
* the initial configuration done during system setup.
|
|
|
|
* @remove: Unbinds this driver from the spi device
|
|
|
|
* @shutdown: Standard shutdown callback used during system state
|
|
|
|
* transitions such as powerdown/halt and kexec
|
|
|
|
* @driver: SPI device drivers should initialize the name and owner
|
|
|
|
* field of this structure.
|
|
|
|
*
|
|
|
|
* This represents the kind of device driver that uses SPI messages to
|
|
|
|
* interact with the hardware at the other end of a SPI link. It's called
|
|
|
|
* a "protocol" driver because it works through messages rather than talking
|
|
|
|
* directly to SPI hardware (which is what the underlying SPI controller
|
|
|
|
* driver does to pass those messages). These protocols are defined in the
|
|
|
|
* specification for the device(s) supported by the driver.
|
|
|
|
*
|
|
|
|
* As a rule, those device protocols represent the lowest level interface
|
|
|
|
* supported by a driver, and it will support upper level interfaces too.
|
|
|
|
* Examples of such upper levels include frameworks like MTD, networking,
|
|
|
|
* MMC, RTC, filesystem character device nodes, and hardware monitoring.
|
|
|
|
*/
|
2006-01-09 05:34:23 +08:00
|
|
|
struct spi_driver {
|
2009-09-23 07:46:04 +08:00
|
|
|
const struct spi_device_id *id_table;
|
2006-01-09 05:34:23 +08:00
|
|
|
int (*probe)(struct spi_device *spi);
|
|
|
|
int (*remove)(struct spi_device *spi);
|
|
|
|
void (*shutdown)(struct spi_device *spi);
|
|
|
|
struct device_driver driver;
|
|
|
|
};
|
|
|
|
|
|
|
|
static inline struct spi_driver *to_spi_driver(struct device_driver *drv)
|
|
|
|
{
|
|
|
|
return drv ? container_of(drv, struct spi_driver, driver) : NULL;
|
|
|
|
}
|
|
|
|
|
2015-10-23 21:59:10 +08:00
|
|
|
extern int __spi_register_driver(struct module *owner, struct spi_driver *sdrv);
|
2006-01-09 05:34:23 +08:00
|
|
|
|
2007-05-08 15:32:21 +08:00
|
|
|
/**
|
|
|
|
* spi_unregister_driver - reverse effect of spi_register_driver
|
|
|
|
* @sdrv: the driver to unregister
|
|
|
|
* Context: can sleep
|
|
|
|
*/
|
2006-01-09 05:34:23 +08:00
|
|
|
static inline void spi_unregister_driver(struct spi_driver *sdrv)
|
|
|
|
{
|
2007-02-12 16:52:43 +08:00
|
|
|
if (sdrv)
|
|
|
|
driver_unregister(&sdrv->driver);
|
2006-01-09 05:34:23 +08:00
|
|
|
}
|
|
|
|
|
2015-10-23 21:59:10 +08:00
|
|
|
/* use a define to avoid include chaining to get THIS_MODULE */
|
|
|
|
#define spi_register_driver(driver) \
|
|
|
|
__spi_register_driver(THIS_MODULE, driver)
|
|
|
|
|
2011-11-16 17:13:37 +08:00
|
|
|
/**
|
|
|
|
* module_spi_driver() - Helper macro for registering a SPI driver
|
|
|
|
* @__spi_driver: spi_driver struct
|
|
|
|
*
|
|
|
|
* Helper macro for SPI drivers which do not do anything special in module
|
|
|
|
* init/exit. This eliminates a lot of boilerplate. Each module may only
|
|
|
|
* use this macro once, and calling it replaces module_init() and module_exit()
|
|
|
|
*/
|
|
|
|
#define module_spi_driver(__spi_driver) \
|
|
|
|
module_driver(__spi_driver, spi_register_driver, \
|
|
|
|
spi_unregister_driver)
|
2006-01-09 05:34:23 +08:00
|
|
|
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
/**
|
2017-06-13 19:23:52 +08:00
|
|
|
* struct spi_controller - interface to SPI master or slave controller
|
2007-10-16 16:27:48 +08:00
|
|
|
* @dev: device interface to this driver
|
2017-06-13 19:23:52 +08:00
|
|
|
* @list: link with the global spi_controller list
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @bus_num: board-specific (and often SOC-specific) identifier for a
|
2006-04-03 02:33:37 +08:00
|
|
|
* given SPI controller.
|
2006-01-09 05:34:23 +08:00
|
|
|
* @num_chipselect: chipselects are used to distinguish individual
|
2006-04-03 02:33:37 +08:00
|
|
|
* 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.
|
2009-04-07 10:00:56 +08:00
|
|
|
* @dma_alignment: SPI controller constraint on DMA buffers alignment.
|
2009-09-23 07:46:00 +08:00
|
|
|
* @mode_bits: flags understood by this controller driver
|
2020-07-25 13:02:57 +08:00
|
|
|
* @buswidth_override_bits: flags to override for this controller driver
|
2013-03-27 10:37:57 +08:00
|
|
|
* @bits_per_word_mask: A mask indicating which values of bits_per_word are
|
|
|
|
* supported by the driver. Bit n indicates that a bits_per_word n+1 is
|
2014-02-18 21:54:36 +08:00
|
|
|
* supported. If set, the SPI core will reject any transfer with an
|
2013-03-27 10:37:57 +08:00
|
|
|
* unsupported bits_per_word. If not set, this value is simply ignored,
|
|
|
|
* and it's up to the individual driver to perform any validation.
|
2013-07-10 21:57:26 +08:00
|
|
|
* @min_speed_hz: Lowest supported transfer speed
|
|
|
|
* @max_speed_hz: Highest supported transfer speed
|
2009-09-23 07:46:00 +08:00
|
|
|
* @flags: other constraints relevant to this driver
|
2017-05-22 21:11:41 +08:00
|
|
|
* @slave: indicates that this is an SPI slave controller
|
2016-02-06 09:31:39 +08:00
|
|
|
* @max_transfer_size: function that returns the max transfer size for
|
|
|
|
* a &spi_device; may be %NULL, so the default %SIZE_MAX will be used.
|
2016-08-18 03:08:01 +08:00
|
|
|
* @max_message_size: function that returns the max message size for
|
|
|
|
* a &spi_device; may be %NULL, so the default %SIZE_MAX will be used.
|
2016-07-22 06:53:31 +08:00
|
|
|
* @io_mutex: mutex for physical bus access
|
2010-08-16 21:10:11 +08:00
|
|
|
* @bus_lock_spinlock: spinlock for SPI bus locking
|
2016-07-22 06:53:31 +08:00
|
|
|
* @bus_lock_mutex: mutex for exclusion of multiple callers
|
2010-08-16 21:10:11 +08:00
|
|
|
* @bus_lock_flag: indicates that the SPI bus is locked for exclusive use
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @setup: updates the device mode and clocking records used by a
|
2007-02-12 16:52:46 +08:00
|
|
|
* device's SPI controller; protocol code may call this. This
|
|
|
|
* must fail if an unrecognized or unsupported mode is requested.
|
2007-05-08 15:32:21 +08:00
|
|
|
* It's always safe to call this unless transfers are pending on
|
|
|
|
* the device whose settings are being modified.
|
2019-04-05 08:14:16 +08:00
|
|
|
* @set_cs_timing: optional hook for SPI devices to request SPI master
|
|
|
|
* controller for configuring specific CS setup time, hold time and inactive
|
|
|
|
* delay interms of clock counts
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @transfer: adds a message to the controller's transfer queue.
|
|
|
|
* @cleanup: frees controller-specific state
|
2017-06-13 19:23:52 +08:00
|
|
|
* @can_dma: determine whether this controller supports DMA
|
|
|
|
* @queued: whether this controller is providing an internal message queue
|
2020-07-09 14:50:07 +08:00
|
|
|
* @kworker: pointer to thread struct for message pump
|
2012-02-22 17:05:38 +08:00
|
|
|
* @pump_messages: work struct for scheduling work to the message pump
|
|
|
|
* @queue_lock: spinlock to syncronise access to message queue
|
|
|
|
* @queue: message queue
|
2014-12-10 05:38:05 +08:00
|
|
|
* @idling: the device is entering idle state
|
2012-02-22 17:05:38 +08:00
|
|
|
* @cur_msg: the currently in-flight message
|
2013-10-05 07:23:12 +08:00
|
|
|
* @cur_msg_prepared: spi_prepare_message was called for the currently
|
|
|
|
* in-flight message
|
2014-08-08 19:02:36 +08:00
|
|
|
* @cur_msg_mapped: message has been mapped for DMA
|
2020-06-30 07:41:06 +08:00
|
|
|
* @last_cs_enable: was enable true on the last call to set_cs.
|
|
|
|
* @last_cs_mode_high: was (mode & SPI_CS_HIGH) true on the last call to set_cs.
|
2014-02-18 21:54:36 +08:00
|
|
|
* @xfer_completion: used by core transfer_one_message()
|
2012-02-22 17:05:38 +08:00
|
|
|
* @busy: message pump is busy
|
|
|
|
* @running: message pump is running
|
|
|
|
* @rt: whether this queue is set to run as a realtime task
|
2013-07-28 21:47:02 +08:00
|
|
|
* @auto_runtime_pm: the core should ensure a runtime PM reference is held
|
|
|
|
* while the hardware is prepared, using the parent
|
|
|
|
* device for the spidev
|
2014-02-02 21:47:47 +08:00
|
|
|
* @max_dma_len: Maximum length of a DMA transfer for the device.
|
2012-02-22 17:05:38 +08:00
|
|
|
* @prepare_transfer_hardware: a message will soon arrive from the queue
|
|
|
|
* so the subsystem requests the driver to prepare the transfer hardware
|
|
|
|
* by issuing this call
|
|
|
|
* @transfer_one_message: the subsystem calls the driver to transfer a single
|
|
|
|
* message while queuing transfers that arrive in the meantime. When the
|
|
|
|
* driver is finished with this message, it must call
|
|
|
|
* spi_finalize_current_message() so the subsystem can issue the next
|
2014-01-26 04:36:15 +08:00
|
|
|
* message
|
2012-04-18 08:03:50 +08:00
|
|
|
* @unprepare_transfer_hardware: there are currently no more messages on the
|
2012-02-22 17:05:38 +08:00
|
|
|
* queue so the subsystem notifies the driver that it may relax the
|
|
|
|
* hardware by issuing this call
|
2019-04-05 08:14:16 +08:00
|
|
|
*
|
2014-01-21 23:10:07 +08:00
|
|
|
* @set_cs: set the logic level of the chip select line. May be called
|
2013-10-05 18:50:40 +08:00
|
|
|
* from interrupt context.
|
2013-10-05 07:23:12 +08:00
|
|
|
* @prepare_message: set up the controller to transfer a single message,
|
|
|
|
* for example doing DMA mapping. Called from threaded
|
|
|
|
* context.
|
2014-01-21 23:10:06 +08:00
|
|
|
* @transfer_one: transfer a single spi_transfer.
|
2020-04-15 00:48:44 +08:00
|
|
|
*
|
2014-01-21 23:10:06 +08:00
|
|
|
* - return 0 if the transfer is finished,
|
|
|
|
* - return 1 if the transfer is still in progress. When
|
|
|
|
* the driver is finished with this transfer it must
|
|
|
|
* call spi_finalize_current_transfer() so the subsystem
|
2014-01-26 04:36:13 +08:00
|
|
|
* can issue the next transfer. Note: transfer_one and
|
|
|
|
* transfer_one_message are mutually exclusive; when both
|
|
|
|
* are set, the generic subsystem does not call your
|
|
|
|
* transfer_one callback.
|
2015-04-08 02:39:19 +08:00
|
|
|
* @handle_err: the subsystem calls the driver to handle an error that occurs
|
2015-02-27 23:34:15 +08:00
|
|
|
* in the generic implementation of transfer_one_message().
|
2018-04-27 00:18:14 +08:00
|
|
|
* @mem_ops: optimized/dedicated operations for interactions with SPI memory.
|
|
|
|
* This field is optional and should only be implemented if the
|
|
|
|
* controller has native support for memory like operations.
|
2013-10-05 07:23:12 +08:00
|
|
|
* @unprepare_message: undo any work done by prepare_message().
|
2017-05-22 21:11:41 +08:00
|
|
|
* @slave_abort: abort the ongoing transfer request on an SPI slave controller
|
2019-10-23 15:00:46 +08:00
|
|
|
* @cs_setup: delay to be introduced by the controller after CS is asserted
|
|
|
|
* @cs_hold: delay to be introduced by the controller before CS is deasserted
|
|
|
|
* @cs_inactive: delay to be introduced by the controller after CS is
|
|
|
|
* deasserted. If @cs_change_delay is used from @spi_transfer, then the
|
|
|
|
* two delays will be added up.
|
2019-01-07 23:51:50 +08:00
|
|
|
* @cs_gpios: LEGACY: array of GPIO descs to use as chip select lines; one per
|
|
|
|
* CS number. Any individual value may be -ENOENT for CS lines that
|
|
|
|
* are not GPIOs (driven by the SPI controller itself). Use the cs_gpiods
|
|
|
|
* in new drivers.
|
|
|
|
* @cs_gpiods: Array of GPIO descs to use as chip select lines; one per CS
|
|
|
|
* number. Any individual value may be NULL for CS lines that
|
2013-01-29 22:53:41 +08:00
|
|
|
* are not GPIOs (driven by the SPI controller itself).
|
2019-01-07 23:51:50 +08:00
|
|
|
* @use_gpio_descriptors: Turns on the code in the SPI core to parse and grab
|
|
|
|
* GPIO descriptors rather than using global GPIO numbers grabbed by the
|
|
|
|
* driver. This will fill in @cs_gpiods and @cs_gpios should not be used,
|
|
|
|
* and SPI devices will have the cs_gpiod assigned rather than cs_gpio.
|
spi: Add generic support for unused native cs with cs-gpios
Some SPI master controllers always drive a native chip select when
performing a transfer. Hence when using both native and GPIO chip
selects, at least one native chip select must be left unused, to be
driven when performing transfers with slave devices using GPIO chip
selects.
Currently, to find an unused native chip select, SPI controller drivers
need to parse and process cs-gpios theirselves. This is not only
duplicated in each driver that needs it, but also duplicates part of the
work done later at SPI controller registration time. Note that this
cannot be done after spi_register_controller() returns, as at that time,
slave devices may have been probed already.
Hence add generic support to the SPI subsystem for finding an unused
native chip select. Optionally, this unused native chip select, and all
other in-use native chip selects, can be validated against the maximum
number of native chip selects available on the controller hardware.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200102133822.29346-2-geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-02 21:38:17 +08:00
|
|
|
* @unused_native_cs: When cs_gpiods is used, spi_register_controller() will
|
|
|
|
* fill in this field with the first unused native CS, to be used by SPI
|
|
|
|
* controller drivers that need to drive a native CS when using GPIO CS.
|
|
|
|
* @max_native_cs: When cs_gpiods is used, and this field is filled in,
|
|
|
|
* spi_register_controller() will validate all native CS (including the
|
|
|
|
* unused native CS) against this value.
|
2017-06-13 19:23:52 +08:00
|
|
|
* @statistics: statistics for the spi_controller
|
2014-08-08 19:02:36 +08:00
|
|
|
* @dma_tx: DMA transmit channel
|
|
|
|
* @dma_rx: DMA receive channel
|
|
|
|
* @dummy_rx: dummy receive buffer for full-duplex devices
|
|
|
|
* @dummy_tx: dummy transmit buffer for full-duplex devices
|
2016-02-08 23:14:28 +08:00
|
|
|
* @fw_translate_cs: If the boot firmware uses different numbering scheme
|
|
|
|
* what Linux expects, this optional hook can be used to translate
|
|
|
|
* between the two.
|
spi: Add a PTP system timestamp to the transfer structure
SPI is one of the interfaces used to access devices which have a POSIX
clock driver (real time clocks, 1588 timers etc). The fact that the SPI
bus is slow is not what the main problem is, but rather the fact that
drivers don't take a constant amount of time in transferring data over
SPI. When there is a high delay in the readout of time, there will be
uncertainty in the value that has been read out of the peripheral.
When that delay is constant, the uncertainty can at least be
approximated with a certain accuracy which is fine more often than not.
Timing jitter occurs all over in the kernel code, and is mainly caused
by having to let go of the CPU for various reasons such as preemption,
servicing interrupts, going to sleep, etc. Another major reason is CPU
dynamic frequency scaling.
It turns out that the problem of retrieving time from a SPI peripheral
with high accuracy can be solved by the use of "PTP system
timestamping" - a mechanism to correlate the time when the device has
snapshotted its internal time counter with the Linux system time at that
same moment. This is sufficient for having a precise time measurement -
it is not necessary for the whole SPI transfer to be transmitted "as
fast as possible", or "as low-jitter as possible". The system has to be
low-jitter for a very short amount of time to be effective.
This patch introduces a PTP system timestamping mechanism in struct
spi_transfer. This is to be used by SPI device drivers when they need to
know the exact time at which the underlying device's time was
snapshotted. More often than not, SPI peripherals have a very exact
timing for when their SPI-to-interconnect bridge issues a transaction
for snapshotting and reading the time register, and that will be
dependent on when the SPI-to-interconnect bridge figures out that this
is what it should do, aka as soon as it sees byte N of the SPI transfer.
Since spi_device drivers are the ones who'd know best how the peripheral
behaves in this regard, expose a mechanism in spi_transfer which allows
them to specify which word (or word range) from the transfer should be
timestamped.
Add a default implementation of the PTP system timestamping in the SPI
core. This is not going to be satisfactory performance-wise, but should
at least increase the likelihood that SPI device drivers will use PTP
system timestamping in the future.
There are 3 entry points from the core towards the SPI controller
drivers:
- transfer_one: The driver is passed individual spi_transfers to
execute. This is the easiest to timestamp.
- transfer_one_message: The core passes the driver an entire spi_message
(a potential batch of spi_transfers). The core puts the same pre and
post timestamp to all transfers within a message. This is not ideal,
but nothing better can be done by default anyway, since the core has
no insight into how the driver batches the transfers.
- transfer: Like transfer_one_message, but for unqueued drivers (i.e.
the driver implements its own queue scheduling).
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190905010114.26718-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-05 09:01:12 +08:00
|
|
|
* @ptp_sts_supported: If the driver sets this to true, it must provide a
|
|
|
|
* time snapshot in @spi_transfer->ptp_sts as close as possible to the
|
|
|
|
* moment in time when @spi_transfer->ptp_sts_word_pre and
|
|
|
|
* @spi_transfer->ptp_sts_word_post were transmitted.
|
|
|
|
* If the driver does not set this, the SPI core takes the snapshot as
|
|
|
|
* close to the driver hand-over as possible.
|
2020-03-10 01:16:19 +08:00
|
|
|
* @irq_flags: Interrupt enable state during PTP system timestamping
|
2020-06-17 06:42:08 +08:00
|
|
|
* @fallback: fallback to pio if dma transfer return failure with
|
|
|
|
* SPI_TRANS_FAIL_NO_START.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*
|
2017-06-13 19:23:52 +08:00
|
|
|
* Each SPI controller can communicate with one or more @spi_device
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* 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
|
2007-05-08 15:32:21 +08:00
|
|
|
* a queue of spi_message transactions, copying data between CPU memory and
|
|
|
|
* an SPI slave device. For each such message it queues, it calls the
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* message's completion function when the transaction completes.
|
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller {
|
2007-10-16 16:27:48 +08:00
|
|
|
struct device dev;
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
2010-08-02 15:52:15 +08:00
|
|
|
struct list_head list;
|
|
|
|
|
2006-04-04 06:49:04 +08:00
|
|
|
/* other than negative (== assign one dynamically), bus_num is fully
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* board-specific. usually that simplifies to being SOC-specific.
|
2006-04-04 06:49:04 +08:00
|
|
|
* example: one SOC has three SPI controllers, numbered 0..2,
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* and one board's schematics might show it using SPI-2. software
|
|
|
|
* would normally use bus_num=2 for that controller.
|
|
|
|
*/
|
2006-04-04 06:49:04 +08:00
|
|
|
s16 bus_num;
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
|
|
|
/* chipselects will be integral to many controllers; some others
|
|
|
|
* might use board-specific GPIOs.
|
|
|
|
*/
|
|
|
|
u16 num_chipselect;
|
|
|
|
|
2009-04-07 10:00:56 +08:00
|
|
|
/* some SPI controllers pose alignment requirements on DMAable
|
|
|
|
* buffers; let protocol drivers know about these requirements.
|
|
|
|
*/
|
|
|
|
u16 dma_alignment;
|
|
|
|
|
2009-06-18 07:26:04 +08:00
|
|
|
/* spi_device.mode flags understood by this controller driver */
|
2019-04-16 05:30:27 +08:00
|
|
|
u32 mode_bits;
|
2009-06-18 07:26:04 +08:00
|
|
|
|
2020-02-28 23:18:49 +08:00
|
|
|
/* spi_device.mode flags override flags for this controller */
|
|
|
|
u32 buswidth_override_bits;
|
|
|
|
|
2013-03-27 10:37:57 +08:00
|
|
|
/* bitmask of supported bits_per_word for transfers */
|
|
|
|
u32 bits_per_word_mask;
|
2013-05-22 10:36:34 +08:00
|
|
|
#define SPI_BPW_MASK(bits) BIT((bits) - 1)
|
2019-03-14 05:00:34 +08:00
|
|
|
#define SPI_BPW_RANGE_MASK(min, max) GENMASK((max) - 1, (min) - 1)
|
2013-03-27 10:37:57 +08:00
|
|
|
|
2013-07-10 21:57:26 +08:00
|
|
|
/* limits on transfer speed */
|
|
|
|
u32 min_speed_hz;
|
|
|
|
u32 max_speed_hz;
|
|
|
|
|
2009-07-01 02:41:27 +08:00
|
|
|
/* other constraints relevant to this driver */
|
|
|
|
u16 flags;
|
2017-06-13 19:23:52 +08:00
|
|
|
#define SPI_CONTROLLER_HALF_DUPLEX BIT(0) /* can't do full duplex */
|
|
|
|
#define SPI_CONTROLLER_NO_RX BIT(1) /* can't do buffer read */
|
|
|
|
#define SPI_CONTROLLER_NO_TX BIT(2) /* can't do buffer write */
|
|
|
|
#define SPI_CONTROLLER_MUST_RX BIT(3) /* requires rx */
|
|
|
|
#define SPI_CONTROLLER_MUST_TX BIT(4) /* requires tx */
|
|
|
|
|
|
|
|
#define SPI_MASTER_GPIO_SS BIT(5) /* GPIO CS must select slave */
|
2009-07-01 02:41:27 +08:00
|
|
|
|
2017-05-22 21:11:41 +08:00
|
|
|
/* flag indicating this is an SPI slave controller */
|
|
|
|
bool slave;
|
|
|
|
|
2015-12-02 18:38:21 +08:00
|
|
|
/*
|
2016-08-18 03:08:01 +08:00
|
|
|
* on some hardware transfer / message size may be constrained
|
2015-12-02 18:38:21 +08:00
|
|
|
* the limit may depend on device transfer settings
|
|
|
|
*/
|
|
|
|
size_t (*max_transfer_size)(struct spi_device *spi);
|
2016-08-18 03:08:01 +08:00
|
|
|
size_t (*max_message_size)(struct spi_device *spi);
|
2015-12-02 18:38:21 +08:00
|
|
|
|
2016-07-22 06:53:31 +08:00
|
|
|
/* I/O mutex */
|
|
|
|
struct mutex io_mutex;
|
|
|
|
|
spi/mmc_spi: SPI bus locking API, using mutex
SPI bus locking API to allow exclusive access to the SPI bus, especially, but
not limited to, for the mmc_spi driver.
Coded according to an outline from Grant Likely; here is his
specification (accidentally swapped function names corrected):
It requires 3 things to be added to struct spi_master.
- 1 Mutex
- 1 spin lock
- 1 flag.
The mutex protects spi_sync, and provides sleeping "for free"
The spinlock protects the atomic spi_async call.
The flag is set when the lock is obtained, and checked while holding
the spinlock in spi_async(). If the flag is checked, then spi_async()
must fail immediately.
The current runtime API looks like this:
spi_async(struct spi_device*, struct spi_message*);
spi_sync(struct spi_device*, struct spi_message*);
The API needs to be extended to this:
spi_async(struct spi_device*, struct spi_message*)
spi_sync(struct spi_device*, struct spi_message*)
spi_bus_lock(struct spi_master*) /* although struct spi_device* might
be easier */
spi_bus_unlock(struct spi_master*)
spi_async_locked(struct spi_device*, struct spi_message*)
spi_sync_locked(struct spi_device*, struct spi_message*)
Drivers can only call the last two if they already hold the spi_master_lock().
spi_bus_lock() obtains the mutex, obtains the spin lock, sets the
flag, and releases the spin lock before returning. It doesn't even
need to sleep while waiting for "in-flight" spi_transactions to
complete because its purpose is to guarantee no additional
transactions are added. It does not guarantee that the bus is idle.
spi_bus_unlock() clears the flag and releases the mutex, which will
wake up any waiters.
The difference between spi_async() and spi_async_locked() is that the
locked version bypasses the check of the lock flag. Both versions
need to obtain the spinlock.
The difference between spi_sync() and spi_sync_locked() is that
spi_sync() must hold the mutex while enqueuing a new transfer.
spi_sync_locked() doesn't because the mutex is already held. Note
however that spi_sync must *not* continue to hold the mutex while
waiting for the transfer to complete, otherwise only one transfer
could be queued up at a time!
Almost no code needs to be written. The current spi_async() and
spi_sync() can probably be renamed to __spi_async() and __spi_sync()
so that spi_async(), spi_sync(), spi_async_locked() and
spi_sync_locked() can just become wrappers around the common code.
spi_sync() is protected by a mutex because it can sleep
spi_async() needs to be protected with a flag and a spinlock because
it can be called atomically and must not sleep
Signed-off-by: Ernst Schwab <eschwab@online.de>
[grant.likely@secretlab.ca: use spin_lock_irqsave()]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Matt Fleming <matt@console-pimps.org>
Tested-by: Antonio Ospite <ospite@studenti.unina.it>
2010-06-29 08:49:29 +08:00
|
|
|
/* lock and mutex for SPI bus locking */
|
|
|
|
spinlock_t bus_lock_spinlock;
|
|
|
|
struct mutex bus_lock_mutex;
|
|
|
|
|
|
|
|
/* flag indicating that the SPI bus is locked for exclusive use */
|
|
|
|
bool bus_lock_flag;
|
|
|
|
|
2009-04-22 03:24:49 +08:00
|
|
|
/* Setup mode and clock, etc (spi driver may call many times).
|
|
|
|
*
|
|
|
|
* IMPORTANT: this may be called when transfers to another
|
|
|
|
* device are active. DO NOT UPDATE SHARED REGISTERS in ways
|
|
|
|
* which could break those transfers.
|
|
|
|
*/
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
int (*setup)(struct spi_device *spi);
|
|
|
|
|
2019-04-05 08:14:16 +08:00
|
|
|
/*
|
|
|
|
* set_cs_timing() method is for SPI controllers that supports
|
|
|
|
* configuring CS timing.
|
|
|
|
*
|
|
|
|
* This hook allows SPI client drivers to request SPI controllers
|
|
|
|
* to configure specific CS timing through spi_set_cs_timing() after
|
|
|
|
* spi_setup().
|
|
|
|
*/
|
2019-09-26 18:51:42 +08:00
|
|
|
int (*set_cs_timing)(struct spi_device *spi, struct spi_delay *setup,
|
|
|
|
struct spi_delay *hold, struct spi_delay *inactive);
|
2019-04-05 08:14:16 +08:00
|
|
|
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
/* 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
|
|
|
|
*
|
2017-06-13 19:23:52 +08:00
|
|
|
* + The controller's main job is to process its message queue,
|
|
|
|
* selecting a chip (for masters), then transferring data
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* + 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);
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
/* called on release() to free memory provided by spi_controller */
|
2007-02-12 16:52:45 +08:00
|
|
|
void (*cleanup)(struct spi_device *spi);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
2014-01-16 20:22:43 +08:00
|
|
|
/*
|
|
|
|
* Used to enable core support for DMA handling, if can_dma()
|
|
|
|
* exists and returns true then the transfer will be mapped
|
|
|
|
* prior to transfer_one() being called. The driver should
|
|
|
|
* not modify or store xfer and dma_tx and dma_rx must be set
|
|
|
|
* while the device is prepared.
|
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
bool (*can_dma)(struct spi_controller *ctlr,
|
2014-01-16 20:22:43 +08:00
|
|
|
struct spi_device *spi,
|
|
|
|
struct spi_transfer *xfer);
|
|
|
|
|
2012-02-22 17:05:38 +08:00
|
|
|
/*
|
|
|
|
* These hooks are for drivers that want to use the generic
|
2017-06-13 19:23:52 +08:00
|
|
|
* controller transfer queueing mechanism. If these are used, the
|
2012-02-22 17:05:38 +08:00
|
|
|
* transfer() function above must NOT be specified by the driver.
|
|
|
|
* Over time we expect SPI drivers to be phased over to this API.
|
|
|
|
*/
|
|
|
|
bool queued;
|
2020-07-09 14:50:07 +08:00
|
|
|
struct kthread_worker *kworker;
|
2012-02-22 17:05:38 +08:00
|
|
|
struct kthread_work pump_messages;
|
|
|
|
spinlock_t queue_lock;
|
|
|
|
struct list_head queue;
|
|
|
|
struct spi_message *cur_msg;
|
2014-12-10 05:38:05 +08:00
|
|
|
bool idling;
|
2012-02-22 17:05:38 +08:00
|
|
|
bool busy;
|
|
|
|
bool running;
|
|
|
|
bool rt;
|
2013-07-28 21:47:02 +08:00
|
|
|
bool auto_runtime_pm;
|
2013-10-05 07:23:12 +08:00
|
|
|
bool cur_msg_prepared;
|
2014-01-16 20:22:43 +08:00
|
|
|
bool cur_msg_mapped;
|
2020-06-30 07:41:06 +08:00
|
|
|
bool last_cs_enable;
|
|
|
|
bool last_cs_mode_high;
|
2020-06-17 06:42:08 +08:00
|
|
|
bool fallback;
|
2013-10-05 18:50:40 +08:00
|
|
|
struct completion xfer_completion;
|
2014-02-02 21:47:47 +08:00
|
|
|
size_t max_dma_len;
|
2012-02-22 17:05:38 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
int (*prepare_transfer_hardware)(struct spi_controller *ctlr);
|
|
|
|
int (*transfer_one_message)(struct spi_controller *ctlr,
|
2012-02-22 17:05:38 +08:00
|
|
|
struct spi_message *mesg);
|
2017-06-13 19:23:52 +08:00
|
|
|
int (*unprepare_transfer_hardware)(struct spi_controller *ctlr);
|
|
|
|
int (*prepare_message)(struct spi_controller *ctlr,
|
2013-10-05 07:23:12 +08:00
|
|
|
struct spi_message *message);
|
2017-06-13 19:23:52 +08:00
|
|
|
int (*unprepare_message)(struct spi_controller *ctlr,
|
2013-10-05 07:23:12 +08:00
|
|
|
struct spi_message *message);
|
2017-06-13 19:23:52 +08:00
|
|
|
int (*slave_abort)(struct spi_controller *ctlr);
|
2013-07-28 21:47:02 +08:00
|
|
|
|
2013-10-05 18:50:40 +08:00
|
|
|
/*
|
|
|
|
* These hooks are for drivers that use a generic implementation
|
|
|
|
* of transfer_one_message() provied by the core.
|
|
|
|
*/
|
|
|
|
void (*set_cs)(struct spi_device *spi, bool enable);
|
2017-06-13 19:23:52 +08:00
|
|
|
int (*transfer_one)(struct spi_controller *ctlr, struct spi_device *spi,
|
2013-10-05 18:50:40 +08:00
|
|
|
struct spi_transfer *transfer);
|
2017-06-13 19:23:52 +08:00
|
|
|
void (*handle_err)(struct spi_controller *ctlr,
|
2015-02-27 23:34:15 +08:00
|
|
|
struct spi_message *message);
|
2013-10-05 18:50:40 +08:00
|
|
|
|
2018-04-27 00:18:14 +08:00
|
|
|
/* Optimized handlers for SPI memory-like operations. */
|
|
|
|
const struct spi_controller_mem_ops *mem_ops;
|
|
|
|
|
2019-09-26 18:51:43 +08:00
|
|
|
/* CS delays */
|
|
|
|
struct spi_delay cs_setup;
|
|
|
|
struct spi_delay cs_hold;
|
|
|
|
struct spi_delay cs_inactive;
|
|
|
|
|
2012-11-16 03:19:57 +08:00
|
|
|
/* gpio chip select */
|
|
|
|
int *cs_gpios;
|
2019-01-07 23:51:50 +08:00
|
|
|
struct gpio_desc **cs_gpiods;
|
|
|
|
bool use_gpio_descriptors;
|
spi: Add generic support for unused native cs with cs-gpios
Some SPI master controllers always drive a native chip select when
performing a transfer. Hence when using both native and GPIO chip
selects, at least one native chip select must be left unused, to be
driven when performing transfers with slave devices using GPIO chip
selects.
Currently, to find an unused native chip select, SPI controller drivers
need to parse and process cs-gpios theirselves. This is not only
duplicated in each driver that needs it, but also duplicates part of the
work done later at SPI controller registration time. Note that this
cannot be done after spi_register_controller() returns, as at that time,
slave devices may have been probed already.
Hence add generic support to the SPI subsystem for finding an unused
native chip select. Optionally, this unused native chip select, and all
other in-use native chip selects, can be validated against the maximum
number of native chip selects available on the controller hardware.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200102133822.29346-2-geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-02 21:38:17 +08:00
|
|
|
u8 unused_native_cs;
|
|
|
|
u8 max_native_cs;
|
2014-01-16 20:22:43 +08:00
|
|
|
|
2015-06-22 21:00:36 +08:00
|
|
|
/* statistics */
|
|
|
|
struct spi_statistics statistics;
|
|
|
|
|
2014-01-16 20:22:43 +08:00
|
|
|
/* DMA channels for use with core dmaengine helpers */
|
|
|
|
struct dma_chan *dma_tx;
|
|
|
|
struct dma_chan *dma_rx;
|
2014-01-29 04:17:03 +08:00
|
|
|
|
|
|
|
/* dummy data for full duplex devices */
|
|
|
|
void *dummy_rx;
|
|
|
|
void *dummy_tx;
|
2016-02-08 23:14:28 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
int (*fw_translate_cs)(struct spi_controller *ctlr, unsigned cs);
|
spi: Add a PTP system timestamp to the transfer structure
SPI is one of the interfaces used to access devices which have a POSIX
clock driver (real time clocks, 1588 timers etc). The fact that the SPI
bus is slow is not what the main problem is, but rather the fact that
drivers don't take a constant amount of time in transferring data over
SPI. When there is a high delay in the readout of time, there will be
uncertainty in the value that has been read out of the peripheral.
When that delay is constant, the uncertainty can at least be
approximated with a certain accuracy which is fine more often than not.
Timing jitter occurs all over in the kernel code, and is mainly caused
by having to let go of the CPU for various reasons such as preemption,
servicing interrupts, going to sleep, etc. Another major reason is CPU
dynamic frequency scaling.
It turns out that the problem of retrieving time from a SPI peripheral
with high accuracy can be solved by the use of "PTP system
timestamping" - a mechanism to correlate the time when the device has
snapshotted its internal time counter with the Linux system time at that
same moment. This is sufficient for having a precise time measurement -
it is not necessary for the whole SPI transfer to be transmitted "as
fast as possible", or "as low-jitter as possible". The system has to be
low-jitter for a very short amount of time to be effective.
This patch introduces a PTP system timestamping mechanism in struct
spi_transfer. This is to be used by SPI device drivers when they need to
know the exact time at which the underlying device's time was
snapshotted. More often than not, SPI peripherals have a very exact
timing for when their SPI-to-interconnect bridge issues a transaction
for snapshotting and reading the time register, and that will be
dependent on when the SPI-to-interconnect bridge figures out that this
is what it should do, aka as soon as it sees byte N of the SPI transfer.
Since spi_device drivers are the ones who'd know best how the peripheral
behaves in this regard, expose a mechanism in spi_transfer which allows
them to specify which word (or word range) from the transfer should be
timestamped.
Add a default implementation of the PTP system timestamping in the SPI
core. This is not going to be satisfactory performance-wise, but should
at least increase the likelihood that SPI device drivers will use PTP
system timestamping in the future.
There are 3 entry points from the core towards the SPI controller
drivers:
- transfer_one: The driver is passed individual spi_transfers to
execute. This is the easiest to timestamp.
- transfer_one_message: The core passes the driver an entire spi_message
(a potential batch of spi_transfers). The core puts the same pre and
post timestamp to all transfers within a message. This is not ideal,
but nothing better can be done by default anyway, since the core has
no insight into how the driver batches the transfers.
- transfer: Like transfer_one_message, but for unqueued drivers (i.e.
the driver implements its own queue scheduling).
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190905010114.26718-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-05 09:01:12 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Driver sets this field to indicate it is able to snapshot SPI
|
|
|
|
* transfers (needed e.g. for reading the time of POSIX clocks)
|
|
|
|
*/
|
|
|
|
bool ptp_sts_supported;
|
|
|
|
|
|
|
|
/* Interrupt enable state during PTP system timestamping */
|
|
|
|
unsigned long irq_flags;
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
};
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static inline void *spi_controller_get_devdata(struct spi_controller *ctlr)
|
2006-01-09 05:34:25 +08:00
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
return dev_get_drvdata(&ctlr->dev);
|
2006-01-09 05:34:25 +08:00
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static inline void spi_controller_set_devdata(struct spi_controller *ctlr,
|
|
|
|
void *data)
|
2006-01-09 05:34:25 +08:00
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_set_drvdata(&ctlr->dev, data);
|
2006-01-09 05:34:25 +08:00
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static inline struct spi_controller *spi_controller_get(struct spi_controller *ctlr)
|
2006-01-09 05:34:25 +08:00
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
if (!ctlr || !get_device(&ctlr->dev))
|
2006-01-09 05:34:25 +08:00
|
|
|
return NULL;
|
2017-06-13 19:23:52 +08:00
|
|
|
return ctlr;
|
2006-01-09 05:34:25 +08:00
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static inline void spi_controller_put(struct spi_controller *ctlr)
|
2006-01-09 05:34:25 +08:00
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr)
|
|
|
|
put_device(&ctlr->dev);
|
2006-01-09 05:34:25 +08:00
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static inline bool spi_controller_is_slave(struct spi_controller *ctlr)
|
2017-05-22 21:11:41 +08:00
|
|
|
{
|
|
|
|
return IS_ENABLED(CONFIG_SPI_SLAVE) && ctlr->slave;
|
|
|
|
}
|
|
|
|
|
2012-02-22 17:05:38 +08:00
|
|
|
/* PM calls that need to be issued by the driver */
|
2017-06-13 19:23:52 +08:00
|
|
|
extern int spi_controller_suspend(struct spi_controller *ctlr);
|
|
|
|
extern int spi_controller_resume(struct spi_controller *ctlr);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
|
|
|
/* Calls the driver make to interact with the message queue */
|
2017-06-13 19:23:52 +08:00
|
|
|
extern struct spi_message *spi_get_next_queued_message(struct spi_controller *ctlr);
|
|
|
|
extern void spi_finalize_current_message(struct spi_controller *ctlr);
|
|
|
|
extern void spi_finalize_current_transfer(struct spi_controller *ctlr);
|
2006-01-09 05:34:25 +08:00
|
|
|
|
spi: Add a PTP system timestamp to the transfer structure
SPI is one of the interfaces used to access devices which have a POSIX
clock driver (real time clocks, 1588 timers etc). The fact that the SPI
bus is slow is not what the main problem is, but rather the fact that
drivers don't take a constant amount of time in transferring data over
SPI. When there is a high delay in the readout of time, there will be
uncertainty in the value that has been read out of the peripheral.
When that delay is constant, the uncertainty can at least be
approximated with a certain accuracy which is fine more often than not.
Timing jitter occurs all over in the kernel code, and is mainly caused
by having to let go of the CPU for various reasons such as preemption,
servicing interrupts, going to sleep, etc. Another major reason is CPU
dynamic frequency scaling.
It turns out that the problem of retrieving time from a SPI peripheral
with high accuracy can be solved by the use of "PTP system
timestamping" - a mechanism to correlate the time when the device has
snapshotted its internal time counter with the Linux system time at that
same moment. This is sufficient for having a precise time measurement -
it is not necessary for the whole SPI transfer to be transmitted "as
fast as possible", or "as low-jitter as possible". The system has to be
low-jitter for a very short amount of time to be effective.
This patch introduces a PTP system timestamping mechanism in struct
spi_transfer. This is to be used by SPI device drivers when they need to
know the exact time at which the underlying device's time was
snapshotted. More often than not, SPI peripherals have a very exact
timing for when their SPI-to-interconnect bridge issues a transaction
for snapshotting and reading the time register, and that will be
dependent on when the SPI-to-interconnect bridge figures out that this
is what it should do, aka as soon as it sees byte N of the SPI transfer.
Since spi_device drivers are the ones who'd know best how the peripheral
behaves in this regard, expose a mechanism in spi_transfer which allows
them to specify which word (or word range) from the transfer should be
timestamped.
Add a default implementation of the PTP system timestamping in the SPI
core. This is not going to be satisfactory performance-wise, but should
at least increase the likelihood that SPI device drivers will use PTP
system timestamping in the future.
There are 3 entry points from the core towards the SPI controller
drivers:
- transfer_one: The driver is passed individual spi_transfers to
execute. This is the easiest to timestamp.
- transfer_one_message: The core passes the driver an entire spi_message
(a potential batch of spi_transfers). The core puts the same pre and
post timestamp to all transfers within a message. This is not ideal,
but nothing better can be done by default anyway, since the core has
no insight into how the driver batches the transfers.
- transfer: Like transfer_one_message, but for unqueued drivers (i.e.
the driver implements its own queue scheduling).
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190905010114.26718-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-05 09:01:12 +08:00
|
|
|
/* Helper calls for driver to timestamp transfer */
|
|
|
|
void spi_take_timestamp_pre(struct spi_controller *ctlr,
|
|
|
|
struct spi_transfer *xfer,
|
2019-12-27 09:24:17 +08:00
|
|
|
size_t progress, bool irqs_off);
|
spi: Add a PTP system timestamp to the transfer structure
SPI is one of the interfaces used to access devices which have a POSIX
clock driver (real time clocks, 1588 timers etc). The fact that the SPI
bus is slow is not what the main problem is, but rather the fact that
drivers don't take a constant amount of time in transferring data over
SPI. When there is a high delay in the readout of time, there will be
uncertainty in the value that has been read out of the peripheral.
When that delay is constant, the uncertainty can at least be
approximated with a certain accuracy which is fine more often than not.
Timing jitter occurs all over in the kernel code, and is mainly caused
by having to let go of the CPU for various reasons such as preemption,
servicing interrupts, going to sleep, etc. Another major reason is CPU
dynamic frequency scaling.
It turns out that the problem of retrieving time from a SPI peripheral
with high accuracy can be solved by the use of "PTP system
timestamping" - a mechanism to correlate the time when the device has
snapshotted its internal time counter with the Linux system time at that
same moment. This is sufficient for having a precise time measurement -
it is not necessary for the whole SPI transfer to be transmitted "as
fast as possible", or "as low-jitter as possible". The system has to be
low-jitter for a very short amount of time to be effective.
This patch introduces a PTP system timestamping mechanism in struct
spi_transfer. This is to be used by SPI device drivers when they need to
know the exact time at which the underlying device's time was
snapshotted. More often than not, SPI peripherals have a very exact
timing for when their SPI-to-interconnect bridge issues a transaction
for snapshotting and reading the time register, and that will be
dependent on when the SPI-to-interconnect bridge figures out that this
is what it should do, aka as soon as it sees byte N of the SPI transfer.
Since spi_device drivers are the ones who'd know best how the peripheral
behaves in this regard, expose a mechanism in spi_transfer which allows
them to specify which word (or word range) from the transfer should be
timestamped.
Add a default implementation of the PTP system timestamping in the SPI
core. This is not going to be satisfactory performance-wise, but should
at least increase the likelihood that SPI device drivers will use PTP
system timestamping in the future.
There are 3 entry points from the core towards the SPI controller
drivers:
- transfer_one: The driver is passed individual spi_transfers to
execute. This is the easiest to timestamp.
- transfer_one_message: The core passes the driver an entire spi_message
(a potential batch of spi_transfers). The core puts the same pre and
post timestamp to all transfers within a message. This is not ideal,
but nothing better can be done by default anyway, since the core has
no insight into how the driver batches the transfers.
- transfer: Like transfer_one_message, but for unqueued drivers (i.e.
the driver implements its own queue scheduling).
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190905010114.26718-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-05 09:01:12 +08:00
|
|
|
void spi_take_timestamp_post(struct spi_controller *ctlr,
|
|
|
|
struct spi_transfer *xfer,
|
2019-12-27 09:24:17 +08:00
|
|
|
size_t progress, bool irqs_off);
|
spi: Add a PTP system timestamp to the transfer structure
SPI is one of the interfaces used to access devices which have a POSIX
clock driver (real time clocks, 1588 timers etc). The fact that the SPI
bus is slow is not what the main problem is, but rather the fact that
drivers don't take a constant amount of time in transferring data over
SPI. When there is a high delay in the readout of time, there will be
uncertainty in the value that has been read out of the peripheral.
When that delay is constant, the uncertainty can at least be
approximated with a certain accuracy which is fine more often than not.
Timing jitter occurs all over in the kernel code, and is mainly caused
by having to let go of the CPU for various reasons such as preemption,
servicing interrupts, going to sleep, etc. Another major reason is CPU
dynamic frequency scaling.
It turns out that the problem of retrieving time from a SPI peripheral
with high accuracy can be solved by the use of "PTP system
timestamping" - a mechanism to correlate the time when the device has
snapshotted its internal time counter with the Linux system time at that
same moment. This is sufficient for having a precise time measurement -
it is not necessary for the whole SPI transfer to be transmitted "as
fast as possible", or "as low-jitter as possible". The system has to be
low-jitter for a very short amount of time to be effective.
This patch introduces a PTP system timestamping mechanism in struct
spi_transfer. This is to be used by SPI device drivers when they need to
know the exact time at which the underlying device's time was
snapshotted. More often than not, SPI peripherals have a very exact
timing for when their SPI-to-interconnect bridge issues a transaction
for snapshotting and reading the time register, and that will be
dependent on when the SPI-to-interconnect bridge figures out that this
is what it should do, aka as soon as it sees byte N of the SPI transfer.
Since spi_device drivers are the ones who'd know best how the peripheral
behaves in this regard, expose a mechanism in spi_transfer which allows
them to specify which word (or word range) from the transfer should be
timestamped.
Add a default implementation of the PTP system timestamping in the SPI
core. This is not going to be satisfactory performance-wise, but should
at least increase the likelihood that SPI device drivers will use PTP
system timestamping in the future.
There are 3 entry points from the core towards the SPI controller
drivers:
- transfer_one: The driver is passed individual spi_transfers to
execute. This is the easiest to timestamp.
- transfer_one_message: The core passes the driver an entire spi_message
(a potential batch of spi_transfers). The core puts the same pre and
post timestamp to all transfers within a message. This is not ideal,
but nothing better can be done by default anyway, since the core has
no insight into how the driver batches the transfers.
- transfer: Like transfer_one_message, but for unqueued drivers (i.e.
the driver implements its own queue scheduling).
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190905010114.26718-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-05 09:01:12 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
/* the spi driver core manages memory for the spi_controller classdev */
|
|
|
|
extern struct spi_controller *__spi_alloc_controller(struct device *host,
|
|
|
|
unsigned int size, bool slave);
|
2017-05-22 21:11:41 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static inline struct spi_controller *spi_alloc_master(struct device *host,
|
|
|
|
unsigned int size)
|
2017-05-22 21:11:41 +08:00
|
|
|
{
|
|
|
|
return __spi_alloc_controller(host, size, false);
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static inline struct spi_controller *spi_alloc_slave(struct device *host,
|
|
|
|
unsigned int size)
|
2017-05-22 21:11:41 +08:00
|
|
|
{
|
|
|
|
if (!IS_ENABLED(CONFIG_SPI_SLAVE))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return __spi_alloc_controller(host, size, true);
|
|
|
|
}
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
spi: Introduce device-managed SPI controller allocation
SPI driver probing currently comprises two steps, whereas removal
comprises only one step:
spi_alloc_master()
spi_register_controller()
spi_unregister_controller()
That's because spi_unregister_controller() calls device_unregister()
instead of device_del(), thereby releasing the reference on the
spi_controller which was obtained by spi_alloc_master().
An SPI driver's private data is contained in the same memory allocation
as the spi_controller struct. Thus, once spi_unregister_controller()
has been called, the private data is inaccessible. But some drivers
need to access it after spi_unregister_controller() to perform further
teardown steps.
Introduce devm_spi_alloc_master() and devm_spi_alloc_slave(), which
release a reference on the spi_controller struct only after the driver
has unbound, thereby keeping the memory allocation accessible. Change
spi_unregister_controller() to not release a reference if the
spi_controller was allocated by one of these new devm functions.
The present commit is small enough to be backportable to stable.
It allows fixing drivers which use the private data in their ->remove()
hook after it's been freed. It also allows fixing drivers which neglect
to release a reference on the spi_controller in the probe error path.
Long-term, most SPI drivers shall be moved over to the devm functions
introduced herein. The few that can't shall be changed in a treewide
commit to explicitly release the last reference on the controller.
That commit shall amend spi_unregister_controller() to no longer release
a reference, thereby completing the migration.
As a result, the behaviour will be less surprising and more consistent
with subsystems such as IIO, which also includes the private data in the
allocation of the generic iio_dev struct, but calls device_del() in
iio_device_unregister().
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/272bae2ef08abd21388c98e23729886663d19192.1605121038.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-12 03:07:10 +08:00
|
|
|
struct spi_controller *__devm_spi_alloc_controller(struct device *dev,
|
|
|
|
unsigned int size,
|
|
|
|
bool slave);
|
|
|
|
|
|
|
|
static inline struct spi_controller *devm_spi_alloc_master(struct device *dev,
|
|
|
|
unsigned int size)
|
|
|
|
{
|
|
|
|
return __devm_spi_alloc_controller(dev, size, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct spi_controller *devm_spi_alloc_slave(struct device *dev,
|
|
|
|
unsigned int size)
|
|
|
|
{
|
|
|
|
if (!IS_ENABLED(CONFIG_SPI_SLAVE))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return __devm_spi_alloc_controller(dev, size, true);
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
extern int spi_register_controller(struct spi_controller *ctlr);
|
|
|
|
extern int devm_spi_register_controller(struct device *dev,
|
|
|
|
struct spi_controller *ctlr);
|
|
|
|
extern void spi_unregister_controller(struct spi_controller *ctlr);
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
extern struct spi_controller *spi_busnum_to_master(u16 busnum);
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
2015-12-14 23:20:18 +08:00
|
|
|
/*
|
|
|
|
* SPI resource management while processing a SPI message
|
|
|
|
*/
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
typedef void (*spi_res_release_t)(struct spi_controller *ctlr,
|
2016-02-18 23:53:10 +08:00
|
|
|
struct spi_message *msg,
|
|
|
|
void *res);
|
|
|
|
|
2015-12-14 23:20:18 +08:00
|
|
|
/**
|
|
|
|
* struct spi_res - spi resource management structure
|
|
|
|
* @entry: list entry
|
|
|
|
* @release: release code called prior to freeing this resource
|
|
|
|
* @data: extra data allocated for the specific use-case
|
|
|
|
*
|
|
|
|
* this is based on ideas from devres, but focused on life-cycle
|
|
|
|
* management during spi_message processing
|
|
|
|
*/
|
|
|
|
struct spi_res {
|
|
|
|
struct list_head entry;
|
|
|
|
spi_res_release_t release;
|
|
|
|
unsigned long long data[]; /* guarantee ull alignment */
|
|
|
|
};
|
|
|
|
|
|
|
|
extern void *spi_res_alloc(struct spi_device *spi,
|
|
|
|
spi_res_release_t release,
|
|
|
|
size_t size, gfp_t gfp);
|
|
|
|
extern void spi_res_add(struct spi_message *message, void *res);
|
|
|
|
extern void spi_res_free(void *res);
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
extern void spi_res_release(struct spi_controller *ctlr,
|
2015-12-14 23:20:18 +08:00
|
|
|
struct spi_message *message);
|
|
|
|
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
/*---------------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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
|
2006-01-09 05:34:28 +08:00
|
|
|
* @tx_buf: data to be written (dma-safe memory), or NULL
|
|
|
|
* @rx_buf: data to be read (dma-safe memory), or NULL
|
2007-05-08 15:32:21 +08:00
|
|
|
* @tx_dma: DMA address of tx_buf, if @spi_message.is_dma_mapped
|
|
|
|
* @rx_dma: DMA address of rx_buf, if @spi_message.is_dma_mapped
|
2014-02-18 21:54:36 +08:00
|
|
|
* @tx_nbits: number of bits used for writing. If 0 the default
|
2013-08-11 18:15:17 +08:00
|
|
|
* (SPI_NBITS_SINGLE) is used.
|
|
|
|
* @rx_nbits: number of bits used for reading. If 0 the default
|
|
|
|
* (SPI_NBITS_SINGLE) is used.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @len: size of rx and tx buffers (in bytes)
|
2008-10-17 01:02:37 +08:00
|
|
|
* @speed_hz: Select a speed other than the device default for this
|
2007-05-08 15:32:21 +08:00
|
|
|
* transfer. If 0 the default (from @spi_device) is used.
|
2008-10-17 01:02:37 +08:00
|
|
|
* @bits_per_word: select a bits_per_word other than the device default
|
2007-05-08 15:32:21 +08:00
|
|
|
* for this transfer. If 0 the default (from @spi_device) is used.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @cs_change: affects chipselect after this transfer completes
|
2019-02-23 16:49:48 +08:00
|
|
|
* @cs_change_delay: delay between cs deassert and assert when
|
|
|
|
* @cs_change is set and @spi_transfer is not the last in @spi_message
|
2019-09-26 18:51:36 +08:00
|
|
|
* @delay: delay to be introduced after this transfer before
|
|
|
|
* (optionally) changing the chipselect status, then starting
|
|
|
|
* the next transfer or completing this @spi_message.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @delay_usecs: microseconds to delay after this transfer before
|
2006-04-03 02:33:37 +08:00
|
|
|
* (optionally) changing the chipselect status, then starting
|
2007-05-08 15:32:21 +08:00
|
|
|
* the next transfer or completing this @spi_message.
|
2019-09-26 18:51:32 +08:00
|
|
|
* @word_delay: inter word delay to be introduced after each word size
|
2018-08-16 20:54:49 +08:00
|
|
|
* (set by bits_per_word) transmission.
|
2019-02-23 16:49:49 +08:00
|
|
|
* @effective_speed_hz: the effective SCK-speed that was used to
|
|
|
|
* transfer this transfer. Set to 0 if the spi bus driver does
|
|
|
|
* not support it.
|
2007-05-08 15:32:21 +08:00
|
|
|
* @transfer_list: transfers are sequenced through @spi_message.transfers
|
2014-02-02 21:47:47 +08:00
|
|
|
* @tx_sg: Scatterlist for transmit, currently not for client use
|
|
|
|
* @rx_sg: Scatterlist for receive, currently not for client use
|
spi: Add a PTP system timestamp to the transfer structure
SPI is one of the interfaces used to access devices which have a POSIX
clock driver (real time clocks, 1588 timers etc). The fact that the SPI
bus is slow is not what the main problem is, but rather the fact that
drivers don't take a constant amount of time in transferring data over
SPI. When there is a high delay in the readout of time, there will be
uncertainty in the value that has been read out of the peripheral.
When that delay is constant, the uncertainty can at least be
approximated with a certain accuracy which is fine more often than not.
Timing jitter occurs all over in the kernel code, and is mainly caused
by having to let go of the CPU for various reasons such as preemption,
servicing interrupts, going to sleep, etc. Another major reason is CPU
dynamic frequency scaling.
It turns out that the problem of retrieving time from a SPI peripheral
with high accuracy can be solved by the use of "PTP system
timestamping" - a mechanism to correlate the time when the device has
snapshotted its internal time counter with the Linux system time at that
same moment. This is sufficient for having a precise time measurement -
it is not necessary for the whole SPI transfer to be transmitted "as
fast as possible", or "as low-jitter as possible". The system has to be
low-jitter for a very short amount of time to be effective.
This patch introduces a PTP system timestamping mechanism in struct
spi_transfer. This is to be used by SPI device drivers when they need to
know the exact time at which the underlying device's time was
snapshotted. More often than not, SPI peripherals have a very exact
timing for when their SPI-to-interconnect bridge issues a transaction
for snapshotting and reading the time register, and that will be
dependent on when the SPI-to-interconnect bridge figures out that this
is what it should do, aka as soon as it sees byte N of the SPI transfer.
Since spi_device drivers are the ones who'd know best how the peripheral
behaves in this regard, expose a mechanism in spi_transfer which allows
them to specify which word (or word range) from the transfer should be
timestamped.
Add a default implementation of the PTP system timestamping in the SPI
core. This is not going to be satisfactory performance-wise, but should
at least increase the likelihood that SPI device drivers will use PTP
system timestamping in the future.
There are 3 entry points from the core towards the SPI controller
drivers:
- transfer_one: The driver is passed individual spi_transfers to
execute. This is the easiest to timestamp.
- transfer_one_message: The core passes the driver an entire spi_message
(a potential batch of spi_transfers). The core puts the same pre and
post timestamp to all transfers within a message. This is not ideal,
but nothing better can be done by default anyway, since the core has
no insight into how the driver batches the transfers.
- transfer: Like transfer_one_message, but for unqueued drivers (i.e.
the driver implements its own queue scheduling).
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190905010114.26718-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-05 09:01:12 +08:00
|
|
|
* @ptp_sts_word_pre: The word (subject to bits_per_word semantics) offset
|
|
|
|
* within @tx_buf for which the SPI device is requesting that the time
|
|
|
|
* snapshot for this transfer begins. Upon completing the SPI transfer,
|
|
|
|
* this value may have changed compared to what was requested, depending
|
|
|
|
* on the available snapshotting resolution (DMA transfer,
|
|
|
|
* @ptp_sts_supported is false, etc).
|
|
|
|
* @ptp_sts_word_post: See @ptp_sts_word_post. The two can be equal (meaning
|
|
|
|
* that a single byte should be snapshotted).
|
|
|
|
* If the core takes care of the timestamp (if @ptp_sts_supported is false
|
|
|
|
* for this controller), it will set @ptp_sts_word_pre to 0, and
|
|
|
|
* @ptp_sts_word_post to the length of the transfer. This is done
|
|
|
|
* purposefully (instead of setting to spi_transfer->len - 1) to denote
|
|
|
|
* that a transfer-level snapshot taken from within the driver may still
|
|
|
|
* be of higher quality.
|
|
|
|
* @ptp_sts: Pointer to a memory location held by the SPI slave device where a
|
|
|
|
* PTP system timestamp structure may lie. If drivers use PIO or their
|
|
|
|
* hardware has some sort of assist for retrieving exact transfer timing,
|
|
|
|
* they can (and should) assert @ptp_sts_supported and populate this
|
|
|
|
* structure using the ptp_read_system_*ts helper functions.
|
|
|
|
* The timestamp must represent the time at which the SPI slave device has
|
|
|
|
* processed the word, i.e. the "pre" timestamp should be taken before
|
|
|
|
* transmitting the "pre" word, and the "post" timestamp after receiving
|
|
|
|
* transmit confirmation from the controller for the "post" word.
|
2020-07-25 13:02:57 +08:00
|
|
|
* @timestamped: true if the transfer has been timestamped
|
2020-06-17 06:42:08 +08:00
|
|
|
* @error: Error status logged by spi controller driver.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*
|
|
|
|
* SPI transfers always write the same number of bytes as they read.
|
2007-05-08 15:32:21 +08:00
|
|
|
* Protocol drivers should always provide @rx_buf and/or @tx_buf.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* 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.
|
|
|
|
*
|
2006-12-30 08:48:39 +08:00
|
|
|
* If the transmit buffer is null, zeroes will be shifted out
|
2007-05-08 15:32:21 +08:00
|
|
|
* while filling @rx_buf. If the receive buffer is null, the data
|
2006-01-09 05:34:28 +08:00
|
|
|
* shifted in will be discarded. Only "len" bytes shift out (or in).
|
|
|
|
* It's an error to try to shift out a partial word. (For example, by
|
|
|
|
* shifting out three bytes with word size of sixteen or twenty bits;
|
|
|
|
* the former uses two bytes per word, the latter uses four bytes.)
|
|
|
|
*
|
2007-02-12 16:52:46 +08:00
|
|
|
* In-memory data values are always in native CPU byte order, translated
|
|
|
|
* from the wire byte order (big-endian except with SPI_LSB_FIRST). So
|
|
|
|
* for example when bits_per_word is sixteen, buffers are 2N bytes long
|
2007-05-08 15:32:21 +08:00
|
|
|
* (@len = 2N) and hold N sixteen bit words in CPU byte order.
|
2007-02-12 16:52:46 +08:00
|
|
|
*
|
|
|
|
* When the word size of the SPI transfer is not a power-of-two multiple
|
|
|
|
* of eight bits, those in-memory words include extra bits. In-memory
|
|
|
|
* words are always seen by protocol drivers as right-justified, so the
|
|
|
|
* undefined (rx) or unused (tx) bits are always the most significant bits.
|
|
|
|
*
|
2006-01-09 05:34:28 +08:00
|
|
|
* All SPI transfers start with the relevant chipselect active. Normally
|
|
|
|
* it stays selected until after the last transfer in a message. Drivers
|
2007-05-08 15:32:21 +08:00
|
|
|
* can affect the chipselect signal using cs_change.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*
|
|
|
|
* (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
|
2007-06-17 01:16:08 +08:00
|
|
|
* stay selected until the next transfer. On multi-device SPI busses
|
|
|
|
* with nothing blocking messages going to other devices, this is just
|
|
|
|
* a performance hint; starting a message to another device deselects
|
|
|
|
* this one. But in other cases, this can be used to ensure correctness.
|
|
|
|
* Some devices need protocol transactions to be built from a series of
|
|
|
|
* spi_message submissions, where the content of one message is determined
|
|
|
|
* by the results of previous messages and where the whole transaction
|
|
|
|
* ends when the chipselect goes intactive.
|
2006-01-09 05:34:25 +08:00
|
|
|
*
|
2014-02-18 21:54:36 +08:00
|
|
|
* When SPI can transfer in 1x,2x or 4x. It can get this transfer information
|
2013-08-11 18:15:17 +08:00
|
|
|
* from device through @tx_nbits and @rx_nbits. In Bi-direction, these
|
|
|
|
* two should both be set. User can set transfer mode with SPI_NBITS_SINGLE(1x)
|
|
|
|
* SPI_NBITS_DUAL(2x) and SPI_NBITS_QUAD(4x) to support these three transfer.
|
|
|
|
*
|
2006-01-09 05:34:25 +08:00
|
|
|
* The code that submits an spi_message (and its spi_transfers)
|
|
|
|
* to the lower layers is responsible for managing its memory.
|
|
|
|
* Zero-initialize every field you don't set up explicitly, to
|
2006-01-09 05:34:28 +08:00
|
|
|
* insulate against future API updates. After you submit a message
|
|
|
|
* and its transfers, ignore them until its completion callback.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*/
|
|
|
|
struct spi_transfer {
|
|
|
|
/* it's ok if tx_buf == rx_buf (right?)
|
|
|
|
* for MicroWire, one buffer must be null
|
2006-01-09 05:34:25 +08:00
|
|
|
* buffers must work with dma_*map_single() calls, unless
|
|
|
|
* spi_message.is_dma_mapped reports a pre-existing mapping
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*/
|
|
|
|
const void *tx_buf;
|
|
|
|
void *rx_buf;
|
|
|
|
unsigned len;
|
|
|
|
|
|
|
|
dma_addr_t tx_dma;
|
|
|
|
dma_addr_t rx_dma;
|
2014-02-02 21:47:47 +08:00
|
|
|
struct sg_table tx_sg;
|
|
|
|
struct sg_table rx_sg;
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
|
|
|
unsigned cs_change:1;
|
2014-01-11 01:09:53 +08:00
|
|
|
unsigned tx_nbits:3;
|
|
|
|
unsigned rx_nbits:3;
|
2013-08-11 18:15:17 +08:00
|
|
|
#define SPI_NBITS_SINGLE 0x01 /* 1bit transfer */
|
|
|
|
#define SPI_NBITS_DUAL 0x02 /* 2bits transfer */
|
|
|
|
#define SPI_NBITS_QUAD 0x04 /* 4bits transfer */
|
2006-02-18 02:02:18 +08:00
|
|
|
u8 bits_per_word;
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
u16 delay_usecs;
|
2019-09-26 18:51:36 +08:00
|
|
|
struct spi_delay delay;
|
2019-09-26 18:51:31 +08:00
|
|
|
struct spi_delay cs_change_delay;
|
2019-09-26 18:51:32 +08:00
|
|
|
struct spi_delay word_delay;
|
2006-02-18 02:02:18 +08:00
|
|
|
u32 speed_hz;
|
2006-01-09 05:34:28 +08:00
|
|
|
|
2019-02-23 16:49:49 +08:00
|
|
|
u32 effective_speed_hz;
|
|
|
|
|
spi: Add a PTP system timestamp to the transfer structure
SPI is one of the interfaces used to access devices which have a POSIX
clock driver (real time clocks, 1588 timers etc). The fact that the SPI
bus is slow is not what the main problem is, but rather the fact that
drivers don't take a constant amount of time in transferring data over
SPI. When there is a high delay in the readout of time, there will be
uncertainty in the value that has been read out of the peripheral.
When that delay is constant, the uncertainty can at least be
approximated with a certain accuracy which is fine more often than not.
Timing jitter occurs all over in the kernel code, and is mainly caused
by having to let go of the CPU for various reasons such as preemption,
servicing interrupts, going to sleep, etc. Another major reason is CPU
dynamic frequency scaling.
It turns out that the problem of retrieving time from a SPI peripheral
with high accuracy can be solved by the use of "PTP system
timestamping" - a mechanism to correlate the time when the device has
snapshotted its internal time counter with the Linux system time at that
same moment. This is sufficient for having a precise time measurement -
it is not necessary for the whole SPI transfer to be transmitted "as
fast as possible", or "as low-jitter as possible". The system has to be
low-jitter for a very short amount of time to be effective.
This patch introduces a PTP system timestamping mechanism in struct
spi_transfer. This is to be used by SPI device drivers when they need to
know the exact time at which the underlying device's time was
snapshotted. More often than not, SPI peripherals have a very exact
timing for when their SPI-to-interconnect bridge issues a transaction
for snapshotting and reading the time register, and that will be
dependent on when the SPI-to-interconnect bridge figures out that this
is what it should do, aka as soon as it sees byte N of the SPI transfer.
Since spi_device drivers are the ones who'd know best how the peripheral
behaves in this regard, expose a mechanism in spi_transfer which allows
them to specify which word (or word range) from the transfer should be
timestamped.
Add a default implementation of the PTP system timestamping in the SPI
core. This is not going to be satisfactory performance-wise, but should
at least increase the likelihood that SPI device drivers will use PTP
system timestamping in the future.
There are 3 entry points from the core towards the SPI controller
drivers:
- transfer_one: The driver is passed individual spi_transfers to
execute. This is the easiest to timestamp.
- transfer_one_message: The core passes the driver an entire spi_message
(a potential batch of spi_transfers). The core puts the same pre and
post timestamp to all transfers within a message. This is not ideal,
but nothing better can be done by default anyway, since the core has
no insight into how the driver batches the transfers.
- transfer: Like transfer_one_message, but for unqueued drivers (i.e.
the driver implements its own queue scheduling).
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190905010114.26718-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-05 09:01:12 +08:00
|
|
|
unsigned int ptp_sts_word_pre;
|
|
|
|
unsigned int ptp_sts_word_post;
|
|
|
|
|
|
|
|
struct ptp_system_timestamp *ptp_sts;
|
|
|
|
|
2020-03-05 06:00:39 +08:00
|
|
|
bool timestamped;
|
spi: Add a PTP system timestamp to the transfer structure
SPI is one of the interfaces used to access devices which have a POSIX
clock driver (real time clocks, 1588 timers etc). The fact that the SPI
bus is slow is not what the main problem is, but rather the fact that
drivers don't take a constant amount of time in transferring data over
SPI. When there is a high delay in the readout of time, there will be
uncertainty in the value that has been read out of the peripheral.
When that delay is constant, the uncertainty can at least be
approximated with a certain accuracy which is fine more often than not.
Timing jitter occurs all over in the kernel code, and is mainly caused
by having to let go of the CPU for various reasons such as preemption,
servicing interrupts, going to sleep, etc. Another major reason is CPU
dynamic frequency scaling.
It turns out that the problem of retrieving time from a SPI peripheral
with high accuracy can be solved by the use of "PTP system
timestamping" - a mechanism to correlate the time when the device has
snapshotted its internal time counter with the Linux system time at that
same moment. This is sufficient for having a precise time measurement -
it is not necessary for the whole SPI transfer to be transmitted "as
fast as possible", or "as low-jitter as possible". The system has to be
low-jitter for a very short amount of time to be effective.
This patch introduces a PTP system timestamping mechanism in struct
spi_transfer. This is to be used by SPI device drivers when they need to
know the exact time at which the underlying device's time was
snapshotted. More often than not, SPI peripherals have a very exact
timing for when their SPI-to-interconnect bridge issues a transaction
for snapshotting and reading the time register, and that will be
dependent on when the SPI-to-interconnect bridge figures out that this
is what it should do, aka as soon as it sees byte N of the SPI transfer.
Since spi_device drivers are the ones who'd know best how the peripheral
behaves in this regard, expose a mechanism in spi_transfer which allows
them to specify which word (or word range) from the transfer should be
timestamped.
Add a default implementation of the PTP system timestamping in the SPI
core. This is not going to be satisfactory performance-wise, but should
at least increase the likelihood that SPI device drivers will use PTP
system timestamping in the future.
There are 3 entry points from the core towards the SPI controller
drivers:
- transfer_one: The driver is passed individual spi_transfers to
execute. This is the easiest to timestamp.
- transfer_one_message: The core passes the driver an entire spi_message
(a potential batch of spi_transfers). The core puts the same pre and
post timestamp to all transfers within a message. This is not ideal,
but nothing better can be done by default anyway, since the core has
no insight into how the driver batches the transfers.
- transfer: Like transfer_one_message, but for unqueued drivers (i.e.
the driver implements its own queue scheduling).
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190905010114.26718-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-05 09:01:12 +08:00
|
|
|
|
2006-01-09 05:34:28 +08:00
|
|
|
struct list_head transfer_list;
|
2020-06-17 06:42:08 +08:00
|
|
|
|
|
|
|
#define SPI_TRANS_FAIL_NO_START BIT(0)
|
|
|
|
u16 error;
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct spi_message - one multi-segment SPI transaction
|
2006-01-09 05:34:28 +08:00
|
|
|
* @transfers: list of transfer segments in this transaction
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @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
|
2014-08-08 19:02:36 +08:00
|
|
|
* @frame_length: the total number of bytes in the message
|
2006-01-09 05:34:23 +08:00
|
|
|
* @actual_length: the total number of bytes that were transferred in all
|
|
|
|
* successful segments
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* @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
|
2015-12-14 23:20:18 +08:00
|
|
|
* @resources: for resource management when the spi message is processed
|
2006-01-09 05:34:25 +08:00
|
|
|
*
|
2007-05-08 15:32:21 +08:00
|
|
|
* A @spi_message is used to execute an atomic sequence of data transfers,
|
2006-01-09 05:34:28 +08:00
|
|
|
* each represented by a struct spi_transfer. The sequence is "atomic"
|
|
|
|
* in the sense that no other spi_message may use that SPI bus until that
|
|
|
|
* sequence completes. On some systems, many such sequences can execute as
|
2020-07-16 09:30:48 +08:00
|
|
|
* a single programmed DMA transfer. On all systems, these messages are
|
2006-01-09 05:34:28 +08:00
|
|
|
* queued, and might complete after transactions to other devices. Messages
|
2015-03-01 20:49:32 +08:00
|
|
|
* sent to a given spi_device are always executed in FIFO order.
|
2006-01-09 05:34:28 +08:00
|
|
|
*
|
2006-01-09 05:34:25 +08:00
|
|
|
* The code that submits an spi_message (and its spi_transfers)
|
|
|
|
* to the lower layers is responsible for managing its memory.
|
|
|
|
* Zero-initialize every field you don't set up explicitly, to
|
2006-01-09 05:34:28 +08:00
|
|
|
* insulate against future API updates. After you submit a message
|
|
|
|
* and its transfers, ignore them until its completion callback.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*/
|
|
|
|
struct spi_message {
|
2006-04-03 02:33:37 +08:00
|
|
|
struct list_head transfers;
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
|
|
|
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
|
2006-01-09 05:34:23 +08:00
|
|
|
* others (with multi-message pipelines) could need a flag to
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* tell them about such special cases.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* completion is reported through a callback */
|
2006-04-03 02:33:37 +08:00
|
|
|
void (*complete)(void *context);
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
void *context;
|
2013-07-18 18:01:25 +08:00
|
|
|
unsigned frame_length;
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
unsigned actual_length;
|
|
|
|
int status;
|
|
|
|
|
|
|
|
/* for optional use by whatever driver currently owns the
|
|
|
|
* spi_message ... between calls to spi_async and then later
|
2017-06-13 19:23:52 +08:00
|
|
|
* complete(), that's the spi_controller controller driver.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*/
|
|
|
|
struct list_head queue;
|
|
|
|
void *state;
|
2015-12-14 23:20:18 +08:00
|
|
|
|
|
|
|
/* list of spi_res reources when the spi message is processed */
|
|
|
|
struct list_head resources;
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
};
|
|
|
|
|
2015-11-27 21:56:03 +08:00
|
|
|
static inline void spi_message_init_no_memset(struct spi_message *m)
|
|
|
|
{
|
|
|
|
INIT_LIST_HEAD(&m->transfers);
|
2015-12-14 23:20:18 +08:00
|
|
|
INIT_LIST_HEAD(&m->resources);
|
2015-11-27 21:56:03 +08:00
|
|
|
}
|
|
|
|
|
2006-01-09 05:34:28 +08:00
|
|
|
static inline void spi_message_init(struct spi_message *m)
|
|
|
|
{
|
|
|
|
memset(m, 0, sizeof *m);
|
2015-11-27 21:56:03 +08:00
|
|
|
spi_message_init_no_memset(m);
|
2006-01-09 05:34:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
spi_message_add_tail(struct spi_transfer *t, struct spi_message *m)
|
|
|
|
{
|
|
|
|
list_add_tail(&t->transfer_list, &m->transfers);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
spi_transfer_del(struct spi_transfer *t)
|
|
|
|
{
|
|
|
|
list_del(&t->transfer_list);
|
|
|
|
}
|
|
|
|
|
2019-09-26 18:51:36 +08:00
|
|
|
static inline int
|
|
|
|
spi_transfer_delay_exec(struct spi_transfer *t)
|
|
|
|
{
|
|
|
|
struct spi_delay d;
|
|
|
|
|
|
|
|
if (t->delay_usecs) {
|
|
|
|
d.value = t->delay_usecs;
|
|
|
|
d.unit = SPI_DELAY_UNIT_USECS;
|
|
|
|
return spi_delay_exec(&d, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
return spi_delay_exec(&t->delay, t);
|
|
|
|
}
|
|
|
|
|
spi: Add helper functions for setting up transfers
Quite often the pattern used for setting up and transferring a synchronous SPI
transaction looks very much like the following:
struct spi_message msg;
struct spi_transfer xfers[] = {
...
};
spi_message_init(&msg);
spi_message_add_tail(&xfers[0], &msg);
...
spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);
ret = spi_sync(&msg);
This patch adds two new helper functions for handling this case. The first
helper function spi_message_init_with_transfers() takes a spi_message and an
array of spi_transfers. It will initialize the message and then call
spi_message_add_tail() for each transfer in the array. E.g. the following
spi_message_init(&msg);
spi_message_add_tail(&xfers[0], &msg);
...
spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);
can be rewritten as
spi_message_init_with_transfers(&msg, xfers, ARRAY_SIZE(xfers));
The second function spi_sync_transfer() takes a SPI device and an array of
spi_transfers. It will allocate a new spi_message (on the stack) and add all
transfers in the array to the message. Finally it will call spi_sync() on the
message.
E.g. the follwing
struct spi_message msg;
struct spi_transfer xfers[] = {
...
};
spi_message_init(&msg);
spi_message_add_tail(&xfers[0], &msg);
...
spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);
ret = spi_sync(spi, &msg);
can be rewritten as
struct spi_transfer xfers[] = {
...
};
ret = spi_sync_transfer(spi, xfers, ARRAY_SIZE(xfers));
A coccinelle script to find such instances will follow.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2013-01-10 01:31:00 +08:00
|
|
|
/**
|
|
|
|
* spi_message_init_with_transfers - Initialize spi_message and append transfers
|
|
|
|
* @m: spi_message to be initialized
|
|
|
|
* @xfers: An array of spi transfers
|
|
|
|
* @num_xfers: Number of items in the xfer array
|
|
|
|
*
|
|
|
|
* This function initializes the given spi_message and adds each spi_transfer in
|
|
|
|
* the given array to the message.
|
|
|
|
*/
|
|
|
|
static inline void
|
|
|
|
spi_message_init_with_transfers(struct spi_message *m,
|
|
|
|
struct spi_transfer *xfers, unsigned int num_xfers)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
spi_message_init(m);
|
|
|
|
for (i = 0; i < num_xfers; ++i)
|
|
|
|
spi_message_add_tail(&xfers[i], m);
|
|
|
|
}
|
|
|
|
|
2006-01-09 05:34:25 +08:00
|
|
|
/* It's fine to embed message and transaction structures in other data
|
|
|
|
* structures so long as you don't free them while they're in use.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static inline struct spi_message *spi_message_alloc(unsigned ntrans, gfp_t flags)
|
|
|
|
{
|
|
|
|
struct spi_message *m;
|
|
|
|
|
|
|
|
m = kzalloc(sizeof(struct spi_message)
|
|
|
|
+ ntrans * sizeof(struct spi_transfer),
|
|
|
|
flags);
|
|
|
|
if (m) {
|
2012-02-27 21:59:05 +08:00
|
|
|
unsigned i;
|
2006-01-09 05:34:28 +08:00
|
|
|
struct spi_transfer *t = (struct spi_transfer *)(m + 1);
|
|
|
|
|
2017-03-28 15:49:29 +08:00
|
|
|
spi_message_init_no_memset(m);
|
2006-01-09 05:34:28 +08:00
|
|
|
for (i = 0; i < ntrans; i++, t++)
|
|
|
|
spi_message_add_tail(t, m);
|
2006-01-09 05:34:25 +08:00
|
|
|
}
|
|
|
|
return m;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void spi_message_free(struct spi_message *m)
|
|
|
|
{
|
|
|
|
kfree(m);
|
|
|
|
}
|
|
|
|
|
2019-09-26 18:51:42 +08:00
|
|
|
extern int spi_set_cs_timing(struct spi_device *spi,
|
|
|
|
struct spi_delay *setup,
|
|
|
|
struct spi_delay *hold,
|
|
|
|
struct spi_delay *inactive);
|
2019-06-16 01:47:37 +08:00
|
|
|
|
2009-06-18 07:26:03 +08:00
|
|
|
extern int spi_setup(struct spi_device *spi);
|
2009-09-23 07:46:18 +08:00
|
|
|
extern int spi_async(struct spi_device *spi, struct spi_message *message);
|
spi/mmc_spi: SPI bus locking API, using mutex
SPI bus locking API to allow exclusive access to the SPI bus, especially, but
not limited to, for the mmc_spi driver.
Coded according to an outline from Grant Likely; here is his
specification (accidentally swapped function names corrected):
It requires 3 things to be added to struct spi_master.
- 1 Mutex
- 1 spin lock
- 1 flag.
The mutex protects spi_sync, and provides sleeping "for free"
The spinlock protects the atomic spi_async call.
The flag is set when the lock is obtained, and checked while holding
the spinlock in spi_async(). If the flag is checked, then spi_async()
must fail immediately.
The current runtime API looks like this:
spi_async(struct spi_device*, struct spi_message*);
spi_sync(struct spi_device*, struct spi_message*);
The API needs to be extended to this:
spi_async(struct spi_device*, struct spi_message*)
spi_sync(struct spi_device*, struct spi_message*)
spi_bus_lock(struct spi_master*) /* although struct spi_device* might
be easier */
spi_bus_unlock(struct spi_master*)
spi_async_locked(struct spi_device*, struct spi_message*)
spi_sync_locked(struct spi_device*, struct spi_message*)
Drivers can only call the last two if they already hold the spi_master_lock().
spi_bus_lock() obtains the mutex, obtains the spin lock, sets the
flag, and releases the spin lock before returning. It doesn't even
need to sleep while waiting for "in-flight" spi_transactions to
complete because its purpose is to guarantee no additional
transactions are added. It does not guarantee that the bus is idle.
spi_bus_unlock() clears the flag and releases the mutex, which will
wake up any waiters.
The difference between spi_async() and spi_async_locked() is that the
locked version bypasses the check of the lock flag. Both versions
need to obtain the spinlock.
The difference between spi_sync() and spi_sync_locked() is that
spi_sync() must hold the mutex while enqueuing a new transfer.
spi_sync_locked() doesn't because the mutex is already held. Note
however that spi_sync must *not* continue to hold the mutex while
waiting for the transfer to complete, otherwise only one transfer
could be queued up at a time!
Almost no code needs to be written. The current spi_async() and
spi_sync() can probably be renamed to __spi_async() and __spi_sync()
so that spi_async(), spi_sync(), spi_async_locked() and
spi_sync_locked() can just become wrappers around the common code.
spi_sync() is protected by a mutex because it can sleep
spi_async() needs to be protected with a flag and a spinlock because
it can be called atomically and must not sleep
Signed-off-by: Ernst Schwab <eschwab@online.de>
[grant.likely@secretlab.ca: use spin_lock_irqsave()]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Matt Fleming <matt@console-pimps.org>
Tested-by: Antonio Ospite <ospite@studenti.unina.it>
2010-06-29 08:49:29 +08:00
|
|
|
extern int spi_async_locked(struct spi_device *spi,
|
|
|
|
struct spi_message *message);
|
2017-05-22 21:11:41 +08:00
|
|
|
extern int spi_slave_abort(struct spi_device *spi);
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
2015-12-02 18:38:21 +08:00
|
|
|
static inline size_t
|
2016-08-18 03:08:01 +08:00
|
|
|
spi_max_message_size(struct spi_device *spi)
|
2015-12-02 18:38:21 +08:00
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = spi->controller;
|
|
|
|
|
|
|
|
if (!ctlr->max_message_size)
|
2015-12-02 18:38:21 +08:00
|
|
|
return SIZE_MAX;
|
2017-06-13 19:23:52 +08:00
|
|
|
return ctlr->max_message_size(spi);
|
2016-08-18 03:08:01 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline size_t
|
|
|
|
spi_max_transfer_size(struct spi_device *spi)
|
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = spi->controller;
|
2016-08-18 03:08:01 +08:00
|
|
|
size_t tr_max = SIZE_MAX;
|
|
|
|
size_t msg_max = spi_max_message_size(spi);
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->max_transfer_size)
|
|
|
|
tr_max = ctlr->max_transfer_size(spi);
|
2016-08-18 03:08:01 +08:00
|
|
|
|
|
|
|
/* transfer size limit must not be greater than messsage size limit */
|
|
|
|
return min(tr_max, msg_max);
|
2015-12-02 18:38:21 +08:00
|
|
|
}
|
|
|
|
|
2019-04-12 17:41:30 +08:00
|
|
|
/**
|
|
|
|
* spi_is_bpw_supported - Check if bits per word is supported
|
|
|
|
* @spi: SPI device
|
|
|
|
* @bpw: Bits per word
|
|
|
|
*
|
|
|
|
* This function checks to see if the SPI controller supports @bpw.
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* True if @bpw is supported, false otherwise.
|
|
|
|
*/
|
|
|
|
static inline bool spi_is_bpw_supported(struct spi_device *spi, u32 bpw)
|
|
|
|
{
|
|
|
|
u32 bpw_mask = spi->master->bits_per_word_mask;
|
|
|
|
|
|
|
|
if (bpw == 8 || (bpw <= 32 && bpw_mask & SPI_BPW_MASK(bpw)))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
/*---------------------------------------------------------------------------*/
|
|
|
|
|
2015-12-14 23:20:19 +08:00
|
|
|
/* SPI transfer replacement methods which make use of spi_res */
|
|
|
|
|
2016-03-11 02:01:13 +08:00
|
|
|
struct spi_replaced_transfers;
|
2017-06-13 19:23:52 +08:00
|
|
|
typedef void (*spi_replaced_release_t)(struct spi_controller *ctlr,
|
2016-03-11 02:01:13 +08:00
|
|
|
struct spi_message *msg,
|
|
|
|
struct spi_replaced_transfers *res);
|
2015-12-14 23:20:19 +08:00
|
|
|
/**
|
|
|
|
* struct spi_replaced_transfers - structure describing the spi_transfer
|
|
|
|
* replacements that have occurred
|
|
|
|
* so that they can get reverted
|
|
|
|
* @release: some extra release code to get executed prior to
|
|
|
|
* relasing this structure
|
|
|
|
* @extradata: pointer to some extra data if requested or NULL
|
|
|
|
* @replaced_transfers: transfers that have been replaced and which need
|
|
|
|
* to get restored
|
|
|
|
* @replaced_after: the transfer after which the @replaced_transfers
|
|
|
|
* are to get re-inserted
|
|
|
|
* @inserted: number of transfers inserted
|
|
|
|
* @inserted_transfers: array of spi_transfers of array-size @inserted,
|
|
|
|
* that have been replacing replaced_transfers
|
|
|
|
*
|
|
|
|
* note: that @extradata will point to @inserted_transfers[@inserted]
|
|
|
|
* if some extra allocation is requested, so alignment will be the same
|
|
|
|
* as for spi_transfers
|
|
|
|
*/
|
|
|
|
struct spi_replaced_transfers {
|
|
|
|
spi_replaced_release_t release;
|
|
|
|
void *extradata;
|
|
|
|
struct list_head replaced_transfers;
|
|
|
|
struct list_head *replaced_after;
|
|
|
|
size_t inserted;
|
|
|
|
struct spi_transfer inserted_transfers[];
|
|
|
|
};
|
|
|
|
|
|
|
|
extern struct spi_replaced_transfers *spi_replace_transfers(
|
|
|
|
struct spi_message *msg,
|
|
|
|
struct spi_transfer *xfer_first,
|
|
|
|
size_t remove,
|
|
|
|
size_t insert,
|
|
|
|
spi_replaced_release_t release,
|
|
|
|
size_t extradatasize,
|
|
|
|
gfp_t gfp);
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------------*/
|
|
|
|
|
2015-12-14 23:20:20 +08:00
|
|
|
/* SPI transfer transformation methods */
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
extern int spi_split_transfers_maxsize(struct spi_controller *ctlr,
|
2015-12-14 23:20:20 +08:00
|
|
|
struct spi_message *msg,
|
|
|
|
size_t maxsize,
|
|
|
|
gfp_t gfp);
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------------*/
|
|
|
|
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
/* 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/mmc_spi: SPI bus locking API, using mutex
SPI bus locking API to allow exclusive access to the SPI bus, especially, but
not limited to, for the mmc_spi driver.
Coded according to an outline from Grant Likely; here is his
specification (accidentally swapped function names corrected):
It requires 3 things to be added to struct spi_master.
- 1 Mutex
- 1 spin lock
- 1 flag.
The mutex protects spi_sync, and provides sleeping "for free"
The spinlock protects the atomic spi_async call.
The flag is set when the lock is obtained, and checked while holding
the spinlock in spi_async(). If the flag is checked, then spi_async()
must fail immediately.
The current runtime API looks like this:
spi_async(struct spi_device*, struct spi_message*);
spi_sync(struct spi_device*, struct spi_message*);
The API needs to be extended to this:
spi_async(struct spi_device*, struct spi_message*)
spi_sync(struct spi_device*, struct spi_message*)
spi_bus_lock(struct spi_master*) /* although struct spi_device* might
be easier */
spi_bus_unlock(struct spi_master*)
spi_async_locked(struct spi_device*, struct spi_message*)
spi_sync_locked(struct spi_device*, struct spi_message*)
Drivers can only call the last two if they already hold the spi_master_lock().
spi_bus_lock() obtains the mutex, obtains the spin lock, sets the
flag, and releases the spin lock before returning. It doesn't even
need to sleep while waiting for "in-flight" spi_transactions to
complete because its purpose is to guarantee no additional
transactions are added. It does not guarantee that the bus is idle.
spi_bus_unlock() clears the flag and releases the mutex, which will
wake up any waiters.
The difference between spi_async() and spi_async_locked() is that the
locked version bypasses the check of the lock flag. Both versions
need to obtain the spinlock.
The difference between spi_sync() and spi_sync_locked() is that
spi_sync() must hold the mutex while enqueuing a new transfer.
spi_sync_locked() doesn't because the mutex is already held. Note
however that spi_sync must *not* continue to hold the mutex while
waiting for the transfer to complete, otherwise only one transfer
could be queued up at a time!
Almost no code needs to be written. The current spi_async() and
spi_sync() can probably be renamed to __spi_async() and __spi_sync()
so that spi_async(), spi_sync(), spi_async_locked() and
spi_sync_locked() can just become wrappers around the common code.
spi_sync() is protected by a mutex because it can sleep
spi_async() needs to be protected with a flag and a spinlock because
it can be called atomically and must not sleep
Signed-off-by: Ernst Schwab <eschwab@online.de>
[grant.likely@secretlab.ca: use spin_lock_irqsave()]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Matt Fleming <matt@console-pimps.org>
Tested-by: Antonio Ospite <ospite@studenti.unina.it>
2010-06-29 08:49:29 +08:00
|
|
|
extern int spi_sync_locked(struct spi_device *spi, struct spi_message *message);
|
2017-06-13 19:23:52 +08:00
|
|
|
extern int spi_bus_lock(struct spi_controller *ctlr);
|
|
|
|
extern int spi_bus_unlock(struct spi_controller *ctlr);
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
2016-09-13 21:38:25 +08:00
|
|
|
/**
|
|
|
|
* spi_sync_transfer - synchronous SPI data transfer
|
|
|
|
* @spi: device with which data will be exchanged
|
|
|
|
* @xfers: An array of spi_transfers
|
|
|
|
* @num_xfers: Number of items in the xfer array
|
|
|
|
* Context: can sleep
|
|
|
|
*
|
|
|
|
* Does a synchronous SPI data transfer of the given spi_transfer array.
|
|
|
|
*
|
|
|
|
* For more specific semantics see spi_sync().
|
|
|
|
*
|
2020-07-16 09:30:48 +08:00
|
|
|
* Return: zero on success, else a negative error code.
|
2016-09-13 21:38:25 +08:00
|
|
|
*/
|
|
|
|
static inline int
|
|
|
|
spi_sync_transfer(struct spi_device *spi, struct spi_transfer *xfers,
|
|
|
|
unsigned int num_xfers)
|
|
|
|
{
|
|
|
|
struct spi_message msg;
|
|
|
|
|
|
|
|
spi_message_init_with_transfers(&msg, xfers, num_xfers);
|
|
|
|
|
|
|
|
return spi_sync(spi, &msg);
|
|
|
|
}
|
|
|
|
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
/**
|
|
|
|
* spi_write - SPI synchronous write
|
|
|
|
* @spi: device to which data will be written
|
|
|
|
* @buf: data buffer
|
|
|
|
* @len: data buffer size
|
2007-05-08 15:32:21 +08:00
|
|
|
* Context: can sleep
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*
|
2015-10-23 00:59:22 +08:00
|
|
|
* This function writes the buffer @buf.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* Callable only from contexts that can sleep.
|
2015-10-23 00:59:22 +08:00
|
|
|
*
|
|
|
|
* Return: zero on success, else a negative error code.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*/
|
|
|
|
static inline int
|
2011-05-11 06:09:30 +08:00
|
|
|
spi_write(struct spi_device *spi, const void *buf, size_t len)
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
{
|
|
|
|
struct spi_transfer t = {
|
|
|
|
.tx_buf = buf,
|
|
|
|
.len = len,
|
|
|
|
};
|
|
|
|
|
2016-09-13 21:38:25 +08:00
|
|
|
return spi_sync_transfer(spi, &t, 1);
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* spi_read - SPI synchronous read
|
|
|
|
* @spi: device from which data will be read
|
|
|
|
* @buf: data buffer
|
|
|
|
* @len: data buffer size
|
2007-05-08 15:32:21 +08:00
|
|
|
* Context: can sleep
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*
|
2015-10-23 00:59:22 +08:00
|
|
|
* This function reads the buffer @buf.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* Callable only from contexts that can sleep.
|
2015-10-23 00:59:22 +08:00
|
|
|
*
|
|
|
|
* Return: zero on success, else a negative error code.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*/
|
|
|
|
static inline int
|
2011-05-11 06:09:30 +08:00
|
|
|
spi_read(struct spi_device *spi, void *buf, size_t len)
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
{
|
|
|
|
struct spi_transfer t = {
|
|
|
|
.rx_buf = buf,
|
|
|
|
.len = len,
|
|
|
|
};
|
|
|
|
|
2016-09-13 21:38:25 +08:00
|
|
|
return spi_sync_transfer(spi, &t, 1);
|
spi: Add helper functions for setting up transfers
Quite often the pattern used for setting up and transferring a synchronous SPI
transaction looks very much like the following:
struct spi_message msg;
struct spi_transfer xfers[] = {
...
};
spi_message_init(&msg);
spi_message_add_tail(&xfers[0], &msg);
...
spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);
ret = spi_sync(&msg);
This patch adds two new helper functions for handling this case. The first
helper function spi_message_init_with_transfers() takes a spi_message and an
array of spi_transfers. It will initialize the message and then call
spi_message_add_tail() for each transfer in the array. E.g. the following
spi_message_init(&msg);
spi_message_add_tail(&xfers[0], &msg);
...
spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);
can be rewritten as
spi_message_init_with_transfers(&msg, xfers, ARRAY_SIZE(xfers));
The second function spi_sync_transfer() takes a SPI device and an array of
spi_transfers. It will allocate a new spi_message (on the stack) and add all
transfers in the array to the message. Finally it will call spi_sync() on the
message.
E.g. the follwing
struct spi_message msg;
struct spi_transfer xfers[] = {
...
};
spi_message_init(&msg);
spi_message_add_tail(&xfers[0], &msg);
...
spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);
ret = spi_sync(spi, &msg);
can be rewritten as
struct spi_transfer xfers[] = {
...
};
ret = spi_sync_transfer(spi, xfers, ARRAY_SIZE(xfers));
A coccinelle script to find such instances will follow.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2013-01-10 01:31:00 +08:00
|
|
|
}
|
|
|
|
|
2006-01-09 05:34:25 +08:00
|
|
|
/* this copies txbuf and rxbuf data; for small transfers only! */
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
extern int spi_write_then_read(struct spi_device *spi,
|
2011-05-11 06:09:30 +08:00
|
|
|
const void *txbuf, unsigned n_tx,
|
|
|
|
void *rxbuf, unsigned n_rx);
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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
|
2007-05-08 15:32:21 +08:00
|
|
|
* Context: can sleep
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*
|
2015-10-23 00:59:22 +08:00
|
|
|
* Callable only from contexts that can sleep.
|
|
|
|
*
|
|
|
|
* Return: the (unsigned) eight bit number returned by the
|
|
|
|
* device, or else a negative error code.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*/
|
|
|
|
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
|
2007-05-08 15:32:21 +08:00
|
|
|
* Context: can sleep
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*
|
|
|
|
* The number is returned in wire-order, which is at least sometimes
|
|
|
|
* big-endian.
|
2015-10-23 00:59:22 +08:00
|
|
|
*
|
|
|
|
* Callable only from contexts that can sleep.
|
|
|
|
*
|
|
|
|
* Return: the (unsigned) sixteen bit number returned by the
|
|
|
|
* device, or else a negative error code.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*/
|
|
|
|
static inline ssize_t spi_w8r16(struct spi_device *spi, u8 cmd)
|
|
|
|
{
|
|
|
|
ssize_t status;
|
|
|
|
u16 result;
|
|
|
|
|
2014-01-12 20:59:06 +08:00
|
|
|
status = spi_write_then_read(spi, &cmd, 1, &result, 2);
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
|
|
|
/* return negative errno or unsigned value */
|
|
|
|
return (status < 0) ? status : result;
|
|
|
|
}
|
|
|
|
|
2013-09-27 22:34:27 +08:00
|
|
|
/**
|
|
|
|
* spi_w8r16be - SPI synchronous 8 bit write followed by 16 bit big-endian read
|
|
|
|
* @spi: device with which data will be exchanged
|
|
|
|
* @cmd: command to be written before data is read back
|
|
|
|
* Context: can sleep
|
|
|
|
*
|
|
|
|
* This function is similar to spi_w8r16, with the exception that it will
|
|
|
|
* convert the read 16 bit data word from big-endian to native endianness.
|
|
|
|
*
|
2015-10-23 00:59:22 +08:00
|
|
|
* Callable only from contexts that can sleep.
|
|
|
|
*
|
|
|
|
* Return: the (unsigned) sixteen bit number returned by the device in cpu
|
|
|
|
* endianness, or else a negative error code.
|
2013-09-27 22:34:27 +08:00
|
|
|
*/
|
|
|
|
static inline ssize_t spi_w8r16be(struct spi_device *spi, u8 cmd)
|
|
|
|
|
|
|
|
{
|
|
|
|
ssize_t status;
|
|
|
|
__be16 result;
|
|
|
|
|
|
|
|
status = spi_write_then_read(spi, &cmd, 1, &result, 2);
|
|
|
|
if (status < 0)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
return be16_to_cpu(result);
|
|
|
|
}
|
|
|
|
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
/*---------------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
2007-07-31 15:39:44 +08:00
|
|
|
/**
|
|
|
|
* struct spi_board_info - board-specific template for a SPI device
|
|
|
|
* @modalias: Initializes spi_device.modalias; identifies the driver.
|
|
|
|
* @platform_data: Initializes spi_device.platform_data; the particular
|
|
|
|
* data stored there is driver-specific.
|
2017-03-01 06:25:18 +08:00
|
|
|
* @properties: Additional device properties for the device.
|
2007-07-31 15:39:44 +08:00
|
|
|
* @controller_data: Initializes spi_device.controller_data; some
|
|
|
|
* controllers need hints about hardware setup, e.g. for DMA.
|
|
|
|
* @irq: Initializes spi_device.irq; depends on how the board is wired.
|
|
|
|
* @max_speed_hz: Initializes spi_device.max_speed_hz; based on limits
|
|
|
|
* from the chip datasheet and board-specific signal quality issues.
|
2017-06-13 19:23:52 +08:00
|
|
|
* @bus_num: Identifies which spi_controller parents the spi_device; unused
|
2007-07-31 15:39:44 +08:00
|
|
|
* by spi_new_device(), and otherwise depends on board wiring.
|
|
|
|
* @chip_select: Initializes spi_device.chip_select; depends on how
|
|
|
|
* the board is wired.
|
|
|
|
* @mode: Initializes spi_device.mode; based on the chip datasheet, board
|
|
|
|
* wiring (some devices support both 3WIRE and standard modes), and
|
|
|
|
* possibly presence of an inverter in the chipselect path.
|
|
|
|
*
|
|
|
|
* When adding new SPI devices to the device tree, these structures serve
|
|
|
|
* as a partial device template. They hold information which can't always
|
|
|
|
* be determined by drivers. Information that probe() can establish (such
|
|
|
|
* as the default transfer wordsize) is not included here.
|
|
|
|
*
|
|
|
|
* These structures are used in two places. Their primary role is to
|
|
|
|
* be stored in tables of board-specific device descriptors, which are
|
|
|
|
* declared early in board initialization and then used (much later) to
|
|
|
|
* populate a controller's device tree after the that controller's driver
|
|
|
|
* initializes. A secondary (and atypical) role is as a parameter to
|
|
|
|
* spi_new_device() call, which happens after those controller drivers
|
|
|
|
* are active in some dynamic board configuration models.
|
|
|
|
*/
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
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,
|
2006-01-09 05:34:23 +08:00
|
|
|
* controller_data goes to spi_device.controller_data,
|
2017-03-01 06:25:18 +08:00
|
|
|
* device properties are copied and attached to spi_device,
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
* irq is copied too
|
|
|
|
*/
|
2009-09-23 07:46:04 +08:00
|
|
|
char modalias[SPI_NAME_SIZE];
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
const void *platform_data;
|
2017-03-01 06:25:18 +08:00
|
|
|
const struct property_entry *properties;
|
2006-01-09 05:34:23 +08:00
|
|
|
void *controller_data;
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
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
|
2017-06-13 19:23:52 +08:00
|
|
|
* spi_controller that will probably be registered later.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*
|
|
|
|
* chip_select reflects how this chip is wired to that master;
|
|
|
|
* it's less than num_chipselect.
|
|
|
|
*/
|
|
|
|
u16 bus_num;
|
|
|
|
u16 chip_select;
|
|
|
|
|
2006-06-28 22:47:15 +08:00
|
|
|
/* mode becomes spi_device.mode, and is essential for chips
|
|
|
|
* where the default of SPI_CS_HIGH = 0 is wrong.
|
|
|
|
*/
|
2019-04-16 05:30:27 +08:00
|
|
|
u32 mode;
|
2006-06-28 22:47:15 +08:00
|
|
|
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
/* ... 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:
|
|
|
|
* - 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)
|
2006-01-09 05:34:25 +08:00
|
|
|
* use spi_new_device() to describe each device. You can also call
|
|
|
|
* spi_unregister_device() to start making that device vanish, but
|
2017-06-13 19:23:52 +08:00
|
|
|
* normally that would be handled by spi_unregister_controller().
|
2008-05-16 06:50:22 +08:00
|
|
|
*
|
|
|
|
* You can also use spi_alloc_device() and spi_add_device() to use a two
|
|
|
|
* stage registration sequence for each spi_device. This gives the caller
|
|
|
|
* some more control over the spi_device structure before it is registered,
|
|
|
|
* but requires that caller to initialize fields that would otherwise
|
|
|
|
* be defined using the board info.
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
*/
|
2008-05-16 06:50:22 +08:00
|
|
|
extern struct spi_device *
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_alloc_device(struct spi_controller *ctlr);
|
2008-05-16 06:50:22 +08:00
|
|
|
|
|
|
|
extern int
|
|
|
|
spi_add_device(struct spi_device *spi);
|
|
|
|
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
extern struct spi_device *
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_new_device(struct spi_controller *, struct spi_board_info *);
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
2015-11-30 22:28:06 +08:00
|
|
|
extern void spi_unregister_device(struct spi_device *spi);
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
|
2009-09-23 07:46:04 +08:00
|
|
|
extern const struct spi_device_id *
|
|
|
|
spi_get_device_id(const struct spi_device *sdev);
|
|
|
|
|
2014-11-22 23:21:39 +08:00
|
|
|
static inline bool
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_transfer_is_last(struct spi_controller *ctlr, struct spi_transfer *xfer)
|
2014-11-22 23:21:39 +08:00
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
return list_is_last(&xfer->transfer_list, &ctlr->cur_msg->transfers);
|
2014-11-22 23:21:39 +08:00
|
|
|
}
|
|
|
|
|
2018-09-25 17:42:29 +08:00
|
|
|
/* OF support code */
|
|
|
|
#if IS_ENABLED(CONFIG_OF)
|
|
|
|
|
|
|
|
/* must call put_device() when done with returned spi_device device */
|
|
|
|
extern struct spi_device *
|
|
|
|
of_find_spi_device_by_node(struct device_node *node);
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
static inline struct spi_device *
|
|
|
|
of_find_spi_device_by_node(struct device_node *node)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* IS_ENABLED(CONFIG_OF) */
|
2017-06-13 19:23:52 +08:00
|
|
|
|
|
|
|
/* Compatibility layer */
|
|
|
|
#define spi_master spi_controller
|
|
|
|
|
|
|
|
#define SPI_MASTER_HALF_DUPLEX SPI_CONTROLLER_HALF_DUPLEX
|
|
|
|
#define SPI_MASTER_NO_RX SPI_CONTROLLER_NO_RX
|
|
|
|
#define SPI_MASTER_NO_TX SPI_CONTROLLER_NO_TX
|
|
|
|
#define SPI_MASTER_MUST_RX SPI_CONTROLLER_MUST_RX
|
|
|
|
#define SPI_MASTER_MUST_TX SPI_CONTROLLER_MUST_TX
|
|
|
|
|
|
|
|
#define spi_master_get_devdata(_ctlr) spi_controller_get_devdata(_ctlr)
|
|
|
|
#define spi_master_set_devdata(_ctlr, _data) \
|
|
|
|
spi_controller_set_devdata(_ctlr, _data)
|
|
|
|
#define spi_master_get(_ctlr) spi_controller_get(_ctlr)
|
|
|
|
#define spi_master_put(_ctlr) spi_controller_put(_ctlr)
|
|
|
|
#define spi_master_suspend(_ctlr) spi_controller_suspend(_ctlr)
|
|
|
|
#define spi_master_resume(_ctlr) spi_controller_resume(_ctlr)
|
|
|
|
|
|
|
|
#define spi_register_master(_ctlr) spi_register_controller(_ctlr)
|
|
|
|
#define devm_spi_register_master(_dev, _ctlr) \
|
|
|
|
devm_spi_register_controller(_dev, _ctlr)
|
|
|
|
#define spi_unregister_master(_ctlr) spi_unregister_controller(_ctlr)
|
|
|
|
|
[PATCH] spi: simple SPI framework
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.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:19 +08:00
|
|
|
#endif /* __LINUX_SPI_H */
|