On Tue, Oct 29, 2013 at 10:18:55PM +0100, Martin Sperl wrote:

Please fix your mailer to word wrap within paragraphs, it will greatly
improve readability of your messages.

> Finally I am also not sure how dmaengine can work when 2 DMAs are
> required working in parallel (one for RX the other for TX).  All this
> means that I have to schedule the RX DMA from the TX-DMA and vice
> versa - in addition to configuring the SPI registers via DMA and
> working arround those HW-bugs.

There's plenty of examples of this in mainline for SPI and other
subsystems, mostly this is fairly simple to implement - for example just
enable the DMAs prior to enablig the SPI controller then the SPI
controller triggerrs the actual transfers.

> But with all that said, I can do a single SPI_MESSAGE with 5 transfers
> ,  2 of which have CS_CHANGE only with DMA without any interrupts -
> besides the final interrupt to trigger the wakeup of the
> spi_message_pump thread.

How exactly does this work in concrete terms?  I'm particularly
interested in how the /CS manipluation is done.  The basic idea doesn't
sound terribly different to things a lot of devices can do with driving
the transfers from the IRQ handler (possibly hard IRQ handler) without
waking the tasklet, I'd hope we can make this work as a special case of
that.

> As for the prepare_spi_message - I was asking for something different
> than prepare_transfer_hardware (unless there is new code there in 3.12
> that already includes that - or it is in a separate tree).

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.