[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.
|
|
|
|
|
#
|
|
|
|
|
menuconfig 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>
19 years ago
|
|
|
bool "SPI support"
|
|
|
|
|
depends on HAS_IOMEM
|
[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
|
|
|
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 microcontrollers to talk with sensors,
|
[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
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
if 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>
19 years ago
|
|
|
config SPI_DEBUG
|
|
|
|
|
boolean "Debug support for SPI drivers"
|
|
|
|
|
depends on DEBUG_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>
19 years ago
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
if SPI_MASTER
|
|
|
|
|
|
[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
|
|
|
comment "SPI Master Controller Drivers"
|
|
|
|
|
|
|
|
|
|
config SPI_ATMEL
|
|
|
|
|
tristate "Atmel SPI Controller"
|
|
|
|
|
depends on (ARCH_AT91 || AVR32)
|
|
|
|
|
help
|
|
|
|
|
This selects a driver for the Atmel SPI Controller, present on
|
|
|
|
|
many AT32 (AVR32) and AT91 (ARM) chips.
|
|
|
|
|
|
|
|
|
|
config SPI_BFIN
|
|
|
|
|
tristate "SPI controller driver for ADI Blackfin5xx"
|
|
|
|
|
depends on BLACKFIN
|
|
|
|
|
help
|
|
|
|
|
This is the SPI controller master driver for Blackfin 5xx processor.
|
|
|
|
|
|
|
|
|
|
config SPI_AU1550
|
|
|
|
|
tristate "Au1550/Au12x0 SPI Controller"
|
|
|
|
|
depends on (SOC_AU1550 || SOC_AU1200) && EXPERIMENTAL
|
|
|
|
|
select SPI_BITBANG
|
|
|
|
|
help
|
|
|
|
|
If you say yes to this option, support will be included for the
|
|
|
|
|
Au1550 SPI controller (may also work with Au1200,Au1210,Au1250).
|
|
|
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
|
|
|
will be called au1550_spi.
|
|
|
|
|
|
|
|
|
|
config SPI_BITBANG
|
|
|
|
|
tristate "Utilities for Bitbanging SPI masters"
|
|
|
|
|
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 PARPORT
|
|
|
|
|
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_GPIO
|
|
|
|
|
tristate "GPIO-based bitbanging SPI Master"
|
|
|
|
|
depends on GENERIC_GPIO
|
|
|
|
|
select SPI_BITBANG
|
|
|
|
|
help
|
|
|
|
|
This simple GPIO bitbanging SPI master uses the arch-neutral GPIO
|
|
|
|
|
interface to manage MOSI, MISO, SCK, and chipselect signals. SPI
|
|
|
|
|
slaves connected to a bus using this driver are configured as usual,
|
|
|
|
|
except that the spi_board_info.controller_data holds the GPIO number
|
|
|
|
|
for the chipselect used by this controller driver.
|
|
|
|
|
|
|
|
|
|
Note that this driver often won't achieve even 1 Mbit/sec speeds,
|
|
|
|
|
making it unusually slow for SPI. If your platform can inline
|
|
|
|
|
GPIO operations, you should be able to leverage that for better
|
|
|
|
|
speed with a custom version of this driver; see the source code.
|
|
|
|
|
|
|
|
|
|
config SPI_IMX
|
|
|
|
|
tristate "Freescale i.MX SPI controllers"
|
|
|
|
|
depends on ARCH_MXC
|
|
|
|
|
select SPI_BITBANG
|
|
|
|
|
help
|
|
|
|
|
This enables using the Freescale i.MX SPI controllers in master
|
|
|
|
|
mode.
|
|
|
|
|
|
|
|
|
|
config SPI_LM70_LLP
|
|
|
|
|
tristate "Parallel port adapter for LM70 eval board (DEVELOPMENT)"
|
|
|
|
|
depends on PARPORT && EXPERIMENTAL
|
|
|
|
|
select SPI_BITBANG
|
|
|
|
|
help
|
|
|
|
|
This driver supports the NS LM70 LLP Evaluation Board,
|
|
|
|
|
which interfaces to an LM70 temperature sensor using
|
|
|
|
|
a parallel port.
|
|
|
|
|
|
|
|
|
|
config SPI_MPC52xx_PSC
|
|
|
|
|
tristate "Freescale MPC52xx PSC SPI controller"
|
|
|
|
|
depends on PPC_MPC52xx && EXPERIMENTAL
|
|
|
|
|
help
|
|
|
|
|
This enables using the Freescale MPC52xx Programmable Serial
|
|
|
|
|
Controller in master SPI mode.
|
|
|
|
|
|
|
|
|
|
config SPI_MPC8xxx
|
|
|
|
|
tristate "Freescale MPC8xxx SPI controller"
|
|
|
|
|
depends on FSL_SOC
|
|
|
|
|
help
|
|
|
|
|
This enables using the Freescale MPC8xxx SPI controllers in master
|
|
|
|
|
mode.
|
|
|
|
|
|
|
|
|
|
This driver uses a simple set of shift registers for data (opposed
|
|
|
|
|
to the CPM based descriptor model).
|
|
|
|
|
|
|
|
|
|
config SPI_OMAP_UWIRE
|
|
|
|
|
tristate "OMAP1 MicroWire"
|
|
|
|
|
depends on ARCH_OMAP1
|
|
|
|
|
select SPI_BITBANG
|
|
|
|
|
help
|
|
|
|
|
This hooks up to the MicroWire controller on OMAP1 chips.
|
|
|
|
|
|
|
|
|
|
config SPI_OMAP24XX
|
|
|
|
|
tristate "McSPI driver for OMAP24xx/OMAP34xx"
|
|
|
|
|
depends on ARCH_OMAP24XX || ARCH_OMAP34XX
|
|
|
|
|
help
|
|
|
|
|
SPI master controller for OMAP24xx/OMAP34xx Multichannel SPI
|
|
|
|
|
(McSPI) modules.
|
|
|
|
|
|
|
|
|
|
config SPI_ORION
|
|
|
|
|
tristate "Orion SPI master (EXPERIMENTAL)"
|
|
|
|
|
depends on PLAT_ORION && EXPERIMENTAL
|
|
|
|
|
help
|
|
|
|
|
This enables using the SPI master controller on the Orion chips.
|
|
|
|
|
|
|
|
|
|
config SPI_PL022
|
|
|
|
|
tristate "ARM AMBA PL022 SSP controller (EXPERIMENTAL)"
|
|
|
|
|
depends on ARM_AMBA && EXPERIMENTAL
|
|
|
|
|
default y if MACH_U300
|
|
|
|
|
default y if ARCH_REALVIEW
|
|
|
|
|
default y if INTEGRATOR_IMPD1
|
|
|
|
|
default y if ARCH_VERSATILE
|
|
|
|
|
help
|
|
|
|
|
This selects the ARM(R) AMBA(R) PrimeCell PL022 SSP
|
|
|
|
|
controller. If you have an embedded system with an AMBA(R)
|
|
|
|
|
bus and a PL022 controller, say Y or M here.
|
|
|
|
|
|
|
|
|
|
config SPI_PPC4xx
|
|
|
|
|
tristate "PPC4xx SPI Controller"
|
|
|
|
|
depends on PPC32 && 4xx && SPI_MASTER
|
|
|
|
|
select SPI_BITBANG
|
|
|
|
|
help
|
|
|
|
|
This selects a driver for the PPC4xx SPI Controller.
|
|
|
|
|
|
|
|
|
|
config SPI_PXA2XX
|
|
|
|
|
tristate "PXA2xx SSP SPI master"
|
|
|
|
|
depends on ARCH_PXA && EXPERIMENTAL
|
|
|
|
|
select PXA_SSP
|
|
|
|
|
help
|
|
|
|
|
This enables using a PXA2xx SSP port as a SPI master controller.
|
|
|
|
|
The driver can be configured to use any SSP port and additional
|
|
|
|
|
documentation can be found a Documentation/spi/pxa2xx.
|
|
|
|
|
|
|
|
|
|
config SPI_S3C24XX
|
|
|
|
|
tristate "Samsung S3C24XX series SPI"
|
|
|
|
|
depends on ARCH_S3C2410 && EXPERIMENTAL
|
|
|
|
|
select SPI_BITBANG
|
|
|
|
|
help
|
|
|
|
|
SPI driver for Samsung S3C24XX series ARM SoCs
|
|
|
|
|
|
|
|
|
|
config SPI_S3C24XX_GPIO
|
|
|
|
|
tristate "Samsung S3C24XX series SPI by GPIO"
|
|
|
|
|
depends on ARCH_S3C2410 && EXPERIMENTAL
|
|
|
|
|
select SPI_BITBANG
|
|
|
|
|
help
|
|
|
|
|
SPI driver for Samsung S3C24XX series ARM SoCs using
|
|
|
|
|
GPIO lines to provide the SPI bus. This can be used where
|
|
|
|
|
the inbuilt hardware cannot provide the transfer mode, or
|
|
|
|
|
where the board is using non hardware connected pins.
|
|
|
|
|
|
|
|
|
|
config SPI_SH_SCI
|
|
|
|
|
tristate "SuperH SCI SPI controller"
|
|
|
|
|
depends on SUPERH
|
|
|
|
|
select SPI_BITBANG
|
|
|
|
|
help
|
|
|
|
|
SPI driver for SuperH SCI blocks.
|
|
|
|
|
|
|
|
|
|
config SPI_STMP3XXX
|
|
|
|
|
tristate "Freescale STMP37xx/378x SPI/SSP controller"
|
|
|
|
|
depends on ARCH_STMP3XXX && SPI_MASTER
|
|
|
|
|
help
|
|
|
|
|
SPI driver for Freescale STMP37xx/378x SoC SSP interface
|
|
|
|
|
|
|
|
|
|
config SPI_TXX9
|
|
|
|
|
tristate "Toshiba TXx9 SPI controller"
|
|
|
|
|
depends on GENERIC_GPIO && CPU_TX49XX
|
|
|
|
|
help
|
|
|
|
|
SPI driver for Toshiba TXx9 MIPS SoCs
|
|
|
|
|
|
|
|
|
|
config SPI_XILINX
|
|
|
|
|
tristate "Xilinx SPI controller"
|
|
|
|
|
depends on (XILINX_VIRTEX || MICROBLAZE) && EXPERIMENTAL
|
|
|
|
|
select SPI_BITBANG
|
|
|
|
|
help
|
|
|
|
|
This exposes the SPI controller IP from the Xilinx EDK.
|
|
|
|
|
|
|
|
|
|
See the "OPB Serial Peripheral Interface (SPI) (v1.00e)"
|
|
|
|
|
Product Specification document (DS464) for hardware details.
|
|
|
|
|
|
[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"
|
|
|
|
|
|
|
|
|
|
config SPI_SPIDEV
|
|
|
|
|
tristate "User mode SPI device driver support"
|
|
|
|
|
depends on EXPERIMENTAL
|
|
|
|
|
help
|
|
|
|
|
This supports user mode SPI protocol drivers.
|
|
|
|
|
|
|
|
|
|
Note that this application programming interface is EXPERIMENTAL
|
|
|
|
|
and hence SUBJECT TO CHANGE WITHOUT NOTICE while it stabilizes.
|
|
|
|
|
|
|
|
|
|
config SPI_TLE62X0
|
|
|
|
|
tristate "Infineon TLE62X0 (for power switching)"
|
|
|
|
|
depends on SYSFS
|
|
|
|
|
help
|
|
|
|
|
SPI driver for Infineon TLE62X0 series line driver chips,
|
|
|
|
|
such as the TLE6220, TLE6230 and TLE6240. This provides a
|
|
|
|
|
sysfs interface, with each line presented as a kind of GPIO
|
|
|
|
|
exposing both switch control and diagnostic feedback.
|
|
|
|
|
|
[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 protocol masters in alphabetical order above this line
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
endif # SPI_MASTER
|
|
|
|
|
|
[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
|
|
|
# (slave support would go here)
|
|
|
|
|
|
|
|
|
|
endif # SPI
|
