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: 2235 bytes --]

On Fri, Nov 15, 2013 at 12:15:55PM +0100, Martin Sperl wrote:

> You essentially gave me the idea that we could reduce restrictions
> on the proposed spi_prepare_message by adding some flags of in what way
> the structure may change. So if you got a "fully" fixed structure,
> then we could add "flags" here to indicate if the structure also is
> fixed with regards to:

Adding flags seems like a good idea, probably easiest to start with
everything is fixed and then add the ability to relax things later.

> This comes with a potential "trap": We would need to define if a
> "reorder" of SPI messages between two different SPI Bus devices with
> different CS is a valid operation or not.
> (the question is mostly: would this "queuing" happen on a per bus-driver
> basis or on a per CS basis)

I'd expect us to continue to do things per bus, at least for the time
being.  This is definitely a stage two consideration though, getting
something working 

> But the first question is: are there any drivers currently that require
> multiple CS to do its work?

No.

> All of these ideas will also help us in the future and may then may get
> used for other bus-drivers as well - we then could even start using a
> "DMA-sequencing" engine inside the framework to reduce the code on the
> driver (how to define those would be tricky though - we would need to
> see how "flexible" other devices are compared to bcm2835).

The only thing that you're talking about that sounds unusual is the
ability to add timed delays in the hardware, otherwise this all sounds
very standard assuming DMA controllers will play nice with mixing in
writes to registers (which I expect to be common).

> We could make this a flag in the spi_message structure or use different
> functions: spi_async_threaded and spi_async_interrupt while having the
> spi_async map to spi_async_interrupt for compatibility reasons with
> older drivers.

Separate functions would be a bit more idiomatic.

> why not call the new interface:
> int spi_(pre)build_message(struct spi_device*,struct spi_message,
> 	unsigned long flags);
> int spi_unbuild_message(struct spi_device*,struct spi_message);

Seems fine.  Or init/done.

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