Re: Depreciated spi_master.transfer and "prepared spi messages" for an optimized pipelined-SPI-DMA-driver

[Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

On Wed, Nov 13, 2013 at 07:35:27PM +0100, Martin Sperl wrote:

> You also see that this driver is already trying to keep the latencies as
> short as possible by using the chaining instead of issuing each of those
> CS-enable sequence separately.

It's going to be more sensible to work to eliminate the extra overhead
for doing multiple messages than to faff around in individual client
drivers, solve the problem at the right level - this will play more
nicely when two devices are hitting the same bus as well.

> So you think this is really cheaper from the CPU perspective to take the
> Interrupt-driven approach?

Well, if we ignore the scheduling (which we ought to be able to get rid
of anyway) then the DMA is starting to look like overhead for what
appears to be a small transfer.

> > Exactly, but this is largely orthogonal to having the client drivers
> > precook the messages.  You can't just discard the thread since some
> > things like clock reprogramming can be sleeping but we should be using
> > it less (and some of the use that is needed can be run in parallel with
> > the transfers of other messages if we build up a queue).

> Ok - the clock setting is possibly valid for some SPI devices, but not for
> all. And we all know that a "one-size fits all" does not scale in 
> performance.

> Also it may be a possibility that different devices have different 
> feature-sets, where in part we need to drop back to something else (thread).

Of course, we will need to allow the driver to control when it punts
back to the thread.  What we don't want to have to do is reimplement the
mechanics of all this in every single driver since that's the situation
we have now for everything that isn't bitbanging.  Broadly speaking most
of the hardware we have now falls into a few classes and most of it
isn't being driven anywhere near as effectively as it could be.

> You see where PIPO looses its time?

Not really, I mean the data transfers wind up being slower because
they're bigger than they looked from the timings (you haven't mentioned
how big they are...) but I don't really see why PIO (assuming that's
what you mean by "PIPO" which is an acronym I don't recall hearing
before) impacts the time taken to raise /CS.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]