[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>
19 years ago
|
|
|
#
|
|
|
|
|
# SPI driver configuration
|
|
|
|
|
#
|
|
|
|
|
# NOTE: the reason this doesn't show SPI slave support is mostly that
|
|
|
|
|
# nobody's needed a slave side API yet. The master-role API is not
|
|
|
|
|
# fully appropriate there, so it'd need some thought to do well.
|
|
|
|
|
#
|
|
|
|
|
menu "SPI support"
|
|
|
|
|
|
|
|
|
|
config SPI
|
|
|
|
|
bool "SPI support"
|
|
|
|
|
help
|
|
|
|
|
The "Serial Peripheral Interface" is a low level synchronous
|
|
|
|
|
protocol. Chips that support SPI can have data transfer rates
|
|
|
|
|
up to several tens of Mbit/sec. Chips are addressed with a
|
|
|
|
|
controller and a chipselect. Most SPI slaves don't support
|
|
|
|
|
dynamic device discovery; some are even write-only or read-only.
|
|
|
|
|
|
|
|
|
|
SPI is widely used by microcontollers to talk with sensors,
|
|
|
|
|
eeprom and flash memory, codecs and various other controller
|
|
|
|
|
chips, analog to digital (and d-to-a) converters, and more.
|
|
|
|
|
MMC and SD cards can be accessed using SPI protocol; and for
|
|
|
|
|
DataFlash cards used in MMC sockets, SPI must always be used.
|
|
|
|
|
|
|
|
|
|
SPI is one of a family of similar protocols using a four wire
|
|
|
|
|
interface (select, clock, data in, data out) including Microwire
|
|
|
|
|
(half duplex), SSP, SSI, and PSP. This driver framework should
|
|
|
|
|
work with most such devices and controllers.
|
|
|
|
|
|
|
|
|
|
config SPI_DEBUG
|
|
|
|
|
boolean "Debug support for SPI drivers"
|
|
|
|
|
depends on SPI && DEBUG_KERNEL
|
|
|
|
|
help
|
|
|
|
|
Say "yes" to enable debug messaging (like dev_dbg and pr_debug),
|
|
|
|
|
sysfs, and debugfs support in SPI controller and protocol drivers.
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# MASTER side ... talking to discrete SPI slave chips including microcontrollers
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
config SPI_MASTER
|
|
|
|
|
# boolean "SPI Master Support"
|
|
|
|
|
boolean
|
|
|
|
|
default SPI
|
|
|
|
|
help
|
|
|
|
|
If your system has an master-capable SPI controller (which
|
|
|
|
|
provides the clock and chipselect), you can enable that
|
|
|
|
|
controller and the protocol drivers for the SPI slave chips
|
|
|
|
|
that are connected.
|
|
|
|
|
|
|
|
|
|
comment "SPI Master Controller Drivers"
|
|
|
|
|
depends on SPI_MASTER
|
|
|
|
|
|
|
|
|
|
config SPI_BITBANG
|
|
|
|
|
tristate "Bitbanging SPI master"
|
|
|
|
|
depends on SPI_MASTER && EXPERIMENTAL
|
|
|
|
|
help
|
|
|
|
|
With a few GPIO pins, your system can bitbang the SPI protocol.
|
|
|
|
|
Select this to get SPI support through I/O pins (GPIO, parallel
|
|
|
|
|
port, etc). Or, some systems' SPI master controller drivers use
|
|
|
|
|
this code to manage the per-word or per-transfer accesses to the
|
|
|
|
|
hardware shift registers.
|
|
|
|
|
|
|
|
|
|
This is library code, and is automatically selected by drivers that
|
|
|
|
|
need it. You only need to select this explicitly to support driver
|
|
|
|
|
modules that aren't part of this kernel tree.
|
[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>
19 years ago
|
|
|
|
|
|
|
|
config SPI_BUTTERFLY
|
|
|
|
|
tristate "Parallel port adapter for AVR Butterfly (DEVELOPMENT)"
|
|
|
|
|
depends on SPI_MASTER && PARPORT && EXPERIMENTAL
|
|
|
|
|
select SPI_BITBANG
|
|
|
|
|
help
|
|
|
|
|
This uses a custom parallel port cable to connect to an AVR
|
|
|
|
|
Butterfly <http://www.atmel.com/products/avr/butterfly>, an
|
|
|
|
|
inexpensive battery powered microcontroller evaluation board.
|
|
|
|
|
This same cable can be used to flash new firmware.
|
|
|
|
|
|
|
|
|
|
config SPI_BUTTERFLY
|
|
|
|
|
tristate "Parallel port adapter for AVR Butterfly (DEVELOPMENT)"
|
|
|
|
|
depends on SPI_MASTER && PARPORT && EXPERIMENTAL
|
|
|
|
|
select SPI_BITBANG
|
|
|
|
|
help
|
|
|
|
|
This uses a custom parallel port cable to connect to an AVR
|
|
|
|
|
Butterfly <http://www.atmel.com/products/avr/butterfly>, an
|
|
|
|
|
inexpensive battery powered microcontroller evaluation board.
|
|
|
|
|
This same cable can be used to flash new firmware.
|
|
|
|
|
|
[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>
19 years ago
|
|
|
#
|
|
|
|
|
# Add new SPI master controllers in alphabetical order above this line
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# There are lots of SPI device types, with sensors and memory
|
|
|
|
|
# being probably the most widely used ones.
|
|
|
|
|
#
|
|
|
|
|
comment "SPI Protocol Masters"
|
|
|
|
|
depends on SPI_MASTER
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Add new SPI protocol masters in alphabetical order above this line
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# (slave support would go here)
|
|
|
|
|
|
|
|
|
|
endmenu # "SPI support"
|
|
|
|
|
|
