On Wed, Oct 30, 2013 at 11:52:33PM +0100, Martin Sperl wrote:

Please fix your mailer to word wrap within paragraphs, it makes things
much more legible.

> After a lot of digging I found the API you are referring to in:
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/include/linux/spi/spi.h

> So when will this go in?

During the v3.13 merge window.

> How would you recommend to connect your prepared structure to a specific  message?
> There is no flag/field in spi_message to link that.

I'm working on the basis that we should add what we need to the
structure as we add code using it, right now there's no real usage so
nothing to do.

> Would this mean that I would keep an internal list with the address of
> the SPI message any my "prepared data" and I need to iterate over that
> list every time I need it?  This search might - worsted case - become
> a scaling issue if too many prepared 
> statements are created... 

Like I say just add stuff to the core as needed.  If we're getting
scaling problems due to too many transfers in flight we can probably
arrange to limit how many we do.  Hopefully that won't be too much of an
issue, though - we're mostly concerned with the last few entries and
with the ones currently in flight with the hardware.

I'd like to see all this stuff done in the framework as much as
possible, like I say a lot of this is very common and even where we
can't offload everything to hardware we can push a lot down into hard
IRQ context which will help avoid scheduling time.  We should build
things up piece by piece though rather than trying to do everything in
one fell swoop.

My general plan had been to start off by factoring out the prepare and
unprepare of DMA transfers for dmaengine based devices, including things
like the cache flushing, then add support for coalscing scatter/gather
operations - right now I think only one driver can do any form of gather
though a large proportion of the hardware with DMA has that support.

> It could lead to all drivers starting "simple" and then at some point it becomes
> an issue as one driver makes heavy use of this showing it becomes a bottle-neck
> and then all spi-bus-drivers would need to get touched to optimize things...

That's why I want to get as much into the core as possible, like was
done with Linus' work on the queue.  dmaengine helps a lot here since
it means all the DMA controllers look the same and hopefully we can also
model the operations we want to do at the hardware interaction level so
all the fancy queue/transfer management stuff is shared in the core.

> Why not provide a lookup function for the prepared data immediately and make 
> sure the drivers use this one. Then we only have to change it later in one place
> and reduce code-replication across drivers.
> (obviously you would also need put/delete methods to make that interface complete.)

That's the sort of stuff I'm talking about, yes (though I'm not 100%
sure what the "prepared data" is here).  

> Also those function pointers do not have wrappers functions for ease of use, 
> so that they can get used in the individual drivers that know that they can 
> prepare the spi_message, as they do not change the transfer structure....

This is part of pushing things into the core - the idea is that we
should have little if any code using these things in the driver and
instead the core could have the code for working out when to do things.