Re: Depreciated spi_master.transfer and "prepared spi messages" for an optimized pipelined-SPI-DMA-driver

[Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]

On Wed, Nov 13, 2013 at 04:48:47PM +0100, Martin Sperl wrote:

> > Drivers can supply pre-mapped DMA buffers if they set is_dma_mapped
> > which is about as good as you get with dmaengine at the minute.  The
> > main opportunities for enhancement here are in the master interface
> > rather than the client, at least as things stand.

> This is part of my pre-requisite for making it prepareable in my case...

> Because otherwise you have (again) to walk the tree to set the rx_dma
> via dma_map_single and here the API explicitly states that between the map 
> and unmap call the caller may NOT access the pages.

So you expect the caller to also keep the buffers mapped separately?
The restrictions on mapping are one of the concerns I have with nailing
down exactly what you're envisaging a prepared and unprepared
transaction doing (plus masters that don't actually want DMA in the
first place).

> The reason is (probably) for old-ISA devices that may only DMA map 24 bit 
> addresses. So the map/unmap actually is supposed to copy data to a bounce 
> buffer and back (depending on the direction given).

> Typically not an issue on ARM though, I would say...

No, it's not just for ISA - other systems can have DMA access
restrictions for example due to LPAE or other things that cause limited
addressing on some internal buses and obviously many modern systems have
IOMMUs which require things to be mapped in and out before devices can
access them without needing bounce buffers.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]