Hi Vitaly,
> can you please describe the data flow in case of DMA transfer? Thanks!
In the current model, the controller driver handles it (assuming
that it uses DMA not PIO):
- Use dma_map_single() at some point between the master->transfer()
call and the time the DMA address is handed to DMA hardware.
- Probably store those addresses in the spi_transfer struct, using
rx_dma and/or tx_dma as appropriate.
- After the DMA transfer completes, call dma_unmap_single() before
calling spi_message.complete(spi_message.context).
There are two fancier approaches to consider for sometime later, both
of which have been used for several years now by host-side USB.
* SPI controller drivers could require the mappings to already
have been done, and stored in {rx,tx}_dma fields. When those
drivers are using DMA, they'd only use those DMA addresses.
The way host-side USB does that is by having usbcore do work
on all the submit and giveback paths. Currently this SPI
framework doesn't do "core" work on those paths; spi_async()
just calls directly to the controller driver (no overhead!)
and the completion reports likewise go right from controller
driver back to the submitter (also, no overhead).
* Drivers for SPI slave chips might sometimes want to provide their
own rx_dma and/or tx_dma values ... either because they mapped the
buffers themselves -- great for dma_map_sg()! -- or because the
memory came from dma_alloc_coherent().
This implies that the controller drivers are ready to accept
those DMA addresses, and that there are per-buffer flags saying
whether its DMA address is also valid (vs just its CPU address).
Note that the slave-side USB support only supports the latter, which
means the USB peripheral controller drivers with DMA support decide
on a per-request basis whether to do the DMA mappings. I'd lean
towards doing that with SPI; it's a bunch simpler.
Right now DMA isn't on my priority list, but I'd be glad to see
someone else take further steps there. Anyone doing bulk I/O to an
SPI flash chip at 50 MHz is surely going to want DMA for it!
- Dave
p.s. Please be sure to CC me on replies, so I'm sure to see them...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
