On Thu, Nov 07, 2013 at 01:43:39AM +0100, Martin Sperl wrote:

> The problem is that you intend to do prepare/unprepare transparently.

Please be more concrete and specific, I'm still really struggling to
understand what your concern is.  Please do also reply to what's being
said rather than deleting the entire mail, it makes it easier to follow
the thread of conversation.

> OK - but I see problems with heuristics on when it is safe to assume
> that a message has not been changed since the last call (either xfers
> or tx/rx_buff pointer). If it has not changed then we can use the cached 
> computations from the previous step ( equivalent to prepared).

Why would the SPI core assume that a message just passed into it is a
previously submitted message which has not been changed?  This seems
like something which would add extra complexity to the implementation
over the simpler approach of just treating each new message as a new
one.

Bear in mind that the goals here are to refactor the code so that the
DMA mapping is factored out of the drivers (and can be moved so that it
runs in parallel with transfers), factor out the handling of /CS and in
general the handling of message breaks and avoid all the drivers having
to implement the logic required to push transfers from interrupt context
where possible.