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.
Attachment:
signature.asc
Description: Digital signature
