Re: [PATCH/RFC 0/2] simple SPI framework, refresh + ads7864 driver

[David Brownell <david-b@pacbell.net>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/