spi: bcm2835: can_dma and scatter/gather question

[Mark Brown]

On Thu, Apr 30, 2015 at 12:35:04PM +0200, Martin Sperl wrote:

> The question is: can the spi-framework fullfill those requirements
> as well? Otherwise there would be the need to add an additional
> translation step inside the driver to translate those...

You can see the code for yourself...  we're mostly not doing anything in
the SPI code, we just throw a list of pages into a scatterlist but the
actual mapping is done by the DMA mapping code which is free to do
things like coalesce adjacent blocks.  If the hardware genuinely
requires that the Tx and Rx scatterlists have entries of exactly the
same length I'm not sure that's going to be reliably satisfied if memory
gets fragmented.

> Maybe we need to make the use of the mapping code configurable
> as well, or should such "custom" things go into prepare_message instead
> without implementing can_dma?

It sounds like the driver should just not DMA anything that isn't page
aligned and 32 bit multiple, or special case the first non-aligned bits.
I'd expect anything doing large DMAs to be trying to make them page
aligned anyway.  A facility to provide an interface for cutting off the
start and end of transfers for separate handling as PIO seems like a
reasonable idea but I'm not immediately seeing a straightforward way to
implement it, it seems like it might require most of the infrastructure
we'd need in order to coalesce adjacent transfers in a message (which
would be really nice to have).

> One more thing: is there a helper to create a sg_table for
> spi_message.is_dma_mapped==1?

is_dma_mapped is legacy and should be going away rather than used in new
code since just providing a single physical address really isn't enough,
if we need something in future it'll be done with the scatterlist.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20150430/2327c670/attachment.sig>