[PATCH 2.6-git 0/4] SPI core refresh
- From: Vitaly Wool <vwool@xxxxxxxxxxxxx>
- Date: Mon, 12 Dec 2005 18:20:26 +0300
Greetings,
this message fill be followed by the following four ones:
1) updated SPI core from Dmitry Pervushin/Vitaly Wool
2) Atmel MTD dataflash driver port for this core
3) SPI controller driver for Philips SPI controller
4) dumb EEPROM driver for EEPROM chip on SPI bus
This SPI core features:
* multiple SPI controller support
* multiple devices on the same bus support
* DMA support
* synchronous and asynchronous transfers
* library for asynchronous transfers on the bus using kernel threads
* character device interface
* custom lightweight SPI message allocation mechanism
The SPI core is now closer to the other one, David Brownell's. For instance, spi_driver structure is now the same, and some API functions are mostly quite similar. Even the footprint is now similar (~2k .text on ARM) :)
However, there are some differences I'd like to summarize:
* this core doesn't support hotplug, and David's does (we'll post this support later in a separate patch)
* our core is transparent for DMA transfers (allocation of DMA-safe buffer is triggered by the message flag set by the caller) and David's one implies limitations on tx/rx buffers passed (which can be easily resolved in the controller driver though)
* our core implements thread-based asynchronous message handling (as an option!) which seems to be the best way to go for most cases. i. e. PXA SSP driver from Stephen would be a lot more lightweight and will gain more performance if it used this method instead of multiple tasklets scheduling (as of now)
* our core hides the SPI message internals and David's exposes them to the outer world. This is in way more robust since the only way to allocate the message is through the API
* our core uses uniform message structure for all transfers and "chains" such messages, and David's uses separate spi_transfer array which hold the chain and is attached to the message structure. It's arguable which one is better; at least ours allows to easily change the message inetrnals w/o affecting actual drivers and use versatile message allocation techniques
* our core allows to omit callbacks for sync transfers which is a reasonable thing IMO (if it's a sync transfer, then the caller will just wait, so having a default callback that just waits-for-completion is rational)
* our core provides more straightfoward means (leading to improved readability of the actual drivers) to express the same things, i. e instead of
> message->status = -EIO;
> if (message->complete) {
> message->complete(message->context);
> }
one is only to do
> spimsg_complete(message, -EIO);
or, instead of
> if (!message->transfers[state->index].cs_change)
> state->cs_control(PXA2XX_CS_DEASSERT);
one is to do
> if (spimsg_get_flags(cur_msg) & SPI_M_CSKEEP)
> state->cs_control(PXA2XX_CS_DEASSERT);
* other minor differences... maybe David's gonna add some here.
Vitaly
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- [PATCH/RFC] SPI: add async message handing library to David Brownell's core
- From: Vitaly Wool
- Re: [PATCH 2.6-git 0/4] SPI core refresh
- From: Rui Sousa
- [PATCH 2.6-git 3/4] SPI core refresh: SPI/PNX controller
- From: Vitaly Wool
- [PATCH 2.6-git 1/4] SPI core refresh: SPI core patch
- From: Vitaly Wool
- Re: [PATCH 2.6-git 2/4] SPI core refresh: MTD dataflash driver
- From: Vitaly Wool
- [PATCH 2.6-git 4/4] SPI core refresh: dumb EEPROM driver
- From: Vitaly Wool
- [PATCH/RFC] SPI: add async message handing library to David Brownell's core
- Prev by Date: Re: [PATCH] move pm_power_off and pm_idle declaration to common code
- Next by Date: [PATCH 2.6-git 4/4] SPI core refresh: dumb EEPROM driver
- Previous by thread: XFS accessing arch-specific structures
- Next by thread: [PATCH 2.6-git 4/4] SPI core refresh: dumb EEPROM driver
- Index(es):
Relevant Pages
|
