On Tue, Oct 29, 2013 at 09:59:23AM -0700, Linus Walleij wrote:
> Let us discuss this on the new mailing list, BTW.

And with the maintainer...  I have zero context for this so I'm not 100%
sure what the original proposal was.

> On Mon, Oct 28, 2013 at 11:42 AM, Martin Sperl <martin-d5rIkyn9cnPYtjvyW6yDsg@public.gmane.org> wrote:
> 
> > (... ) I thought of moving away from spi_transfer_one_message and back to
> > the simpler transfer interface, where the preprocessing would get done
> > (DMA control block-chain generation) and then appending it to the
> > existing (possibly running) DMA chain.

> OK quite a cool idea.

How is this going to interact with /CS manipulation?  We need /CS to
rise and fall as requested by the client, if we coalesce adjacent
messages that's going to be an issue...

> As you will be using dmaengine (I guess?) maybe a lot of this can
> actually be handled directly in the core since that code should be
> pretty generic, or in a separate file like spi-dmaengine-chain.c?

FWIW this is one of the things I've been aiming to tackle in my ongoing
refactoring, the initial two things were making the core able to do the
DMA mapping (probably adding a transfer API which passses in sg_list, it
can then handle things like blocks that aren't physically contiguous and
coalescing scatter/gather for the controller) and trying to overlap the
cache flushing of the next transfer with the I/O for the current
transfer.

> > Now this brings me to different question:
> > Could we implement some additional "functions" for preparing
> > an SPI message (...)
> > The interface could looks something like this:
> > int spi_prepare_message(struct_spi_dev*, struct spi_message *);
> > int spi_unprepare_message(struct_spi_dev*, struct spi_message *);

> Maybe? I cannot tell from the above how this would look so
> I think it is better if you send a patch showing how this improves
> efficiency.

The current SPI API has exactly those functions...