On Wed, Oct 30, 2013 at 06:11:45PM +0100, Martin Sperl wrote:

> * schedule some "idle" DMA cycles to RX queue to wait until the clock is finished

I don't follow this, sorry.  What does 'schedule some "idle" DMA cycles
to RX queue' involve?  Please remember that I've never seen anything
about this specific hardware before...

> * if cs_change write 4 bytes to CS-register resetting the "transfer flags
>   also add some idle cycles so that CS does stay high for half a clock cycle

If you're writing to registers doesn't that mean you need to do this
after the transfer has completed rather than having the hardware do
things autonomously (which seemed to be what you were describing)?

With the exception of these 'idle cycles' this all sounds like fairly
standard hardware with a DMA controller capable of chaining transfers
for scatter/gather.

> > You should be working against the latest development code, we're almost
> > at the merge window for v3.13, the v3.12 code is about 3 months old at
> > this point.  Also bear in mind that this is open source, you can extend
> > the frameworks if they don't do what you want.

> That is a bit more effort for me - if the RPI came with upstream code already,
> then it would be much easier, but it does not...
> Device-tree came just before the RPI tree could get integrated, so I am left 
> somewhat behind, because my main project relies on things that are not 
> upstream and might take a long (RPI camera,...)

> Still I want to get these things upstream, because I hope that it will
> eventually happen...

Device tree is totally orthogonal to any of this, this is all about the
SPI core.  I can't think of anythning in the SPI core that is even
particularly dependant on advanced changes in the rest of the kernel,
you could probably just drop a new version into an old kernel with
minimal fixups for integration with the old kernel.