ARM: bcm2835: DMA driver + spi_optimize_message - some questions/info

[Martin Sperl]

Thanks for the feedback.

Will try to keep emails shorter - I wanted to get everything out in one
and document it also trying to answer questions I thought would come up.

So I will take it that I can continue from where I am right now.

Just to summarize the current "modules" and their respective files:

spi-optimize - essentially the patch shared with my original email touching:
include/linux/spi/spi.h
driver/spi/spi.c

maybe adding some documentation on how to "optimize" high-volume drivers
to make optimal use of the interface.

basic generic dma-fragment support (structures/methods):
include/linux/dma-fragment.h
drivers/dma/dma-fragment.c
(maybe add: Documentation/dma-fragment.txt)

bcm2835 specific fragment support (dumping, scheduling, linking):
include/linux/dma/bcm2835-dma.h
drivers/dma/bcm2835-dma.c

generic spi specific dma-fragment code: 
include/linux/spi/spi-dmafragment.h
drivers/spi/spi-dmafragment.c
mostly about extensions pre/post dma transforms for vary support 
- also handling DMA-mapping, and data for the state-machine used in transformation
from spi-message to dma_fragment)
this could get integrated with spi.h/spi.c if it is deemed sensible

spi-bcm2835dma driver:
include/linux/spi/bcm2835.h (SPI DMA registers and Bits)
drivers/spi/spi-bcm2835dma.h (datastructures and defines)
drivers/spi/spi-bcm2835dma_drv.c (driver itself)
drivers/spi/spi-bcm2835dma_frag.c (the code filling/creating the fragments)

Does this look "ok" from an approach perspective?

I will share one module after the other for initial review.

I will brush up the code for the generic DMA fragment code, so that it
becomes presentable and will share that part in the hope that it live in
parallel to dmaengine and/or get somehow integrated - possibly as another target
besides cyclic.

It is really mostly management of those dma blocks so that they can get
joined together easily as well as the management of a group of those blocks.

Also it is designed to be generic that is why there is the bcm2835 specific code
as well as a separate module.

As such drivers using this specific interface will need to know enough about
the HW itself, my assumption is that the driver will need to know about the DMA
engine used to work properly - so I left all sorts of abstractions out of the 
design - this can get added later if needed...
Anyway this should come with deeper integration with dma-engine.

With regards to VARY: I have used the "options" provided to cover most of the
bases that I thought I would need to "auto-optimize" those simple cases of
spi_read, spi_write, spi_write_then_read. The VARY_DELAY_USEC was just added as
an after-thought, as it is not so "complex" to enable this as a feature...

As for the measurements on effective CPU utilization shared originally - is the
data shared understood/convincing? Does it need more explanation?

Ciao, Martin

P.s: as an afterthought: I actually think that I could implement a DMA driven
bit-bang SPI bus driver with up to 8 data-lines using the above dma_fragment 
approach - not sure about the effective clock speed that this could run... 
But right now it is not worth pursuing that further.