On Fri, Nov 15, 2013 at 03:52:42PM +0100, Martin Sperl wrote:

> Well - we first need to see what is the real "common denominator" of
> boards, that can do DMA to configure SPI itself. So we would need at
> least 2 or 3 to figure that out (and also all the bugs we may expect to 
> see and find work-arrounds for those)

There's a bunch of fairly clear patterns for drivers here - the main
constraints are going to be having to punt to task context for sleeping
operations and DMA controllers that just can't have transfers to or from
the register space mixed in with the command stream (all of which fits
into the general patterns we've got already).

> But my guess is that you would not even allow to get something generic as
> this merged unless there are multiple drivers that would be using that
> interface.

> So we would be in a chicken/egg from this direction as well...

We're already going in this direction, that's why I'm going through
splitting up the operations that actually talk to the hardware from the
bits that implement generic logic and queue driving.  The major blocker
previously was that I didn't know what you were proposing to do in your
driver.

> > Or in the async case we just punt the prepare to the thread.

> again: that means an uneccessary delay
> especially when you think about running the message_pump without
> real-time priority introduces 10us additional delay...

For the cases you're concerned about this shouldn't be an issue, the
thread should be behind the I/O or the client driver will have prepared.
I'd also expect to be able to fall back to PIO (which I suspect we'll
want to keep as an option for idle cases anyway).

> > Right, and the big concern with the way you're currently proposing to
> > implement the optimisation is that it's leaving essentially the whole
> > thing up to the individual driver.  This is going to result in limited
> > adoption and is going to mean there's no sharing of learning and fixes
> > between drivers.

> Well, any driver that is using spi_sync can not get improved without a 
> rewrite anyway - the context switching becomes prohibitive.

No, I'm talking about requiring things to be done on the master side not
the client side.  That's key for making it worthwhile for client drivers
to use things like preparing messages and makes it much easier to do the
adaptions required in the master drivers.

> Well - as I understand this, it means that:
> If there were more bus-drivers that could drive the whole SPI transfer of
> a message via DMA, then it would become acceptable to get that API in 
> place until then if there is only a single bus and device driver, then it
> is not acceptable.

No, like I said in an earlier e-mail now that I understand how it can be
generally useful rather than just being a driver specific thing I'm OK
with adding the user visible prepare API (but not the calls into the
master driver).  It's the master driver interface that still needs work
so the logic isn't open coded in individual drivers.