2018-09-25 17:42:28 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2018-11-30 00:24:37 +08:00
|
|
|
// SPI init/core code
|
|
|
|
//
|
|
|
|
// Copyright (C) 2005 David Brownell
|
|
|
|
// Copyright (C) 2008 Secret Lab Technologies Ltd.
|
[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
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/cache.h>
|
2014-01-16 20:22:43 +08:00
|
|
|
#include <linux/dma-mapping.h>
|
|
|
|
#include <linux/dmaengine.h>
|
2007-07-17 19:04:16 +08:00
|
|
|
#include <linux/mutex.h>
|
2010-10-03 11:28:29 +08:00
|
|
|
#include <linux/of_device.h>
|
2012-04-08 04:16:53 +08:00
|
|
|
#include <linux/of_irq.h>
|
2014-06-18 23:29:32 +08:00
|
|
|
#include <linux/clk/clk-conf.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>
|
2009-09-23 07:46:08 +08:00
|
|
|
#include <linux/mod_devicetable.h>
|
[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
|
|
|
#include <linux/spi/spi.h>
|
2018-04-27 00:18:15 +08:00
|
|
|
#include <linux/spi/spi-mem.h>
|
2019-01-07 23:51:50 +08:00
|
|
|
#include <linux/gpio/consumer.h>
|
2010-12-25 22:32:27 +08:00
|
|
|
#include <linux/pm_runtime.h>
|
2014-09-29 19:58:47 +08:00
|
|
|
#include <linux/pm_domain.h>
|
2017-03-01 06:25:18 +08:00
|
|
|
#include <linux/property.h>
|
2011-07-11 00:57:55 +08:00
|
|
|
#include <linux/export.h>
|
2013-02-07 23:47:07 +08:00
|
|
|
#include <linux/sched/rt.h>
|
2017-02-02 01:07:51 +08:00
|
|
|
#include <uapi/linux/sched/types.h>
|
2012-02-22 17:05:38 +08:00
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/kthread.h>
|
2012-11-30 19:37:53 +08:00
|
|
|
#include <linux/ioport.h>
|
|
|
|
#include <linux/acpi.h>
|
2016-08-17 17:52:36 +08:00
|
|
|
#include <linux/highmem.h>
|
2017-08-03 12:35:57 +08:00
|
|
|
#include <linux/idr.h>
|
2017-08-01 20:10:41 +08:00
|
|
|
#include <linux/platform_data/x86/apple.h>
|
2021-09-04 09:31:40 +08:00
|
|
|
#include <linux/ptp_clock_kernel.h>
|
2022-05-24 17:18:08 +08:00
|
|
|
#include <linux/percpu.h>
|
[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
|
|
|
|
2013-10-08 02:33:53 +08:00
|
|
|
#define CREATE_TRACE_POINTS
|
|
|
|
#include <trace/events/spi.h>
|
2019-03-21 20:42:25 +08:00
|
|
|
EXPORT_TRACEPOINT_SYMBOL(spi_transfer_start);
|
|
|
|
EXPORT_TRACEPOINT_SYMBOL(spi_transfer_stop);
|
2017-08-03 12:35:57 +08:00
|
|
|
|
2018-04-23 02:35:14 +08:00
|
|
|
#include "internals.h"
|
|
|
|
|
2017-08-03 12:35:57 +08:00
|
|
|
static DEFINE_IDR(spi_master_idr);
|
2013-10-08 02:33:53 +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
|
|
|
static void spidev_release(struct device *dev)
|
|
|
|
{
|
2007-02-12 16:52:45 +08:00
|
|
|
struct spi_device *spi = to_spi_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
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_controller_put(spi->controller);
|
2018-09-21 03:18:32 +08:00
|
|
|
kfree(spi->driver_override);
|
2022-05-24 17:18:08 +08:00
|
|
|
free_percpu(spi->pcpu_statistics);
|
2010-04-12 17:56:35 +08:00
|
|
|
kfree(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
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t
|
|
|
|
modalias_show(struct device *dev, struct device_attribute *a, char *buf)
|
|
|
|
{
|
|
|
|
const struct spi_device *spi = to_spi_device(dev);
|
ACPI: fix module autoloading for ACPI enumerated devices
ACPI enumerated devices has ACPI style _HID and _CID strings,
all of these strings can be used for both driver loading and matching.
Currently, in Platform, I2C and SPI bus, the ACPI style driver matching
is supported by invoking acpi_driver_match_device() in bus .match() callback.
But, the module autoloading is still broken.
For example, there is any ACPI device with _HID "INTABCD" that is
enumerated to platform bus, and we have a driver that can probe it.
The driver exports its module_alias as "acpi:INTABCD" use the following code
static const struct acpi_device_id xxx_acpi_match[] = {
{ "INTABCD", 0 },
{ }
};
MODULE_DEVICE_TABLE(acpi, xxx_acpi_match);
But, unfortunately, the device' modalias is shown as "platform:INTABCD:00",
please refer to modalias_show() and platform_uevent() in
drivers/base/platform.c.
This results in that the driver will not be loaded automatically when the
device node is created, because their modalias do not match.
This also applies to I2C and SPI bus.
With this patch, the device' modalias will be shown as "acpi:INTABCD" as well.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Mark Brown <broonie@linaro.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-14 16:46:37 +08:00
|
|
|
int len;
|
|
|
|
|
|
|
|
len = acpi_device_modalias(dev, buf, PAGE_SIZE - 1);
|
|
|
|
if (len != -ENODEV)
|
|
|
|
return 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
|
|
|
|
2012-05-20 14:08:13 +08:00
|
|
|
return sprintf(buf, "%s%s\n", SPI_MODULE_PREFIX, spi->modalias);
|
[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
|
|
|
}
|
2013-10-08 09:27:38 +08:00
|
|
|
static DEVICE_ATTR_RO(modalias);
|
[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-21 03:18:32 +08:00
|
|
|
static ssize_t driver_override_store(struct device *dev,
|
|
|
|
struct device_attribute *a,
|
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
struct spi_device *spi = to_spi_device(dev);
|
2022-04-19 19:34:30 +08:00
|
|
|
int ret;
|
2018-09-21 03:18:32 +08:00
|
|
|
|
2022-04-19 19:34:30 +08:00
|
|
|
ret = driver_set_override(dev, &spi->driver_override, buf, count);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2018-09-21 03:18:32 +08:00
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t driver_override_show(struct device *dev,
|
|
|
|
struct device_attribute *a, char *buf)
|
|
|
|
{
|
|
|
|
const struct spi_device *spi = to_spi_device(dev);
|
|
|
|
ssize_t len;
|
|
|
|
|
|
|
|
device_lock(dev);
|
|
|
|
len = snprintf(buf, PAGE_SIZE, "%s\n", spi->driver_override ? : "");
|
|
|
|
device_unlock(dev);
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RW(driver_override);
|
|
|
|
|
2022-08-05 16:44:58 +08:00
|
|
|
static struct spi_statistics __percpu *spi_alloc_pcpu_stats(struct device *dev)
|
2022-05-24 17:18:08 +08:00
|
|
|
{
|
|
|
|
struct spi_statistics __percpu *pcpu_stats;
|
|
|
|
|
|
|
|
if (dev)
|
|
|
|
pcpu_stats = devm_alloc_percpu(dev, struct spi_statistics);
|
|
|
|
else
|
|
|
|
pcpu_stats = alloc_percpu_gfp(struct spi_statistics, GFP_KERNEL);
|
|
|
|
|
|
|
|
if (pcpu_stats) {
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
struct spi_statistics *stat;
|
|
|
|
|
|
|
|
stat = per_cpu_ptr(pcpu_stats, cpu);
|
|
|
|
u64_stats_init(&stat->syncp);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return pcpu_stats;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define spi_pcpu_stats_totalize(ret, in, field) \
|
|
|
|
do { \
|
|
|
|
int i; \
|
|
|
|
ret = 0; \
|
|
|
|
for_each_possible_cpu(i) { \
|
|
|
|
const struct spi_statistics *pcpu_stats; \
|
|
|
|
u64 inc; \
|
|
|
|
unsigned int start; \
|
|
|
|
pcpu_stats = per_cpu_ptr(in, i); \
|
|
|
|
do { \
|
|
|
|
start = u64_stats_fetch_begin_irq( \
|
|
|
|
&pcpu_stats->syncp); \
|
|
|
|
inc = u64_stats_read(&pcpu_stats->field); \
|
|
|
|
} while (u64_stats_fetch_retry_irq( \
|
|
|
|
&pcpu_stats->syncp, start)); \
|
|
|
|
ret += inc; \
|
|
|
|
} \
|
|
|
|
} while (0)
|
|
|
|
|
2015-06-22 21:00:36 +08:00
|
|
|
#define SPI_STATISTICS_ATTRS(field, file) \
|
2017-06-13 19:23:52 +08:00
|
|
|
static ssize_t spi_controller_##field##_show(struct device *dev, \
|
|
|
|
struct device_attribute *attr, \
|
|
|
|
char *buf) \
|
2015-06-22 21:00:36 +08:00
|
|
|
{ \
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = container_of(dev, \
|
|
|
|
struct spi_controller, dev); \
|
2022-05-24 17:18:08 +08:00
|
|
|
return spi_statistics_##field##_show(ctlr->pcpu_statistics, buf); \
|
2015-06-22 21:00:36 +08:00
|
|
|
} \
|
2017-06-13 19:23:52 +08:00
|
|
|
static struct device_attribute dev_attr_spi_controller_##field = { \
|
2017-05-04 22:29:56 +08:00
|
|
|
.attr = { .name = file, .mode = 0444 }, \
|
2017-06-13 19:23:52 +08:00
|
|
|
.show = spi_controller_##field##_show, \
|
2015-06-22 21:00:36 +08:00
|
|
|
}; \
|
|
|
|
static ssize_t spi_device_##field##_show(struct device *dev, \
|
|
|
|
struct device_attribute *attr, \
|
|
|
|
char *buf) \
|
|
|
|
{ \
|
2015-12-23 00:18:41 +08:00
|
|
|
struct spi_device *spi = to_spi_device(dev); \
|
2022-05-24 17:18:08 +08:00
|
|
|
return spi_statistics_##field##_show(spi->pcpu_statistics, buf); \
|
2015-06-22 21:00:36 +08:00
|
|
|
} \
|
|
|
|
static struct device_attribute dev_attr_spi_device_##field = { \
|
2017-05-04 22:29:56 +08:00
|
|
|
.attr = { .name = file, .mode = 0444 }, \
|
2015-06-22 21:00:36 +08:00
|
|
|
.show = spi_device_##field##_show, \
|
|
|
|
}
|
|
|
|
|
2022-05-24 17:18:08 +08:00
|
|
|
#define SPI_STATISTICS_SHOW_NAME(name, file, field) \
|
2022-08-05 16:44:58 +08:00
|
|
|
static ssize_t spi_statistics_##name##_show(struct spi_statistics __percpu *stat, \
|
2015-06-22 21:00:36 +08:00
|
|
|
char *buf) \
|
|
|
|
{ \
|
|
|
|
ssize_t len; \
|
2022-05-24 17:18:08 +08:00
|
|
|
u64 val; \
|
|
|
|
spi_pcpu_stats_totalize(val, stat, field); \
|
|
|
|
len = sysfs_emit(buf, "%llu\n", val); \
|
2015-06-22 21:00:36 +08:00
|
|
|
return len; \
|
|
|
|
} \
|
|
|
|
SPI_STATISTICS_ATTRS(name, file)
|
|
|
|
|
2022-05-24 17:18:08 +08:00
|
|
|
#define SPI_STATISTICS_SHOW(field) \
|
2015-06-22 21:00:36 +08:00
|
|
|
SPI_STATISTICS_SHOW_NAME(field, __stringify(field), \
|
2022-05-24 17:18:08 +08:00
|
|
|
field)
|
2015-06-22 21:00:36 +08:00
|
|
|
|
2022-05-24 17:18:08 +08:00
|
|
|
SPI_STATISTICS_SHOW(messages);
|
|
|
|
SPI_STATISTICS_SHOW(transfers);
|
|
|
|
SPI_STATISTICS_SHOW(errors);
|
|
|
|
SPI_STATISTICS_SHOW(timedout);
|
2015-06-22 21:00:36 +08:00
|
|
|
|
2022-05-24 17:18:08 +08:00
|
|
|
SPI_STATISTICS_SHOW(spi_sync);
|
|
|
|
SPI_STATISTICS_SHOW(spi_sync_immediate);
|
|
|
|
SPI_STATISTICS_SHOW(spi_async);
|
2015-06-22 21:00:36 +08:00
|
|
|
|
2022-05-24 17:18:08 +08:00
|
|
|
SPI_STATISTICS_SHOW(bytes);
|
|
|
|
SPI_STATISTICS_SHOW(bytes_rx);
|
|
|
|
SPI_STATISTICS_SHOW(bytes_tx);
|
2015-06-22 21:00:36 +08:00
|
|
|
|
2015-06-22 21:02:04 +08:00
|
|
|
#define SPI_STATISTICS_TRANSFER_BYTES_HISTO(index, number) \
|
|
|
|
SPI_STATISTICS_SHOW_NAME(transfer_bytes_histo##index, \
|
|
|
|
"transfer_bytes_histo_" number, \
|
2022-05-24 17:18:08 +08:00
|
|
|
transfer_bytes_histo[index])
|
2015-06-22 21:02:04 +08:00
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(0, "0-1");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(1, "2-3");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(2, "4-7");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(3, "8-15");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(4, "16-31");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(5, "32-63");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(6, "64-127");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(7, "128-255");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(8, "256-511");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(9, "512-1023");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(10, "1024-2047");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(11, "2048-4095");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(12, "4096-8191");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(13, "8192-16383");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(14, "16384-32767");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(15, "32768-65535");
|
|
|
|
SPI_STATISTICS_TRANSFER_BYTES_HISTO(16, "65536+");
|
|
|
|
|
2022-05-24 17:18:08 +08:00
|
|
|
SPI_STATISTICS_SHOW(transfers_split_maxsize);
|
2015-12-14 23:20:20 +08:00
|
|
|
|
2013-10-08 09:27:38 +08:00
|
|
|
static struct attribute *spi_dev_attrs[] = {
|
|
|
|
&dev_attr_modalias.attr,
|
2018-09-21 03:18:32 +08:00
|
|
|
&dev_attr_driver_override.attr,
|
2013-10-08 09:27:38 +08:00
|
|
|
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
|
|
|
};
|
2015-06-22 21:00:36 +08:00
|
|
|
|
|
|
|
static const struct attribute_group spi_dev_group = {
|
|
|
|
.attrs = spi_dev_attrs,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct attribute *spi_device_statistics_attrs[] = {
|
|
|
|
&dev_attr_spi_device_messages.attr,
|
|
|
|
&dev_attr_spi_device_transfers.attr,
|
|
|
|
&dev_attr_spi_device_errors.attr,
|
|
|
|
&dev_attr_spi_device_timedout.attr,
|
|
|
|
&dev_attr_spi_device_spi_sync.attr,
|
|
|
|
&dev_attr_spi_device_spi_sync_immediate.attr,
|
|
|
|
&dev_attr_spi_device_spi_async.attr,
|
|
|
|
&dev_attr_spi_device_bytes.attr,
|
|
|
|
&dev_attr_spi_device_bytes_rx.attr,
|
|
|
|
&dev_attr_spi_device_bytes_tx.attr,
|
2015-06-22 21:02:04 +08:00
|
|
|
&dev_attr_spi_device_transfer_bytes_histo0.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo1.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo2.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo3.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo4.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo5.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo6.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo7.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo8.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo9.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo10.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo11.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo12.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo13.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo14.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo15.attr,
|
|
|
|
&dev_attr_spi_device_transfer_bytes_histo16.attr,
|
2015-12-14 23:20:20 +08:00
|
|
|
&dev_attr_spi_device_transfers_split_maxsize.attr,
|
2015-06-22 21:00:36 +08:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct attribute_group spi_device_statistics_group = {
|
|
|
|
.name = "statistics",
|
|
|
|
.attrs = spi_device_statistics_attrs,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct attribute_group *spi_dev_groups[] = {
|
|
|
|
&spi_dev_group,
|
|
|
|
&spi_device_statistics_group,
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static struct attribute *spi_controller_statistics_attrs[] = {
|
|
|
|
&dev_attr_spi_controller_messages.attr,
|
|
|
|
&dev_attr_spi_controller_transfers.attr,
|
|
|
|
&dev_attr_spi_controller_errors.attr,
|
|
|
|
&dev_attr_spi_controller_timedout.attr,
|
|
|
|
&dev_attr_spi_controller_spi_sync.attr,
|
|
|
|
&dev_attr_spi_controller_spi_sync_immediate.attr,
|
|
|
|
&dev_attr_spi_controller_spi_async.attr,
|
|
|
|
&dev_attr_spi_controller_bytes.attr,
|
|
|
|
&dev_attr_spi_controller_bytes_rx.attr,
|
|
|
|
&dev_attr_spi_controller_bytes_tx.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo0.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo1.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo2.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo3.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo4.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo5.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo6.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo7.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo8.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo9.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo10.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo11.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo12.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo13.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo14.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo15.attr,
|
|
|
|
&dev_attr_spi_controller_transfer_bytes_histo16.attr,
|
|
|
|
&dev_attr_spi_controller_transfers_split_maxsize.attr,
|
2015-06-22 21:00:36 +08:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static const struct attribute_group spi_controller_statistics_group = {
|
2015-06-22 21:00:36 +08:00
|
|
|
.name = "statistics",
|
2017-06-13 19:23:52 +08:00
|
|
|
.attrs = spi_controller_statistics_attrs,
|
2015-06-22 21:00:36 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct attribute_group *spi_master_groups[] = {
|
2017-06-13 19:23:52 +08:00
|
|
|
&spi_controller_statistics_group,
|
2015-06-22 21:00:36 +08:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2022-08-05 16:44:58 +08:00
|
|
|
static void spi_statistics_add_transfer_stats(struct spi_statistics __percpu *pcpu_stats,
|
2021-10-07 20:14:15 +08:00
|
|
|
struct spi_transfer *xfer,
|
|
|
|
struct spi_controller *ctlr)
|
2015-06-22 21:00:36 +08:00
|
|
|
{
|
2015-06-22 21:02:04 +08:00
|
|
|
int l2len = min(fls(xfer->len), SPI_STATISTICS_HISTO_SIZE) - 1;
|
2022-06-09 20:13:34 +08:00
|
|
|
struct spi_statistics *stats;
|
2015-06-22 21:02:04 +08:00
|
|
|
|
|
|
|
if (l2len < 0)
|
|
|
|
l2len = 0;
|
2015-06-22 21:00:36 +08:00
|
|
|
|
2022-06-09 20:13:34 +08:00
|
|
|
get_cpu();
|
|
|
|
stats = this_cpu_ptr(pcpu_stats);
|
2022-05-24 17:18:08 +08:00
|
|
|
u64_stats_update_begin(&stats->syncp);
|
2015-06-22 21:00:36 +08:00
|
|
|
|
2022-05-24 17:18:08 +08:00
|
|
|
u64_stats_inc(&stats->transfers);
|
|
|
|
u64_stats_inc(&stats->transfer_bytes_histo[l2len]);
|
2015-06-22 21:00:36 +08:00
|
|
|
|
2022-05-24 17:18:08 +08:00
|
|
|
u64_stats_add(&stats->bytes, xfer->len);
|
2015-06-22 21:00:36 +08:00
|
|
|
if ((xfer->tx_buf) &&
|
2017-06-13 19:23:52 +08:00
|
|
|
(xfer->tx_buf != ctlr->dummy_tx))
|
2022-05-24 17:18:08 +08:00
|
|
|
u64_stats_add(&stats->bytes_tx, xfer->len);
|
2015-06-22 21:00:36 +08:00
|
|
|
if ((xfer->rx_buf) &&
|
2017-06-13 19:23:52 +08:00
|
|
|
(xfer->rx_buf != ctlr->dummy_rx))
|
2022-05-24 17:18:08 +08:00
|
|
|
u64_stats_add(&stats->bytes_rx, xfer->len);
|
2015-06-22 21:00:36 +08:00
|
|
|
|
2022-05-24 17:18:08 +08:00
|
|
|
u64_stats_update_end(&stats->syncp);
|
2022-06-09 20:13:34 +08:00
|
|
|
put_cpu();
|
2015-06-22 21:00:36 +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
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* modalias support makes "modprobe $MODALIAS" new-style hotplug work,
|
[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 the sysfs version makes coldplug work too.
|
|
|
|
*/
|
2021-11-20 01:37:17 +08:00
|
|
|
static const struct spi_device_id *spi_match_id(const struct spi_device_id *id, const char *name)
|
2009-09-23 07:46:04 +08:00
|
|
|
{
|
|
|
|
while (id->name[0]) {
|
2021-11-20 01:37:17 +08:00
|
|
|
if (!strcmp(name, id->name))
|
2009-09-23 07:46:04 +08:00
|
|
|
return id;
|
|
|
|
id++;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
const struct spi_device_id *spi_get_device_id(const struct spi_device *sdev)
|
|
|
|
{
|
|
|
|
const struct spi_driver *sdrv = to_spi_driver(sdev->dev.driver);
|
|
|
|
|
2021-11-20 01:37:17 +08:00
|
|
|
return spi_match_id(sdrv->id_table, sdev->modalias);
|
2009-09-23 07:46:04 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_get_device_id);
|
|
|
|
|
[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 int spi_match_device(struct device *dev, struct device_driver *drv)
|
|
|
|
{
|
|
|
|
const struct spi_device *spi = to_spi_device(dev);
|
2009-09-23 07:46:04 +08:00
|
|
|
const struct spi_driver *sdrv = to_spi_driver(drv);
|
|
|
|
|
2018-09-21 03:18:32 +08:00
|
|
|
/* Check override first, and if set, only use the named driver */
|
|
|
|
if (spi->driver_override)
|
|
|
|
return strcmp(spi->driver_override, drv->name) == 0;
|
|
|
|
|
2010-10-03 11:28:29 +08:00
|
|
|
/* Attempt an OF style match */
|
|
|
|
if (of_driver_match_device(dev, drv))
|
|
|
|
return 1;
|
|
|
|
|
2012-11-30 19:37:53 +08:00
|
|
|
/* Then try ACPI */
|
|
|
|
if (acpi_driver_match_device(dev, drv))
|
|
|
|
return 1;
|
|
|
|
|
2009-09-23 07:46:04 +08:00
|
|
|
if (sdrv->id_table)
|
2021-11-20 01:37:17 +08:00
|
|
|
return !!spi_match_id(sdrv->id_table, spi->modalias);
|
[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-01-07 02:44:37 +08:00
|
|
|
return strcmp(spi->modalias, drv->name) == 0;
|
[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
|
|
|
}
|
|
|
|
|
2007-08-14 21:15:12 +08:00
|
|
|
static int spi_uevent(struct device *dev, struct kobj_uevent_env *env)
|
[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 struct spi_device *spi = to_spi_device(dev);
|
ACPI: fix module autoloading for ACPI enumerated devices
ACPI enumerated devices has ACPI style _HID and _CID strings,
all of these strings can be used for both driver loading and matching.
Currently, in Platform, I2C and SPI bus, the ACPI style driver matching
is supported by invoking acpi_driver_match_device() in bus .match() callback.
But, the module autoloading is still broken.
For example, there is any ACPI device with _HID "INTABCD" that is
enumerated to platform bus, and we have a driver that can probe it.
The driver exports its module_alias as "acpi:INTABCD" use the following code
static const struct acpi_device_id xxx_acpi_match[] = {
{ "INTABCD", 0 },
{ }
};
MODULE_DEVICE_TABLE(acpi, xxx_acpi_match);
But, unfortunately, the device' modalias is shown as "platform:INTABCD:00",
please refer to modalias_show() and platform_uevent() in
drivers/base/platform.c.
This results in that the driver will not be loaded automatically when the
device node is created, because their modalias do not match.
This also applies to I2C and SPI bus.
With this patch, the device' modalias will be shown as "acpi:INTABCD" as well.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Mark Brown <broonie@linaro.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-14 16:46:37 +08:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = acpi_device_uevent_modalias(dev, env);
|
|
|
|
if (rc != -ENODEV)
|
|
|
|
return rc;
|
[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-07-26 21:14:00 +08:00
|
|
|
return add_uevent_var(env, "MODALIAS=%s%s", SPI_MODULE_PREFIX, spi->modalias);
|
[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-11-20 00:16:03 +08:00
|
|
|
static int spi_probe(struct device *dev)
|
2006-01-09 05:34:23 +08:00
|
|
|
{
|
|
|
|
const struct spi_driver *sdrv = to_spi_driver(dev->driver);
|
2015-10-09 22:45:55 +08:00
|
|
|
struct spi_device *spi = to_spi_device(dev);
|
2013-10-10 18:28:48 +08:00
|
|
|
int ret;
|
|
|
|
|
2014-06-18 23:29:32 +08:00
|
|
|
ret = of_clk_set_defaults(dev->of_node, false);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2015-10-09 22:45:55 +08:00
|
|
|
if (dev->of_node) {
|
|
|
|
spi->irq = of_irq_get(dev->of_node, 0);
|
|
|
|
if (spi->irq == -EPROBE_DEFER)
|
|
|
|
return -EPROBE_DEFER;
|
|
|
|
if (spi->irq < 0)
|
|
|
|
spi->irq = 0;
|
|
|
|
}
|
|
|
|
|
2014-09-20 02:27:41 +08:00
|
|
|
ret = dev_pm_domain_attach(dev, true);
|
2018-04-26 16:53:10 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2020-11-20 00:16:02 +08:00
|
|
|
if (sdrv->probe) {
|
|
|
|
ret = sdrv->probe(spi);
|
|
|
|
if (ret)
|
|
|
|
dev_pm_domain_detach(dev, true);
|
|
|
|
}
|
2006-01-09 05:34:23 +08:00
|
|
|
|
2013-10-10 18:28:48 +08:00
|
|
|
return ret;
|
2006-01-09 05:34:23 +08:00
|
|
|
}
|
|
|
|
|
2021-07-14 03:35:22 +08:00
|
|
|
static void spi_remove(struct device *dev)
|
2006-01-09 05:34:23 +08:00
|
|
|
{
|
|
|
|
const struct spi_driver *sdrv = to_spi_driver(dev->driver);
|
2013-10-10 18:28:48 +08:00
|
|
|
|
2022-01-24 01:52:01 +08:00
|
|
|
if (sdrv->remove)
|
|
|
|
sdrv->remove(to_spi_device(dev));
|
2020-11-20 00:16:04 +08:00
|
|
|
|
2014-09-20 02:27:41 +08:00
|
|
|
dev_pm_domain_detach(dev, true);
|
2006-01-09 05:34:23 +08:00
|
|
|
}
|
|
|
|
|
2020-11-20 00:16:03 +08:00
|
|
|
static void spi_shutdown(struct device *dev)
|
2006-01-09 05:34:23 +08:00
|
|
|
{
|
2020-11-24 21:15:23 +08:00
|
|
|
if (dev->driver) {
|
|
|
|
const struct spi_driver *sdrv = to_spi_driver(dev->driver);
|
2006-01-09 05:34:23 +08:00
|
|
|
|
2020-11-24 21:15:23 +08:00
|
|
|
if (sdrv->shutdown)
|
|
|
|
sdrv->shutdown(to_spi_device(dev));
|
|
|
|
}
|
2006-01-09 05:34:23 +08:00
|
|
|
}
|
|
|
|
|
2020-11-20 00:16:03 +08:00
|
|
|
struct bus_type spi_bus_type = {
|
|
|
|
.name = "spi",
|
|
|
|
.dev_groups = spi_dev_groups,
|
|
|
|
.match = spi_match_device,
|
|
|
|
.uevent = spi_uevent,
|
|
|
|
.probe = spi_probe,
|
|
|
|
.remove = spi_remove,
|
|
|
|
.shutdown = spi_shutdown,
|
|
|
|
};
|
|
|
|
EXPORT_SYMBOL_GPL(spi_bus_type);
|
|
|
|
|
2007-05-08 15:32:21 +08:00
|
|
|
/**
|
2015-10-23 21:59:10 +08:00
|
|
|
* __spi_register_driver - register a SPI driver
|
2015-11-10 20:03:04 +08:00
|
|
|
* @owner: owner module of the driver to register
|
2007-05-08 15:32:21 +08:00
|
|
|
* @sdrv: the driver to register
|
|
|
|
* Context: can sleep
|
2015-10-23 00:59:23 +08:00
|
|
|
*
|
|
|
|
* Return: zero on success, else a negative error code.
|
2007-05-08 15:32:21 +08:00
|
|
|
*/
|
2015-10-23 21:59:10 +08:00
|
|
|
int __spi_register_driver(struct module *owner, struct spi_driver *sdrv)
|
2006-01-09 05:34:23 +08:00
|
|
|
{
|
2015-10-23 21:59:10 +08:00
|
|
|
sdrv->driver.owner = owner;
|
2006-01-09 05:34:23 +08:00
|
|
|
sdrv->driver.bus = &spi_bus_type;
|
2021-09-22 03:21:49 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* For Really Good Reasons we use spi: modaliases not of:
|
|
|
|
* modaliases for DT so module autoloading won't work if we
|
|
|
|
* don't have a spi_device_id as well as a compatible string.
|
|
|
|
*/
|
|
|
|
if (sdrv->driver.of_match_table) {
|
|
|
|
const struct of_device_id *of_id;
|
|
|
|
|
|
|
|
for (of_id = sdrv->driver.of_match_table; of_id->compatible[0];
|
|
|
|
of_id++) {
|
|
|
|
const char *of_name;
|
|
|
|
|
|
|
|
/* Strip off any vendor prefix */
|
|
|
|
of_name = strnchr(of_id->compatible,
|
|
|
|
sizeof(of_id->compatible), ',');
|
|
|
|
if (of_name)
|
|
|
|
of_name++;
|
|
|
|
else
|
|
|
|
of_name = of_id->compatible;
|
|
|
|
|
|
|
|
if (sdrv->id_table) {
|
|
|
|
const struct spi_device_id *spi_id;
|
|
|
|
|
2021-11-20 01:37:17 +08:00
|
|
|
spi_id = spi_match_id(sdrv->id_table, of_name);
|
2021-11-24 01:00:32 +08:00
|
|
|
if (spi_id)
|
2021-09-22 03:21:49 +08:00
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
if (strcmp(sdrv->driver.name, of_name) == 0)
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
pr_warn("SPI driver %s has no spi_device_id for %s\n",
|
|
|
|
sdrv->driver.name, of_id->compatible);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-01-09 05:34:23 +08:00
|
|
|
return driver_register(&sdrv->driver);
|
|
|
|
}
|
2015-10-23 21:59:10 +08:00
|
|
|
EXPORT_SYMBOL_GPL(__spi_register_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
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* SPI devices should normally not be created by SPI device drivers; that
|
2017-06-13 19:23:52 +08:00
|
|
|
* would make them board-specific. Similarly with SPI controller drivers.
|
[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 registration normally goes into like arch/.../mach.../board-YYY.c
|
|
|
|
* with other readonly (flashable) information about mainboard devices.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct boardinfo {
|
|
|
|
struct list_head list;
|
2010-08-02 15:52:15 +08:00
|
|
|
struct spi_board_info 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
|
|
|
};
|
|
|
|
|
|
|
|
static LIST_HEAD(board_list);
|
2017-06-13 19:23:52 +08:00
|
|
|
static LIST_HEAD(spi_controller_list);
|
2010-08-02 15:52:15 +08:00
|
|
|
|
|
|
|
/*
|
2019-10-23 20:16:43 +08:00
|
|
|
* Used to protect add/del operation for board_info list and
|
2021-11-23 01:17:21 +08:00
|
|
|
* spi_controller list, and their matching process also used
|
|
|
|
* to protect object of type struct idr.
|
2010-08-02 15:52:15 +08:00
|
|
|
*/
|
2007-07-17 19:04:16 +08:00
|
|
|
static DEFINE_MUTEX(board_lock);
|
[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
|
|
|
/**
|
|
|
|
* spi_alloc_device - Allocate a new SPI device
|
2017-06-13 19:23:52 +08:00
|
|
|
* @ctlr: Controller to which device is connected
|
2008-05-16 06:50:22 +08:00
|
|
|
* Context: can sleep
|
|
|
|
*
|
|
|
|
* Allows a driver to allocate and initialize a spi_device without
|
|
|
|
* registering it immediately. This allows a driver to directly
|
|
|
|
* fill the spi_device with device parameters before calling
|
|
|
|
* spi_add_device() on it.
|
|
|
|
*
|
|
|
|
* Caller is responsible to call spi_add_device() on the returned
|
2017-06-13 19:23:52 +08:00
|
|
|
* spi_device structure to add it to the SPI controller. If the caller
|
2008-05-16 06:50:22 +08:00
|
|
|
* needs to discard the spi_device without adding it, then it should
|
|
|
|
* call spi_dev_put() on it.
|
|
|
|
*
|
2015-10-23 00:59:23 +08:00
|
|
|
* Return: a pointer to the new device, or NULL.
|
2008-05-16 06:50:22 +08:00
|
|
|
*/
|
2022-01-22 01:24:23 +08:00
|
|
|
struct spi_device *spi_alloc_device(struct spi_controller *ctlr)
|
2008-05-16 06:50:22 +08:00
|
|
|
{
|
|
|
|
struct spi_device *spi;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (!spi_controller_get(ctlr))
|
2008-05-16 06:50:22 +08:00
|
|
|
return NULL;
|
|
|
|
|
2013-10-14 09:31:51 +08:00
|
|
|
spi = kzalloc(sizeof(*spi), GFP_KERNEL);
|
2008-05-16 06:50:22 +08:00
|
|
|
if (!spi) {
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_controller_put(ctlr);
|
2008-05-16 06:50:22 +08:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2022-05-24 17:18:08 +08:00
|
|
|
spi->pcpu_statistics = spi_alloc_pcpu_stats(NULL);
|
|
|
|
if (!spi->pcpu_statistics) {
|
|
|
|
kfree(spi);
|
|
|
|
spi_controller_put(ctlr);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spi->master = spi->controller = ctlr;
|
|
|
|
spi->dev.parent = &ctlr->dev;
|
2008-05-16 06:50:22 +08:00
|
|
|
spi->dev.bus = &spi_bus_type;
|
|
|
|
spi->dev.release = spidev_release;
|
2020-02-28 23:18:49 +08:00
|
|
|
spi->mode = ctlr->buswidth_override_bits;
|
2015-06-22 21:00:36 +08:00
|
|
|
|
2008-05-16 06:50:22 +08:00
|
|
|
device_initialize(&spi->dev);
|
|
|
|
return spi;
|
|
|
|
}
|
2022-01-22 01:24:23 +08:00
|
|
|
EXPORT_SYMBOL_GPL(spi_alloc_device);
|
2008-05-16 06:50:22 +08:00
|
|
|
|
2013-11-14 20:03:53 +08:00
|
|
|
static void spi_dev_set_name(struct spi_device *spi)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev = ACPI_COMPANION(&spi->dev);
|
|
|
|
|
|
|
|
if (adev) {
|
|
|
|
dev_set_name(&spi->dev, "spi-%s", acpi_dev_name(adev));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_set_name(&spi->dev, "%s.%u", dev_name(&spi->controller->dev),
|
2013-11-14 20:03:53 +08:00
|
|
|
spi->chip_select);
|
|
|
|
}
|
|
|
|
|
2014-01-09 21:23:55 +08:00
|
|
|
static int spi_dev_check(struct device *dev, void *data)
|
|
|
|
{
|
|
|
|
struct spi_device *spi = to_spi_device(dev);
|
|
|
|
struct spi_device *new_spi = data;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (spi->controller == new_spi->controller &&
|
2014-01-09 21:23:55 +08:00
|
|
|
spi->chip_select == new_spi->chip_select)
|
|
|
|
return -EBUSY;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-04-27 07:56:38 +08:00
|
|
|
static void spi_cleanup(struct spi_device *spi)
|
|
|
|
{
|
|
|
|
if (spi->controller->cleanup)
|
|
|
|
spi->controller->cleanup(spi);
|
|
|
|
}
|
|
|
|
|
2021-06-22 01:53:55 +08:00
|
|
|
static int __spi_add_device(struct spi_device *spi)
|
2008-05-16 06:50:22 +08:00
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = spi->controller;
|
|
|
|
struct device *dev = ctlr->dev.parent;
|
2008-05-16 06:50:22 +08:00
|
|
|
int status;
|
|
|
|
|
2021-10-07 20:14:12 +08:00
|
|
|
/*
|
|
|
|
* We need to make sure there's no other device with this
|
|
|
|
* chipselect **BEFORE** we call setup(), else we'll trash
|
|
|
|
* its configuration.
|
|
|
|
*/
|
2014-01-09 21:23:55 +08:00
|
|
|
status = bus_for_each_dev(&spi_bus_type, NULL, spi, spi_dev_check);
|
|
|
|
if (status) {
|
2008-08-15 15:40:44 +08:00
|
|
|
dev_err(dev, "chipselect %d already in use\n",
|
|
|
|
spi->chip_select);
|
2021-06-22 01:53:55 +08:00
|
|
|
return status;
|
2008-08-15 15:40:44 +08:00
|
|
|
}
|
|
|
|
|
2020-08-03 19:09:01 +08:00
|
|
|
/* Controller may unregister concurrently */
|
|
|
|
if (IS_ENABLED(CONFIG_SPI_DYNAMIC) &&
|
|
|
|
!device_is_registered(&ctlr->dev)) {
|
2021-06-22 01:53:55 +08:00
|
|
|
return -ENODEV;
|
2020-08-03 19:09:01 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:51:50 +08:00
|
|
|
if (ctlr->cs_gpiods)
|
|
|
|
spi->cs_gpiod = ctlr->cs_gpiods[spi->chip_select];
|
2012-11-16 03:19:57 +08:00
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* Drivers may modify this initial i/o setup, but will
|
2008-08-15 15:40:44 +08:00
|
|
|
* normally rely on the device being setup. Devices
|
|
|
|
* using SPI_CS_HIGH can't coexist well otherwise...
|
|
|
|
*/
|
2009-06-18 07:26:03 +08:00
|
|
|
status = spi_setup(spi);
|
2008-05-16 06:50:22 +08:00
|
|
|
if (status < 0) {
|
2010-10-22 03:06:44 +08:00
|
|
|
dev_err(dev, "can't setup %s, status %d\n",
|
|
|
|
dev_name(&spi->dev), status);
|
2021-06-22 01:53:55 +08:00
|
|
|
return status;
|
2008-05-16 06:50:22 +08:00
|
|
|
}
|
|
|
|
|
2008-08-15 15:40:44 +08:00
|
|
|
/* Device may be bound to an active driver when this returns */
|
2008-05-16 06:50:22 +08:00
|
|
|
status = device_add(&spi->dev);
|
2021-04-27 07:56:38 +08:00
|
|
|
if (status < 0) {
|
2010-10-22 03:06:44 +08:00
|
|
|
dev_err(dev, "can't add %s, status %d\n",
|
|
|
|
dev_name(&spi->dev), status);
|
2021-04-27 07:56:38 +08:00
|
|
|
spi_cleanup(spi);
|
|
|
|
} else {
|
2009-01-07 02:44:37 +08:00
|
|
|
dev_dbg(dev, "registered child %s\n", dev_name(&spi->dev));
|
2021-04-27 07:56:38 +08:00
|
|
|
}
|
2008-05-16 06:50:22 +08:00
|
|
|
|
2021-06-22 01:53:55 +08:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* spi_add_device - Add spi_device allocated with spi_alloc_device
|
|
|
|
* @spi: spi_device to register
|
|
|
|
*
|
|
|
|
* Companion function to spi_alloc_device. Devices allocated with
|
|
|
|
* spi_alloc_device can be added onto the spi bus with this function.
|
|
|
|
*
|
|
|
|
* Return: 0 on success; negative errno on failure
|
|
|
|
*/
|
2022-01-22 01:24:23 +08:00
|
|
|
int spi_add_device(struct spi_device *spi)
|
2021-06-22 01:53:55 +08:00
|
|
|
{
|
|
|
|
struct spi_controller *ctlr = spi->controller;
|
|
|
|
struct device *dev = ctlr->dev.parent;
|
|
|
|
int status;
|
|
|
|
|
|
|
|
/* Chipselects are numbered 0..max; validate. */
|
|
|
|
if (spi->chip_select >= ctlr->num_chipselect) {
|
|
|
|
dev_err(dev, "cs%d >= max %d\n", spi->chip_select,
|
|
|
|
ctlr->num_chipselect);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Set the bus ID string */
|
|
|
|
spi_dev_set_name(spi);
|
|
|
|
|
2021-10-08 21:31:57 +08:00
|
|
|
mutex_lock(&ctlr->add_lock);
|
2021-06-22 01:53:55 +08:00
|
|
|
status = __spi_add_device(spi);
|
2021-10-08 21:31:57 +08:00
|
|
|
mutex_unlock(&ctlr->add_lock);
|
2008-08-15 15:40:44 +08:00
|
|
|
return status;
|
2008-05-16 06:50:22 +08:00
|
|
|
}
|
2022-01-22 01:24:23 +08:00
|
|
|
EXPORT_SYMBOL_GPL(spi_add_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
|
|
|
|
2021-06-22 01:53:55 +08:00
|
|
|
static int spi_add_device_locked(struct spi_device *spi)
|
|
|
|
{
|
|
|
|
struct spi_controller *ctlr = spi->controller;
|
|
|
|
struct device *dev = ctlr->dev.parent;
|
|
|
|
|
|
|
|
/* Chipselects are numbered 0..max; validate. */
|
|
|
|
if (spi->chip_select >= ctlr->num_chipselect) {
|
|
|
|
dev_err(dev, "cs%d >= max %d\n", spi->chip_select,
|
|
|
|
ctlr->num_chipselect);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Set the bus ID string */
|
|
|
|
spi_dev_set_name(spi);
|
|
|
|
|
2021-10-08 21:31:57 +08:00
|
|
|
WARN_ON(!mutex_is_locked(&ctlr->add_lock));
|
2021-06-22 01:53:55 +08:00
|
|
|
return __spi_add_device(spi);
|
|
|
|
}
|
|
|
|
|
2007-05-08 15:32:21 +08:00
|
|
|
/**
|
|
|
|
* spi_new_device - instantiate one new SPI device
|
2017-06-13 19:23:52 +08:00
|
|
|
* @ctlr: Controller to which device is connected
|
2007-05-08 15:32:21 +08:00
|
|
|
* @chip: Describes the SPI device
|
|
|
|
* Context: can sleep
|
|
|
|
*
|
|
|
|
* On typical mainboards, this is purely internal; and it's not needed
|
[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
|
|
|
* after board init creates the hard-wired devices. Some development
|
|
|
|
* platforms may not be able to use spi_register_board_info though, and
|
|
|
|
* this is exported so that for example a USB or parport based adapter
|
|
|
|
* driver could add devices (which it would learn about out-of-band).
|
2007-07-31 15:39:45 +08:00
|
|
|
*
|
2015-10-23 00:59:23 +08:00
|
|
|
* Return: the new device, or 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
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_device *spi_new_device(struct spi_controller *ctlr,
|
2007-03-27 13:32:23 +08:00
|
|
|
struct spi_board_info *chip)
|
[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 *proxy;
|
|
|
|
int status;
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* NOTE: caller did any chip->bus_num checks necessary.
|
2007-07-31 15:39:45 +08:00
|
|
|
*
|
|
|
|
* Also, unless we change the return value convention to use
|
|
|
|
* error-or-pointer (not NULL-or-pointer), troubleshootability
|
|
|
|
* suggests syslogged diagnostics are best here (ugh).
|
|
|
|
*/
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
proxy = spi_alloc_device(ctlr);
|
2008-05-16 06:50:22 +08:00
|
|
|
if (!proxy)
|
[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 NULL;
|
|
|
|
|
2008-07-24 12:29:55 +08:00
|
|
|
WARN_ON(strlen(chip->modalias) >= sizeof(proxy->modalias));
|
|
|
|
|
[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
|
|
|
proxy->chip_select = chip->chip_select;
|
|
|
|
proxy->max_speed_hz = chip->max_speed_hz;
|
2006-06-28 22:47:15 +08:00
|
|
|
proxy->mode = chip->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
|
|
|
proxy->irq = chip->irq;
|
2008-07-24 12:29:55 +08:00
|
|
|
strlcpy(proxy->modalias, chip->modalias, sizeof(proxy->modalias));
|
[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
|
|
|
proxy->dev.platform_data = (void *) chip->platform_data;
|
|
|
|
proxy->controller_data = chip->controller_data;
|
|
|
|
proxy->controller_state = NULL;
|
|
|
|
|
2021-03-03 23:28:11 +08:00
|
|
|
if (chip->swnode) {
|
|
|
|
status = device_add_software_node(&proxy->dev, chip->swnode);
|
2017-03-01 06:25:18 +08:00
|
|
|
if (status) {
|
2021-03-17 17:39:36 +08:00
|
|
|
dev_err(&ctlr->dev, "failed to add software node to '%s': %d\n",
|
2017-03-01 06:25:18 +08:00
|
|
|
chip->modalias, status);
|
|
|
|
goto err_dev_put;
|
|
|
|
}
|
[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-03-01 06:25:18 +08:00
|
|
|
status = spi_add_device(proxy);
|
|
|
|
if (status < 0)
|
2021-03-03 23:28:14 +08:00
|
|
|
goto err_dev_put;
|
2017-03-01 06:25:18 +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
|
|
|
return proxy;
|
2017-03-01 06:25:18 +08:00
|
|
|
|
|
|
|
err_dev_put:
|
2021-03-03 23:28:14 +08:00
|
|
|
device_remove_software_node(&proxy->dev);
|
2017-03-01 06:25:18 +08:00
|
|
|
spi_dev_put(proxy);
|
|
|
|
return 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
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_new_device);
|
|
|
|
|
2015-11-30 22:28:06 +08:00
|
|
|
/**
|
|
|
|
* spi_unregister_device - unregister a single SPI device
|
|
|
|
* @spi: spi_device to unregister
|
|
|
|
*
|
|
|
|
* Start making the passed SPI device vanish. Normally this would be handled
|
2017-06-13 19:23:52 +08:00
|
|
|
* by spi_unregister_controller().
|
2015-11-30 22:28:06 +08:00
|
|
|
*/
|
|
|
|
void spi_unregister_device(struct spi_device *spi)
|
|
|
|
{
|
2015-11-30 22:28:07 +08:00
|
|
|
if (!spi)
|
|
|
|
return;
|
|
|
|
|
2017-01-31 00:47:05 +08:00
|
|
|
if (spi->dev.of_node) {
|
2015-11-30 22:28:07 +08:00
|
|
|
of_node_clear_flag(spi->dev.of_node, OF_POPULATED);
|
2017-01-31 00:47:05 +08:00
|
|
|
of_node_put(spi->dev.of_node);
|
|
|
|
}
|
2016-07-09 00:13:11 +08:00
|
|
|
if (ACPI_COMPANION(&spi->dev))
|
|
|
|
acpi_device_clear_enumerated(ACPI_COMPANION(&spi->dev));
|
2021-03-03 23:28:11 +08:00
|
|
|
device_remove_software_node(&spi->dev);
|
2021-05-06 00:47:34 +08:00
|
|
|
device_del(&spi->dev);
|
|
|
|
spi_cleanup(spi);
|
|
|
|
put_device(&spi->dev);
|
2015-11-30 22:28:06 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_unregister_device);
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static void spi_match_controller_to_boardinfo(struct spi_controller *ctlr,
|
|
|
|
struct spi_board_info *bi)
|
2010-08-02 15:52:15 +08:00
|
|
|
{
|
|
|
|
struct spi_device *dev;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->bus_num != bi->bus_num)
|
2010-08-02 15:52:15 +08:00
|
|
|
return;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
dev = spi_new_device(ctlr, bi);
|
2010-08-02 15:52:15 +08:00
|
|
|
if (!dev)
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_err(ctlr->dev.parent, "can't create new device for %s\n",
|
2010-08-02 15:52:15 +08:00
|
|
|
bi->modalias);
|
|
|
|
}
|
|
|
|
|
2007-05-08 15:32:21 +08:00
|
|
|
/**
|
|
|
|
* spi_register_board_info - register SPI devices for a given board
|
|
|
|
* @info: array of chip descriptors
|
|
|
|
* @n: how many descriptors are provided
|
|
|
|
* 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
|
|
|
* Board-specific early init code calls this (probably during arch_initcall)
|
|
|
|
* with segments of the SPI device table. Any device nodes are created later,
|
|
|
|
* after the relevant parent SPI controller (bus_num) is defined. We keep
|
|
|
|
* this table of devices forever, so that reloading a controller driver will
|
|
|
|
* not make Linux forget about these hard-wired devices.
|
|
|
|
*
|
|
|
|
* Other code can also call this, e.g. a particular add-on board might provide
|
|
|
|
* SPI devices through its expansion connector, so code initializing that board
|
|
|
|
* would naturally declare its SPI devices.
|
|
|
|
*
|
|
|
|
* The board info passed can safely be __initdata ... but be careful of
|
|
|
|
* any embedded pointers (platform_data, etc), they're copied as-is.
|
2015-10-23 00:59:23 +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
|
|
|
*/
|
2012-12-08 00:57:14 +08:00
|
|
|
int spi_register_board_info(struct spi_board_info const *info, unsigned n)
|
[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 boardinfo *bi;
|
|
|
|
int i;
|
[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
|
|
|
|
2014-09-24 14:30:29 +08:00
|
|
|
if (!n)
|
2017-03-01 06:25:19 +08:00
|
|
|
return 0;
|
2014-09-24 14:30:29 +08:00
|
|
|
|
2017-01-13 19:28:04 +08:00
|
|
|
bi = kcalloc(n, sizeof(*bi), GFP_KERNEL);
|
[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 (!bi)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2010-08-02 15:52:15 +08:00
|
|
|
for (i = 0; i < n; i++, bi++, info++) {
|
2017-06-13 19:23:52 +08:00
|
|
|
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
|
|
|
|
2010-08-02 15:52:15 +08:00
|
|
|
memcpy(&bi->board_info, info, sizeof(*info));
|
2017-03-01 06:25:18 +08:00
|
|
|
|
2010-08-02 15:52:15 +08:00
|
|
|
mutex_lock(&board_lock);
|
|
|
|
list_add_tail(&bi->list, &board_list);
|
2017-06-13 19:23:52 +08:00
|
|
|
list_for_each_entry(ctlr, &spi_controller_list, list)
|
|
|
|
spi_match_controller_to_boardinfo(ctlr,
|
|
|
|
&bi->board_info);
|
2010-08-02 15:52:15 +08:00
|
|
|
mutex_unlock(&board_lock);
|
[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
|
|
|
|
|
|
|
return 0;
|
[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
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
2021-10-07 20:14:14 +08:00
|
|
|
/* Core methods for SPI resource management */
|
|
|
|
|
|
|
|
/**
|
|
|
|
* spi_res_alloc - allocate a spi resource that is life-cycle managed
|
|
|
|
* during the processing of a spi_message while using
|
|
|
|
* spi_transfer_one
|
|
|
|
* @spi: the spi device for which we allocate memory
|
|
|
|
* @release: the release code to execute for this resource
|
|
|
|
* @size: size to alloc and return
|
|
|
|
* @gfp: GFP allocation flags
|
|
|
|
*
|
|
|
|
* Return: the pointer to the allocated data
|
|
|
|
*
|
|
|
|
* This may get enhanced in the future to allocate from a memory pool
|
|
|
|
* of the @spi_device or @spi_controller to avoid repeated allocations.
|
|
|
|
*/
|
2021-10-07 20:14:15 +08:00
|
|
|
static void *spi_res_alloc(struct spi_device *spi, spi_res_release_t release,
|
|
|
|
size_t size, gfp_t gfp)
|
2021-10-07 20:14:14 +08:00
|
|
|
{
|
|
|
|
struct spi_res *sres;
|
|
|
|
|
|
|
|
sres = kzalloc(sizeof(*sres) + size, gfp);
|
|
|
|
if (!sres)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&sres->entry);
|
|
|
|
sres->release = release;
|
|
|
|
|
|
|
|
return sres->data;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* spi_res_free - free an spi resource
|
|
|
|
* @res: pointer to the custom data of a resource
|
|
|
|
*/
|
2021-10-07 20:14:15 +08:00
|
|
|
static void spi_res_free(void *res)
|
2021-10-07 20:14:14 +08:00
|
|
|
{
|
|
|
|
struct spi_res *sres = container_of(res, struct spi_res, data);
|
|
|
|
|
|
|
|
if (!res)
|
|
|
|
return;
|
|
|
|
|
|
|
|
WARN_ON(!list_empty(&sres->entry));
|
|
|
|
kfree(sres);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* spi_res_add - add a spi_res to the spi_message
|
|
|
|
* @message: the spi message
|
|
|
|
* @res: the spi_resource
|
|
|
|
*/
|
2021-10-07 20:14:15 +08:00
|
|
|
static void spi_res_add(struct spi_message *message, void *res)
|
2021-10-07 20:14:14 +08:00
|
|
|
{
|
|
|
|
struct spi_res *sres = container_of(res, struct spi_res, data);
|
|
|
|
|
|
|
|
WARN_ON(!list_empty(&sres->entry));
|
|
|
|
list_add_tail(&sres->entry, &message->resources);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* spi_res_release - release all spi resources for this message
|
|
|
|
* @ctlr: the @spi_controller
|
|
|
|
* @message: the @spi_message
|
|
|
|
*/
|
2021-10-07 20:14:15 +08:00
|
|
|
static void spi_res_release(struct spi_controller *ctlr, struct spi_message *message)
|
2021-10-07 20:14:14 +08:00
|
|
|
{
|
|
|
|
struct spi_res *res, *tmp;
|
|
|
|
|
|
|
|
list_for_each_entry_safe_reverse(res, tmp, &message->resources, entry) {
|
|
|
|
if (res->release)
|
|
|
|
res->release(ctlr, message, res->data);
|
|
|
|
|
|
|
|
list_del(&res->entry);
|
|
|
|
|
|
|
|
kfree(res);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
2021-04-17 03:59:56 +08:00
|
|
|
static void spi_set_cs(struct spi_device *spi, bool enable, bool force)
|
2013-10-05 18:50:40 +08:00
|
|
|
{
|
2021-04-20 21:18:46 +08:00
|
|
|
bool activate = enable;
|
2019-09-26 18:51:43 +08:00
|
|
|
|
2020-06-30 07:41:06 +08:00
|
|
|
/*
|
|
|
|
* Avoid calling into the driver (or doing delays) if the chip select
|
|
|
|
* isn't actually changing from the last time this was called.
|
|
|
|
*/
|
2022-02-17 22:12:34 +08:00
|
|
|
if (!force && ((enable && spi->controller->last_cs == spi->chip_select) ||
|
|
|
|
(!enable && spi->controller->last_cs != spi->chip_select)) &&
|
2020-06-30 07:41:06 +08:00
|
|
|
(spi->controller->last_cs_mode_high == (spi->mode & SPI_CS_HIGH)))
|
|
|
|
return;
|
|
|
|
|
2021-05-27 03:56:55 +08:00
|
|
|
trace_spi_set_cs(spi, activate);
|
|
|
|
|
2022-02-17 22:12:34 +08:00
|
|
|
spi->controller->last_cs = enable ? spi->chip_select : -1;
|
2020-06-30 07:41:06 +08:00
|
|
|
spi->controller->last_cs_mode_high = spi->mode & SPI_CS_HIGH;
|
|
|
|
|
2022-02-11 07:19:54 +08:00
|
|
|
if ((spi->cs_gpiod || !spi->controller->set_cs_timing) && !activate) {
|
2021-12-11 01:05:34 +08:00
|
|
|
spi_delay_exec(&spi->cs_hold, NULL);
|
2019-09-26 18:51:43 +08:00
|
|
|
}
|
|
|
|
|
2013-10-05 18:50:40 +08:00
|
|
|
if (spi->mode & SPI_CS_HIGH)
|
|
|
|
enable = !enable;
|
|
|
|
|
2022-02-11 07:19:54 +08:00
|
|
|
if (spi->cs_gpiod) {
|
2019-01-07 23:51:50 +08:00
|
|
|
if (!(spi->mode & SPI_NO_CS)) {
|
2022-02-11 07:19:54 +08:00
|
|
|
/*
|
|
|
|
* Historically ACPI has no means of the GPIO polarity and
|
|
|
|
* thus the SPISerialBus() resource defines it on the per-chip
|
|
|
|
* basis. In order to avoid a chain of negations, the GPIO
|
|
|
|
* polarity is considered being Active High. Even for the cases
|
|
|
|
* when _DSD() is involved (in the updated versions of ACPI)
|
|
|
|
* the GPIO CS polarity must be defined Active High to avoid
|
|
|
|
* ambiguity. That's why we use enable, that takes SPI_CS_HIGH
|
|
|
|
* into account.
|
|
|
|
*/
|
|
|
|
if (has_acpi_companion(&spi->dev))
|
|
|
|
gpiod_set_value_cansleep(spi->cs_gpiod, !enable);
|
|
|
|
else
|
|
|
|
/* Polarity handled by GPIO library */
|
|
|
|
gpiod_set_value_cansleep(spi->cs_gpiod, activate);
|
2019-01-07 23:51:50 +08:00
|
|
|
}
|
2016-10-10 22:25:24 +08:00
|
|
|
/* Some SPI masters need both GPIO CS & slave_select */
|
2017-06-13 19:23:52 +08:00
|
|
|
if ((spi->controller->flags & SPI_MASTER_GPIO_SS) &&
|
|
|
|
spi->controller->set_cs)
|
|
|
|
spi->controller->set_cs(spi, !enable);
|
|
|
|
} else if (spi->controller->set_cs) {
|
|
|
|
spi->controller->set_cs(spi, !enable);
|
2016-10-10 22:25:24 +08:00
|
|
|
}
|
2019-09-26 18:51:43 +08:00
|
|
|
|
2022-02-11 07:19:54 +08:00
|
|
|
if (spi->cs_gpiod || !spi->controller->set_cs_timing) {
|
2021-12-11 01:05:34 +08:00
|
|
|
if (activate)
|
|
|
|
spi_delay_exec(&spi->cs_setup, NULL);
|
|
|
|
else
|
2021-08-04 21:37:17 +08:00
|
|
|
spi_delay_exec(&spi->cs_inactive, NULL);
|
2019-09-26 18:51:43 +08:00
|
|
|
}
|
2013-10-05 18:50:40 +08:00
|
|
|
}
|
|
|
|
|
2014-05-02 12:29:34 +08:00
|
|
|
#ifdef CONFIG_HAS_DMA
|
2018-04-23 02:35:14 +08:00
|
|
|
int spi_map_buf(struct spi_controller *ctlr, struct device *dev,
|
|
|
|
struct sg_table *sgt, void *buf, size_t len,
|
|
|
|
enum dma_data_direction dir)
|
2014-02-02 21:47:47 +08:00
|
|
|
{
|
|
|
|
const bool vmalloced_buf = is_vmalloc_addr(buf);
|
2016-03-09 17:20:00 +08:00
|
|
|
unsigned int max_seg_size = dma_get_max_seg_size(dev);
|
2016-08-17 17:52:36 +08:00
|
|
|
#ifdef CONFIG_HIGHMEM
|
|
|
|
const bool kmap_buf = ((unsigned long)buf >= PKMAP_BASE &&
|
|
|
|
(unsigned long)buf < (PKMAP_BASE +
|
|
|
|
(LAST_PKMAP * PAGE_SIZE)));
|
|
|
|
#else
|
|
|
|
const bool kmap_buf = false;
|
|
|
|
#endif
|
2015-06-30 23:48:37 +08:00
|
|
|
int desc_len;
|
|
|
|
int sgs;
|
2014-02-02 21:47:47 +08:00
|
|
|
struct page *vm_page;
|
2016-11-22 06:50:03 +08:00
|
|
|
struct scatterlist *sg;
|
2014-02-02 21:47:47 +08:00
|
|
|
void *sg_buf;
|
|
|
|
size_t min;
|
|
|
|
int i, ret;
|
|
|
|
|
2016-08-17 17:52:36 +08:00
|
|
|
if (vmalloced_buf || kmap_buf) {
|
2022-03-17 01:53:17 +08:00
|
|
|
desc_len = min_t(unsigned long, max_seg_size, PAGE_SIZE);
|
2015-06-30 23:48:37 +08:00
|
|
|
sgs = DIV_ROUND_UP(len + offset_in_page(buf), desc_len);
|
2016-04-25 17:44:00 +08:00
|
|
|
} else if (virt_addr_valid(buf)) {
|
2022-03-17 01:53:17 +08:00
|
|
|
desc_len = min_t(size_t, max_seg_size, ctlr->max_dma_len);
|
2015-06-30 23:48:37 +08:00
|
|
|
sgs = DIV_ROUND_UP(len, desc_len);
|
2016-04-25 17:44:00 +08:00
|
|
|
} else {
|
|
|
|
return -EINVAL;
|
2015-06-30 23:48:37 +08:00
|
|
|
}
|
|
|
|
|
2014-02-02 21:47:47 +08:00
|
|
|
ret = sg_alloc_table(sgt, sgs, GFP_KERNEL);
|
|
|
|
if (ret != 0)
|
|
|
|
return ret;
|
|
|
|
|
2016-11-22 06:50:03 +08:00
|
|
|
sg = &sgt->sgl[0];
|
2014-02-02 21:47:47 +08:00
|
|
|
for (i = 0; i < sgs; i++) {
|
|
|
|
|
2016-08-17 17:52:36 +08:00
|
|
|
if (vmalloced_buf || kmap_buf) {
|
2018-03-02 22:55:09 +08:00
|
|
|
/*
|
|
|
|
* Next scatterlist entry size is the minimum between
|
|
|
|
* the desc_len and the remaining buffer length that
|
|
|
|
* fits in a page.
|
|
|
|
*/
|
|
|
|
min = min_t(size_t, desc_len,
|
|
|
|
min_t(size_t, len,
|
|
|
|
PAGE_SIZE - offset_in_page(buf)));
|
2016-08-17 17:52:36 +08:00
|
|
|
if (vmalloced_buf)
|
|
|
|
vm_page = vmalloc_to_page(buf);
|
|
|
|
else
|
|
|
|
vm_page = kmap_to_page(buf);
|
2014-02-02 21:47:47 +08:00
|
|
|
if (!vm_page) {
|
|
|
|
sg_free_table(sgt);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
2016-11-22 06:50:03 +08:00
|
|
|
sg_set_page(sg, vm_page,
|
2014-11-17 17:14:31 +08:00
|
|
|
min, offset_in_page(buf));
|
2014-02-02 21:47:47 +08:00
|
|
|
} else {
|
2015-06-30 23:48:37 +08:00
|
|
|
min = min_t(size_t, len, desc_len);
|
2014-02-02 21:47:47 +08:00
|
|
|
sg_buf = buf;
|
2016-11-22 06:50:03 +08:00
|
|
|
sg_set_buf(sg, sg_buf, min);
|
2014-02-02 21:47:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
buf += min;
|
|
|
|
len -= min;
|
2016-11-22 06:50:03 +08:00
|
|
|
sg = sg_next(sg);
|
2014-02-02 21:47:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ret = dma_map_sg(dev, sgt->sgl, sgt->nents, dir);
|
2014-07-10 21:29:32 +08:00
|
|
|
if (!ret)
|
|
|
|
ret = -ENOMEM;
|
2014-02-02 21:47:47 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
sg_free_table(sgt);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
sgt->nents = ret;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-04-23 02:35:14 +08:00
|
|
|
void spi_unmap_buf(struct spi_controller *ctlr, struct device *dev,
|
|
|
|
struct sg_table *sgt, enum dma_data_direction dir)
|
2014-02-02 21:47:47 +08:00
|
|
|
{
|
|
|
|
if (sgt->orig_nents) {
|
|
|
|
dma_unmap_sg(dev, sgt->sgl, sgt->orig_nents, dir);
|
|
|
|
sg_free_table(sgt);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static int __spi_map_msg(struct spi_controller *ctlr, struct spi_message *msg)
|
2014-01-16 20:22:43 +08:00
|
|
|
{
|
|
|
|
struct device *tx_dev, *rx_dev;
|
|
|
|
struct spi_transfer *xfer;
|
2014-02-02 21:47:47 +08:00
|
|
|
int ret;
|
2014-01-29 04:17:03 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (!ctlr->can_dma)
|
2014-01-16 20:22:43 +08:00
|
|
|
return 0;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->dma_tx)
|
|
|
|
tx_dev = ctlr->dma_tx->device->dev;
|
2021-06-25 13:22:11 +08:00
|
|
|
else if (ctlr->dma_map_dev)
|
|
|
|
tx_dev = ctlr->dma_map_dev;
|
2015-07-23 17:10:40 +08:00
|
|
|
else
|
2017-06-13 19:23:52 +08:00
|
|
|
tx_dev = ctlr->dev.parent;
|
2015-07-23 17:10:40 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->dma_rx)
|
|
|
|
rx_dev = ctlr->dma_rx->device->dev;
|
2021-06-25 13:22:11 +08:00
|
|
|
else if (ctlr->dma_map_dev)
|
|
|
|
rx_dev = ctlr->dma_map_dev;
|
2015-07-23 17:10:40 +08:00
|
|
|
else
|
2017-06-13 19:23:52 +08:00
|
|
|
rx_dev = ctlr->dev.parent;
|
2014-01-16 20:22:43 +08:00
|
|
|
|
|
|
|
list_for_each_entry(xfer, &msg->transfers, transfer_list) {
|
2017-06-13 19:23:52 +08:00
|
|
|
if (!ctlr->can_dma(ctlr, msg->spi, xfer))
|
2014-01-16 20:22:43 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
if (xfer->tx_buf != NULL) {
|
2017-06-13 19:23:52 +08:00
|
|
|
ret = spi_map_buf(ctlr, tx_dev, &xfer->tx_sg,
|
2014-02-02 21:47:47 +08:00
|
|
|
(void *)xfer->tx_buf, xfer->len,
|
|
|
|
DMA_TO_DEVICE);
|
|
|
|
if (ret != 0)
|
|
|
|
return ret;
|
2014-01-16 20:22:43 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (xfer->rx_buf != NULL) {
|
2017-06-13 19:23:52 +08:00
|
|
|
ret = spi_map_buf(ctlr, rx_dev, &xfer->rx_sg,
|
2014-02-02 21:47:47 +08:00
|
|
|
xfer->rx_buf, xfer->len,
|
|
|
|
DMA_FROM_DEVICE);
|
|
|
|
if (ret != 0) {
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_unmap_buf(ctlr, tx_dev, &xfer->tx_sg,
|
2014-02-02 21:47:47 +08:00
|
|
|
DMA_TO_DEVICE);
|
|
|
|
return ret;
|
2014-01-16 20:22:43 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr->cur_msg_mapped = true;
|
2014-01-16 20:22:43 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static int __spi_unmap_msg(struct spi_controller *ctlr, struct spi_message *msg)
|
2014-01-16 20:22:43 +08:00
|
|
|
{
|
|
|
|
struct spi_transfer *xfer;
|
|
|
|
struct device *tx_dev, *rx_dev;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (!ctlr->cur_msg_mapped || !ctlr->can_dma)
|
2014-01-16 20:22:43 +08:00
|
|
|
return 0;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->dma_tx)
|
|
|
|
tx_dev = ctlr->dma_tx->device->dev;
|
2022-04-06 21:22:38 +08:00
|
|
|
else if (ctlr->dma_map_dev)
|
|
|
|
tx_dev = ctlr->dma_map_dev;
|
2015-07-23 17:10:40 +08:00
|
|
|
else
|
2017-06-13 19:23:52 +08:00
|
|
|
tx_dev = ctlr->dev.parent;
|
2015-07-23 17:10:40 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->dma_rx)
|
|
|
|
rx_dev = ctlr->dma_rx->device->dev;
|
2022-04-06 21:22:38 +08:00
|
|
|
else if (ctlr->dma_map_dev)
|
|
|
|
rx_dev = ctlr->dma_map_dev;
|
2015-07-23 17:10:40 +08:00
|
|
|
else
|
2017-06-13 19:23:52 +08:00
|
|
|
rx_dev = ctlr->dev.parent;
|
2014-01-16 20:22:43 +08:00
|
|
|
|
|
|
|
list_for_each_entry(xfer, &msg->transfers, transfer_list) {
|
2017-06-13 19:23:52 +08:00
|
|
|
if (!ctlr->can_dma(ctlr, msg->spi, xfer))
|
2014-01-16 20:22:43 +08:00
|
|
|
continue;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_unmap_buf(ctlr, rx_dev, &xfer->rx_sg, DMA_FROM_DEVICE);
|
|
|
|
spi_unmap_buf(ctlr, tx_dev, &xfer->tx_sg, DMA_TO_DEVICE);
|
2014-01-16 20:22:43 +08:00
|
|
|
}
|
|
|
|
|
2020-06-17 06:42:08 +08:00
|
|
|
ctlr->cur_msg_mapped = false;
|
|
|
|
|
2014-01-16 20:22:43 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2014-05-02 12:29:34 +08:00
|
|
|
#else /* !CONFIG_HAS_DMA */
|
2017-06-13 19:23:52 +08:00
|
|
|
static inline int __spi_map_msg(struct spi_controller *ctlr,
|
2014-05-02 12:29:34 +08:00
|
|
|
struct spi_message *msg)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static inline int __spi_unmap_msg(struct spi_controller *ctlr,
|
2015-05-25 18:13:10 +08:00
|
|
|
struct spi_message *msg)
|
2014-05-02 12:29:34 +08:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif /* !CONFIG_HAS_DMA */
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static inline int spi_unmap_msg(struct spi_controller *ctlr,
|
2015-05-25 18:13:10 +08:00
|
|
|
struct spi_message *msg)
|
|
|
|
{
|
|
|
|
struct spi_transfer *xfer;
|
|
|
|
|
|
|
|
list_for_each_entry(xfer, &msg->transfers, transfer_list) {
|
|
|
|
/*
|
|
|
|
* Restore the original value of tx_buf or rx_buf if they are
|
|
|
|
* NULL.
|
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
if (xfer->tx_buf == ctlr->dummy_tx)
|
2015-05-25 18:13:10 +08:00
|
|
|
xfer->tx_buf = NULL;
|
2017-06-13 19:23:52 +08:00
|
|
|
if (xfer->rx_buf == ctlr->dummy_rx)
|
2015-05-25 18:13:10 +08:00
|
|
|
xfer->rx_buf = NULL;
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
return __spi_unmap_msg(ctlr, msg);
|
2015-05-25 18:13:10 +08:00
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static int spi_map_msg(struct spi_controller *ctlr, struct spi_message *msg)
|
2014-05-02 12:29:34 +08:00
|
|
|
{
|
|
|
|
struct spi_transfer *xfer;
|
|
|
|
void *tmp;
|
|
|
|
unsigned int max_tx, max_rx;
|
|
|
|
|
2020-05-25 11:45:48 +08:00
|
|
|
if ((ctlr->flags & (SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX))
|
|
|
|
&& !(msg->spi->mode & SPI_3WIRE)) {
|
2014-05-02 12:29:34 +08:00
|
|
|
max_tx = 0;
|
|
|
|
max_rx = 0;
|
|
|
|
|
|
|
|
list_for_each_entry(xfer, &msg->transfers, transfer_list) {
|
2017-06-13 19:23:52 +08:00
|
|
|
if ((ctlr->flags & SPI_CONTROLLER_MUST_TX) &&
|
2014-05-02 12:29:34 +08:00
|
|
|
!xfer->tx_buf)
|
|
|
|
max_tx = max(xfer->len, max_tx);
|
2017-06-13 19:23:52 +08:00
|
|
|
if ((ctlr->flags & SPI_CONTROLLER_MUST_RX) &&
|
2014-05-02 12:29:34 +08:00
|
|
|
!xfer->rx_buf)
|
|
|
|
max_rx = max(xfer->len, max_rx);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (max_tx) {
|
2017-06-13 19:23:52 +08:00
|
|
|
tmp = krealloc(ctlr->dummy_tx, max_tx,
|
2021-11-23 01:17:20 +08:00
|
|
|
GFP_KERNEL | GFP_DMA | __GFP_ZERO);
|
2014-05-02 12:29:34 +08:00
|
|
|
if (!tmp)
|
|
|
|
return -ENOMEM;
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr->dummy_tx = tmp;
|
2014-05-02 12:29:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (max_rx) {
|
2017-06-13 19:23:52 +08:00
|
|
|
tmp = krealloc(ctlr->dummy_rx, max_rx,
|
2014-05-02 12:29:34 +08:00
|
|
|
GFP_KERNEL | GFP_DMA);
|
|
|
|
if (!tmp)
|
|
|
|
return -ENOMEM;
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr->dummy_rx = tmp;
|
2014-05-02 12:29:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (max_tx || max_rx) {
|
|
|
|
list_for_each_entry(xfer, &msg->transfers,
|
|
|
|
transfer_list) {
|
2019-03-08 04:39:00 +08:00
|
|
|
if (!xfer->len)
|
|
|
|
continue;
|
2014-05-02 12:29:34 +08:00
|
|
|
if (!xfer->tx_buf)
|
2017-06-13 19:23:52 +08:00
|
|
|
xfer->tx_buf = ctlr->dummy_tx;
|
2014-05-02 12:29:34 +08:00
|
|
|
if (!xfer->rx_buf)
|
2017-06-13 19:23:52 +08:00
|
|
|
xfer->rx_buf = ctlr->dummy_rx;
|
2014-05-02 12:29:34 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
return __spi_map_msg(ctlr, msg);
|
2014-05-02 12:29:34 +08:00
|
|
|
}
|
2014-01-16 20:22:43 +08:00
|
|
|
|
2018-11-13 18:22:24 +08:00
|
|
|
static int spi_transfer_wait(struct spi_controller *ctlr,
|
|
|
|
struct spi_message *msg,
|
|
|
|
struct spi_transfer *xfer)
|
|
|
|
{
|
2022-08-05 16:44:58 +08:00
|
|
|
struct spi_statistics __percpu *statm = ctlr->pcpu_statistics;
|
|
|
|
struct spi_statistics __percpu *stats = msg->spi->pcpu_statistics;
|
2021-01-04 09:29:09 +08:00
|
|
|
u32 speed_hz = xfer->speed_hz;
|
2020-04-10 20:23:15 +08:00
|
|
|
unsigned long long ms;
|
2018-11-13 18:22:24 +08:00
|
|
|
|
|
|
|
if (spi_controller_is_slave(ctlr)) {
|
|
|
|
if (wait_for_completion_interruptible(&ctlr->xfer_completion)) {
|
|
|
|
dev_dbg(&msg->spi->dev, "SPI transfer interrupted\n");
|
|
|
|
return -EINTR;
|
|
|
|
}
|
|
|
|
} else {
|
2021-01-04 09:29:09 +08:00
|
|
|
if (!speed_hz)
|
|
|
|
speed_hz = 100000;
|
|
|
|
|
2021-05-10 21:11:20 +08:00
|
|
|
/*
|
|
|
|
* For each byte we wait for 8 cycles of the SPI clock.
|
|
|
|
* Since speed is defined in Hz and we want milliseconds,
|
|
|
|
* use respective multiplier, but before the division,
|
|
|
|
* otherwise we may get 0 for short transfers.
|
|
|
|
*/
|
|
|
|
ms = 8LL * MSEC_PER_SEC * xfer->len;
|
2021-01-04 09:29:09 +08:00
|
|
|
do_div(ms, speed_hz);
|
2018-11-13 18:22:24 +08:00
|
|
|
|
2021-05-10 21:11:20 +08:00
|
|
|
/*
|
|
|
|
* Increase it twice and add 200 ms tolerance, use
|
|
|
|
* predefined maximum in case of overflow.
|
|
|
|
*/
|
|
|
|
ms += ms + 200;
|
2018-11-13 18:22:24 +08:00
|
|
|
if (ms > UINT_MAX)
|
|
|
|
ms = UINT_MAX;
|
|
|
|
|
|
|
|
ms = wait_for_completion_timeout(&ctlr->xfer_completion,
|
|
|
|
msecs_to_jiffies(ms));
|
|
|
|
|
|
|
|
if (ms == 0) {
|
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(statm, timedout);
|
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(stats, timedout);
|
|
|
|
dev_err(&msg->spi->dev,
|
|
|
|
"SPI transfer timed out\n");
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-23 16:49:48 +08:00
|
|
|
static void _spi_transfer_delay_ns(u32 ns)
|
|
|
|
{
|
|
|
|
if (!ns)
|
|
|
|
return;
|
2021-05-10 21:11:20 +08:00
|
|
|
if (ns <= NSEC_PER_USEC) {
|
2019-02-23 16:49:48 +08:00
|
|
|
ndelay(ns);
|
|
|
|
} else {
|
2021-05-10 21:11:20 +08:00
|
|
|
u32 us = DIV_ROUND_UP(ns, NSEC_PER_USEC);
|
2019-02-23 16:49:48 +08:00
|
|
|
|
|
|
|
if (us <= 10)
|
|
|
|
udelay(us);
|
|
|
|
else
|
|
|
|
usleep_range(us, us + DIV_ROUND_UP(us, 10));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-26 18:51:44 +08:00
|
|
|
int spi_delay_to_ns(struct spi_delay *_delay, struct spi_transfer *xfer)
|
2019-02-23 16:49:48 +08:00
|
|
|
{
|
2019-09-26 18:51:30 +08:00
|
|
|
u32 delay = _delay->value;
|
|
|
|
u32 unit = _delay->unit;
|
2019-02-23 16:49:50 +08:00
|
|
|
u32 hz;
|
2019-02-23 16:49:48 +08:00
|
|
|
|
2019-09-26 18:51:30 +08:00
|
|
|
if (!delay)
|
|
|
|
return 0;
|
2019-02-23 16:49:48 +08:00
|
|
|
|
|
|
|
switch (unit) {
|
|
|
|
case SPI_DELAY_UNIT_USECS:
|
2021-05-10 21:11:20 +08:00
|
|
|
delay *= NSEC_PER_USEC;
|
2019-02-23 16:49:48 +08:00
|
|
|
break;
|
2021-05-10 21:11:20 +08:00
|
|
|
case SPI_DELAY_UNIT_NSECS:
|
|
|
|
/* Nothing to do here */
|
2019-02-23 16:49:48 +08:00
|
|
|
break;
|
2019-02-23 16:49:50 +08:00
|
|
|
case SPI_DELAY_UNIT_SCK:
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Clock cycles need to be obtained from spi_transfer */
|
2019-09-26 18:51:30 +08:00
|
|
|
if (!xfer)
|
|
|
|
return -EINVAL;
|
2021-05-10 21:11:20 +08:00
|
|
|
/*
|
|
|
|
* If there is unknown effective speed, approximate it
|
|
|
|
* by underestimating with half of the requested hz.
|
2019-02-23 16:49:50 +08:00
|
|
|
*/
|
|
|
|
hz = xfer->effective_speed_hz ?: xfer->speed_hz / 2;
|
2019-09-26 18:51:30 +08:00
|
|
|
if (!hz)
|
|
|
|
return -EINVAL;
|
2021-05-10 21:11:20 +08:00
|
|
|
|
|
|
|
/* Convert delay to nanoseconds */
|
|
|
|
delay *= DIV_ROUND_UP(NSEC_PER_SEC, hz);
|
2019-02-23 16:49:50 +08:00
|
|
|
break;
|
2019-02-23 16:49:48 +08:00
|
|
|
default:
|
2019-09-26 18:51:30 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return delay;
|
|
|
|
}
|
2019-09-26 18:51:44 +08:00
|
|
|
EXPORT_SYMBOL_GPL(spi_delay_to_ns);
|
2019-09-26 18:51:30 +08:00
|
|
|
|
|
|
|
int spi_delay_exec(struct spi_delay *_delay, struct spi_transfer *xfer)
|
|
|
|
{
|
|
|
|
int delay;
|
|
|
|
|
2020-05-22 23:50:05 +08:00
|
|
|
might_sleep();
|
|
|
|
|
2019-09-26 18:51:30 +08:00
|
|
|
if (!_delay)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2019-09-26 18:51:44 +08:00
|
|
|
delay = spi_delay_to_ns(_delay, xfer);
|
2019-09-26 18:51:30 +08:00
|
|
|
if (delay < 0)
|
|
|
|
return delay;
|
|
|
|
|
|
|
|
_spi_transfer_delay_ns(delay);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_delay_exec);
|
|
|
|
|
2019-02-23 16:49:48 +08:00
|
|
|
static void _spi_transfer_cs_change_delay(struct spi_message *msg,
|
|
|
|
struct spi_transfer *xfer)
|
|
|
|
{
|
2021-05-10 21:11:20 +08:00
|
|
|
u32 default_delay_ns = 10 * NSEC_PER_USEC;
|
2019-09-26 18:51:31 +08:00
|
|
|
u32 delay = xfer->cs_change_delay.value;
|
|
|
|
u32 unit = xfer->cs_change_delay.unit;
|
|
|
|
int ret;
|
2019-02-23 16:49:48 +08:00
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Return early on "fast" mode - for everything but USECS */
|
2019-09-26 18:51:29 +08:00
|
|
|
if (!delay) {
|
|
|
|
if (unit == SPI_DELAY_UNIT_USECS)
|
2021-05-10 21:11:20 +08:00
|
|
|
_spi_transfer_delay_ns(default_delay_ns);
|
2019-02-23 16:49:48 +08:00
|
|
|
return;
|
2019-09-26 18:51:29 +08:00
|
|
|
}
|
2019-02-23 16:49:48 +08:00
|
|
|
|
2019-09-26 18:51:31 +08:00
|
|
|
ret = spi_delay_exec(&xfer->cs_change_delay, xfer);
|
|
|
|
if (ret) {
|
2019-02-23 16:49:48 +08:00
|
|
|
dev_err_once(&msg->spi->dev,
|
2021-05-10 21:11:20 +08:00
|
|
|
"Use of unsupported delay unit %i, using default of %luus\n",
|
|
|
|
unit, default_delay_ns / NSEC_PER_USEC);
|
|
|
|
_spi_transfer_delay_ns(default_delay_ns);
|
2019-02-23 16:49:48 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-05 18:50:40 +08:00
|
|
|
/*
|
|
|
|
* spi_transfer_one_message - Default implementation of transfer_one_message()
|
|
|
|
*
|
|
|
|
* This is a standard implementation of transfer_one_message() for
|
2016-05-04 02:59:30 +08:00
|
|
|
* drivers which implement a transfer_one() operation. It provides
|
2013-10-05 18:50:40 +08:00
|
|
|
* standard handling of delays and chip select management.
|
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
static int spi_transfer_one_message(struct spi_controller *ctlr,
|
2013-10-05 18:50:40 +08:00
|
|
|
struct spi_message *msg)
|
|
|
|
{
|
|
|
|
struct spi_transfer *xfer;
|
|
|
|
bool keep_cs = false;
|
|
|
|
int ret = 0;
|
2022-08-05 16:44:58 +08:00
|
|
|
struct spi_statistics __percpu *statm = ctlr->pcpu_statistics;
|
|
|
|
struct spi_statistics __percpu *stats = msg->spi->pcpu_statistics;
|
2013-10-05 18:50:40 +08:00
|
|
|
|
2021-04-17 03:59:56 +08:00
|
|
|
spi_set_cs(msg->spi, true, false);
|
2013-10-05 18:50:40 +08:00
|
|
|
|
2015-06-22 21:00:36 +08:00
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(statm, messages);
|
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(stats, messages);
|
|
|
|
|
2013-10-05 18:50:40 +08:00
|
|
|
list_for_each_entry(xfer, &msg->transfers, transfer_list) {
|
|
|
|
trace_spi_transfer_start(msg, xfer);
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_statistics_add_transfer_stats(statm, xfer, ctlr);
|
|
|
|
spi_statistics_add_transfer_stats(stats, xfer, ctlr);
|
2015-06-22 21:00:36 +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
|
|
|
if (!ctlr->ptp_sts_supported) {
|
|
|
|
xfer->ptp_sts_word_pre = 0;
|
|
|
|
ptp_read_system_prets(xfer->ptp_sts);
|
|
|
|
}
|
|
|
|
|
2021-02-12 02:08:20 +08:00
|
|
|
if ((xfer->tx_buf || xfer->rx_buf) && xfer->len) {
|
2017-06-13 19:23:52 +08:00
|
|
|
reinit_completion(&ctlr->xfer_completion);
|
2013-10-05 18:50:40 +08:00
|
|
|
|
2020-06-17 06:42:08 +08:00
|
|
|
fallback_pio:
|
2017-06-13 19:23:52 +08:00
|
|
|
ret = ctlr->transfer_one(ctlr, msg->spi, xfer);
|
2014-08-16 23:27:41 +08:00
|
|
|
if (ret < 0) {
|
2020-06-17 06:42:08 +08:00
|
|
|
if (ctlr->cur_msg_mapped &&
|
|
|
|
(xfer->error & SPI_TRANS_FAIL_NO_START)) {
|
|
|
|
__spi_unmap_msg(ctlr, msg);
|
|
|
|
ctlr->fallback = true;
|
|
|
|
xfer->error &= ~SPI_TRANS_FAIL_NO_START;
|
|
|
|
goto fallback_pio;
|
|
|
|
}
|
|
|
|
|
2015-06-22 21:00:36 +08:00
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(statm,
|
|
|
|
errors);
|
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(stats,
|
|
|
|
errors);
|
2014-08-16 23:27:41 +08:00
|
|
|
dev_err(&msg->spi->dev,
|
|
|
|
"SPI transfer failed: %d\n", ret);
|
|
|
|
goto out;
|
|
|
|
}
|
2013-10-05 18:50:40 +08:00
|
|
|
|
2018-11-16 08:08:32 +08:00
|
|
|
if (ret > 0) {
|
|
|
|
ret = spi_transfer_wait(ctlr, msg, xfer);
|
|
|
|
if (ret < 0)
|
|
|
|
msg->status = ret;
|
|
|
|
}
|
2014-08-16 23:27:41 +08:00
|
|
|
} else {
|
|
|
|
if (xfer->len)
|
|
|
|
dev_err(&msg->spi->dev,
|
|
|
|
"Bufferless transfer has length %u\n",
|
|
|
|
xfer->len);
|
2014-01-18 22:05:22 +08:00
|
|
|
}
|
2013-10-05 18:50:40 +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
|
|
|
if (!ctlr->ptp_sts_supported) {
|
|
|
|
ptp_read_system_postts(xfer->ptp_sts);
|
|
|
|
xfer->ptp_sts_word_post = xfer->len;
|
|
|
|
}
|
|
|
|
|
2013-10-05 18:50:40 +08:00
|
|
|
trace_spi_transfer_stop(msg, xfer);
|
|
|
|
|
|
|
|
if (msg->status != -EINPROGRESS)
|
|
|
|
goto out;
|
|
|
|
|
2019-09-26 18:51:36 +08:00
|
|
|
spi_transfer_delay_exec(xfer);
|
2013-10-05 18:50:40 +08:00
|
|
|
|
|
|
|
if (xfer->cs_change) {
|
|
|
|
if (list_is_last(&xfer->transfer_list,
|
|
|
|
&msg->transfers)) {
|
|
|
|
keep_cs = true;
|
|
|
|
} else {
|
2021-04-17 03:59:56 +08:00
|
|
|
spi_set_cs(msg->spi, false, false);
|
2019-02-23 16:49:48 +08:00
|
|
|
_spi_transfer_cs_change_delay(msg, xfer);
|
2021-04-17 03:59:56 +08:00
|
|
|
spi_set_cs(msg->spi, true, false);
|
2013-10-05 18:50:40 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
msg->actual_length += xfer->len;
|
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
if (ret != 0 || !keep_cs)
|
2021-04-17 03:59:56 +08:00
|
|
|
spi_set_cs(msg->spi, false, false);
|
2013-10-05 18:50:40 +08:00
|
|
|
|
|
|
|
if (msg->status == -EINPROGRESS)
|
|
|
|
msg->status = ret;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (msg->status && ctlr->handle_err)
|
|
|
|
ctlr->handle_err(ctlr, msg);
|
2015-02-27 23:34:15 +08:00
|
|
|
|
2019-05-09 10:27:17 +08:00
|
|
|
spi_finalize_current_message(ctlr);
|
|
|
|
|
2013-10-05 18:50:40 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* spi_finalize_current_transfer - report completion of a transfer
|
2017-06-13 19:23:52 +08:00
|
|
|
* @ctlr: the controller reporting completion
|
2013-10-05 18:50:40 +08:00
|
|
|
*
|
|
|
|
* Called by SPI drivers using the core transfer_one_message()
|
|
|
|
* implementation to notify it that the current interrupt driven
|
2014-01-21 23:10:05 +08:00
|
|
|
* transfer has finished and the next one may be scheduled.
|
2013-10-05 18:50:40 +08:00
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
void spi_finalize_current_transfer(struct spi_controller *ctlr)
|
2013-10-05 18:50:40 +08:00
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
complete(&ctlr->xfer_completion);
|
2013-10-05 18:50:40 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_finalize_current_transfer);
|
|
|
|
|
2020-07-16 00:36:10 +08:00
|
|
|
static void spi_idle_runtime_pm(struct spi_controller *ctlr)
|
|
|
|
{
|
|
|
|
if (ctlr->auto_runtime_pm) {
|
|
|
|
pm_runtime_mark_last_busy(ctlr->dev.parent);
|
|
|
|
pm_runtime_put_autosuspend(ctlr->dev.parent);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-06-21 14:12:25 +08:00
|
|
|
static int __spi_pump_transfer_message(struct spi_controller *ctlr,
|
|
|
|
struct spi_message *msg, bool was_busy)
|
|
|
|
{
|
|
|
|
struct spi_transfer *xfer;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!was_busy && ctlr->auto_runtime_pm) {
|
|
|
|
ret = pm_runtime_get_sync(ctlr->dev.parent);
|
|
|
|
if (ret < 0) {
|
|
|
|
pm_runtime_put_noidle(ctlr->dev.parent);
|
|
|
|
dev_err(&ctlr->dev, "Failed to power device: %d\n",
|
|
|
|
ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!was_busy)
|
|
|
|
trace_spi_controller_busy(ctlr);
|
|
|
|
|
|
|
|
if (!was_busy && ctlr->prepare_transfer_hardware) {
|
|
|
|
ret = ctlr->prepare_transfer_hardware(ctlr);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(&ctlr->dev,
|
|
|
|
"failed to prepare transfer hardware: %d\n",
|
|
|
|
ret);
|
|
|
|
|
|
|
|
if (ctlr->auto_runtime_pm)
|
|
|
|
pm_runtime_put(ctlr->dev.parent);
|
|
|
|
|
|
|
|
msg->status = ret;
|
|
|
|
spi_finalize_current_message(ctlr);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
trace_spi_message_start(msg);
|
|
|
|
|
|
|
|
if (ctlr->prepare_message) {
|
|
|
|
ret = ctlr->prepare_message(ctlr, msg);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(&ctlr->dev, "failed to prepare message: %d\n",
|
|
|
|
ret);
|
|
|
|
msg->status = ret;
|
|
|
|
spi_finalize_current_message(ctlr);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
msg->prepared = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = spi_map_msg(ctlr, msg);
|
|
|
|
if (ret) {
|
|
|
|
msg->status = ret;
|
|
|
|
spi_finalize_current_message(ctlr);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ctlr->ptp_sts_supported && !ctlr->transfer_one) {
|
|
|
|
list_for_each_entry(xfer, &msg->transfers, transfer_list) {
|
|
|
|
xfer->ptp_sts_word_pre = 0;
|
|
|
|
ptp_read_system_prets(xfer->ptp_sts);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-06-21 14:12:34 +08:00
|
|
|
/*
|
|
|
|
* Drivers implementation of transfer_one_message() must arrange for
|
|
|
|
* spi_finalize_current_message() to get called. Most drivers will do
|
|
|
|
* this in the calling context, but some don't. For those cases, a
|
|
|
|
* completion is used to guarantee that this function does not return
|
|
|
|
* until spi_finalize_current_message() is done accessing
|
|
|
|
* ctlr->cur_msg.
|
|
|
|
* Use of the following two flags enable to opportunistically skip the
|
|
|
|
* use of the completion since its use involves expensive spin locks.
|
|
|
|
* In case of a race with the context that calls
|
|
|
|
* spi_finalize_current_message() the completion will always be used,
|
|
|
|
* due to strict ordering of these flags using barriers.
|
|
|
|
*/
|
|
|
|
WRITE_ONCE(ctlr->cur_msg_incomplete, true);
|
|
|
|
WRITE_ONCE(ctlr->cur_msg_need_completion, false);
|
2022-06-21 14:12:33 +08:00
|
|
|
reinit_completion(&ctlr->cur_msg_completion);
|
2022-06-29 22:25:18 +08:00
|
|
|
smp_wmb(); /* Make these available to spi_finalize_current_message() */
|
2022-06-21 14:12:34 +08:00
|
|
|
|
2022-06-21 14:12:25 +08:00
|
|
|
ret = ctlr->transfer_one_message(ctlr, msg);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(&ctlr->dev,
|
|
|
|
"failed to transfer one message from queue\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-06-29 22:25:19 +08:00
|
|
|
WRITE_ONCE(ctlr->cur_msg_need_completion, true);
|
|
|
|
smp_mb(); /* See spi_finalize_current_message()... */
|
|
|
|
if (READ_ONCE(ctlr->cur_msg_incomplete))
|
|
|
|
wait_for_completion(&ctlr->cur_msg_completion);
|
|
|
|
|
2022-06-21 14:12:25 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-02-22 17:05:38 +08:00
|
|
|
/**
|
2014-12-10 21:46:33 +08:00
|
|
|
* __spi_pump_messages - function which processes spi message queue
|
2017-06-13 19:23:52 +08:00
|
|
|
* @ctlr: controller to process queue for
|
2014-12-10 21:46:33 +08:00
|
|
|
* @in_kthread: true if we are in the context of the message pump thread
|
2012-02-22 17:05:38 +08:00
|
|
|
*
|
|
|
|
* This function checks if there is any spi message in the queue that
|
|
|
|
* needs processing and if so call out to the driver to initialize hardware
|
|
|
|
* and transfer each message.
|
|
|
|
*
|
2014-12-10 05:38:05 +08:00
|
|
|
* Note that it is called both from the kthread itself and also from
|
|
|
|
* inside spi_sync(); the queue extraction handling at the top of the
|
|
|
|
* function should deal with this safely.
|
2012-02-22 17:05:38 +08:00
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
static void __spi_pump_messages(struct spi_controller *ctlr, bool in_kthread)
|
2012-02-22 17:05:38 +08:00
|
|
|
{
|
2019-09-05 09:01:11 +08:00
|
|
|
struct spi_message *msg;
|
2012-02-22 17:05:38 +08:00
|
|
|
bool was_busy = false;
|
2019-09-05 09:01:11 +08:00
|
|
|
unsigned long flags;
|
2012-02-22 17:05:38 +08:00
|
|
|
int ret;
|
|
|
|
|
2022-06-21 14:12:26 +08:00
|
|
|
/* Take the IO mutex */
|
|
|
|
mutex_lock(&ctlr->io_mutex);
|
|
|
|
|
2014-12-10 03:46:56 +08:00
|
|
|
/* Lock queue */
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_lock_irqsave(&ctlr->queue_lock, flags);
|
2014-12-10 03:46:56 +08:00
|
|
|
|
|
|
|
/* Make sure we are not already running a message */
|
2022-06-21 14:12:27 +08:00
|
|
|
if (ctlr->cur_msg)
|
2022-06-21 14:12:26 +08:00
|
|
|
goto out_unlock;
|
2014-12-10 03:46:56 +08:00
|
|
|
|
|
|
|
/* Check if the queue is idle */
|
2017-06-13 19:23:52 +08:00
|
|
|
if (list_empty(&ctlr->queue) || !ctlr->running) {
|
2022-06-21 14:12:27 +08:00
|
|
|
if (!ctlr->busy)
|
2022-06-21 14:12:26 +08:00
|
|
|
goto out_unlock;
|
2014-12-10 21:46:33 +08:00
|
|
|
|
2020-07-16 00:36:10 +08:00
|
|
|
/* Defer any non-atomic teardown to the thread */
|
2019-01-24 01:29:53 +08:00
|
|
|
if (!in_kthread) {
|
2020-07-16 00:36:10 +08:00
|
|
|
if (!ctlr->dummy_rx && !ctlr->dummy_tx &&
|
|
|
|
!ctlr->unprepare_transfer_hardware) {
|
|
|
|
spi_idle_runtime_pm(ctlr);
|
|
|
|
ctlr->busy = false;
|
2022-06-21 14:12:25 +08:00
|
|
|
ctlr->queue_empty = true;
|
2020-07-16 00:36:10 +08:00
|
|
|
trace_spi_controller_idle(ctlr);
|
|
|
|
} else {
|
|
|
|
kthread_queue_work(ctlr->kworker,
|
|
|
|
&ctlr->pump_messages);
|
|
|
|
}
|
2022-06-21 14:12:26 +08:00
|
|
|
goto out_unlock;
|
2019-01-24 01:29:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ctlr->busy = false;
|
|
|
|
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
|
|
|
|
|
|
|
|
kfree(ctlr->dummy_rx);
|
|
|
|
ctlr->dummy_rx = NULL;
|
|
|
|
kfree(ctlr->dummy_tx);
|
|
|
|
ctlr->dummy_tx = NULL;
|
|
|
|
if (ctlr->unprepare_transfer_hardware &&
|
|
|
|
ctlr->unprepare_transfer_hardware(ctlr))
|
|
|
|
dev_err(&ctlr->dev,
|
|
|
|
"failed to unprepare transfer hardware\n");
|
2020-07-16 00:36:10 +08:00
|
|
|
spi_idle_runtime_pm(ctlr);
|
2019-01-24 01:29:53 +08:00
|
|
|
trace_spi_controller_idle(ctlr);
|
|
|
|
|
|
|
|
spin_lock_irqsave(&ctlr->queue_lock, flags);
|
2022-06-21 14:12:25 +08:00
|
|
|
ctlr->queue_empty = true;
|
2022-06-21 14:12:26 +08:00
|
|
|
goto out_unlock;
|
2012-02-22 17:05:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Extract head of queue */
|
2019-09-05 09:01:11 +08:00
|
|
|
msg = list_first_entry(&ctlr->queue, struct spi_message, queue);
|
|
|
|
ctlr->cur_msg = msg;
|
2012-02-22 17:05:38 +08:00
|
|
|
|
2019-09-05 09:01:11 +08:00
|
|
|
list_del_init(&msg->queue);
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->busy)
|
2012-02-22 17:05:38 +08:00
|
|
|
was_busy = true;
|
|
|
|
else
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr->busy = true;
|
|
|
|
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
2022-06-21 14:12:25 +08:00
|
|
|
ret = __spi_pump_transfer_message(ctlr, msg, was_busy);
|
2022-06-21 14:12:33 +08:00
|
|
|
if (!ret)
|
|
|
|
kthread_queue_work(ctlr->kworker, &ctlr->pump_messages);
|
2022-06-29 22:25:17 +08:00
|
|
|
|
2022-06-21 14:12:33 +08:00
|
|
|
ctlr->cur_msg = NULL;
|
|
|
|
ctlr->fallback = false;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
mutex_unlock(&ctlr->io_mutex);
|
2016-02-16 02:28:02 +08:00
|
|
|
|
|
|
|
/* Prod the scheduler in case transfer_one() was busy waiting */
|
2016-03-08 20:28:20 +08:00
|
|
|
if (!ret)
|
|
|
|
cond_resched();
|
2022-06-21 14:12:26 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
out_unlock:
|
2022-06-21 14:12:27 +08:00
|
|
|
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
|
2022-06-21 14:12:26 +08:00
|
|
|
mutex_unlock(&ctlr->io_mutex);
|
2012-02-22 17:05:38 +08:00
|
|
|
}
|
|
|
|
|
2014-12-10 21:46:33 +08:00
|
|
|
/**
|
|
|
|
* spi_pump_messages - kthread work function which processes spi message queue
|
2017-06-13 19:23:52 +08:00
|
|
|
* @work: pointer to kthread work struct contained in the controller struct
|
2014-12-10 21:46:33 +08:00
|
|
|
*/
|
|
|
|
static void spi_pump_messages(struct kthread_work *work)
|
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr =
|
|
|
|
container_of(work, struct spi_controller, pump_messages);
|
2014-12-10 21:46:33 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
__spi_pump_messages(ctlr, true);
|
2014-12-10 21:46:33 +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
|
|
|
/**
|
2021-11-23 01:17:21 +08:00
|
|
|
* spi_take_timestamp_pre - helper to collect the beginning of the TX timestamp
|
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
|
|
|
* @ctlr: Pointer to the spi_controller structure of the driver
|
|
|
|
* @xfer: Pointer to the transfer being timestamped
|
2019-12-27 09:24:17 +08:00
|
|
|
* @progress: How many words (not bytes) have been transferred so far
|
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
|
|
|
* @irqs_off: If true, will disable IRQs and preemption for the duration of the
|
|
|
|
* transfer, for less jitter in time measurement. Only compatible
|
|
|
|
* with PIO drivers. If true, must follow up with
|
|
|
|
* spi_take_timestamp_post or otherwise system will crash.
|
|
|
|
* WARNING: for fully predictable results, the CPU frequency must
|
|
|
|
* also be under control (governor).
|
2021-11-23 01:17:21 +08:00
|
|
|
*
|
|
|
|
* This is a helper for drivers to collect the beginning of the TX timestamp
|
|
|
|
* for the requested byte from the SPI transfer. The frequency with which this
|
|
|
|
* function must be called (once per word, once for the whole transfer, once
|
|
|
|
* per batch of words etc) is arbitrary as long as the @tx buffer offset is
|
|
|
|
* greater than or equal to the requested byte at the time of the call. The
|
|
|
|
* timestamp is only taken once, at the first such call. It is assumed that
|
|
|
|
* the driver advances its @tx buffer pointer monotonically.
|
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_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
|
|
|
{
|
|
|
|
if (!xfer->ptp_sts)
|
|
|
|
return;
|
|
|
|
|
2020-03-05 06:00:39 +08:00
|
|
|
if (xfer->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
|
|
|
return;
|
|
|
|
|
2020-03-05 06:00:39 +08:00
|
|
|
if (progress > xfer->ptp_sts_word_pre)
|
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
|
|
|
return;
|
|
|
|
|
|
|
|
/* Capture the resolution of the timestamp */
|
2019-12-27 09:24:17 +08:00
|
|
|
xfer->ptp_sts_word_pre = progress;
|
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
|
|
|
|
|
|
|
if (irqs_off) {
|
|
|
|
local_irq_save(ctlr->irq_flags);
|
|
|
|
preempt_disable();
|
|
|
|
}
|
|
|
|
|
|
|
|
ptp_read_system_prets(xfer->ptp_sts);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_take_timestamp_pre);
|
|
|
|
|
|
|
|
/**
|
2021-11-23 01:17:21 +08:00
|
|
|
* spi_take_timestamp_post - helper to collect the end of the TX timestamp
|
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
|
|
|
* @ctlr: Pointer to the spi_controller structure of the driver
|
|
|
|
* @xfer: Pointer to the transfer being timestamped
|
2019-12-27 09:24:17 +08:00
|
|
|
* @progress: How many words (not bytes) have been transferred so far
|
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
|
|
|
* @irqs_off: If true, will re-enable IRQs and preemption for the local CPU.
|
2021-11-23 01:17:21 +08:00
|
|
|
*
|
|
|
|
* This is a helper for drivers to collect the end of the TX timestamp for
|
|
|
|
* the requested byte from the SPI transfer. Can be called with an arbitrary
|
|
|
|
* frequency: only the first call where @tx exceeds or is equal to the
|
|
|
|
* requested word will be 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
|
|
|
*/
|
|
|
|
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
|
|
|
{
|
|
|
|
if (!xfer->ptp_sts)
|
|
|
|
return;
|
|
|
|
|
2020-03-05 06:00:39 +08:00
|
|
|
if (xfer->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
|
|
|
return;
|
|
|
|
|
2019-12-27 09:24:17 +08:00
|
|
|
if (progress < xfer->ptp_sts_word_post)
|
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
|
|
|
return;
|
|
|
|
|
|
|
|
ptp_read_system_postts(xfer->ptp_sts);
|
|
|
|
|
|
|
|
if (irqs_off) {
|
|
|
|
local_irq_restore(ctlr->irq_flags);
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Capture the resolution of the timestamp */
|
2019-12-27 09:24:17 +08:00
|
|
|
xfer->ptp_sts_word_post = progress;
|
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
|
|
|
|
2020-03-05 06:00:39 +08:00
|
|
|
xfer->timestamped = true;
|
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
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_take_timestamp_post);
|
|
|
|
|
2019-05-16 00:48:12 +08:00
|
|
|
/**
|
|
|
|
* spi_set_thread_rt - set the controller to pump at realtime priority
|
|
|
|
* @ctlr: controller to boost priority of
|
|
|
|
*
|
|
|
|
* This can be called because the controller requested realtime priority
|
|
|
|
* (by setting the ->rt value before calling spi_register_controller()) or
|
|
|
|
* because a device on the bus said that its transfers needed realtime
|
|
|
|
* priority.
|
|
|
|
*
|
|
|
|
* NOTE: at the moment if any device on a bus says it needs realtime then
|
|
|
|
* the thread will be at realtime priority for all transfers on that
|
|
|
|
* controller. If this eventually becomes a problem we may see if we can
|
|
|
|
* find a way to boost the priority only temporarily during relevant
|
|
|
|
* transfers.
|
|
|
|
*/
|
|
|
|
static void spi_set_thread_rt(struct spi_controller *ctlr)
|
2012-02-22 17:05:38 +08:00
|
|
|
{
|
2019-05-16 00:48:12 +08:00
|
|
|
dev_info(&ctlr->dev,
|
|
|
|
"will run message pump with realtime priority\n");
|
This tree adds the sched_set_fifo*() encapsulation APIs to remove
static priority level knowledge from non-scheduler code.
The three APIs for non-scheduler code to set SCHED_FIFO are:
- sched_set_fifo()
- sched_set_fifo_low()
- sched_set_normal()
These are two FIFO priority levels: default (high), and a 'low' priority level,
plus sched_set_normal() to set the policy back to non-SCHED_FIFO.
Since the changes affect a lot of non-scheduler code, we kept this in a separate
tree.
When merging to the latest upstream tree there's a conflict in drivers/spi/spi.c,
which can be resolved via:
sched_set_fifo(ctlr->kworker_task);
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAl8pPQIRHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1j0Jw/+LlSyX6gD2ATy3cizGL7DFPZogD5MVKTb
IXbhXH/ACpuPQlBe1+haRLbJj6XfXqbOlAleVKt7eh+jZ1jYjC972RCSTO4566mJ
0v8Iy9kkEeb2TDbYx1H3bnk78lf85t0CB+sCzyKUYFuTrXU04eRj7MtN3vAQyRQU
xJg83x/sT5DGdDTP50sL7lpbwk3INWkD0aDCJEaO/a9yHElMsTZiZBKoXxN/s30o
FsfzW56jqtng771H2bo8ERN7+abwJg10crQU5mIaLhacNMETuz0NZ/f8fY/fydCL
Ju8HAdNKNXyphWkAOmixQuyYtWKe2/GfbHg8hld0jmpwxkOSTgZjY+pFcv7/w306
g2l1TPOt8e1n5jbfnY3eig+9Kr8y0qHkXPfLfgRqKwMMaOqTTYixEzj+NdxEIRX9
Kr7oFAv6VEFfXGSpb5L1qyjIGVgQ5/JE/p3OC3GHEsw5VKiy5yjhNLoSmSGzdS61
1YurVvypSEUAn3DqTXgeGX76f0HH365fIKqmbFrUWxliF+YyflMhtrj2JFtejGzH
Md3RgAzxusE9S6k3gw1ev4byh167bPBbY8jz0w3Gd7IBRKy9vo92h6ZRYIl6xeoC
BU2To1IhCAydIr6hNsIiCSDTgiLbsYQzPuVVovUxNh+l1ZvKV2X+csEHhs8oW4pr
4BRU7dKL2NE=
=/7JH
-----END PGP SIGNATURE-----
Merge tag 'sched-fifo-2020-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull sched/fifo updates from Ingo Molnar:
"This adds the sched_set_fifo*() encapsulation APIs to remove static
priority level knowledge from non-scheduler code.
The three APIs for non-scheduler code to set SCHED_FIFO are:
- sched_set_fifo()
- sched_set_fifo_low()
- sched_set_normal()
These are two FIFO priority levels: default (high), and a 'low'
priority level, plus sched_set_normal() to set the policy back to
non-SCHED_FIFO.
Since the changes affect a lot of non-scheduler code, we kept this in
a separate tree"
* tag 'sched-fifo-2020-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (24 commits)
sched,tracing: Convert to sched_set_fifo()
sched: Remove sched_set_*() return value
sched: Remove sched_setscheduler*() EXPORTs
sched,psi: Convert to sched_set_fifo_low()
sched,rcutorture: Convert to sched_set_fifo_low()
sched,rcuperf: Convert to sched_set_fifo_low()
sched,locktorture: Convert to sched_set_fifo()
sched,irq: Convert to sched_set_fifo()
sched,watchdog: Convert to sched_set_fifo()
sched,serial: Convert to sched_set_fifo()
sched,powerclamp: Convert to sched_set_fifo()
sched,ion: Convert to sched_set_normal()
sched,powercap: Convert to sched_set_fifo*()
sched,spi: Convert to sched_set_fifo*()
sched,mmc: Convert to sched_set_fifo*()
sched,ivtv: Convert to sched_set_fifo*()
sched,drm/scheduler: Convert to sched_set_fifo*()
sched,msm: Convert to sched_set_fifo*()
sched,psci: Convert to sched_set_fifo*()
sched,drbd: Convert to sched_set_fifo*()
...
2020-08-07 02:55:43 +08:00
|
|
|
sched_set_fifo(ctlr->kworker->task);
|
2019-05-16 00:48:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int spi_init_queue(struct spi_controller *ctlr)
|
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr->running = false;
|
|
|
|
ctlr->busy = false;
|
2022-06-21 14:12:25 +08:00
|
|
|
ctlr->queue_empty = true;
|
2012-02-22 17:05:38 +08:00
|
|
|
|
2020-07-09 14:50:07 +08:00
|
|
|
ctlr->kworker = kthread_create_worker(0, dev_name(&ctlr->dev));
|
|
|
|
if (IS_ERR(ctlr->kworker)) {
|
|
|
|
dev_err(&ctlr->dev, "failed to create message pump kworker\n");
|
|
|
|
return PTR_ERR(ctlr->kworker);
|
2012-02-22 17:05:38 +08:00
|
|
|
}
|
2020-07-09 14:50:07 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
kthread_init_work(&ctlr->pump_messages, spi_pump_messages);
|
2019-01-24 01:29:53 +08:00
|
|
|
|
2012-02-22 17:05:38 +08:00
|
|
|
/*
|
2017-06-13 19:23:52 +08:00
|
|
|
* Controller config will indicate if this controller should run the
|
2012-02-22 17:05:38 +08:00
|
|
|
* message pump with high (realtime) priority to reduce the transfer
|
|
|
|
* latency on the bus by minimising the delay between a transfer
|
|
|
|
* request and the scheduling of the message pump thread. Without this
|
|
|
|
* setting the message pump thread will remain at default priority.
|
|
|
|
*/
|
2019-05-16 00:48:12 +08:00
|
|
|
if (ctlr->rt)
|
|
|
|
spi_set_thread_rt(ctlr);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* spi_get_next_queued_message() - called by driver to check for queued
|
|
|
|
* messages
|
2017-06-13 19:23:52 +08:00
|
|
|
* @ctlr: the controller to check for queued messages
|
2012-02-22 17:05:38 +08:00
|
|
|
*
|
|
|
|
* If there are more messages in the queue, the next message is returned from
|
|
|
|
* this call.
|
2015-10-23 00:59:23 +08:00
|
|
|
*
|
|
|
|
* Return: the next message in the queue, else NULL if the queue is empty.
|
2012-02-22 17:05:38 +08:00
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_message *spi_get_next_queued_message(struct spi_controller *ctlr)
|
2012-02-22 17:05:38 +08:00
|
|
|
{
|
|
|
|
struct spi_message *next;
|
|
|
|
unsigned long flags;
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Get a pointer to the next message, if any */
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_lock_irqsave(&ctlr->queue_lock, flags);
|
|
|
|
next = list_first_entry_or_null(&ctlr->queue, struct spi_message,
|
2014-01-02 15:16:40 +08:00
|
|
|
queue);
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
|
|
|
return next;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_get_next_queued_message);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* spi_finalize_current_message() - the current message is complete
|
2017-06-13 19:23:52 +08:00
|
|
|
* @ctlr: the controller to return the message to
|
2012-02-22 17:05:38 +08:00
|
|
|
*
|
|
|
|
* Called by the driver to notify the core that the message in the front of the
|
|
|
|
* queue is complete and can be removed from the queue.
|
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
void spi_finalize_current_message(struct spi_controller *ctlr)
|
2012-02-22 17:05:38 +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
|
|
|
struct spi_transfer *xfer;
|
2012-02-22 17:05:38 +08:00
|
|
|
struct spi_message *mesg;
|
2013-10-05 07:23:12 +08:00
|
|
|
int ret;
|
2012-02-22 17:05:38 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
mesg = ctlr->cur_msg;
|
2012-02-22 17:05:38 +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
|
|
|
if (!ctlr->ptp_sts_supported && !ctlr->transfer_one) {
|
|
|
|
list_for_each_entry(xfer, &mesg->transfers, transfer_list) {
|
|
|
|
ptp_read_system_postts(xfer->ptp_sts);
|
|
|
|
xfer->ptp_sts_word_post = xfer->len;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-05 06:00:39 +08:00
|
|
|
if (unlikely(ctlr->ptp_sts_supported))
|
|
|
|
list_for_each_entry(xfer, &mesg->transfers, transfer_list)
|
|
|
|
WARN_ON_ONCE(xfer->ptp_sts && !xfer->timestamped);
|
2019-12-27 09:24:44 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_unmap_msg(ctlr, mesg);
|
2014-01-16 20:22:43 +08:00
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* In the prepare_messages callback the SPI bus has the opportunity
|
|
|
|
* to split a transfer to smaller chunks.
|
|
|
|
*
|
|
|
|
* Release the split transfers here since spi_map_msg() is done on
|
|
|
|
* the split transfers.
|
2020-09-08 23:11:29 +08:00
|
|
|
*/
|
|
|
|
spi_res_release(ctlr, mesg);
|
|
|
|
|
2022-06-21 14:12:24 +08:00
|
|
|
if (mesg->prepared && ctlr->unprepare_message) {
|
2017-06-13 19:23:52 +08:00
|
|
|
ret = ctlr->unprepare_message(ctlr, mesg);
|
2013-10-05 07:23:12 +08:00
|
|
|
if (ret) {
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_err(&ctlr->dev, "failed to unprepare message: %d\n",
|
|
|
|
ret);
|
2013-10-05 07:23:12 +08:00
|
|
|
}
|
|
|
|
}
|
2015-03-18 18:27:28 +08:00
|
|
|
|
2022-06-21 14:12:24 +08:00
|
|
|
mesg->prepared = false;
|
|
|
|
|
2022-06-21 14:12:34 +08:00
|
|
|
WRITE_ONCE(ctlr->cur_msg_incomplete, false);
|
|
|
|
smp_mb(); /* See __spi_pump_transfer_message()... */
|
|
|
|
if (READ_ONCE(ctlr->cur_msg_need_completion))
|
|
|
|
complete(&ctlr->cur_msg_completion);
|
2015-05-10 15:50:45 +08:00
|
|
|
|
|
|
|
trace_spi_message_done(mesg);
|
2013-10-05 07:23:12 +08:00
|
|
|
|
2012-02-22 17:05:38 +08:00
|
|
|
mesg->state = NULL;
|
|
|
|
if (mesg->complete)
|
|
|
|
mesg->complete(mesg->context);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_finalize_current_message);
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static int spi_start_queue(struct spi_controller *ctlr)
|
2012-02-22 17:05:38 +08:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_lock_irqsave(&ctlr->queue_lock, flags);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->running || ctlr->busy) {
|
|
|
|
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
|
2012-02-22 17:05:38 +08:00
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr->running = true;
|
|
|
|
ctlr->cur_msg = NULL;
|
|
|
|
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
2020-07-09 14:50:07 +08:00
|
|
|
kthread_queue_work(ctlr->kworker, &ctlr->pump_messages);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static int spi_stop_queue(struct spi_controller *ctlr)
|
2012-02-22 17:05:38 +08:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
unsigned limit = 500;
|
|
|
|
int ret = 0;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_lock_irqsave(&ctlr->queue_lock, flags);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This is a bit lame, but is optimized for the common execution path.
|
2017-06-13 19:23:52 +08:00
|
|
|
* A wait_queue on the ctlr->busy could be used, but then the common
|
2012-02-22 17:05:38 +08:00
|
|
|
* execution path (pump_messages) would be required to call wake_up or
|
|
|
|
* friends on every SPI message. Do this instead.
|
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
while ((!list_empty(&ctlr->queue) || ctlr->busy) && limit--) {
|
|
|
|
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
|
2014-02-21 09:15:18 +08:00
|
|
|
usleep_range(10000, 11000);
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_lock_irqsave(&ctlr->queue_lock, flags);
|
2012-02-22 17:05:38 +08:00
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (!list_empty(&ctlr->queue) || ctlr->busy)
|
2012-02-22 17:05:38 +08:00
|
|
|
ret = -EBUSY;
|
|
|
|
else
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr->running = false;
|
2012-02-22 17:05:38 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
|
|
|
if (ret) {
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_warn(&ctlr->dev, "could not stop message queue\n");
|
2012-02-22 17:05:38 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static int spi_destroy_queue(struct spi_controller *ctlr)
|
2012-02-22 17:05:38 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
ret = spi_stop_queue(ctlr);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
|
|
|
/*
|
2016-10-12 04:55:20 +08:00
|
|
|
* kthread_flush_worker will block until all work is done.
|
2012-02-22 17:05:38 +08:00
|
|
|
* If the reason that stop_queue timed out is that the work will never
|
|
|
|
* finish, then it does no good to call flush/stop thread, so
|
|
|
|
* return anyway.
|
|
|
|
*/
|
|
|
|
if (ret) {
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_err(&ctlr->dev, "problem destroying queue\n");
|
2012-02-22 17:05:38 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-07-09 14:50:07 +08:00
|
|
|
kthread_destroy_worker(ctlr->kworker);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-12-10 05:38:05 +08:00
|
|
|
static int __spi_queued_transfer(struct spi_device *spi,
|
|
|
|
struct spi_message *msg,
|
|
|
|
bool need_pump)
|
2012-02-22 17:05:38 +08:00
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = spi->controller;
|
2012-02-22 17:05:38 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_lock_irqsave(&ctlr->queue_lock, flags);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (!ctlr->running) {
|
|
|
|
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
|
2012-02-22 17:05:38 +08:00
|
|
|
return -ESHUTDOWN;
|
|
|
|
}
|
|
|
|
msg->actual_length = 0;
|
|
|
|
msg->status = -EINPROGRESS;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
list_add_tail(&msg->queue, &ctlr->queue);
|
2022-06-21 14:12:25 +08:00
|
|
|
ctlr->queue_empty = false;
|
2019-01-24 01:29:53 +08:00
|
|
|
if (!ctlr->busy && need_pump)
|
2020-07-09 14:50:07 +08:00
|
|
|
kthread_queue_work(ctlr->kworker, &ctlr->pump_messages);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
|
2012-02-22 17:05:38 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-12-10 05:38:05 +08:00
|
|
|
/**
|
|
|
|
* spi_queued_transfer - transfer function for queued transfers
|
|
|
|
* @spi: spi device which is requesting transfer
|
|
|
|
* @msg: spi message which is to handled is queued to driver queue
|
2015-10-23 00:59:23 +08:00
|
|
|
*
|
|
|
|
* Return: zero on success, else a negative error code.
|
2014-12-10 05:38:05 +08:00
|
|
|
*/
|
|
|
|
static int spi_queued_transfer(struct spi_device *spi, struct spi_message *msg)
|
|
|
|
{
|
|
|
|
return __spi_queued_transfer(spi, msg, true);
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static int spi_controller_initialize_queue(struct spi_controller *ctlr)
|
2012-02-22 17:05:38 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr->transfer = spi_queued_transfer;
|
|
|
|
if (!ctlr->transfer_one_message)
|
|
|
|
ctlr->transfer_one_message = spi_transfer_one_message;
|
2012-02-22 17:05:38 +08:00
|
|
|
|
|
|
|
/* Initialize and start queue */
|
2017-06-13 19:23:52 +08:00
|
|
|
ret = spi_init_queue(ctlr);
|
2012-02-22 17:05:38 +08:00
|
|
|
if (ret) {
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_err(&ctlr->dev, "problem initializing queue\n");
|
2012-02-22 17:05:38 +08:00
|
|
|
goto err_init_queue;
|
|
|
|
}
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr->queued = true;
|
|
|
|
ret = spi_start_queue(ctlr);
|
2012-02-22 17:05:38 +08:00
|
|
|
if (ret) {
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_err(&ctlr->dev, "problem starting queue\n");
|
2012-02-22 17:05:38 +08:00
|
|
|
goto err_start_queue;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_start_queue:
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_destroy_queue(ctlr);
|
2014-05-02 01:47:52 +08:00
|
|
|
err_init_queue:
|
2012-02-22 17:05:38 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-04-23 02:35:15 +08:00
|
|
|
/**
|
|
|
|
* spi_flush_queue - Send all pending messages in the queue from the callers'
|
|
|
|
* context
|
|
|
|
* @ctlr: controller to process queue for
|
|
|
|
*
|
|
|
|
* This should be used when one wants to ensure all pending messages have been
|
|
|
|
* sent before doing something. Is used by the spi-mem code to make sure SPI
|
|
|
|
* memory operations do not preempt regular SPI transfers that have been queued
|
|
|
|
* before the spi-mem operation.
|
|
|
|
*/
|
|
|
|
void spi_flush_queue(struct spi_controller *ctlr)
|
|
|
|
{
|
|
|
|
if (ctlr->transfer == spi_queued_transfer)
|
|
|
|
__spi_pump_messages(ctlr, false);
|
|
|
|
}
|
|
|
|
|
2012-02-22 17:05:38 +08:00
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
2012-12-04 22:09:38 +08:00
|
|
|
#if defined(CONFIG_OF)
|
2017-06-13 19:23:52 +08:00
|
|
|
static int of_spi_parse_dt(struct spi_controller *ctlr, struct spi_device *spi,
|
2016-09-13 04:50:41 +08:00
|
|
|
struct device_node *nc)
|
2014-10-29 16:40:37 +08:00
|
|
|
{
|
|
|
|
u32 value;
|
2016-09-13 04:50:41 +08:00
|
|
|
int rc;
|
2014-10-29 16:40:37 +08:00
|
|
|
|
|
|
|
/* Mode (clock phase/polarity/etc.) */
|
2017-08-07 04:15:31 +08:00
|
|
|
if (of_property_read_bool(nc, "spi-cpha"))
|
2014-10-29 16:40:37 +08:00
|
|
|
spi->mode |= SPI_CPHA;
|
2017-08-07 04:15:31 +08:00
|
|
|
if (of_property_read_bool(nc, "spi-cpol"))
|
2014-10-29 16:40:37 +08:00
|
|
|
spi->mode |= SPI_CPOL;
|
2017-08-07 04:15:31 +08:00
|
|
|
if (of_property_read_bool(nc, "spi-3wire"))
|
2014-10-29 16:40:37 +08:00
|
|
|
spi->mode |= SPI_3WIRE;
|
2017-08-07 04:15:31 +08:00
|
|
|
if (of_property_read_bool(nc, "spi-lsb-first"))
|
2014-10-29 16:40:37 +08:00
|
|
|
spi->mode |= SPI_LSB_FIRST;
|
2019-10-18 23:29:29 +08:00
|
|
|
if (of_property_read_bool(nc, "spi-cs-high"))
|
2019-01-07 23:51:50 +08:00
|
|
|
spi->mode |= SPI_CS_HIGH;
|
|
|
|
|
2014-10-29 16:40:37 +08:00
|
|
|
/* Device DUAL/QUAD mode */
|
|
|
|
if (!of_property_read_u32(nc, "spi-tx-bus-width", &value)) {
|
|
|
|
switch (value) {
|
2020-12-21 23:29:35 +08:00
|
|
|
case 0:
|
|
|
|
spi->mode |= SPI_NO_TX;
|
|
|
|
break;
|
2014-10-29 16:40:37 +08:00
|
|
|
case 1:
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
spi->mode |= SPI_TX_DUAL;
|
|
|
|
break;
|
|
|
|
case 4:
|
|
|
|
spi->mode |= SPI_TX_QUAD;
|
|
|
|
break;
|
2018-12-03 16:39:06 +08:00
|
|
|
case 8:
|
|
|
|
spi->mode |= SPI_TX_OCTAL;
|
|
|
|
break;
|
2014-10-29 16:40:37 +08:00
|
|
|
default:
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_warn(&ctlr->dev,
|
2014-10-29 16:40:37 +08:00
|
|
|
"spi-tx-bus-width %d not supported\n",
|
|
|
|
value);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!of_property_read_u32(nc, "spi-rx-bus-width", &value)) {
|
|
|
|
switch (value) {
|
2020-12-21 23:29:35 +08:00
|
|
|
case 0:
|
|
|
|
spi->mode |= SPI_NO_RX;
|
|
|
|
break;
|
2014-10-29 16:40:37 +08:00
|
|
|
case 1:
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
spi->mode |= SPI_RX_DUAL;
|
|
|
|
break;
|
|
|
|
case 4:
|
|
|
|
spi->mode |= SPI_RX_QUAD;
|
|
|
|
break;
|
2018-12-03 16:39:06 +08:00
|
|
|
case 8:
|
|
|
|
spi->mode |= SPI_RX_OCTAL;
|
|
|
|
break;
|
2014-10-29 16:40:37 +08:00
|
|
|
default:
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_warn(&ctlr->dev,
|
2014-10-29 16:40:37 +08:00
|
|
|
"spi-rx-bus-width %d not supported\n",
|
|
|
|
value);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (spi_controller_is_slave(ctlr)) {
|
2018-12-06 03:50:41 +08:00
|
|
|
if (!of_node_name_eq(nc, "slave")) {
|
2017-07-19 05:43:31 +08:00
|
|
|
dev_err(&ctlr->dev, "%pOF is not called 'slave'\n",
|
|
|
|
nc);
|
2017-05-22 21:11:41 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Device address */
|
|
|
|
rc = of_property_read_u32(nc, "reg", &value);
|
|
|
|
if (rc) {
|
2017-07-19 05:43:31 +08:00
|
|
|
dev_err(&ctlr->dev, "%pOF has no valid 'reg' property (%d)\n",
|
|
|
|
nc, rc);
|
2017-05-22 21:11:41 +08:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
spi->chip_select = value;
|
|
|
|
|
2014-10-29 16:40:37 +08:00
|
|
|
/* Device speed */
|
2020-03-06 16:50:49 +08:00
|
|
|
if (!of_property_read_u32(nc, "spi-max-frequency", &value))
|
|
|
|
spi->max_speed_hz = value;
|
2014-10-29 16:40:37 +08:00
|
|
|
|
2016-09-13 04:50:41 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct spi_device *
|
2017-06-13 19:23:52 +08:00
|
|
|
of_register_spi_device(struct spi_controller *ctlr, struct device_node *nc)
|
2016-09-13 04:50:41 +08:00
|
|
|
{
|
|
|
|
struct spi_device *spi;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
/* Alloc an spi_device */
|
2017-06-13 19:23:52 +08:00
|
|
|
spi = spi_alloc_device(ctlr);
|
2016-09-13 04:50:41 +08:00
|
|
|
if (!spi) {
|
2017-07-19 05:43:31 +08:00
|
|
|
dev_err(&ctlr->dev, "spi_device alloc error for %pOF\n", nc);
|
2016-09-13 04:50:41 +08:00
|
|
|
rc = -ENOMEM;
|
|
|
|
goto err_out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Select device driver */
|
|
|
|
rc = of_modalias_node(nc, spi->modalias,
|
|
|
|
sizeof(spi->modalias));
|
|
|
|
if (rc < 0) {
|
2017-07-19 05:43:31 +08:00
|
|
|
dev_err(&ctlr->dev, "cannot find modalias for %pOF\n", nc);
|
2016-09-13 04:50:41 +08:00
|
|
|
goto err_out;
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
rc = of_spi_parse_dt(ctlr, spi, nc);
|
2016-09-13 04:50:41 +08:00
|
|
|
if (rc)
|
|
|
|
goto err_out;
|
|
|
|
|
2014-10-29 16:40:37 +08:00
|
|
|
/* Store a pointer to the node in the device structure */
|
|
|
|
of_node_get(nc);
|
|
|
|
spi->dev.of_node = nc;
|
2021-04-21 18:14:02 +08:00
|
|
|
spi->dev.fwnode = of_fwnode_handle(nc);
|
2014-10-29 16:40:37 +08:00
|
|
|
|
|
|
|
/* Register the new device */
|
|
|
|
rc = spi_add_device(spi);
|
|
|
|
if (rc) {
|
2017-07-19 05:43:31 +08:00
|
|
|
dev_err(&ctlr->dev, "spi_device register error %pOF\n", nc);
|
2017-01-31 00:47:05 +08:00
|
|
|
goto err_of_node_put;
|
2014-10-29 16:40:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return spi;
|
|
|
|
|
2017-01-31 00:47:05 +08:00
|
|
|
err_of_node_put:
|
|
|
|
of_node_put(nc);
|
2014-10-29 16:40:37 +08:00
|
|
|
err_out:
|
|
|
|
spi_dev_put(spi);
|
|
|
|
return ERR_PTR(rc);
|
|
|
|
}
|
|
|
|
|
2012-04-08 04:16:53 +08:00
|
|
|
/**
|
|
|
|
* of_register_spi_devices() - Register child devices onto the SPI bus
|
2017-06-13 19:23:52 +08:00
|
|
|
* @ctlr: Pointer to spi_controller device
|
2012-04-08 04:16:53 +08:00
|
|
|
*
|
2017-05-22 21:11:41 +08:00
|
|
|
* Registers an spi_device for each child node of controller node which
|
|
|
|
* represents a valid SPI slave.
|
2012-04-08 04:16:53 +08:00
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
static void of_register_spi_devices(struct spi_controller *ctlr)
|
2012-04-08 04:16:53 +08:00
|
|
|
{
|
|
|
|
struct spi_device *spi;
|
|
|
|
struct device_node *nc;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (!ctlr->dev.of_node)
|
2012-04-08 04:16:53 +08:00
|
|
|
return;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
for_each_available_child_of_node(ctlr->dev.of_node, nc) {
|
2015-11-30 22:28:07 +08:00
|
|
|
if (of_node_test_and_set_flag(nc, OF_POPULATED))
|
|
|
|
continue;
|
2017-06-13 19:23:52 +08:00
|
|
|
spi = of_register_spi_device(ctlr, nc);
|
2016-10-17 21:59:56 +08:00
|
|
|
if (IS_ERR(spi)) {
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_warn(&ctlr->dev,
|
2017-07-19 05:43:31 +08:00
|
|
|
"Failed to create SPI device for %pOF\n", nc);
|
2016-10-17 21:59:56 +08:00
|
|
|
of_node_clear_flag(nc, OF_POPULATED);
|
|
|
|
}
|
2012-04-08 04:16:53 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#else
|
2017-06-13 19:23:52 +08:00
|
|
|
static void of_register_spi_devices(struct spi_controller *ctlr) { }
|
2012-04-08 04:16:53 +08:00
|
|
|
#endif
|
|
|
|
|
2021-06-22 01:53:55 +08:00
|
|
|
/**
|
|
|
|
* spi_new_ancillary_device() - Register ancillary SPI device
|
|
|
|
* @spi: Pointer to the main SPI device registering the ancillary device
|
|
|
|
* @chip_select: Chip Select of the ancillary device
|
|
|
|
*
|
|
|
|
* Register an ancillary SPI device; for example some chips have a chip-select
|
|
|
|
* for normal device usage and another one for setup/firmware upload.
|
|
|
|
*
|
|
|
|
* This may only be called from main SPI device's probe routine.
|
|
|
|
*
|
|
|
|
* Return: 0 on success; negative errno on failure
|
|
|
|
*/
|
|
|
|
struct spi_device *spi_new_ancillary_device(struct spi_device *spi,
|
|
|
|
u8 chip_select)
|
|
|
|
{
|
|
|
|
struct spi_device *ancillary;
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
/* Alloc an spi_device */
|
|
|
|
ancillary = spi_alloc_device(spi->controller);
|
|
|
|
if (!ancillary) {
|
|
|
|
rc = -ENOMEM;
|
|
|
|
goto err_out;
|
|
|
|
}
|
|
|
|
|
|
|
|
strlcpy(ancillary->modalias, "dummy", sizeof(ancillary->modalias));
|
|
|
|
|
|
|
|
/* Use provided chip-select for ancillary device */
|
|
|
|
ancillary->chip_select = chip_select;
|
|
|
|
|
|
|
|
/* Take over SPI mode/speed from SPI main device */
|
|
|
|
ancillary->max_speed_hz = spi->max_speed_hz;
|
2021-06-24 01:23:00 +08:00
|
|
|
ancillary->mode = spi->mode;
|
2021-06-22 01:53:55 +08:00
|
|
|
|
|
|
|
/* Register the new device */
|
|
|
|
rc = spi_add_device_locked(ancillary);
|
|
|
|
if (rc) {
|
|
|
|
dev_err(&spi->dev, "failed to register ancillary device\n");
|
|
|
|
goto err_out;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ancillary;
|
|
|
|
|
|
|
|
err_out:
|
|
|
|
spi_dev_put(ancillary);
|
|
|
|
return ERR_PTR(rc);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_new_ancillary_device);
|
|
|
|
|
2012-11-30 19:37:53 +08:00
|
|
|
#ifdef CONFIG_ACPI
|
2019-05-30 19:16:34 +08:00
|
|
|
struct acpi_spi_lookup {
|
|
|
|
struct spi_controller *ctlr;
|
|
|
|
u32 max_speed_hz;
|
|
|
|
u32 mode;
|
|
|
|
int irq;
|
|
|
|
u8 bits_per_word;
|
|
|
|
u8 chip_select;
|
2022-01-22 01:24:25 +08:00
|
|
|
int n;
|
|
|
|
int index;
|
2019-05-30 19:16:34 +08:00
|
|
|
};
|
|
|
|
|
2022-01-22 01:24:26 +08:00
|
|
|
static int acpi_spi_count(struct acpi_resource *ares, void *data)
|
|
|
|
{
|
|
|
|
struct acpi_resource_spi_serialbus *sb;
|
|
|
|
int *count = data;
|
|
|
|
|
|
|
|
if (ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
sb = &ares->data.spi_serial_bus;
|
|
|
|
if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_SPI)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
*count = *count + 1;
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_spi_count_resources - Count the number of SpiSerialBus resources
|
|
|
|
* @adev: ACPI device
|
|
|
|
*
|
|
|
|
* Returns the number of SpiSerialBus resources in the ACPI-device's
|
|
|
|
* resource-list; or a negative error code.
|
|
|
|
*/
|
|
|
|
int acpi_spi_count_resources(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
LIST_HEAD(r);
|
|
|
|
int count = 0;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = acpi_dev_get_resources(adev, &r, acpi_spi_count, &count);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
acpi_dev_free_resource_list(&r);
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_spi_count_resources);
|
|
|
|
|
2019-05-30 19:16:34 +08:00
|
|
|
static void acpi_spi_parse_apple_properties(struct acpi_device *dev,
|
|
|
|
struct acpi_spi_lookup *lookup)
|
2017-08-01 20:10:41 +08:00
|
|
|
{
|
|
|
|
const union acpi_object *obj;
|
|
|
|
|
|
|
|
if (!x86_apple_machine)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!acpi_dev_get_property(dev, "spiSclkPeriod", ACPI_TYPE_BUFFER, &obj)
|
|
|
|
&& obj->buffer.length >= 4)
|
2019-05-30 19:16:34 +08:00
|
|
|
lookup->max_speed_hz = NSEC_PER_SEC / *(u32 *)obj->buffer.pointer;
|
2017-08-01 20:10:41 +08:00
|
|
|
|
|
|
|
if (!acpi_dev_get_property(dev, "spiWordSize", ACPI_TYPE_BUFFER, &obj)
|
|
|
|
&& obj->buffer.length == 8)
|
2019-05-30 19:16:34 +08:00
|
|
|
lookup->bits_per_word = *(u64 *)obj->buffer.pointer;
|
2017-08-01 20:10:41 +08:00
|
|
|
|
|
|
|
if (!acpi_dev_get_property(dev, "spiBitOrder", ACPI_TYPE_BUFFER, &obj)
|
|
|
|
&& obj->buffer.length == 8 && !*(u64 *)obj->buffer.pointer)
|
2019-05-30 19:16:34 +08:00
|
|
|
lookup->mode |= SPI_LSB_FIRST;
|
2017-08-01 20:10:41 +08:00
|
|
|
|
|
|
|
if (!acpi_dev_get_property(dev, "spiSPO", ACPI_TYPE_BUFFER, &obj)
|
|
|
|
&& obj->buffer.length == 8 && *(u64 *)obj->buffer.pointer)
|
2019-05-30 19:16:34 +08:00
|
|
|
lookup->mode |= SPI_CPOL;
|
2017-08-01 20:10:41 +08:00
|
|
|
|
|
|
|
if (!acpi_dev_get_property(dev, "spiSPH", ACPI_TYPE_BUFFER, &obj)
|
|
|
|
&& obj->buffer.length == 8 && *(u64 *)obj->buffer.pointer)
|
2019-05-30 19:16:34 +08:00
|
|
|
lookup->mode |= SPI_CPHA;
|
2017-08-01 20:10:41 +08:00
|
|
|
}
|
|
|
|
|
2022-01-22 01:24:25 +08:00
|
|
|
static struct spi_controller *acpi_spi_find_controller_by_adev(struct acpi_device *adev);
|
|
|
|
|
2012-11-30 19:37:53 +08:00
|
|
|
static int acpi_spi_add_resource(struct acpi_resource *ares, void *data)
|
|
|
|
{
|
2019-05-30 19:16:34 +08:00
|
|
|
struct acpi_spi_lookup *lookup = data;
|
|
|
|
struct spi_controller *ctlr = lookup->ctlr;
|
2012-11-30 19:37:53 +08:00
|
|
|
|
|
|
|
if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
|
|
|
|
struct acpi_resource_spi_serialbus *sb;
|
2019-05-30 19:16:34 +08:00
|
|
|
acpi_handle parent_handle;
|
|
|
|
acpi_status status;
|
2012-11-30 19:37:53 +08:00
|
|
|
|
|
|
|
sb = &ares->data.spi_serial_bus;
|
|
|
|
if (sb->type == ACPI_RESOURCE_SERIAL_TYPE_SPI) {
|
2019-05-30 19:16:34 +08:00
|
|
|
|
2022-01-22 01:24:25 +08:00
|
|
|
if (lookup->index != -1 && lookup->n++ != lookup->index)
|
|
|
|
return 1;
|
|
|
|
|
2019-05-30 19:16:34 +08:00
|
|
|
status = acpi_get_handle(NULL,
|
|
|
|
sb->resource_source.string_ptr,
|
|
|
|
&parent_handle);
|
|
|
|
|
2022-01-22 01:24:25 +08:00
|
|
|
if (ACPI_FAILURE(status))
|
2019-05-30 19:16:34 +08:00
|
|
|
return -ENODEV;
|
|
|
|
|
2022-01-22 01:24:25 +08:00
|
|
|
if (ctlr) {
|
|
|
|
if (ACPI_HANDLE(ctlr->dev.parent) != parent_handle)
|
|
|
|
return -ENODEV;
|
|
|
|
} else {
|
|
|
|
struct acpi_device *adev;
|
|
|
|
|
2022-04-06 01:49:26 +08:00
|
|
|
adev = acpi_fetch_acpi_dev(parent_handle);
|
|
|
|
if (!adev)
|
2022-01-22 01:24:25 +08:00
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
ctlr = acpi_spi_find_controller_by_adev(adev);
|
|
|
|
if (!ctlr)
|
2022-07-10 05:29:56 +08:00
|
|
|
return -EPROBE_DEFER;
|
2022-01-22 01:24:25 +08:00
|
|
|
|
|
|
|
lookup->ctlr = ctlr;
|
|
|
|
}
|
|
|
|
|
2016-02-08 23:14:28 +08:00
|
|
|
/*
|
|
|
|
* ACPI DeviceSelection numbering is handled by the
|
|
|
|
* host controller driver in Windows and can vary
|
|
|
|
* from driver to driver. In Linux we always expect
|
|
|
|
* 0 .. max - 1 so we need to ask the driver to
|
|
|
|
* translate between the two schemes.
|
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->fw_translate_cs) {
|
|
|
|
int cs = ctlr->fw_translate_cs(ctlr,
|
2016-02-08 23:14:28 +08:00
|
|
|
sb->device_selection);
|
|
|
|
if (cs < 0)
|
|
|
|
return cs;
|
2019-05-30 19:16:34 +08:00
|
|
|
lookup->chip_select = cs;
|
2016-02-08 23:14:28 +08:00
|
|
|
} else {
|
2019-05-30 19:16:34 +08:00
|
|
|
lookup->chip_select = sb->device_selection;
|
2016-02-08 23:14:28 +08:00
|
|
|
}
|
|
|
|
|
2019-05-30 19:16:34 +08:00
|
|
|
lookup->max_speed_hz = sb->connection_speed;
|
2020-04-14 02:04:06 +08:00
|
|
|
lookup->bits_per_word = sb->data_bit_length;
|
2012-11-30 19:37:53 +08:00
|
|
|
|
|
|
|
if (sb->clock_phase == ACPI_SPI_SECOND_PHASE)
|
2019-05-30 19:16:34 +08:00
|
|
|
lookup->mode |= SPI_CPHA;
|
2012-11-30 19:37:53 +08:00
|
|
|
if (sb->clock_polarity == ACPI_SPI_START_HIGH)
|
2019-05-30 19:16:34 +08:00
|
|
|
lookup->mode |= SPI_CPOL;
|
2012-11-30 19:37:53 +08:00
|
|
|
if (sb->device_polarity == ACPI_SPI_ACTIVE_HIGH)
|
2019-05-30 19:16:34 +08:00
|
|
|
lookup->mode |= SPI_CS_HIGH;
|
2012-11-30 19:37:53 +08:00
|
|
|
}
|
2019-05-30 19:16:34 +08:00
|
|
|
} else if (lookup->irq < 0) {
|
2012-11-30 19:37:53 +08:00
|
|
|
struct resource r;
|
|
|
|
|
|
|
|
if (acpi_dev_resource_interrupt(ares, 0, &r))
|
2019-05-30 19:16:34 +08:00
|
|
|
lookup->irq = r.start;
|
2012-11-30 19:37:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Always tell the ACPI core to skip this resource */
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2022-01-22 01:24:24 +08:00
|
|
|
/**
|
|
|
|
* acpi_spi_device_alloc - Allocate a spi device, and fill it in with ACPI information
|
|
|
|
* @ctlr: controller to which the spi device belongs
|
|
|
|
* @adev: ACPI Device for the spi device
|
2022-01-22 01:24:25 +08:00
|
|
|
* @index: Index of the spi resource inside the ACPI Node
|
2022-01-22 01:24:24 +08:00
|
|
|
*
|
|
|
|
* This should be used to allocate a new spi device from and ACPI Node.
|
|
|
|
* The caller is responsible for calling spi_add_device to register the spi device.
|
|
|
|
*
|
2022-01-22 01:24:25 +08:00
|
|
|
* If ctlr is set to NULL, the Controller for the spi device will be looked up
|
|
|
|
* using the resource.
|
|
|
|
* If index is set to -1, index is not used.
|
|
|
|
* Note: If index is -1, ctlr must be set.
|
|
|
|
*
|
2022-01-22 01:24:24 +08:00
|
|
|
* Return: a pointer to the new device, or ERR_PTR on error.
|
|
|
|
*/
|
|
|
|
struct spi_device *acpi_spi_device_alloc(struct spi_controller *ctlr,
|
2022-01-22 01:24:25 +08:00
|
|
|
struct acpi_device *adev,
|
|
|
|
int index)
|
2012-11-30 19:37:53 +08:00
|
|
|
{
|
2019-05-30 19:16:34 +08:00
|
|
|
acpi_handle parent_handle = NULL;
|
2012-11-30 19:37:53 +08:00
|
|
|
struct list_head resource_list;
|
2019-06-20 20:36:49 +08:00
|
|
|
struct acpi_spi_lookup lookup = {};
|
2012-11-30 19:37:53 +08:00
|
|
|
struct spi_device *spi;
|
|
|
|
int ret;
|
|
|
|
|
2022-01-22 01:24:25 +08:00
|
|
|
if (!ctlr && index == -1)
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2019-05-30 19:16:34 +08:00
|
|
|
lookup.ctlr = ctlr;
|
|
|
|
lookup.irq = -1;
|
2022-01-22 01:24:25 +08:00
|
|
|
lookup.index = index;
|
|
|
|
lookup.n = 0;
|
2012-11-30 19:37:53 +08:00
|
|
|
|
|
|
|
INIT_LIST_HEAD(&resource_list);
|
|
|
|
ret = acpi_dev_get_resources(adev, &resource_list,
|
2019-05-30 19:16:34 +08:00
|
|
|
acpi_spi_add_resource, &lookup);
|
2012-11-30 19:37:53 +08:00
|
|
|
acpi_dev_free_resource_list(&resource_list);
|
|
|
|
|
2019-05-30 19:16:34 +08:00
|
|
|
if (ret < 0)
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Found SPI in _CRS but it points to another controller */
|
2022-07-09 08:07:08 +08:00
|
|
|
return ERR_PTR(ret);
|
2017-08-01 20:10:41 +08:00
|
|
|
|
2019-05-30 19:16:34 +08:00
|
|
|
if (!lookup.max_speed_hz &&
|
2021-01-27 04:23:17 +08:00
|
|
|
ACPI_SUCCESS(acpi_get_parent(adev->handle, &parent_handle)) &&
|
2022-01-22 01:24:25 +08:00
|
|
|
ACPI_HANDLE(lookup.ctlr->dev.parent) == parent_handle) {
|
2019-05-30 19:16:34 +08:00
|
|
|
/* Apple does not use _CRS but nested devices for SPI slaves */
|
|
|
|
acpi_spi_parse_apple_properties(adev, &lookup);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!lookup.max_speed_hz)
|
2022-01-22 01:24:24 +08:00
|
|
|
return ERR_PTR(-ENODEV);
|
2019-05-30 19:16:34 +08:00
|
|
|
|
2022-01-22 01:24:25 +08:00
|
|
|
spi = spi_alloc_device(lookup.ctlr);
|
2019-05-30 19:16:34 +08:00
|
|
|
if (!spi) {
|
2022-01-22 01:24:25 +08:00
|
|
|
dev_err(&lookup.ctlr->dev, "failed to allocate SPI device for %s\n",
|
2019-05-30 19:16:34 +08:00
|
|
|
dev_name(&adev->dev));
|
2022-01-22 01:24:24 +08:00
|
|
|
return ERR_PTR(-ENOMEM);
|
2012-11-30 19:37:53 +08:00
|
|
|
}
|
|
|
|
|
2019-05-30 19:16:34 +08:00
|
|
|
ACPI_COMPANION_SET(&spi->dev, adev);
|
|
|
|
spi->max_speed_hz = lookup.max_speed_hz;
|
2020-02-28 23:18:49 +08:00
|
|
|
spi->mode |= lookup.mode;
|
2019-05-30 19:16:34 +08:00
|
|
|
spi->irq = lookup.irq;
|
|
|
|
spi->bits_per_word = lookup.bits_per_word;
|
|
|
|
spi->chip_select = lookup.chip_select;
|
|
|
|
|
2022-01-22 01:24:24 +08:00
|
|
|
return spi;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_spi_device_alloc);
|
|
|
|
|
|
|
|
static acpi_status acpi_register_spi_device(struct spi_controller *ctlr,
|
|
|
|
struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
struct spi_device *spi;
|
|
|
|
|
|
|
|
if (acpi_bus_get_status(adev) || !adev->status.present ||
|
|
|
|
acpi_device_enumerated(adev))
|
|
|
|
return AE_OK;
|
|
|
|
|
2022-01-22 01:24:25 +08:00
|
|
|
spi = acpi_spi_device_alloc(ctlr, adev, -1);
|
2022-01-22 01:24:24 +08:00
|
|
|
if (IS_ERR(spi)) {
|
|
|
|
if (PTR_ERR(spi) == -ENOMEM)
|
|
|
|
return AE_NO_MEMORY;
|
|
|
|
else
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
2017-02-06 00:30:14 +08:00
|
|
|
acpi_set_modalias(adev, acpi_device_hid(adev), spi->modalias,
|
|
|
|
sizeof(spi->modalias));
|
|
|
|
|
2015-12-24 06:25:35 +08:00
|
|
|
if (spi->irq < 0)
|
|
|
|
spi->irq = acpi_dev_gpio_irq_get(adev, 0);
|
|
|
|
|
2016-07-09 00:13:11 +08:00
|
|
|
acpi_device_set_enumerated(adev);
|
|
|
|
|
2013-10-10 18:28:48 +08:00
|
|
|
adev->power.flags.ignore_parent = true;
|
2012-11-30 19:37:53 +08:00
|
|
|
if (spi_add_device(spi)) {
|
2013-10-10 18:28:48 +08:00
|
|
|
adev->power.flags.ignore_parent = false;
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_err(&ctlr->dev, "failed to add SPI device %s from ACPI\n",
|
2012-11-30 19:37:53 +08:00
|
|
|
dev_name(&adev->dev));
|
|
|
|
spi_dev_put(spi);
|
|
|
|
}
|
|
|
|
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
2016-07-09 00:13:11 +08:00
|
|
|
static acpi_status acpi_spi_add_device(acpi_handle handle, u32 level,
|
|
|
|
void *data, void **return_value)
|
|
|
|
{
|
2022-02-02 04:05:59 +08:00
|
|
|
struct acpi_device *adev = acpi_fetch_acpi_dev(handle);
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = data;
|
2016-07-09 00:13:11 +08:00
|
|
|
|
2022-02-02 04:05:59 +08:00
|
|
|
if (!adev)
|
2016-07-09 00:13:11 +08:00
|
|
|
return AE_OK;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
return acpi_register_spi_device(ctlr, adev);
|
2016-07-09 00:13:11 +08:00
|
|
|
}
|
|
|
|
|
2019-05-30 19:16:34 +08:00
|
|
|
#define SPI_ACPI_ENUMERATE_MAX_DEPTH 32
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static void acpi_register_spi_devices(struct spi_controller *ctlr)
|
2012-11-30 19:37:53 +08:00
|
|
|
{
|
|
|
|
acpi_status status;
|
|
|
|
acpi_handle handle;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
handle = ACPI_HANDLE(ctlr->dev.parent);
|
2012-11-30 19:37:53 +08:00
|
|
|
if (!handle)
|
|
|
|
return;
|
|
|
|
|
2019-05-30 19:16:34 +08:00
|
|
|
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
|
|
|
|
SPI_ACPI_ENUMERATE_MAX_DEPTH,
|
2017-06-13 19:23:52 +08:00
|
|
|
acpi_spi_add_device, NULL, ctlr, NULL);
|
2012-11-30 19:37:53 +08:00
|
|
|
if (ACPI_FAILURE(status))
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_warn(&ctlr->dev, "failed to enumerate SPI slaves\n");
|
2012-11-30 19:37:53 +08:00
|
|
|
}
|
|
|
|
#else
|
2017-06-13 19:23:52 +08:00
|
|
|
static inline void acpi_register_spi_devices(struct spi_controller *ctlr) {}
|
2012-11-30 19:37:53 +08:00
|
|
|
#endif /* CONFIG_ACPI */
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static void spi_controller_release(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
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
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
|
|
|
ctlr = container_of(dev, struct spi_controller, dev);
|
|
|
|
kfree(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
|
|
|
}
|
|
|
|
|
|
|
|
static struct class spi_master_class = {
|
|
|
|
.name = "spi_master",
|
|
|
|
.owner = THIS_MODULE,
|
2017-06-13 19:23:52 +08:00
|
|
|
.dev_release = spi_controller_release,
|
2015-06-22 21:00:36 +08:00
|
|
|
.dev_groups = spi_master_groups,
|
[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
|
|
|
#ifdef CONFIG_SPI_SLAVE
|
|
|
|
/**
|
|
|
|
* spi_slave_abort - abort the ongoing transfer request on an SPI slave
|
|
|
|
* controller
|
|
|
|
* @spi: device used for the current transfer
|
|
|
|
*/
|
|
|
|
int spi_slave_abort(struct spi_device *spi)
|
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = spi->controller;
|
2017-05-22 21:11:41 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (spi_controller_is_slave(ctlr) && ctlr->slave_abort)
|
|
|
|
return ctlr->slave_abort(ctlr);
|
2017-05-22 21:11:41 +08:00
|
|
|
|
|
|
|
return -ENOTSUPP;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_slave_abort);
|
|
|
|
|
2019-07-31 20:47:38 +08:00
|
|
|
static ssize_t slave_show(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf)
|
2017-05-22 21:11:41 +08:00
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = container_of(dev, struct spi_controller,
|
|
|
|
dev);
|
2017-05-22 21:11:41 +08:00
|
|
|
struct device *child;
|
|
|
|
|
2022-06-10 20:02:19 +08:00
|
|
|
child = device_find_any_child(&ctlr->dev);
|
2017-05-22 21:11:41 +08:00
|
|
|
return sprintf(buf, "%s\n",
|
|
|
|
child ? to_spi_device(child)->modalias : NULL);
|
|
|
|
}
|
|
|
|
|
2019-07-31 20:47:38 +08:00
|
|
|
static ssize_t slave_store(struct device *dev, struct device_attribute *attr,
|
|
|
|
const char *buf, size_t count)
|
2017-05-22 21:11:41 +08:00
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = container_of(dev, struct spi_controller,
|
|
|
|
dev);
|
2017-05-22 21:11:41 +08:00
|
|
|
struct spi_device *spi;
|
|
|
|
struct device *child;
|
|
|
|
char name[32];
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = sscanf(buf, "%31s", name);
|
|
|
|
if (rc != 1 || !name[0])
|
|
|
|
return -EINVAL;
|
|
|
|
|
2022-06-10 20:02:19 +08:00
|
|
|
child = device_find_any_child(&ctlr->dev);
|
2017-05-22 21:11:41 +08:00
|
|
|
if (child) {
|
|
|
|
/* Remove registered slave */
|
|
|
|
device_unregister(child);
|
|
|
|
put_device(child);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (strcmp(name, "(null)")) {
|
|
|
|
/* Register new slave */
|
|
|
|
spi = spi_alloc_device(ctlr);
|
|
|
|
if (!spi)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
strlcpy(spi->modalias, name, sizeof(spi->modalias));
|
|
|
|
|
|
|
|
rc = spi_add_device(spi);
|
|
|
|
if (rc) {
|
|
|
|
spi_dev_put(spi);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2019-07-31 20:47:38 +08:00
|
|
|
static DEVICE_ATTR_RW(slave);
|
2017-05-22 21:11:41 +08:00
|
|
|
|
|
|
|
static struct attribute *spi_slave_attrs[] = {
|
|
|
|
&dev_attr_slave.attr,
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct attribute_group spi_slave_group = {
|
|
|
|
.attrs = spi_slave_attrs,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct attribute_group *spi_slave_groups[] = {
|
2017-06-13 19:23:52 +08:00
|
|
|
&spi_controller_statistics_group,
|
2017-05-22 21:11:41 +08:00
|
|
|
&spi_slave_group,
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct class spi_slave_class = {
|
|
|
|
.name = "spi_slave",
|
|
|
|
.owner = THIS_MODULE,
|
2017-06-13 19:23:52 +08:00
|
|
|
.dev_release = spi_controller_release,
|
2017-05-22 21:11:41 +08:00
|
|
|
.dev_groups = spi_slave_groups,
|
|
|
|
};
|
|
|
|
#else
|
|
|
|
extern struct class spi_slave_class; /* dummy */
|
|
|
|
#endif
|
[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
|
|
|
* __spi_alloc_controller - allocate an SPI master or slave 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
|
|
|
* @dev: the controller, possibly using the platform_bus
|
2007-05-08 15:32:21 +08:00
|
|
|
* @size: how much zeroed driver-private data to allocate; the pointer to this
|
2019-09-11 18:15:30 +08:00
|
|
|
* memory is in the driver_data field of the returned device, accessible
|
|
|
|
* with spi_controller_get_devdata(); the memory is cacheline aligned;
|
|
|
|
* drivers granting DMA access to portions of their private data need to
|
|
|
|
* round up @size using ALIGN(size, dma_get_cache_alignment()).
|
2017-05-22 21:11:41 +08:00
|
|
|
* @slave: flag indicating whether to allocate an SPI master (false) or SPI
|
|
|
|
* slave (true) controller
|
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
|
|
|
*
|
2017-05-22 21:11:41 +08:00
|
|
|
* This call is used only by SPI controller drivers, which are 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
|
|
|
* only ones directly touching chip registers. It's how they allocate
|
2017-06-13 19:23:52 +08:00
|
|
|
* an spi_controller structure, prior to calling spi_register_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
|
|
|
*
|
2015-10-23 00:59:23 +08:00
|
|
|
* This must be called from context that 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
|
|
|
*
|
2017-05-22 21:11:41 +08:00
|
|
|
* The caller is responsible for assigning the bus number and initializing the
|
2017-06-13 19:23:52 +08:00
|
|
|
* controller's methods before calling spi_register_controller(); and (after
|
|
|
|
* errors adding the device) calling spi_controller_put() to prevent a memory
|
|
|
|
* leak.
|
2015-10-23 00:59:23 +08:00
|
|
|
*
|
2017-05-22 21:11:41 +08:00
|
|
|
* Return: the SPI controller structure on success, else 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
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *__spi_alloc_controller(struct device *dev,
|
|
|
|
unsigned int size, bool 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
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr;
|
2019-09-11 18:15:30 +08:00
|
|
|
size_t ctlr_size = ALIGN(sizeof(*ctlr), dma_get_cache_alignment());
|
[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
|
|
|
|
2006-01-09 05:34:25 +08:00
|
|
|
if (!dev)
|
|
|
|
return NULL;
|
|
|
|
|
2019-09-11 18:15:30 +08:00
|
|
|
ctlr = kzalloc(size + ctlr_size, GFP_KERNEL);
|
2017-06-13 19:23:52 +08:00
|
|
|
if (!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
|
|
|
return NULL;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
device_initialize(&ctlr->dev);
|
2021-10-13 21:37:10 +08:00
|
|
|
INIT_LIST_HEAD(&ctlr->queue);
|
|
|
|
spin_lock_init(&ctlr->queue_lock);
|
|
|
|
spin_lock_init(&ctlr->bus_lock_spinlock);
|
|
|
|
mutex_init(&ctlr->bus_lock_mutex);
|
|
|
|
mutex_init(&ctlr->io_mutex);
|
|
|
|
mutex_init(&ctlr->add_lock);
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr->bus_num = -1;
|
|
|
|
ctlr->num_chipselect = 1;
|
|
|
|
ctlr->slave = slave;
|
2017-05-22 21:11:41 +08:00
|
|
|
if (IS_ENABLED(CONFIG_SPI_SLAVE) && slave)
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr->dev.class = &spi_slave_class;
|
2017-05-22 21:11:41 +08:00
|
|
|
else
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr->dev.class = &spi_master_class;
|
|
|
|
ctlr->dev.parent = dev;
|
|
|
|
pm_suspend_ignore_children(&ctlr->dev, true);
|
2019-09-11 18:15:30 +08:00
|
|
|
spi_controller_set_devdata(ctlr, (void *)ctlr + ctlr_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
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
return 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-05-22 21:11:41 +08:00
|
|
|
EXPORT_SYMBOL_GPL(__spi_alloc_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
|
|
|
|
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
|
|
|
static void devm_spi_release_controller(struct device *dev, void *ctlr)
|
|
|
|
{
|
|
|
|
spi_controller_put(*(struct spi_controller **)ctlr);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* __devm_spi_alloc_controller - resource-managed __spi_alloc_controller()
|
|
|
|
* @dev: physical device of SPI controller
|
|
|
|
* @size: how much zeroed driver-private data to allocate
|
|
|
|
* @slave: whether to allocate an SPI master (false) or SPI slave (true)
|
|
|
|
* Context: can sleep
|
|
|
|
*
|
|
|
|
* Allocate an SPI controller and automatically release a reference on it
|
|
|
|
* when @dev is unbound from its driver. Drivers are thus relieved from
|
|
|
|
* having to call spi_controller_put().
|
|
|
|
*
|
|
|
|
* The arguments to this function are identical to __spi_alloc_controller().
|
|
|
|
*
|
|
|
|
* Return: the SPI controller structure on success, else NULL.
|
|
|
|
*/
|
|
|
|
struct spi_controller *__devm_spi_alloc_controller(struct device *dev,
|
|
|
|
unsigned int size,
|
|
|
|
bool slave)
|
|
|
|
{
|
|
|
|
struct spi_controller **ptr, *ctlr;
|
|
|
|
|
|
|
|
ptr = devres_alloc(devm_spi_release_controller, sizeof(*ptr),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!ptr)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
ctlr = __spi_alloc_controller(dev, size, slave);
|
|
|
|
if (ctlr) {
|
2021-04-07 17:55:27 +08:00
|
|
|
ctlr->devm_allocated = true;
|
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
|
|
|
*ptr = ctlr;
|
|
|
|
devres_add(dev, ptr);
|
|
|
|
} else {
|
|
|
|
devres_free(ptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ctlr;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__devm_spi_alloc_controller);
|
|
|
|
|
2019-01-07 23:51:50 +08:00
|
|
|
/**
|
|
|
|
* spi_get_gpio_descs() - grab chip select GPIOs for the master
|
|
|
|
* @ctlr: The SPI master to grab GPIO descriptors for
|
|
|
|
*/
|
|
|
|
static int spi_get_gpio_descs(struct spi_controller *ctlr)
|
|
|
|
{
|
|
|
|
int nb, i;
|
|
|
|
struct gpio_desc **cs;
|
|
|
|
struct device *dev = &ctlr->dev;
|
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
|
|
|
unsigned long native_cs_mask = 0;
|
|
|
|
unsigned int num_cs_gpios = 0;
|
2019-01-07 23:51:50 +08:00
|
|
|
|
|
|
|
nb = gpiod_count(dev, "cs");
|
2021-04-21 00:40:40 +08:00
|
|
|
if (nb < 0) {
|
|
|
|
/* No GPIOs at all is fine, else return the error */
|
|
|
|
if (nb == -ENOENT)
|
|
|
|
return 0;
|
2019-01-07 23:51:50 +08:00
|
|
|
return nb;
|
2021-04-21 00:40:40 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ctlr->num_chipselect = max_t(int, nb, ctlr->num_chipselect);
|
2019-01-07 23:51:50 +08:00
|
|
|
|
|
|
|
cs = devm_kcalloc(dev, ctlr->num_chipselect, sizeof(*cs),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!cs)
|
|
|
|
return -ENOMEM;
|
|
|
|
ctlr->cs_gpiods = cs;
|
|
|
|
|
|
|
|
for (i = 0; i < nb; i++) {
|
|
|
|
/*
|
|
|
|
* Most chipselects are active low, the inverted
|
|
|
|
* semantics are handled by special quirks in gpiolib,
|
|
|
|
* so initializing them GPIOD_OUT_LOW here means
|
|
|
|
* "unasserted", in most cases this will drive the physical
|
|
|
|
* line high.
|
|
|
|
*/
|
|
|
|
cs[i] = devm_gpiod_get_index_optional(dev, "cs", i,
|
|
|
|
GPIOD_OUT_LOW);
|
2019-04-03 22:46:56 +08:00
|
|
|
if (IS_ERR(cs[i]))
|
|
|
|
return PTR_ERR(cs[i]);
|
2019-01-07 23:51:50 +08:00
|
|
|
|
|
|
|
if (cs[i]) {
|
|
|
|
/*
|
|
|
|
* If we find a CS GPIO, name it after the device and
|
|
|
|
* chip select line.
|
|
|
|
*/
|
|
|
|
char *gpioname;
|
|
|
|
|
|
|
|
gpioname = devm_kasprintf(dev, GFP_KERNEL, "%s CS%d",
|
|
|
|
dev_name(dev), i);
|
|
|
|
if (!gpioname)
|
|
|
|
return -ENOMEM;
|
|
|
|
gpiod_set_consumer_name(cs[i], gpioname);
|
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
|
|
|
num_cs_gpios++;
|
|
|
|
continue;
|
2019-01-07 23:51:50 +08:00
|
|
|
}
|
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
|
|
|
|
|
|
|
if (ctlr->max_native_cs && i >= ctlr->max_native_cs) {
|
|
|
|
dev_err(dev, "Invalid native chip select %d\n", i);
|
|
|
|
return -EINVAL;
|
2019-01-07 23:51:50 +08:00
|
|
|
}
|
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
|
|
|
native_cs_mask |= BIT(i);
|
|
|
|
}
|
|
|
|
|
2021-04-21 00:44:25 +08:00
|
|
|
ctlr->unused_native_cs = ffs(~native_cs_mask) - 1;
|
2021-04-21 00:44:24 +08:00
|
|
|
|
|
|
|
if ((ctlr->flags & SPI_MASTER_GPIO_SS) && num_cs_gpios &&
|
|
|
|
ctlr->max_native_cs && ctlr->unused_native_cs >= ctlr->max_native_cs) {
|
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
|
|
|
dev_err(dev, "No unused native chip select available\n");
|
|
|
|
return -EINVAL;
|
2019-01-07 23:51:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-04-11 06:44:30 +08:00
|
|
|
static int spi_controller_check_ops(struct spi_controller *ctlr)
|
|
|
|
{
|
|
|
|
/*
|
2018-04-27 00:18:15 +08:00
|
|
|
* The controller may implement only the high-level SPI-memory like
|
|
|
|
* operations if it does not support regular SPI transfers, and this is
|
|
|
|
* valid use case.
|
|
|
|
* If ->mem_ops is NULL, we request that at least one of the
|
|
|
|
* ->transfer_xxx() method be implemented.
|
2018-04-11 06:44:30 +08:00
|
|
|
*/
|
2018-04-27 00:18:15 +08:00
|
|
|
if (ctlr->mem_ops) {
|
|
|
|
if (!ctlr->mem_ops->exec_op)
|
|
|
|
return -EINVAL;
|
|
|
|
} else if (!ctlr->transfer && !ctlr->transfer_one &&
|
|
|
|
!ctlr->transfer_one_message) {
|
2018-04-11 06:44:30 +08:00
|
|
|
return -EINVAL;
|
2018-04-27 00:18:15 +08:00
|
|
|
}
|
2018-04-11 06:44:30 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
* spi_register_controller - register SPI master or slave controller
|
|
|
|
* @ctlr: initialized master, originally from spi_alloc_master() or
|
|
|
|
* spi_alloc_slave()
|
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
|
|
|
*
|
2017-06-13 19:23:52 +08:00
|
|
|
* SPI controllers connect to their drivers using some non-SPI bus,
|
[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
|
|
|
* such as the platform bus. The final stage of probe() in that code
|
2017-06-13 19:23:52 +08:00
|
|
|
* includes calling spi_register_controller() to hook up to this SPI bus glue.
|
[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 controllers use board specific (often SOC specific) bus numbers,
|
|
|
|
* and board-specific addressing for SPI devices combines those numbers
|
|
|
|
* with chip select numbers. Since SPI does not directly support dynamic
|
|
|
|
* device identification, boards need configuration tables telling which
|
|
|
|
* chip is at which address.
|
|
|
|
*
|
|
|
|
* This must be called from context that can sleep. It returns zero on
|
2017-06-13 19:23:52 +08:00
|
|
|
* success, else a negative error code (dropping the controller's refcount).
|
2006-01-09 05:34:25 +08:00
|
|
|
* After a successful return, the caller is responsible for calling
|
2017-06-13 19:23:52 +08:00
|
|
|
* spi_unregister_controller().
|
2015-10-23 00:59:23 +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
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
int spi_register_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
|
|
|
struct device *dev = ctlr->dev.parent;
|
2010-08-02 15:52:15 +08:00
|
|
|
struct boardinfo *bi;
|
2019-04-05 23:48:50 +08:00
|
|
|
int status;
|
2017-10-16 18:27:58 +08:00
|
|
|
int id, first_dynamic;
|
[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
|
|
|
|
2006-01-09 05:34:25 +08:00
|
|
|
if (!dev)
|
|
|
|
return -ENODEV;
|
|
|
|
|
2018-04-11 06:44:30 +08:00
|
|
|
/*
|
|
|
|
* Make sure all necessary hooks are implemented before registering
|
|
|
|
* the SPI controller.
|
|
|
|
*/
|
|
|
|
status = spi_controller_check_ops(ctlr);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
2018-08-21 17:53:03 +08:00
|
|
|
if (ctlr->bus_num >= 0) {
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Devices with a fixed bus num must check-in with the num */
|
2018-08-21 17:53:03 +08:00
|
|
|
mutex_lock(&board_lock);
|
|
|
|
id = idr_alloc(&spi_master_idr, ctlr, ctlr->bus_num,
|
|
|
|
ctlr->bus_num + 1, GFP_KERNEL);
|
|
|
|
mutex_unlock(&board_lock);
|
|
|
|
if (WARN(id < 0, "couldn't get idr"))
|
|
|
|
return id == -ENOSPC ? -EBUSY : id;
|
|
|
|
ctlr->bus_num = id;
|
|
|
|
} else if (ctlr->dev.of_node) {
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Allocate dynamic bus number using Linux idr */
|
2017-08-03 12:35:57 +08:00
|
|
|
id = of_alias_get_id(ctlr->dev.of_node, "spi");
|
|
|
|
if (id >= 0) {
|
|
|
|
ctlr->bus_num = id;
|
|
|
|
mutex_lock(&board_lock);
|
|
|
|
id = idr_alloc(&spi_master_idr, ctlr, ctlr->bus_num,
|
|
|
|
ctlr->bus_num + 1, GFP_KERNEL);
|
|
|
|
mutex_unlock(&board_lock);
|
|
|
|
if (WARN(id < 0, "couldn't get idr"))
|
|
|
|
return id == -ENOSPC ? -EBUSY : id;
|
|
|
|
}
|
|
|
|
}
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->bus_num < 0) {
|
2017-10-16 18:27:58 +08:00
|
|
|
first_dynamic = of_alias_get_highest_id("spi");
|
|
|
|
if (first_dynamic < 0)
|
|
|
|
first_dynamic = 0;
|
|
|
|
else
|
|
|
|
first_dynamic++;
|
|
|
|
|
2017-08-17 20:48:22 +08:00
|
|
|
mutex_lock(&board_lock);
|
2017-10-16 18:27:58 +08:00
|
|
|
id = idr_alloc(&spi_master_idr, ctlr, first_dynamic,
|
|
|
|
0, GFP_KERNEL);
|
2017-08-17 20:48:22 +08:00
|
|
|
mutex_unlock(&board_lock);
|
|
|
|
if (WARN(id < 0, "couldn't get idr"))
|
|
|
|
return id;
|
|
|
|
ctlr->bus_num = id;
|
[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
|
|
|
ctlr->bus_lock_flag = 0;
|
|
|
|
init_completion(&ctlr->xfer_completion);
|
2022-06-21 14:12:33 +08:00
|
|
|
init_completion(&ctlr->cur_msg_completion);
|
2017-06-13 19:23:52 +08:00
|
|
|
if (!ctlr->max_dma_len)
|
|
|
|
ctlr->max_dma_len = INT_MAX;
|
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
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* Register the device, then userspace will see it.
|
|
|
|
* Registration fails if the bus ID is in 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
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_set_name(&ctlr->dev, "spi%u", ctlr->bus_num);
|
2019-04-03 12:01:28 +08:00
|
|
|
|
2022-02-11 07:19:54 +08:00
|
|
|
if (!spi_controller_is_slave(ctlr) && ctlr->use_gpio_descriptors) {
|
|
|
|
status = spi_get_gpio_descs(ctlr);
|
|
|
|
if (status)
|
|
|
|
goto free_bus_id;
|
|
|
|
/*
|
|
|
|
* A controller using GPIO descriptors always
|
|
|
|
* supports SPI_CS_HIGH if need be.
|
|
|
|
*/
|
|
|
|
ctlr->mode_bits |= SPI_CS_HIGH;
|
2019-04-03 12:01:28 +08:00
|
|
|
}
|
|
|
|
|
2019-06-19 22:38:28 +08:00
|
|
|
/*
|
|
|
|
* Even if it's just one always-selected device, there must
|
|
|
|
* be at least one chipselect.
|
|
|
|
*/
|
2020-03-04 19:17:40 +08:00
|
|
|
if (!ctlr->num_chipselect) {
|
|
|
|
status = -EINVAL;
|
|
|
|
goto free_bus_id;
|
|
|
|
}
|
2019-06-19 22:38:28 +08:00
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Setting last_cs to -1 means no chip selected */
|
2022-02-17 22:12:34 +08:00
|
|
|
ctlr->last_cs = -1;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
status = device_add(&ctlr->dev);
|
2020-03-04 19:17:40 +08:00
|
|
|
if (status < 0)
|
|
|
|
goto free_bus_id;
|
2017-08-03 12:35:57 +08:00
|
|
|
dev_dbg(dev, "registered %s %s\n",
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_controller_is_slave(ctlr) ? "slave" : "master",
|
2017-08-03 12:35:57 +08:00
|
|
|
dev_name(&ctlr->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
|
|
|
|
2018-04-27 00:18:15 +08:00
|
|
|
/*
|
|
|
|
* If we're using a queued driver, start the queue. Note that we don't
|
|
|
|
* need the queueing logic if the driver is only supporting high-level
|
|
|
|
* memory operations.
|
|
|
|
*/
|
|
|
|
if (ctlr->transfer) {
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_info(dev, "controller is unqueued, this is deprecated\n");
|
2018-04-27 00:18:15 +08:00
|
|
|
} else if (ctlr->transfer_one || ctlr->transfer_one_message) {
|
2017-06-13 19:23:52 +08:00
|
|
|
status = spi_controller_initialize_queue(ctlr);
|
2012-02-22 17:05:38 +08:00
|
|
|
if (status) {
|
2017-06-13 19:23:52 +08:00
|
|
|
device_del(&ctlr->dev);
|
2020-03-04 19:17:40 +08:00
|
|
|
goto free_bus_id;
|
2012-02-22 17:05:38 +08:00
|
|
|
}
|
|
|
|
}
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Add statistics */
|
2022-05-24 17:18:08 +08:00
|
|
|
ctlr->pcpu_statistics = spi_alloc_pcpu_stats(dev);
|
|
|
|
if (!ctlr->pcpu_statistics) {
|
|
|
|
dev_err(dev, "Error allocating per-cpu statistics\n");
|
2022-06-14 20:09:17 +08:00
|
|
|
status = -ENOMEM;
|
2022-05-24 17:18:08 +08:00
|
|
|
goto destroy_queue;
|
|
|
|
}
|
2012-02-22 17:05:38 +08:00
|
|
|
|
2010-08-02 15:52:15 +08:00
|
|
|
mutex_lock(&board_lock);
|
2017-06-13 19:23:52 +08:00
|
|
|
list_add_tail(&ctlr->list, &spi_controller_list);
|
2010-08-02 15:52:15 +08:00
|
|
|
list_for_each_entry(bi, &board_list, list)
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_match_controller_to_boardinfo(ctlr, &bi->board_info);
|
2010-08-02 15:52:15 +08:00
|
|
|
mutex_unlock(&board_lock);
|
|
|
|
|
2012-11-30 19:37:53 +08:00
|
|
|
/* Register devices from the device tree and ACPI */
|
2017-06-13 19:23:52 +08:00
|
|
|
of_register_spi_devices(ctlr);
|
|
|
|
acpi_register_spi_devices(ctlr);
|
2020-03-04 19:17:40 +08:00
|
|
|
return status;
|
|
|
|
|
2022-05-24 17:18:08 +08:00
|
|
|
destroy_queue:
|
|
|
|
spi_destroy_queue(ctlr);
|
2020-03-04 19:17:40 +08:00
|
|
|
free_bus_id:
|
|
|
|
mutex_lock(&board_lock);
|
|
|
|
idr_remove(&spi_master_idr, ctlr->bus_num);
|
|
|
|
mutex_unlock(&board_lock);
|
[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 status;
|
|
|
|
}
|
2017-06-13 19:23:52 +08:00
|
|
|
EXPORT_SYMBOL_GPL(spi_register_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
|
|
|
|
2022-07-12 21:55:04 +08:00
|
|
|
static void devm_spi_unregister(struct device *dev, void *res)
|
2013-09-01 01:50:52 +08:00
|
|
|
{
|
2022-07-12 21:55:04 +08:00
|
|
|
spi_unregister_controller(*(struct spi_controller **)res);
|
2013-09-01 01:50:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2017-06-13 19:23:52 +08:00
|
|
|
* devm_spi_register_controller - register managed SPI master or slave
|
|
|
|
* controller
|
|
|
|
* @dev: device managing SPI controller
|
|
|
|
* @ctlr: initialized controller, originally from spi_alloc_master() or
|
|
|
|
* spi_alloc_slave()
|
2013-09-01 01:50:52 +08:00
|
|
|
* Context: can sleep
|
|
|
|
*
|
2017-06-13 19:23:52 +08:00
|
|
|
* Register a SPI device as with spi_register_controller() which will
|
2017-10-30 18:35:26 +08:00
|
|
|
* automatically be unregistered and freed.
|
2015-10-23 00:59:23 +08:00
|
|
|
*
|
|
|
|
* Return: zero on success, else a negative error code.
|
2013-09-01 01:50:52 +08:00
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
int devm_spi_register_controller(struct device *dev,
|
|
|
|
struct spi_controller *ctlr)
|
2013-09-01 01:50:52 +08:00
|
|
|
{
|
2022-07-12 21:55:04 +08:00
|
|
|
struct spi_controller **ptr;
|
2013-09-01 01:50:52 +08:00
|
|
|
int ret;
|
|
|
|
|
2022-07-12 21:55:04 +08:00
|
|
|
ptr = devres_alloc(devm_spi_unregister, sizeof(*ptr), GFP_KERNEL);
|
|
|
|
if (!ptr)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
ret = spi_register_controller(ctlr);
|
2022-07-12 21:55:04 +08:00
|
|
|
if (!ret) {
|
|
|
|
*ptr = ctlr;
|
|
|
|
devres_add(dev, ptr);
|
|
|
|
} else {
|
|
|
|
devres_free(ptr);
|
|
|
|
}
|
2013-09-01 01:50:52 +08:00
|
|
|
|
2022-07-12 21:55:04 +08:00
|
|
|
return ret;
|
2013-09-01 01:50:52 +08:00
|
|
|
}
|
2017-06-13 19:23:52 +08:00
|
|
|
EXPORT_SYMBOL_GPL(devm_spi_register_controller);
|
2013-09-01 01:50:52 +08:00
|
|
|
|
2010-08-31 05:54:17 +08:00
|
|
|
static int __unregister(struct device *dev, void *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
|
|
|
{
|
2010-08-31 05:54:17 +08:00
|
|
|
spi_unregister_device(to_spi_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
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2017-06-13 19:23:52 +08:00
|
|
|
* spi_unregister_controller - unregister SPI master or slave controller
|
|
|
|
* @ctlr: the controller being unregistered
|
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
|
|
|
*
|
2017-06-13 19:23:52 +08:00
|
|
|
* This call is used only by SPI controller drivers, which are 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
|
|
|
* only ones directly touching chip registers.
|
|
|
|
*
|
|
|
|
* This must be called from context that can sleep.
|
2017-10-30 18:35:26 +08:00
|
|
|
*
|
|
|
|
* Note that this function also drops a reference to the 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
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
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-08-03 12:35:57 +08:00
|
|
|
struct spi_controller *found;
|
2017-10-30 18:35:25 +08:00
|
|
|
int id = ctlr->bus_num;
|
2006-12-07 12:35:35 +08:00
|
|
|
|
2020-08-03 19:09:01 +08:00
|
|
|
/* Prevent addition of new devices, unregister existing ones */
|
|
|
|
if (IS_ENABLED(CONFIG_SPI_DYNAMIC))
|
2021-10-08 21:31:57 +08:00
|
|
|
mutex_lock(&ctlr->add_lock);
|
2020-08-03 19:09:01 +08:00
|
|
|
|
2020-05-15 23:58:01 +08:00
|
|
|
device_for_each_child(&ctlr->dev, NULL, __unregister);
|
|
|
|
|
2017-08-03 12:35:57 +08:00
|
|
|
/* First make sure that this controller was ever added */
|
|
|
|
mutex_lock(&board_lock);
|
2017-10-30 18:35:25 +08:00
|
|
|
found = idr_find(&spi_master_idr, id);
|
2017-08-03 12:35:57 +08:00
|
|
|
mutex_unlock(&board_lock);
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->queued) {
|
|
|
|
if (spi_destroy_queue(ctlr))
|
|
|
|
dev_err(&ctlr->dev, "queue remove failed\n");
|
2012-02-22 17:05:38 +08:00
|
|
|
}
|
2010-08-02 15:52:15 +08:00
|
|
|
mutex_lock(&board_lock);
|
2017-06-13 19:23:52 +08:00
|
|
|
list_del(&ctlr->list);
|
2010-08-02 15:52:15 +08:00
|
|
|
mutex_unlock(&board_lock);
|
|
|
|
|
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
|
|
|
device_del(&ctlr->dev);
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Free bus id */
|
2017-08-03 12:35:57 +08:00
|
|
|
mutex_lock(&board_lock);
|
2018-03-20 16:27:50 +08:00
|
|
|
if (found == ctlr)
|
|
|
|
idr_remove(&spi_master_idr, id);
|
2017-08-03 12:35:57 +08:00
|
|
|
mutex_unlock(&board_lock);
|
2020-08-03 19:09:01 +08:00
|
|
|
|
|
|
|
if (IS_ENABLED(CONFIG_SPI_DYNAMIC))
|
2021-10-08 21:31:57 +08:00
|
|
|
mutex_unlock(&ctlr->add_lock);
|
2021-11-11 16:37:13 +08:00
|
|
|
|
|
|
|
/* Release the last reference on the controller if its driver
|
|
|
|
* has not yet been converted to devm_spi_alloc_master/slave().
|
|
|
|
*/
|
|
|
|
if (!ctlr->devm_allocated)
|
|
|
|
put_device(&ctlr->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
|
|
|
}
|
2017-06-13 19:23:52 +08:00
|
|
|
EXPORT_SYMBOL_GPL(spi_unregister_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
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
int spi_controller_suspend(struct spi_controller *ctlr)
|
2012-02-22 17:05:38 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
/* Basically no-ops for non-queued controllers */
|
|
|
|
if (!ctlr->queued)
|
2012-02-22 17:05:38 +08:00
|
|
|
return 0;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
ret = spi_stop_queue(ctlr);
|
2012-02-22 17:05:38 +08:00
|
|
|
if (ret)
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_err(&ctlr->dev, "queue stop failed\n");
|
2012-02-22 17:05:38 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2017-06-13 19:23:52 +08:00
|
|
|
EXPORT_SYMBOL_GPL(spi_controller_suspend);
|
2012-02-22 17:05:38 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
int spi_controller_resume(struct spi_controller *ctlr)
|
2012-02-22 17:05:38 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (!ctlr->queued)
|
2012-02-22 17:05:38 +08:00
|
|
|
return 0;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
ret = spi_start_queue(ctlr);
|
2012-02-22 17:05:38 +08:00
|
|
|
if (ret)
|
2017-06-13 19:23:52 +08:00
|
|
|
dev_err(&ctlr->dev, "queue restart failed\n");
|
2012-02-22 17:05:38 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2017-06-13 19:23:52 +08:00
|
|
|
EXPORT_SYMBOL_GPL(spi_controller_resume);
|
2012-02-22 17:05:38 +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
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
2015-12-14 23:20:19 +08:00
|
|
|
/* Core methods for spi_message alterations */
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static void __spi_replace_transfers_release(struct spi_controller *ctlr,
|
2015-12-14 23:20:19 +08:00
|
|
|
struct spi_message *msg,
|
|
|
|
void *res)
|
|
|
|
{
|
|
|
|
struct spi_replaced_transfers *rxfer = res;
|
|
|
|
size_t i;
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Call extra callback if requested */
|
2015-12-14 23:20:19 +08:00
|
|
|
if (rxfer->release)
|
2017-06-13 19:23:52 +08:00
|
|
|
rxfer->release(ctlr, msg, res);
|
2015-12-14 23:20:19 +08:00
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Insert replaced transfers back into the message */
|
2015-12-14 23:20:19 +08:00
|
|
|
list_splice(&rxfer->replaced_transfers, rxfer->replaced_after);
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Remove the formerly inserted entries */
|
2015-12-14 23:20:19 +08:00
|
|
|
for (i = 0; i < rxfer->inserted; i++)
|
|
|
|
list_del(&rxfer->inserted_transfers[i].transfer_list);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* spi_replace_transfers - replace transfers with several transfers
|
|
|
|
* and register change with spi_message.resources
|
|
|
|
* @msg: the spi_message we work upon
|
|
|
|
* @xfer_first: the first spi_transfer we want to replace
|
|
|
|
* @remove: number of transfers to remove
|
|
|
|
* @insert: the number of transfers we want to insert instead
|
|
|
|
* @release: extra release code necessary in some circumstances
|
|
|
|
* @extradatasize: extra data to allocate (with alignment guarantees
|
|
|
|
* of struct @spi_transfer)
|
2016-02-18 23:53:11 +08:00
|
|
|
* @gfp: gfp flags
|
2015-12-14 23:20:19 +08:00
|
|
|
*
|
|
|
|
* Returns: pointer to @spi_replaced_transfers,
|
|
|
|
* PTR_ERR(...) in case of errors.
|
|
|
|
*/
|
2021-10-07 20:14:15 +08:00
|
|
|
static struct spi_replaced_transfers *spi_replace_transfers(
|
2015-12-14 23:20:19 +08:00
|
|
|
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)
|
|
|
|
{
|
|
|
|
struct spi_replaced_transfers *rxfer;
|
|
|
|
struct spi_transfer *xfer;
|
|
|
|
size_t i;
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Allocate the structure using spi_res */
|
2015-12-14 23:20:19 +08:00
|
|
|
rxfer = spi_res_alloc(msg->spi, __spi_replace_transfers_release,
|
2019-06-08 02:48:45 +08:00
|
|
|
struct_size(rxfer, inserted_transfers, insert)
|
2015-12-14 23:20:19 +08:00
|
|
|
+ extradatasize,
|
|
|
|
gfp);
|
|
|
|
if (!rxfer)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* The release code to invoke before running the generic release */
|
2015-12-14 23:20:19 +08:00
|
|
|
rxfer->release = release;
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Assign extradata */
|
2015-12-14 23:20:19 +08:00
|
|
|
if (extradatasize)
|
|
|
|
rxfer->extradata =
|
|
|
|
&rxfer->inserted_transfers[insert];
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Init the replaced_transfers list */
|
2015-12-14 23:20:19 +08:00
|
|
|
INIT_LIST_HEAD(&rxfer->replaced_transfers);
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* Assign the list_entry after which we should reinsert
|
2015-12-14 23:20:19 +08:00
|
|
|
* the @replaced_transfers - it may be spi_message.messages!
|
|
|
|
*/
|
|
|
|
rxfer->replaced_after = xfer_first->transfer_list.prev;
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Remove the requested number of transfers */
|
2015-12-14 23:20:19 +08:00
|
|
|
for (i = 0; i < remove; i++) {
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* If the entry after replaced_after it is msg->transfers
|
2015-12-14 23:20:19 +08:00
|
|
|
* then we have been requested to remove more transfers
|
2021-11-23 01:17:21 +08:00
|
|
|
* than are in the list.
|
2015-12-14 23:20:19 +08:00
|
|
|
*/
|
|
|
|
if (rxfer->replaced_after->next == &msg->transfers) {
|
|
|
|
dev_err(&msg->spi->dev,
|
|
|
|
"requested to remove more spi_transfers than are available\n");
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Insert replaced transfers back into the message */
|
2015-12-14 23:20:19 +08:00
|
|
|
list_splice(&rxfer->replaced_transfers,
|
|
|
|
rxfer->replaced_after);
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Free the spi_replace_transfer structure... */
|
2015-12-14 23:20:19 +08:00
|
|
|
spi_res_free(rxfer);
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* ...and return with an error */
|
2015-12-14 23:20:19 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* Remove the entry after replaced_after from list of
|
|
|
|
* transfers and add it to list of replaced_transfers.
|
2015-12-14 23:20:19 +08:00
|
|
|
*/
|
|
|
|
list_move_tail(rxfer->replaced_after->next,
|
|
|
|
&rxfer->replaced_transfers);
|
|
|
|
}
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* Create copy of the given xfer with identical settings
|
|
|
|
* based on the first transfer to get removed.
|
2015-12-14 23:20:19 +08:00
|
|
|
*/
|
|
|
|
for (i = 0; i < insert; i++) {
|
2022-06-29 22:25:18 +08:00
|
|
|
/* We need to run in reverse order */
|
2015-12-14 23:20:19 +08:00
|
|
|
xfer = &rxfer->inserted_transfers[insert - 1 - i];
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Copy all spi_transfer data */
|
2015-12-14 23:20:19 +08:00
|
|
|
memcpy(xfer, xfer_first, sizeof(*xfer));
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Add to list */
|
2015-12-14 23:20:19 +08:00
|
|
|
list_add(&xfer->transfer_list, rxfer->replaced_after);
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Clear cs_change and delay for all but the last */
|
2015-12-14 23:20:19 +08:00
|
|
|
if (i) {
|
|
|
|
xfer->cs_change = false;
|
2019-09-26 18:51:36 +08:00
|
|
|
xfer->delay.value = 0;
|
2015-12-14 23:20:19 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Set up inserted... */
|
2015-12-14 23:20:19 +08:00
|
|
|
rxfer->inserted = insert;
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* ...and register it with spi_res/spi_message */
|
2015-12-14 23:20:19 +08:00
|
|
|
spi_res_add(msg, rxfer);
|
|
|
|
|
|
|
|
return rxfer;
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static int __spi_split_transfer_maxsize(struct spi_controller *ctlr,
|
2016-02-14 23:33:50 +08:00
|
|
|
struct spi_message *msg,
|
|
|
|
struct spi_transfer **xferp,
|
|
|
|
size_t maxsize,
|
|
|
|
gfp_t gfp)
|
2015-12-14 23:20:20 +08:00
|
|
|
{
|
|
|
|
struct spi_transfer *xfer = *xferp, *xfers;
|
|
|
|
struct spi_replaced_transfers *srt;
|
|
|
|
size_t offset;
|
|
|
|
size_t count, i;
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Calculate how many we have to replace */
|
2015-12-14 23:20:20 +08:00
|
|
|
count = DIV_ROUND_UP(xfer->len, maxsize);
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Create replacement */
|
2015-12-14 23:20:20 +08:00
|
|
|
srt = spi_replace_transfers(msg, xfer, 1, count, NULL, 0, gfp);
|
2016-02-12 14:38:33 +08:00
|
|
|
if (IS_ERR(srt))
|
|
|
|
return PTR_ERR(srt);
|
2015-12-14 23:20:20 +08:00
|
|
|
xfers = srt->inserted_transfers;
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* Now handle each of those newly inserted spi_transfers.
|
|
|
|
* Note that the replacements spi_transfers all are preset
|
2015-12-14 23:20:20 +08:00
|
|
|
* to the same values as *xferp, so tx_buf, rx_buf and len
|
|
|
|
* are all identical (as well as most others)
|
|
|
|
* so we just have to fix up len and the pointers.
|
|
|
|
*
|
2021-11-23 01:17:21 +08:00
|
|
|
* This also includes support for the depreciated
|
|
|
|
* spi_message.is_dma_mapped interface.
|
2015-12-14 23:20:20 +08:00
|
|
|
*/
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* The first transfer just needs the length modified, so we
|
|
|
|
* run it outside the loop.
|
2015-12-14 23:20:20 +08:00
|
|
|
*/
|
2016-02-18 01:42:28 +08:00
|
|
|
xfers[0].len = min_t(size_t, maxsize, xfer[0].len);
|
2015-12-14 23:20:20 +08:00
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* All the others need rx_buf/tx_buf also set */
|
2015-12-14 23:20:20 +08:00
|
|
|
for (i = 1, offset = maxsize; i < count; offset += maxsize, i++) {
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Update rx_buf, tx_buf and dma */
|
2015-12-14 23:20:20 +08:00
|
|
|
if (xfers[i].rx_buf)
|
|
|
|
xfers[i].rx_buf += offset;
|
|
|
|
if (xfers[i].rx_dma)
|
|
|
|
xfers[i].rx_dma += offset;
|
|
|
|
if (xfers[i].tx_buf)
|
|
|
|
xfers[i].tx_buf += offset;
|
|
|
|
if (xfers[i].tx_dma)
|
|
|
|
xfers[i].tx_dma += offset;
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Update length */
|
2015-12-14 23:20:20 +08:00
|
|
|
xfers[i].len = min(maxsize, xfers[i].len - offset);
|
|
|
|
}
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* We set up xferp to the last entry we have inserted,
|
|
|
|
* so that we skip those already split transfers.
|
2015-12-14 23:20:20 +08:00
|
|
|
*/
|
|
|
|
*xferp = &xfers[count - 1];
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Increment statistics counters */
|
2022-05-24 17:18:08 +08:00
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(ctlr->pcpu_statistics,
|
2015-12-14 23:20:20 +08:00
|
|
|
transfers_split_maxsize);
|
2022-05-24 17:18:08 +08:00
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(msg->spi->pcpu_statistics,
|
2015-12-14 23:20:20 +08:00
|
|
|
transfers_split_maxsize);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2020-10-24 00:33:16 +08:00
|
|
|
* spi_split_transfers_maxsize - split spi transfers into multiple transfers
|
|
|
|
* when an individual transfer exceeds a
|
|
|
|
* certain size
|
2017-06-13 19:23:52 +08:00
|
|
|
* @ctlr: the @spi_controller for this transfer
|
2016-02-22 19:33:44 +08:00
|
|
|
* @msg: the @spi_message to transform
|
|
|
|
* @maxsize: the maximum when to apply this
|
2016-03-11 02:01:14 +08:00
|
|
|
* @gfp: GFP allocation flags
|
2015-12-14 23:20:20 +08:00
|
|
|
*
|
|
|
|
* Return: status of transformation
|
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
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)
|
|
|
|
{
|
|
|
|
struct spi_transfer *xfer;
|
|
|
|
int ret;
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* Iterate over the transfer_list,
|
2015-12-14 23:20:20 +08:00
|
|
|
* but note that xfer is advanced to the last transfer inserted
|
|
|
|
* to avoid checking sizes again unnecessarily (also xfer does
|
2021-11-23 01:17:21 +08:00
|
|
|
* potentially belong to a different list by the time the
|
|
|
|
* replacement has happened).
|
2015-12-14 23:20:20 +08:00
|
|
|
*/
|
|
|
|
list_for_each_entry(xfer, &msg->transfers, transfer_list) {
|
|
|
|
if (xfer->len > maxsize) {
|
2017-06-13 19:23:52 +08:00
|
|
|
ret = __spi_split_transfer_maxsize(ctlr, msg, &xfer,
|
|
|
|
maxsize, gfp);
|
2015-12-14 23:20:20 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_split_transfers_maxsize);
|
[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
|
|
|
/* Core methods for SPI controller protocol drivers. Some of the
|
2009-06-18 07:26:03 +08:00
|
|
|
* other core methods are currently defined as inline functions.
|
|
|
|
*/
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static int __spi_validate_bits_per_word(struct spi_controller *ctlr,
|
|
|
|
u8 bits_per_word)
|
2015-08-23 22:06:30 +08:00
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->bits_per_word_mask) {
|
2015-08-23 22:06:30 +08:00
|
|
|
/* Only 32 bits fit in the mask */
|
|
|
|
if (bits_per_word > 32)
|
|
|
|
return -EINVAL;
|
2017-06-13 19:23:52 +08:00
|
|
|
if (!(ctlr->bits_per_word_mask & SPI_BPW_MASK(bits_per_word)))
|
2015-08-23 22:06:30 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-06-18 07:26:03 +08:00
|
|
|
/**
|
|
|
|
* spi_setup - setup SPI mode and clock rate
|
|
|
|
* @spi: the device whose settings are being modified
|
|
|
|
* Context: can sleep, and no requests are queued to the device
|
|
|
|
*
|
|
|
|
* SPI protocol drivers may need to update the transfer mode if the
|
|
|
|
* device doesn't work with its default. They may likewise need
|
|
|
|
* to update clock rates or word sizes from initial values. This function
|
|
|
|
* changes those settings, and must be called from a context that can sleep.
|
|
|
|
* Except for SPI_CS_HIGH, which takes effect immediately, the changes take
|
|
|
|
* effect the next time the device is selected and data is transferred to
|
|
|
|
* or from it. When this function returns, the spi device is deselected.
|
|
|
|
*
|
|
|
|
* Note that this call will fail if the protocol driver specifies an option
|
|
|
|
* that the underlying controller or its driver does not support. For
|
|
|
|
* example, not all hardware supports wire transfers using nine bit words,
|
|
|
|
* LSB-first wire encoding, or active-high chipselects.
|
2015-10-23 00:59:23 +08:00
|
|
|
*
|
|
|
|
* Return: zero on success, else a negative error code.
|
2009-06-18 07:26:03 +08:00
|
|
|
*/
|
|
|
|
int spi_setup(struct spi_device *spi)
|
|
|
|
{
|
2014-04-15 01:39:53 +08:00
|
|
|
unsigned bad_bits, ugly_bits;
|
2022-04-14 16:40:40 +08:00
|
|
|
int status = 0;
|
2009-06-18 07:26:03 +08:00
|
|
|
|
2020-12-21 23:29:35 +08:00
|
|
|
/*
|
2021-11-23 01:17:21 +08:00
|
|
|
* Check mode to prevent that any two of DUAL, QUAD and NO_MOSI/MISO
|
|
|
|
* are set at the same time.
|
2013-08-11 18:15:17 +08:00
|
|
|
*/
|
2020-12-21 23:29:35 +08:00
|
|
|
if ((hweight_long(spi->mode &
|
|
|
|
(SPI_TX_DUAL | SPI_TX_QUAD | SPI_NO_TX)) > 1) ||
|
|
|
|
(hweight_long(spi->mode &
|
|
|
|
(SPI_RX_DUAL | SPI_RX_QUAD | SPI_NO_RX)) > 1)) {
|
2013-08-11 18:15:17 +08:00
|
|
|
dev_err(&spi->dev,
|
2020-12-21 23:29:35 +08:00
|
|
|
"setup: can not select any two of dual, quad and no-rx/tx at the same time\n");
|
2013-08-11 18:15:17 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
2021-11-23 01:17:21 +08:00
|
|
|
/* If it is SPI_3WIRE mode, DUAL and QUAD should be forbidden */
|
2013-08-11 18:15:17 +08:00
|
|
|
if ((spi->mode & SPI_3WIRE) && (spi->mode &
|
2018-12-03 16:39:06 +08:00
|
|
|
(SPI_TX_DUAL | SPI_TX_QUAD | SPI_TX_OCTAL |
|
|
|
|
SPI_RX_DUAL | SPI_RX_QUAD | SPI_RX_OCTAL)))
|
2013-08-11 18:15:17 +08:00
|
|
|
return -EINVAL;
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* Help drivers fail *cleanly* when they need options
|
|
|
|
* that aren't supported with their current controller.
|
2018-09-13 08:39:18 +08:00
|
|
|
* SPI_CS_WORD has a fallback software implementation,
|
|
|
|
* so it is ignored here.
|
2009-06-18 07:26:04 +08:00
|
|
|
*/
|
2020-12-21 23:29:35 +08:00
|
|
|
bad_bits = spi->mode & ~(spi->controller->mode_bits | SPI_CS_WORD |
|
|
|
|
SPI_NO_TX | SPI_NO_RX);
|
2014-04-15 01:39:53 +08:00
|
|
|
ugly_bits = bad_bits &
|
2018-12-03 16:39:06 +08:00
|
|
|
(SPI_TX_DUAL | SPI_TX_QUAD | SPI_TX_OCTAL |
|
|
|
|
SPI_RX_DUAL | SPI_RX_QUAD | SPI_RX_OCTAL);
|
2014-04-15 01:39:53 +08:00
|
|
|
if (ugly_bits) {
|
|
|
|
dev_warn(&spi->dev,
|
|
|
|
"setup: ignoring unsupported mode bits %x\n",
|
|
|
|
ugly_bits);
|
|
|
|
spi->mode &= ~ugly_bits;
|
|
|
|
bad_bits &= ~ugly_bits;
|
|
|
|
}
|
2009-06-18 07:26:04 +08:00
|
|
|
if (bad_bits) {
|
2010-10-22 03:06:44 +08:00
|
|
|
dev_err(&spi->dev, "setup: unsupported mode bits %x\n",
|
2009-06-18 07:26:04 +08:00
|
|
|
bad_bits);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2022-04-12 20:22:07 +08:00
|
|
|
if (!spi->bits_per_word) {
|
2009-06-18 07:26:03 +08:00
|
|
|
spi->bits_per_word = 8;
|
2022-04-12 20:22:07 +08:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Some controllers may not support the default 8 bits-per-word
|
|
|
|
* so only perform the check when this is explicitly provided.
|
|
|
|
*/
|
|
|
|
status = __spi_validate_bits_per_word(spi->controller,
|
|
|
|
spi->bits_per_word);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
}
|
2015-08-23 22:06:30 +08:00
|
|
|
|
2020-12-16 17:23:21 +08:00
|
|
|
if (spi->controller->max_speed_hz &&
|
|
|
|
(!spi->max_speed_hz ||
|
|
|
|
spi->max_speed_hz > spi->controller->max_speed_hz))
|
2017-06-13 19:23:52 +08:00
|
|
|
spi->max_speed_hz = spi->controller->max_speed_hz;
|
2014-02-10 00:08:05 +08:00
|
|
|
|
spi: Take the SPI IO-mutex in the spi_setup() method
I've discovered that due to the recent commit 49d7d695ca4b ("spi: dw:
Explicitly de-assert CS on SPI transfer completion") a concurrent usage of
the spidev devices with different chip-selects causes the "SPI transfer
timed out" error. The root cause of the problem has turned to be in a race
condition of the SPI-transfer execution procedure and the spi_setup()
method being called at the same time. In particular in calling the
spi_set_cs(false) while there is an SPI-transfer being executed. In my
case due to the commit cited above all CSs get to be switched off by
calling the spi_setup() for /dev/spidev0.1 while there is an concurrent
SPI-transfer execution performed on /dev/spidev0.0. Of course a situation
of the spi_setup() being called while there is an SPI-transfer being
executed for two different SPI peripheral devices of the same controller
may happen not only for the spidev driver, but for instance for MMC SPI +
some another device, or spi_setup() being called from an SPI-peripheral
probe method while some other device has already been probed and is being
used by a corresponding driver...
Of course I could have provided a fix affecting the DW APB SSI driver
only, for instance, by creating a mutual exclusive access to the set_cs
callback and setting/clearing only the bit responsible for the
corresponding chip-select. But after a short research I've discovered that
the problem most likely affects a lot of the other drivers:
- drivers/spi/spi-sun4i.c - RMW the chip-select register;
- drivers/spi/spi-rockchip.c - RMW the chip-select register;
- drivers/spi/spi-qup.c - RMW a generic force-CS flag in a CSR.
- drivers/spi/spi-sifive.c - set a generic CS-mode flag in a CSR.
- drivers/spi/spi-bcm63xx-hsspi.c - uses an internal mutex to serialize
the bus config changes, but still isn't protected from the race
condition described above;
- drivers/spi/spi-geni-qcom.c - RMW a chip-select internal flag and set the
CS state in HW;
- drivers/spi/spi-orion.c - RMW a chip-select register;
- drivers/spi/spi-cadence.c - RMW a chip-select register;
- drivers/spi/spi-armada-3700.c - RMW a chip-select register;
- drivers/spi/spi-lantiq-ssc.c - overwrites the chip-select register;
- drivers/spi/spi-sun6i.c - RMW a chip-select register;
- drivers/spi/spi-synquacer.c - RMW a chip-select register;
- drivers/spi/spi-altera.c - directly sets the chip-select state;
- drivers/spi/spi-omap2-mcspi.c - RMW an internally cached CS state and
writes it to HW;
- drivers/spi/spi-mt65xx.c - RMW some CSR;
- drivers/spi/spi-jcore.c - directly sets the chip-selects state;
- drivers/spi/spi-mt7621.c - RMW a chip-select register;
I could have missed some drivers, but a scale of the problem is obvious.
As you can see most of the drivers perform an unprotected
Read-modify-write chip-select register modification in the set_cs callback.
Seeing the spi_setup() function is calling the spi_set_cs() and it can be
executed concurrently with SPI-transfers exec procedure, which also calls
spi_set_cs() in the SPI core spi_transfer_one_message() method, the race
condition of the register modification turns to be obvious.
To sum up the problem denoted above affects each driver for a controller
having more than one chip-select lane and which:
1) performs the RMW to some CS-related register with no serialization;
2) directly disables any CS on spi_set_cs(dev, false).
* the later is the case of the DW APB SSI driver.
The controllers which equipped with a single CS theoretically can also
experience the problem, but in practice will not since normally the
spi_setup() isn't called concurrently with the SPI-transfers executed on
the same SPI peripheral device.
In order to generically fix the denoted bug I'd suggest to serialize an
access to the controller IO by taking the IO mutex in the spi_setup()
callback. The mutex is held while there is an SPI communication going on
on the SPI-bus of the corresponding SPI-controller. So calling the
spi_setup() method and disabling/updating the CS state within it would be
safe while there is no any SPI-transfers being executed. Also note I
suppose it would be safer to protect the spi_controller->setup() callback
invocation too, seeing some of the SPI-controller drivers update a HW
state in there.
Fixes: 49d7d695ca4b ("spi: dw: Explicitly de-assert CS on SPI transfer completion")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201117094517.5654-1-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-17 17:45:17 +08:00
|
|
|
mutex_lock(&spi->controller->io_mutex);
|
|
|
|
|
2021-04-19 21:06:31 +08:00
|
|
|
if (spi->controller->setup) {
|
2017-06-13 19:23:52 +08:00
|
|
|
status = spi->controller->setup(spi);
|
2021-04-19 21:06:31 +08:00
|
|
|
if (status) {
|
|
|
|
mutex_unlock(&spi->controller->io_mutex);
|
|
|
|
dev_err(&spi->controller->dev, "Failed to setup device: %d\n",
|
|
|
|
status);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
}
|
2009-06-18 07:26:03 +08:00
|
|
|
|
2019-10-30 17:03:54 +08:00
|
|
|
if (spi->controller->auto_runtime_pm && spi->controller->set_cs) {
|
2022-04-18 19:02:26 +08:00
|
|
|
status = pm_runtime_resume_and_get(spi->controller->dev.parent);
|
2019-10-30 17:03:54 +08:00
|
|
|
if (status < 0) {
|
spi: Take the SPI IO-mutex in the spi_setup() method
I've discovered that due to the recent commit 49d7d695ca4b ("spi: dw:
Explicitly de-assert CS on SPI transfer completion") a concurrent usage of
the spidev devices with different chip-selects causes the "SPI transfer
timed out" error. The root cause of the problem has turned to be in a race
condition of the SPI-transfer execution procedure and the spi_setup()
method being called at the same time. In particular in calling the
spi_set_cs(false) while there is an SPI-transfer being executed. In my
case due to the commit cited above all CSs get to be switched off by
calling the spi_setup() for /dev/spidev0.1 while there is an concurrent
SPI-transfer execution performed on /dev/spidev0.0. Of course a situation
of the spi_setup() being called while there is an SPI-transfer being
executed for two different SPI peripheral devices of the same controller
may happen not only for the spidev driver, but for instance for MMC SPI +
some another device, or spi_setup() being called from an SPI-peripheral
probe method while some other device has already been probed and is being
used by a corresponding driver...
Of course I could have provided a fix affecting the DW APB SSI driver
only, for instance, by creating a mutual exclusive access to the set_cs
callback and setting/clearing only the bit responsible for the
corresponding chip-select. But after a short research I've discovered that
the problem most likely affects a lot of the other drivers:
- drivers/spi/spi-sun4i.c - RMW the chip-select register;
- drivers/spi/spi-rockchip.c - RMW the chip-select register;
- drivers/spi/spi-qup.c - RMW a generic force-CS flag in a CSR.
- drivers/spi/spi-sifive.c - set a generic CS-mode flag in a CSR.
- drivers/spi/spi-bcm63xx-hsspi.c - uses an internal mutex to serialize
the bus config changes, but still isn't protected from the race
condition described above;
- drivers/spi/spi-geni-qcom.c - RMW a chip-select internal flag and set the
CS state in HW;
- drivers/spi/spi-orion.c - RMW a chip-select register;
- drivers/spi/spi-cadence.c - RMW a chip-select register;
- drivers/spi/spi-armada-3700.c - RMW a chip-select register;
- drivers/spi/spi-lantiq-ssc.c - overwrites the chip-select register;
- drivers/spi/spi-sun6i.c - RMW a chip-select register;
- drivers/spi/spi-synquacer.c - RMW a chip-select register;
- drivers/spi/spi-altera.c - directly sets the chip-select state;
- drivers/spi/spi-omap2-mcspi.c - RMW an internally cached CS state and
writes it to HW;
- drivers/spi/spi-mt65xx.c - RMW some CSR;
- drivers/spi/spi-jcore.c - directly sets the chip-selects state;
- drivers/spi/spi-mt7621.c - RMW a chip-select register;
I could have missed some drivers, but a scale of the problem is obvious.
As you can see most of the drivers perform an unprotected
Read-modify-write chip-select register modification in the set_cs callback.
Seeing the spi_setup() function is calling the spi_set_cs() and it can be
executed concurrently with SPI-transfers exec procedure, which also calls
spi_set_cs() in the SPI core spi_transfer_one_message() method, the race
condition of the register modification turns to be obvious.
To sum up the problem denoted above affects each driver for a controller
having more than one chip-select lane and which:
1) performs the RMW to some CS-related register with no serialization;
2) directly disables any CS on spi_set_cs(dev, false).
* the later is the case of the DW APB SSI driver.
The controllers which equipped with a single CS theoretically can also
experience the problem, but in practice will not since normally the
spi_setup() isn't called concurrently with the SPI-transfers executed on
the same SPI peripheral device.
In order to generically fix the denoted bug I'd suggest to serialize an
access to the controller IO by taking the IO mutex in the spi_setup()
callback. The mutex is held while there is an SPI communication going on
on the SPI-bus of the corresponding SPI-controller. So calling the
spi_setup() method and disabling/updating the CS state within it would be
safe while there is no any SPI-transfers being executed. Also note I
suppose it would be safer to protect the spi_controller->setup() callback
invocation too, seeing some of the SPI-controller drivers update a HW
state in there.
Fixes: 49d7d695ca4b ("spi: dw: Explicitly de-assert CS on SPI transfer completion")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201117094517.5654-1-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-17 17:45:17 +08:00
|
|
|
mutex_unlock(&spi->controller->io_mutex);
|
2019-10-30 17:03:54 +08:00
|
|
|
dev_err(&spi->controller->dev, "Failed to power device: %d\n",
|
|
|
|
status);
|
|
|
|
return status;
|
|
|
|
}
|
2019-11-12 03:53:34 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We do not want to return positive value from pm_runtime_get,
|
|
|
|
* there are many instances of devices calling spi_setup() and
|
|
|
|
* checking for a non-zero return value instead of a negative
|
|
|
|
* return value.
|
|
|
|
*/
|
|
|
|
status = 0;
|
|
|
|
|
2021-04-17 03:59:56 +08:00
|
|
|
spi_set_cs(spi, false, true);
|
2019-10-30 17:03:54 +08:00
|
|
|
pm_runtime_mark_last_busy(spi->controller->dev.parent);
|
|
|
|
pm_runtime_put_autosuspend(spi->controller->dev.parent);
|
|
|
|
} else {
|
2021-04-17 03:59:56 +08:00
|
|
|
spi_set_cs(spi, false, true);
|
2019-10-30 17:03:54 +08:00
|
|
|
}
|
2015-10-16 23:29:03 +08:00
|
|
|
|
spi: Take the SPI IO-mutex in the spi_setup() method
I've discovered that due to the recent commit 49d7d695ca4b ("spi: dw:
Explicitly de-assert CS on SPI transfer completion") a concurrent usage of
the spidev devices with different chip-selects causes the "SPI transfer
timed out" error. The root cause of the problem has turned to be in a race
condition of the SPI-transfer execution procedure and the spi_setup()
method being called at the same time. In particular in calling the
spi_set_cs(false) while there is an SPI-transfer being executed. In my
case due to the commit cited above all CSs get to be switched off by
calling the spi_setup() for /dev/spidev0.1 while there is an concurrent
SPI-transfer execution performed on /dev/spidev0.0. Of course a situation
of the spi_setup() being called while there is an SPI-transfer being
executed for two different SPI peripheral devices of the same controller
may happen not only for the spidev driver, but for instance for MMC SPI +
some another device, or spi_setup() being called from an SPI-peripheral
probe method while some other device has already been probed and is being
used by a corresponding driver...
Of course I could have provided a fix affecting the DW APB SSI driver
only, for instance, by creating a mutual exclusive access to the set_cs
callback and setting/clearing only the bit responsible for the
corresponding chip-select. But after a short research I've discovered that
the problem most likely affects a lot of the other drivers:
- drivers/spi/spi-sun4i.c - RMW the chip-select register;
- drivers/spi/spi-rockchip.c - RMW the chip-select register;
- drivers/spi/spi-qup.c - RMW a generic force-CS flag in a CSR.
- drivers/spi/spi-sifive.c - set a generic CS-mode flag in a CSR.
- drivers/spi/spi-bcm63xx-hsspi.c - uses an internal mutex to serialize
the bus config changes, but still isn't protected from the race
condition described above;
- drivers/spi/spi-geni-qcom.c - RMW a chip-select internal flag and set the
CS state in HW;
- drivers/spi/spi-orion.c - RMW a chip-select register;
- drivers/spi/spi-cadence.c - RMW a chip-select register;
- drivers/spi/spi-armada-3700.c - RMW a chip-select register;
- drivers/spi/spi-lantiq-ssc.c - overwrites the chip-select register;
- drivers/spi/spi-sun6i.c - RMW a chip-select register;
- drivers/spi/spi-synquacer.c - RMW a chip-select register;
- drivers/spi/spi-altera.c - directly sets the chip-select state;
- drivers/spi/spi-omap2-mcspi.c - RMW an internally cached CS state and
writes it to HW;
- drivers/spi/spi-mt65xx.c - RMW some CSR;
- drivers/spi/spi-jcore.c - directly sets the chip-selects state;
- drivers/spi/spi-mt7621.c - RMW a chip-select register;
I could have missed some drivers, but a scale of the problem is obvious.
As you can see most of the drivers perform an unprotected
Read-modify-write chip-select register modification in the set_cs callback.
Seeing the spi_setup() function is calling the spi_set_cs() and it can be
executed concurrently with SPI-transfers exec procedure, which also calls
spi_set_cs() in the SPI core spi_transfer_one_message() method, the race
condition of the register modification turns to be obvious.
To sum up the problem denoted above affects each driver for a controller
having more than one chip-select lane and which:
1) performs the RMW to some CS-related register with no serialization;
2) directly disables any CS on spi_set_cs(dev, false).
* the later is the case of the DW APB SSI driver.
The controllers which equipped with a single CS theoretically can also
experience the problem, but in practice will not since normally the
spi_setup() isn't called concurrently with the SPI-transfers executed on
the same SPI peripheral device.
In order to generically fix the denoted bug I'd suggest to serialize an
access to the controller IO by taking the IO mutex in the spi_setup()
callback. The mutex is held while there is an SPI communication going on
on the SPI-bus of the corresponding SPI-controller. So calling the
spi_setup() method and disabling/updating the CS state within it would be
safe while there is no any SPI-transfers being executed. Also note I
suppose it would be safer to protect the spi_controller->setup() callback
invocation too, seeing some of the SPI-controller drivers update a HW
state in there.
Fixes: 49d7d695ca4b ("spi: dw: Explicitly de-assert CS on SPI transfer completion")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201117094517.5654-1-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-17 17:45:17 +08:00
|
|
|
mutex_unlock(&spi->controller->io_mutex);
|
|
|
|
|
2019-05-16 00:48:12 +08:00
|
|
|
if (spi->rt && !spi->controller->rt) {
|
|
|
|
spi->controller->rt = true;
|
|
|
|
spi_set_thread_rt(spi->controller);
|
|
|
|
}
|
|
|
|
|
2021-05-27 03:56:55 +08:00
|
|
|
trace_spi_setup(spi, status);
|
|
|
|
|
2021-05-10 21:12:11 +08:00
|
|
|
dev_dbg(&spi->dev, "setup mode %lu, %s%s%s%s%u bits/w, %u Hz max --> %d\n",
|
|
|
|
spi->mode & SPI_MODE_X_MASK,
|
2009-06-18 07:26:03 +08:00
|
|
|
(spi->mode & SPI_CS_HIGH) ? "cs_high, " : "",
|
|
|
|
(spi->mode & SPI_LSB_FIRST) ? "lsb, " : "",
|
|
|
|
(spi->mode & SPI_3WIRE) ? "3wire, " : "",
|
|
|
|
(spi->mode & SPI_LOOP) ? "loopback, " : "",
|
|
|
|
spi->bits_per_word, spi->max_speed_hz,
|
|
|
|
status);
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_setup);
|
|
|
|
|
2019-09-26 18:51:35 +08:00
|
|
|
static int _spi_xfer_word_delay_update(struct spi_transfer *xfer,
|
|
|
|
struct spi_device *spi)
|
|
|
|
{
|
|
|
|
int delay1, delay2;
|
|
|
|
|
2019-09-26 18:51:44 +08:00
|
|
|
delay1 = spi_delay_to_ns(&xfer->word_delay, xfer);
|
2019-09-26 18:51:35 +08:00
|
|
|
if (delay1 < 0)
|
|
|
|
return delay1;
|
|
|
|
|
2019-09-26 18:51:44 +08:00
|
|
|
delay2 = spi_delay_to_ns(&spi->word_delay, xfer);
|
2019-09-26 18:51:35 +08:00
|
|
|
if (delay2 < 0)
|
|
|
|
return delay2;
|
|
|
|
|
|
|
|
if (delay1 < delay2)
|
|
|
|
memcpy(&xfer->word_delay, &spi->word_delay,
|
|
|
|
sizeof(xfer->word_delay));
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-11-14 07:44:15 +08:00
|
|
|
static int __spi_validate(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
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = spi->controller;
|
2012-11-09 17:06:45 +08:00
|
|
|
struct spi_transfer *xfer;
|
2014-02-28 22:03:16 +08:00
|
|
|
int w_size;
|
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
|
|
|
|
2013-07-10 22:05:40 +08:00
|
|
|
if (list_empty(&message->transfers))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* If an SPI controller does not support toggling the CS line on each
|
2018-09-19 01:08:48 +08:00
|
|
|
* transfer (indicated by the SPI_CS_WORD flag) or we are using a GPIO
|
|
|
|
* for the CS line, we can emulate the CS-per-word hardware function by
|
2018-09-13 08:39:18 +08:00
|
|
|
* splitting transfers into one-word transfers and ensuring that
|
|
|
|
* cs_change is set for each transfer.
|
|
|
|
*/
|
2018-09-19 01:08:48 +08:00
|
|
|
if ((spi->mode & SPI_CS_WORD) && (!(ctlr->mode_bits & SPI_CS_WORD) ||
|
2022-02-11 07:19:54 +08:00
|
|
|
spi->cs_gpiod)) {
|
2018-09-13 08:39:18 +08:00
|
|
|
size_t maxsize;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
maxsize = (spi->bits_per_word + 7) / 8;
|
|
|
|
|
|
|
|
/* spi_split_transfers_maxsize() requires message->spi */
|
|
|
|
message->spi = spi;
|
|
|
|
|
|
|
|
ret = spi_split_transfers_maxsize(ctlr, message, maxsize,
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
list_for_each_entry(xfer, &message->transfers, transfer_list) {
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Don't change cs_change on the last entry in the list */
|
2018-09-13 08:39:18 +08:00
|
|
|
if (list_is_last(&xfer->transfer_list, &message->transfers))
|
|
|
|
break;
|
|
|
|
xfer->cs_change = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* Half-duplex links include original MicroWire, and ones with
|
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
|
|
|
* only one data pin like SPI_3WIRE (switches direction) or where
|
|
|
|
* either MOSI or MISO is missing. They can also be caused by
|
|
|
|
* software limitations.
|
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
if ((ctlr->flags & SPI_CONTROLLER_HALF_DUPLEX) ||
|
|
|
|
(spi->mode & SPI_3WIRE)) {
|
|
|
|
unsigned flags = ctlr->flags;
|
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
|
|
|
|
|
|
|
list_for_each_entry(xfer, &message->transfers, transfer_list) {
|
|
|
|
if (xfer->rx_buf && xfer->tx_buf)
|
|
|
|
return -EINVAL;
|
2017-06-13 19:23:52 +08:00
|
|
|
if ((flags & SPI_CONTROLLER_NO_TX) && xfer->tx_buf)
|
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
|
|
|
return -EINVAL;
|
2017-06-13 19:23:52 +08:00
|
|
|
if ((flags & SPI_CONTROLLER_NO_RX) && xfer->rx_buf)
|
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
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
2013-01-05 02:47:14 +08:00
|
|
|
* Set transfer bits_per_word and max speed as spi device default if
|
|
|
|
* it is not set for this transfer.
|
2013-08-11 18:15:17 +08:00
|
|
|
* Set transfer tx_nbits and rx_nbits as single transfer default
|
|
|
|
* (SPI_NBITS_SINGLE) if it is not set for this transfer.
|
2019-01-30 16:40:04 +08:00
|
|
|
* Ensure transfer word_delay is at least as long as that required by
|
|
|
|
* device itself.
|
2012-11-09 17:06:45 +08:00
|
|
|
*/
|
2015-11-27 20:31:09 +08:00
|
|
|
message->frame_length = 0;
|
2012-11-09 17:06:45 +08:00
|
|
|
list_for_each_entry(xfer, &message->transfers, transfer_list) {
|
2019-02-23 16:49:49 +08:00
|
|
|
xfer->effective_speed_hz = 0;
|
2013-07-18 18:01:25 +08:00
|
|
|
message->frame_length += xfer->len;
|
2012-11-09 17:06:45 +08:00
|
|
|
if (!xfer->bits_per_word)
|
|
|
|
xfer->bits_per_word = spi->bits_per_word;
|
2014-03-17 10:08:12 +08:00
|
|
|
|
|
|
|
if (!xfer->speed_hz)
|
2013-01-05 02:47:14 +08:00
|
|
|
xfer->speed_hz = spi->max_speed_hz;
|
2014-03-17 10:08:12 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->max_speed_hz && xfer->speed_hz > ctlr->max_speed_hz)
|
|
|
|
xfer->speed_hz = ctlr->max_speed_hz;
|
2013-08-14 16:25:28 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (__spi_validate_bits_per_word(ctlr, xfer->bits_per_word))
|
2015-08-23 22:06:30 +08:00
|
|
|
return -EINVAL;
|
2013-07-10 21:57:26 +08:00
|
|
|
|
2014-02-20 18:02:08 +08:00
|
|
|
/*
|
|
|
|
* SPI transfer length should be multiple of SPI word size
|
2021-11-23 01:17:21 +08:00
|
|
|
* where SPI word size should be power-of-two multiple.
|
2014-02-20 18:02:08 +08:00
|
|
|
*/
|
|
|
|
if (xfer->bits_per_word <= 8)
|
|
|
|
w_size = 1;
|
|
|
|
else if (xfer->bits_per_word <= 16)
|
|
|
|
w_size = 2;
|
|
|
|
else
|
|
|
|
w_size = 4;
|
|
|
|
|
|
|
|
/* No partial transfers accepted */
|
2014-02-28 22:03:16 +08:00
|
|
|
if (xfer->len % w_size)
|
2014-02-20 18:02:08 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (xfer->speed_hz && ctlr->min_speed_hz &&
|
|
|
|
xfer->speed_hz < ctlr->min_speed_hz)
|
2013-07-10 21:57:26 +08:00
|
|
|
return -EINVAL;
|
2013-08-11 18:15:17 +08:00
|
|
|
|
|
|
|
if (xfer->tx_buf && !xfer->tx_nbits)
|
|
|
|
xfer->tx_nbits = SPI_NBITS_SINGLE;
|
|
|
|
if (xfer->rx_buf && !xfer->rx_nbits)
|
|
|
|
xfer->rx_nbits = SPI_NBITS_SINGLE;
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* Check transfer tx/rx_nbits:
|
2014-01-12 21:00:29 +08:00
|
|
|
* 1. check the value matches one of single, dual and quad
|
|
|
|
* 2. check tx/rx_nbits match the mode in spi_device
|
2013-08-11 18:15:17 +08:00
|
|
|
*/
|
2013-08-22 23:50:48 +08:00
|
|
|
if (xfer->tx_buf) {
|
2020-12-21 23:29:35 +08:00
|
|
|
if (spi->mode & SPI_NO_TX)
|
|
|
|
return -EINVAL;
|
2013-08-22 23:50:48 +08:00
|
|
|
if (xfer->tx_nbits != SPI_NBITS_SINGLE &&
|
|
|
|
xfer->tx_nbits != SPI_NBITS_DUAL &&
|
|
|
|
xfer->tx_nbits != SPI_NBITS_QUAD)
|
|
|
|
return -EINVAL;
|
|
|
|
if ((xfer->tx_nbits == SPI_NBITS_DUAL) &&
|
|
|
|
!(spi->mode & (SPI_TX_DUAL | SPI_TX_QUAD)))
|
|
|
|
return -EINVAL;
|
|
|
|
if ((xfer->tx_nbits == SPI_NBITS_QUAD) &&
|
|
|
|
!(spi->mode & SPI_TX_QUAD))
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Check transfer rx_nbits */
|
2013-08-22 23:50:48 +08:00
|
|
|
if (xfer->rx_buf) {
|
2020-12-21 23:29:35 +08:00
|
|
|
if (spi->mode & SPI_NO_RX)
|
|
|
|
return -EINVAL;
|
2013-08-22 23:50:48 +08:00
|
|
|
if (xfer->rx_nbits != SPI_NBITS_SINGLE &&
|
|
|
|
xfer->rx_nbits != SPI_NBITS_DUAL &&
|
|
|
|
xfer->rx_nbits != SPI_NBITS_QUAD)
|
|
|
|
return -EINVAL;
|
|
|
|
if ((xfer->rx_nbits == SPI_NBITS_DUAL) &&
|
|
|
|
!(spi->mode & (SPI_RX_DUAL | SPI_RX_QUAD)))
|
|
|
|
return -EINVAL;
|
|
|
|
if ((xfer->rx_nbits == SPI_NBITS_QUAD) &&
|
|
|
|
!(spi->mode & SPI_RX_QUAD))
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2019-01-30 16:40:04 +08:00
|
|
|
|
2019-09-26 18:51:35 +08:00
|
|
|
if (_spi_xfer_word_delay_update(xfer, spi))
|
|
|
|
return -EINVAL;
|
2012-11-09 17:06:45 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
message->status = -EINPROGRESS;
|
2013-11-14 07:44:15 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __spi_async(struct spi_device *spi, struct spi_message *message)
|
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = spi->controller;
|
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
|
|
|
struct spi_transfer *xfer;
|
2013-11-14 07:44:15 +08:00
|
|
|
|
2018-04-27 00:18:15 +08:00
|
|
|
/*
|
|
|
|
* Some controllers do not support doing regular SPI transfers. Return
|
|
|
|
* ENOTSUPP when this is the case.
|
|
|
|
*/
|
|
|
|
if (!ctlr->transfer)
|
|
|
|
return -ENOTSUPP;
|
|
|
|
|
2013-11-14 07:44:15 +08:00
|
|
|
message->spi = spi;
|
|
|
|
|
2022-05-24 17:18:08 +08:00
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(ctlr->pcpu_statistics, spi_async);
|
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(spi->pcpu_statistics, spi_async);
|
2015-06-22 21:00:36 +08:00
|
|
|
|
2013-11-14 07:44:15 +08:00
|
|
|
trace_spi_message_submit(message);
|
|
|
|
|
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
|
|
|
if (!ctlr->ptp_sts_supported) {
|
|
|
|
list_for_each_entry(xfer, &message->transfers, transfer_list) {
|
|
|
|
xfer->ptp_sts_word_pre = 0;
|
|
|
|
ptp_read_system_prets(xfer->ptp_sts);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
return ctlr->transfer(spi, 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
|
|
|
}
|
|
|
|
|
2009-09-23 07:46:18 +08:00
|
|
|
/**
|
|
|
|
* spi_async - asynchronous SPI transfer
|
|
|
|
* @spi: device with which data will be exchanged
|
|
|
|
* @message: describes the data transfers, including completion callback
|
|
|
|
* Context: any (irqs may be blocked, etc)
|
|
|
|
*
|
|
|
|
* This call may be used in_irq and other contexts which can't sleep,
|
|
|
|
* as well as from task contexts which can sleep.
|
|
|
|
*
|
|
|
|
* The completion callback is invoked in a context which can't sleep.
|
|
|
|
* Before that invocation, the value of message->status is undefined.
|
|
|
|
* When the callback is issued, message->status holds either zero (to
|
|
|
|
* indicate complete success) or a negative error code. After that
|
|
|
|
* callback returns, the driver which issued the transfer request may
|
|
|
|
* deallocate the associated memory; it's no longer in use by any SPI
|
|
|
|
* core or controller driver code.
|
|
|
|
*
|
|
|
|
* Note that although all messages to a spi_device are handled in
|
|
|
|
* FIFO order, messages may go to different devices in other orders.
|
|
|
|
* Some device might be higher priority, or have various "hard" access
|
|
|
|
* time requirements, for example.
|
|
|
|
*
|
|
|
|
* On detection of any fault during the transfer, processing of
|
|
|
|
* the entire message is aborted, and the device is deselected.
|
|
|
|
* Until returning from the associated message completion callback,
|
|
|
|
* no other spi_message queued to that device will be processed.
|
|
|
|
* (This rule applies equally to all the synchronous transfer calls,
|
|
|
|
* which are wrappers around this core asynchronous primitive.)
|
2015-10-23 00:59:23 +08:00
|
|
|
*
|
|
|
|
* Return: zero on success, else a negative error code.
|
2009-09-23 07:46:18 +08:00
|
|
|
*/
|
|
|
|
int spi_async(struct spi_device *spi, struct spi_message *message)
|
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = spi->controller;
|
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
|
|
|
int ret;
|
|
|
|
unsigned long flags;
|
2009-09-23 07:46:18 +08:00
|
|
|
|
2013-11-14 07:44:15 +08:00
|
|
|
ret = __spi_validate(spi, message);
|
|
|
|
if (ret != 0)
|
|
|
|
return ret;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_lock_irqsave(&ctlr->bus_lock_spinlock, flags);
|
2009-09-23 07:46:18 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
if (ctlr->bus_lock_flag)
|
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
|
|
|
ret = -EBUSY;
|
|
|
|
else
|
|
|
|
ret = __spi_async(spi, message);
|
2009-09-23 07:46:18 +08:00
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_unlock_irqrestore(&ctlr->bus_lock_spinlock, flags);
|
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
|
|
|
|
|
|
|
return ret;
|
2009-09-23 07:46:18 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_async);
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* spi_async_locked - version of spi_async with exclusive bus usage
|
|
|
|
* @spi: device with which data will be exchanged
|
|
|
|
* @message: describes the data transfers, including completion callback
|
|
|
|
* Context: any (irqs may be blocked, etc)
|
|
|
|
*
|
|
|
|
* This call may be used in_irq and other contexts which can't sleep,
|
|
|
|
* as well as from task contexts which can sleep.
|
|
|
|
*
|
|
|
|
* The completion callback is invoked in a context which can't sleep.
|
|
|
|
* Before that invocation, the value of message->status is undefined.
|
|
|
|
* When the callback is issued, message->status holds either zero (to
|
|
|
|
* indicate complete success) or a negative error code. After that
|
|
|
|
* callback returns, the driver which issued the transfer request may
|
|
|
|
* deallocate the associated memory; it's no longer in use by any SPI
|
|
|
|
* core or controller driver code.
|
|
|
|
*
|
|
|
|
* Note that although all messages to a spi_device are handled in
|
|
|
|
* FIFO order, messages may go to different devices in other orders.
|
|
|
|
* Some device might be higher priority, or have various "hard" access
|
|
|
|
* time requirements, for example.
|
|
|
|
*
|
|
|
|
* On detection of any fault during the transfer, processing of
|
|
|
|
* the entire message is aborted, and the device is deselected.
|
|
|
|
* Until returning from the associated message completion callback,
|
|
|
|
* no other spi_message queued to that device will be processed.
|
|
|
|
* (This rule applies equally to all the synchronous transfer calls,
|
|
|
|
* which are wrappers around this core asynchronous primitive.)
|
2015-10-23 00:59:23 +08:00
|
|
|
*
|
|
|
|
* Return: zero on success, else a negative error code.
|
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
|
|
|
*/
|
2021-10-07 20:14:15 +08:00
|
|
|
static int spi_async_locked(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
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = spi->controller;
|
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
|
|
|
int ret;
|
|
|
|
unsigned long flags;
|
|
|
|
|
2013-11-14 07:44:15 +08:00
|
|
|
ret = __spi_validate(spi, message);
|
|
|
|
if (ret != 0)
|
|
|
|
return ret;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_lock_irqsave(&ctlr->bus_lock_spinlock, flags);
|
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
|
|
|
|
|
|
|
ret = __spi_async(spi, message);
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_unlock_irqrestore(&ctlr->bus_lock_spinlock, flags);
|
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
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2022-06-21 14:12:25 +08:00
|
|
|
static void __spi_transfer_message_noqueue(struct spi_controller *ctlr, struct spi_message *msg)
|
|
|
|
{
|
|
|
|
bool was_busy;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&ctlr->io_mutex);
|
|
|
|
|
2022-06-21 14:12:31 +08:00
|
|
|
was_busy = ctlr->busy;
|
2022-06-21 14:12:25 +08:00
|
|
|
|
2022-06-21 14:12:32 +08:00
|
|
|
ctlr->cur_msg = msg;
|
2022-06-21 14:12:25 +08:00
|
|
|
ret = __spi_pump_transfer_message(ctlr, msg, was_busy);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
|
2022-06-21 14:12:33 +08:00
|
|
|
ctlr->cur_msg = NULL;
|
|
|
|
ctlr->fallback = false;
|
|
|
|
|
2022-06-21 14:12:25 +08:00
|
|
|
if (!was_busy) {
|
|
|
|
kfree(ctlr->dummy_rx);
|
|
|
|
ctlr->dummy_rx = NULL;
|
|
|
|
kfree(ctlr->dummy_tx);
|
|
|
|
ctlr->dummy_tx = NULL;
|
|
|
|
if (ctlr->unprepare_transfer_hardware &&
|
|
|
|
ctlr->unprepare_transfer_hardware(ctlr))
|
|
|
|
dev_err(&ctlr->dev,
|
|
|
|
"failed to unprepare transfer hardware\n");
|
|
|
|
spi_idle_runtime_pm(ctlr);
|
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
mutex_unlock(&ctlr->io_mutex);
|
|
|
|
}
|
|
|
|
|
2009-06-18 07:26:03 +08:00
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* Utility methods for SPI protocol drivers, layered on
|
2009-06-18 07:26:03 +08:00
|
|
|
* top of the core. Some other utility methods are defined as
|
|
|
|
* inline functions.
|
|
|
|
*/
|
|
|
|
|
2006-01-12 03:23:49 +08:00
|
|
|
static void spi_complete(void *arg)
|
|
|
|
{
|
|
|
|
complete(arg);
|
|
|
|
}
|
|
|
|
|
2016-07-22 06:53:31 +08:00
|
|
|
static 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
|
|
|
{
|
|
|
|
DECLARE_COMPLETION_ONSTACK(done);
|
|
|
|
int status;
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr = spi->controller;
|
2014-12-10 05:38:05 +08:00
|
|
|
|
|
|
|
status = __spi_validate(spi, message);
|
|
|
|
if (status != 0)
|
|
|
|
return status;
|
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
|
|
|
|
2014-12-10 05:38:05 +08:00
|
|
|
message->spi = spi;
|
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
|
|
|
|
2022-05-24 17:18:08 +08:00
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(ctlr->pcpu_statistics, spi_sync);
|
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(spi->pcpu_statistics, spi_sync);
|
2015-06-22 21:00:36 +08:00
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
2022-06-21 14:12:25 +08:00
|
|
|
* Checking queue_empty here only guarantees async/sync message
|
|
|
|
* ordering when coming from the same context. It does not need to
|
|
|
|
* guard against reentrancy from a different context. The io_mutex
|
|
|
|
* will catch those cases.
|
2014-12-10 05:38:05 +08:00
|
|
|
*/
|
2022-06-21 14:12:25 +08:00
|
|
|
if (READ_ONCE(ctlr->queue_empty)) {
|
|
|
|
message->actual_length = 0;
|
|
|
|
message->status = -EINPROGRESS;
|
2014-12-10 05:38:05 +08:00
|
|
|
|
|
|
|
trace_spi_message_submit(message);
|
|
|
|
|
2022-06-21 14:12:25 +08:00
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(ctlr->pcpu_statistics, spi_sync_immediate);
|
|
|
|
SPI_STATISTICS_INCREMENT_FIELD(spi->pcpu_statistics, spi_sync_immediate);
|
2014-12-10 05:38:05 +08:00
|
|
|
|
2022-06-21 14:12:25 +08:00
|
|
|
__spi_transfer_message_noqueue(ctlr, message);
|
|
|
|
|
|
|
|
return message->status;
|
2014-12-10 05:38:05 +08:00
|
|
|
}
|
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
|
|
|
|
2022-06-21 14:12:25 +08:00
|
|
|
/*
|
|
|
|
* There are messages in the async queue that could have originated
|
|
|
|
* from the same context, so we need to preserve ordering.
|
|
|
|
* Therefor we send the message to the async queue and wait until they
|
|
|
|
* are completed.
|
|
|
|
*/
|
|
|
|
message->complete = spi_complete;
|
|
|
|
message->context = &done;
|
|
|
|
status = spi_async_locked(spi, 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
|
|
|
if (status == 0) {
|
|
|
|
wait_for_completion(&done);
|
|
|
|
status = message->status;
|
|
|
|
}
|
|
|
|
message->context = NULL;
|
2022-06-21 14:12:25 +08:00
|
|
|
|
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
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
[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_sync - blocking/synchronous SPI data transfers
|
|
|
|
* @spi: device with which data will be exchanged
|
|
|
|
* @message: describes the data transfers
|
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
|
|
|
*
|
|
|
|
* This call may only be used from a context that may sleep. The sleep
|
|
|
|
* is non-interruptible, and has no timeout. Low-overhead controller
|
|
|
|
* drivers may DMA directly into and out of the message buffers.
|
|
|
|
*
|
|
|
|
* Note that the SPI device's chip select is active during the message,
|
|
|
|
* and then is normally disabled between messages. Drivers for some
|
|
|
|
* frequently-used devices may want to minimize costs of selecting a chip,
|
|
|
|
* by leaving it selected in anticipation that the next message will go
|
|
|
|
* to the same chip. (That may increase power usage.)
|
|
|
|
*
|
2006-01-09 05:34:25 +08:00
|
|
|
* Also, the caller is guaranteeing that the memory associated with the
|
|
|
|
* message will not be freed before this call returns.
|
|
|
|
*
|
2015-10-23 00:59:23 +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
|
|
|
*/
|
|
|
|
int spi_sync(struct spi_device *spi, struct spi_message *message)
|
|
|
|
{
|
2016-07-22 06:53:31 +08:00
|
|
|
int ret;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
mutex_lock(&spi->controller->bus_lock_mutex);
|
2016-07-22 06:53:31 +08:00
|
|
|
ret = __spi_sync(spi, message);
|
2017-06-13 19:23:52 +08:00
|
|
|
mutex_unlock(&spi->controller->bus_lock_mutex);
|
2016-07-22 06:53:31 +08:00
|
|
|
|
|
|
|
return ret;
|
[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
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_sync);
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* spi_sync_locked - version of spi_sync with exclusive bus usage
|
|
|
|
* @spi: device with which data will be exchanged
|
|
|
|
* @message: describes the data transfers
|
|
|
|
* Context: can sleep
|
|
|
|
*
|
|
|
|
* This call may only be used from a context that may sleep. The sleep
|
|
|
|
* is non-interruptible, and has no timeout. Low-overhead controller
|
|
|
|
* drivers may DMA directly into and out of the message buffers.
|
|
|
|
*
|
|
|
|
* This call should be used by drivers that require exclusive access to the
|
2011-03-31 09:57:33 +08:00
|
|
|
* SPI bus. It has to be preceded by a spi_bus_lock call. The SPI bus must
|
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
|
|
|
* be released by a spi_bus_unlock call when the exclusive access is over.
|
|
|
|
*
|
2015-10-23 00:59:23 +08:00
|
|
|
* Return: zero on success, else a negative error code.
|
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
|
|
|
*/
|
|
|
|
int spi_sync_locked(struct spi_device *spi, struct spi_message *message)
|
|
|
|
{
|
2016-07-22 06:53:31 +08:00
|
|
|
return __spi_sync(spi, 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
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_sync_locked);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* spi_bus_lock - obtain a lock for exclusive SPI bus usage
|
2017-06-13 19:23:52 +08:00
|
|
|
* @ctlr: SPI bus master that should be locked for exclusive bus access
|
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
|
|
|
* Context: can sleep
|
|
|
|
*
|
|
|
|
* This call may only be used from a context that may sleep. The sleep
|
|
|
|
* is non-interruptible, and has no timeout.
|
|
|
|
*
|
|
|
|
* This call should be used by drivers that require exclusive access to the
|
|
|
|
* SPI bus. The SPI bus must be released by a spi_bus_unlock call when the
|
|
|
|
* exclusive access is over. Data transfer must be done by spi_sync_locked
|
|
|
|
* and spi_async_locked calls when the SPI bus lock is held.
|
|
|
|
*
|
2015-10-23 00:59:23 +08:00
|
|
|
* Return: always zero.
|
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
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
int spi_bus_lock(struct spi_controller *ctlr)
|
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
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
mutex_lock(&ctlr->bus_lock_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
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spin_lock_irqsave(&ctlr->bus_lock_spinlock, flags);
|
|
|
|
ctlr->bus_lock_flag = 1;
|
|
|
|
spin_unlock_irqrestore(&ctlr->bus_lock_spinlock, flags);
|
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
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Mutex remains locked until spi_bus_unlock() is called */
|
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
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_bus_lock);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* spi_bus_unlock - release the lock for exclusive SPI bus usage
|
2017-06-13 19:23:52 +08:00
|
|
|
* @ctlr: SPI bus master that was locked for exclusive bus access
|
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
|
|
|
* Context: can sleep
|
|
|
|
*
|
|
|
|
* This call may only be used from a context that may sleep. The sleep
|
|
|
|
* is non-interruptible, and has no timeout.
|
|
|
|
*
|
|
|
|
* This call releases an SPI bus lock previously obtained by an spi_bus_lock
|
|
|
|
* call.
|
|
|
|
*
|
2015-10-23 00:59:23 +08:00
|
|
|
* Return: always zero.
|
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
|
|
|
*/
|
2017-06-13 19:23:52 +08:00
|
|
|
int spi_bus_unlock(struct spi_controller *ctlr)
|
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
|
|
|
{
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr->bus_lock_flag = 0;
|
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
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
mutex_unlock(&ctlr->bus_lock_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
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_bus_unlock);
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Portable code must never pass more than 32 bytes */
|
2013-10-14 09:31:51 +08:00
|
|
|
#define SPI_BUFSIZ max(32, SMP_CACHE_BYTES)
|
[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 u8 *buf;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* spi_write_then_read - SPI synchronous write followed by read
|
|
|
|
* @spi: device with which data will be exchanged
|
|
|
|
* @txbuf: data to be written (need not be dma-safe)
|
|
|
|
* @n_tx: size of txbuf, in bytes
|
2009-06-18 07:26:06 +08:00
|
|
|
* @rxbuf: buffer into which data will be read (need not be dma-safe)
|
|
|
|
* @n_rx: size of rxbuf, in bytes
|
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
|
|
|
*
|
|
|
|
* This performs a half duplex MicroWire style transaction with the
|
|
|
|
* device, sending txbuf and then reading rxbuf. The return value
|
|
|
|
* is zero for success, else a negative errno status code.
|
2006-01-09 05:34:23 +08:00
|
|
|
* This call may only be used from a context that may 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
|
|
|
*
|
2020-05-25 21:31:20 +08:00
|
|
|
* Parameters to this routine are always copied using a small buffer.
|
2007-05-08 15:32:21 +08:00
|
|
|
* Performance-sensitive or bulk transfer code should instead use
|
2006-01-09 05:34:25 +08:00
|
|
|
* spi_{async,sync}() calls with dma-safe buffers.
|
2015-10-23 00:59:23 +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
|
|
|
*/
|
|
|
|
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
|
|
|
{
|
2007-12-05 15:45:09 +08:00
|
|
|
static DEFINE_MUTEX(lock);
|
[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 status;
|
|
|
|
struct spi_message message;
|
2009-04-14 05:39:57 +08:00
|
|
|
struct spi_transfer x[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
|
|
|
u8 *local_buf;
|
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* Use preallocated DMA-safe buffer if we can. We can't avoid
|
2012-12-02 11:54:25 +08:00
|
|
|
* copying here, (as a pure convenience thing), but we can
|
|
|
|
* keep heap costs out of the hot path unless someone else is
|
|
|
|
* using the pre-allocated buffer or the transfer is too large.
|
[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
|
|
|
*/
|
2012-12-02 11:54:25 +08:00
|
|
|
if ((n_tx + n_rx) > SPI_BUFSIZ || !mutex_trylock(&lock)) {
|
2013-01-27 14:35:04 +08:00
|
|
|
local_buf = kmalloc(max((unsigned)SPI_BUFSIZ, n_tx + n_rx),
|
|
|
|
GFP_KERNEL | GFP_DMA);
|
2012-12-02 11:54:25 +08:00
|
|
|
if (!local_buf)
|
|
|
|
return -ENOMEM;
|
|
|
|
} else {
|
|
|
|
local_buf = 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
|
|
|
|
2006-01-09 05:34:28 +08:00
|
|
|
spi_message_init(&message);
|
2013-10-14 09:31:51 +08:00
|
|
|
memset(x, 0, sizeof(x));
|
2009-04-14 05:39:57 +08:00
|
|
|
if (n_tx) {
|
|
|
|
x[0].len = n_tx;
|
|
|
|
spi_message_add_tail(&x[0], &message);
|
|
|
|
}
|
|
|
|
if (n_rx) {
|
|
|
|
x[1].len = n_rx;
|
|
|
|
spi_message_add_tail(&x[1], &message);
|
|
|
|
}
|
2006-01-09 05:34:28 +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
|
|
|
memcpy(local_buf, txbuf, n_tx);
|
2009-04-14 05:39:57 +08:00
|
|
|
x[0].tx_buf = local_buf;
|
|
|
|
x[1].rx_buf = local_buf + n_tx;
|
[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
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Do the i/o */
|
[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 = spi_sync(spi, &message);
|
2007-12-05 15:45:10 +08:00
|
|
|
if (status == 0)
|
2009-04-14 05:39:57 +08:00
|
|
|
memcpy(rxbuf, x[1].rx_buf, 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
|
|
|
|
2009-04-14 05:39:57 +08:00
|
|
|
if (x[0].tx_buf == buf)
|
2007-12-05 15:45:09 +08:00
|
|
|
mutex_unlock(&lock);
|
[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
|
|
|
else
|
|
|
|
kfree(local_buf);
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(spi_write_then_read);
|
|
|
|
|
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
2021-10-07 20:14:15 +08:00
|
|
|
#if IS_ENABLED(CONFIG_OF_DYNAMIC)
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Must call put_device() when done with returned spi_device device */
|
2021-10-07 20:14:15 +08:00
|
|
|
static struct spi_device *of_find_spi_device_by_node(struct device_node *node)
|
2014-10-29 04:36:05 +08:00
|
|
|
{
|
2019-07-24 06:18:33 +08:00
|
|
|
struct device *dev = bus_find_device_by_of_node(&spi_bus_type, node);
|
|
|
|
|
2014-10-29 04:36:05 +08:00
|
|
|
return dev ? to_spi_device(dev) : NULL;
|
|
|
|
}
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* The spi controllers are not using spi_bus, so we find it with another way */
|
2017-06-13 19:23:52 +08:00
|
|
|
static struct spi_controller *of_find_spi_controller_by_node(struct device_node *node)
|
2014-10-29 04:36:05 +08:00
|
|
|
{
|
|
|
|
struct device *dev;
|
|
|
|
|
2019-07-24 06:18:33 +08:00
|
|
|
dev = class_find_device_by_of_node(&spi_master_class, node);
|
2017-05-22 21:11:41 +08:00
|
|
|
if (!dev && IS_ENABLED(CONFIG_SPI_SLAVE))
|
2019-07-24 06:18:33 +08:00
|
|
|
dev = class_find_device_by_of_node(&spi_slave_class, node);
|
2014-10-29 04:36:05 +08:00
|
|
|
if (!dev)
|
|
|
|
return NULL;
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Reference got in class_find_device */
|
2017-06-13 19:23:52 +08:00
|
|
|
return container_of(dev, struct spi_controller, dev);
|
2014-10-29 04:36:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int of_spi_notify(struct notifier_block *nb, unsigned long action,
|
|
|
|
void *arg)
|
|
|
|
{
|
|
|
|
struct of_reconfig_data *rd = arg;
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr;
|
2014-10-29 04:36:05 +08:00
|
|
|
struct spi_device *spi;
|
|
|
|
|
|
|
|
switch (of_reconfig_get_state_change(action, arg)) {
|
|
|
|
case OF_RECONFIG_CHANGE_ADD:
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr = of_find_spi_controller_by_node(rd->dn->parent);
|
|
|
|
if (ctlr == NULL)
|
2022-06-29 22:25:18 +08:00
|
|
|
return NOTIFY_OK; /* Not for us */
|
2014-10-29 04:36:05 +08:00
|
|
|
|
2015-11-30 22:28:07 +08:00
|
|
|
if (of_node_test_and_set_flag(rd->dn, OF_POPULATED)) {
|
2017-06-13 19:23:52 +08:00
|
|
|
put_device(&ctlr->dev);
|
2015-11-30 22:28:07 +08:00
|
|
|
return NOTIFY_OK;
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
spi = of_register_spi_device(ctlr, rd->dn);
|
|
|
|
put_device(&ctlr->dev);
|
2014-10-29 04:36:05 +08:00
|
|
|
|
|
|
|
if (IS_ERR(spi)) {
|
2017-07-19 05:43:31 +08:00
|
|
|
pr_err("%s: failed to create for '%pOF'\n",
|
|
|
|
__func__, rd->dn);
|
2016-10-17 21:59:56 +08:00
|
|
|
of_node_clear_flag(rd->dn, OF_POPULATED);
|
2014-10-29 04:36:05 +08:00
|
|
|
return notifier_from_errno(PTR_ERR(spi));
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case OF_RECONFIG_CHANGE_REMOVE:
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Already depopulated? */
|
2015-11-30 22:28:07 +08:00
|
|
|
if (!of_node_check_flag(rd->dn, OF_POPULATED))
|
|
|
|
return NOTIFY_OK;
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Find our device by node */
|
2014-10-29 04:36:05 +08:00
|
|
|
spi = of_find_spi_device_by_node(rd->dn);
|
|
|
|
if (spi == NULL)
|
2022-06-29 22:25:18 +08:00
|
|
|
return NOTIFY_OK; /* No? not meant for us */
|
2014-10-29 04:36:05 +08:00
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* Unregister takes one ref away */
|
2014-10-29 04:36:05 +08:00
|
|
|
spi_unregister_device(spi);
|
|
|
|
|
2022-06-29 22:25:18 +08:00
|
|
|
/* And put the reference of the find */
|
2014-10-29 04:36:05 +08:00
|
|
|
put_device(&spi->dev);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NOTIFY_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct notifier_block spi_of_notifier = {
|
|
|
|
.notifier_call = of_spi_notify,
|
|
|
|
};
|
|
|
|
#else /* IS_ENABLED(CONFIG_OF_DYNAMIC) */
|
|
|
|
extern struct notifier_block spi_of_notifier;
|
|
|
|
#endif /* IS_ENABLED(CONFIG_OF_DYNAMIC) */
|
|
|
|
|
2016-07-09 00:13:11 +08:00
|
|
|
#if IS_ENABLED(CONFIG_ACPI)
|
2017-06-13 19:23:52 +08:00
|
|
|
static int spi_acpi_controller_match(struct device *dev, const void *data)
|
2016-07-09 00:13:11 +08:00
|
|
|
{
|
|
|
|
return ACPI_COMPANION(dev->parent) == data;
|
|
|
|
}
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
static struct spi_controller *acpi_spi_find_controller_by_adev(struct acpi_device *adev)
|
2016-07-09 00:13:11 +08:00
|
|
|
{
|
|
|
|
struct device *dev;
|
|
|
|
|
|
|
|
dev = class_find_device(&spi_master_class, NULL, adev,
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_acpi_controller_match);
|
2017-05-22 21:11:41 +08:00
|
|
|
if (!dev && IS_ENABLED(CONFIG_SPI_SLAVE))
|
|
|
|
dev = class_find_device(&spi_slave_class, NULL, adev,
|
2017-06-13 19:23:52 +08:00
|
|
|
spi_acpi_controller_match);
|
2016-07-09 00:13:11 +08:00
|
|
|
if (!dev)
|
|
|
|
return NULL;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
return container_of(dev, struct spi_controller, dev);
|
2016-07-09 00:13:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct spi_device *acpi_spi_find_device_by_adev(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
struct device *dev;
|
|
|
|
|
2019-07-24 06:18:36 +08:00
|
|
|
dev = bus_find_device_by_acpi_dev(&spi_bus_type, adev);
|
2020-03-12 21:45:07 +08:00
|
|
|
return to_spi_device(dev);
|
2016-07-09 00:13:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_spi_notify(struct notifier_block *nb, unsigned long value,
|
|
|
|
void *arg)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev = arg;
|
2017-06-13 19:23:52 +08:00
|
|
|
struct spi_controller *ctlr;
|
2016-07-09 00:13:11 +08:00
|
|
|
struct spi_device *spi;
|
|
|
|
|
|
|
|
switch (value) {
|
|
|
|
case ACPI_RECONFIG_DEVICE_ADD:
|
2017-06-13 19:23:52 +08:00
|
|
|
ctlr = acpi_spi_find_controller_by_adev(adev->parent);
|
|
|
|
if (!ctlr)
|
2016-07-09 00:13:11 +08:00
|
|
|
break;
|
|
|
|
|
2017-06-13 19:23:52 +08:00
|
|
|
acpi_register_spi_device(ctlr, adev);
|
|
|
|
put_device(&ctlr->dev);
|
2016-07-09 00:13:11 +08:00
|
|
|
break;
|
|
|
|
case ACPI_RECONFIG_DEVICE_REMOVE:
|
|
|
|
if (!acpi_device_enumerated(adev))
|
|
|
|
break;
|
|
|
|
|
|
|
|
spi = acpi_spi_find_device_by_adev(adev);
|
|
|
|
if (!spi)
|
|
|
|
break;
|
|
|
|
|
|
|
|
spi_unregister_device(spi);
|
|
|
|
put_device(&spi->dev);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NOTIFY_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct notifier_block spi_acpi_notifier = {
|
|
|
|
.notifier_call = acpi_spi_notify,
|
|
|
|
};
|
|
|
|
#else
|
|
|
|
extern struct notifier_block spi_acpi_notifier;
|
|
|
|
#endif
|
|
|
|
|
[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 int __init spi_init(void)
|
|
|
|
{
|
2006-01-09 05:34:23 +08:00
|
|
|
int status;
|
|
|
|
|
2006-12-07 12:33:17 +08:00
|
|
|
buf = kmalloc(SPI_BUFSIZ, GFP_KERNEL);
|
2006-01-09 05:34:23 +08:00
|
|
|
if (!buf) {
|
|
|
|
status = -ENOMEM;
|
|
|
|
goto err0;
|
|
|
|
}
|
|
|
|
|
|
|
|
status = bus_register(&spi_bus_type);
|
|
|
|
if (status < 0)
|
|
|
|
goto err1;
|
[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
|
|
|
|
2006-01-09 05:34:23 +08:00
|
|
|
status = class_register(&spi_master_class);
|
|
|
|
if (status < 0)
|
|
|
|
goto err2;
|
2014-10-29 04:36:05 +08:00
|
|
|
|
2017-05-22 21:11:41 +08:00
|
|
|
if (IS_ENABLED(CONFIG_SPI_SLAVE)) {
|
|
|
|
status = class_register(&spi_slave_class);
|
|
|
|
if (status < 0)
|
|
|
|
goto err3;
|
|
|
|
}
|
|
|
|
|
2014-11-27 06:13:57 +08:00
|
|
|
if (IS_ENABLED(CONFIG_OF_DYNAMIC))
|
2014-10-29 04:36:05 +08:00
|
|
|
WARN_ON(of_reconfig_notifier_register(&spi_of_notifier));
|
2016-07-09 00:13:11 +08:00
|
|
|
if (IS_ENABLED(CONFIG_ACPI))
|
|
|
|
WARN_ON(acpi_reconfig_notifier_register(&spi_acpi_notifier));
|
2014-10-29 04:36:05 +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
|
|
|
return 0;
|
2006-01-09 05:34:23 +08:00
|
|
|
|
2017-05-22 21:11:41 +08:00
|
|
|
err3:
|
|
|
|
class_unregister(&spi_master_class);
|
2006-01-09 05:34:23 +08:00
|
|
|
err2:
|
|
|
|
bus_unregister(&spi_bus_type);
|
|
|
|
err1:
|
|
|
|
kfree(buf);
|
|
|
|
buf = NULL;
|
|
|
|
err0:
|
|
|
|
return status;
|
[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
|
|
|
}
|
2006-01-09 05:34:23 +08:00
|
|
|
|
2021-11-23 01:17:21 +08:00
|
|
|
/*
|
|
|
|
* A board_info is normally registered in arch_initcall(),
|
|
|
|
* but even essential drivers wait till later.
|
2006-01-09 05:34:23 +08:00
|
|
|
*
|
2021-11-23 01:17:21 +08:00
|
|
|
* REVISIT only boardinfo really needs static linking. The rest (device and
|
|
|
|
* driver registration) _could_ be dynamically linked (modular) ... Costs
|
2006-01-09 05:34:23 +08:00
|
|
|
* include needing to have boardinfo data structures be much more public.
|
[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-10-16 13:02:46 +08:00
|
|
|
postcore_initcall(spi_init);
|