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

On Fri, Nov 08, 2013 at 03:16:57PM +0100, Martin Sperl wrote:

Please fix the formatting in your mails, odd line wrapping makes things
harder to read.

> While I am more concerned about the cost of running a prepare EVERY time we
> schedule a message - and that becomes significant CPU utilization if you 
> look at my report (doing the setup calculation for the DMA of a message,
> with 2x2 Byte (write_then_read) transfer at 8MHz takes about as long as the
> actual transfer over the bus. (if more data gets transmitted the ratio 
> changes to the transfer side)

I'd be rather surprised if there's a meaningful benefit from doing such
a transfer using DMA in the first place, with most hardware you are
better off doing small transfers with PIO and using a completion
interrupt for the transfer.  Talking to the DMA controller tends to end
up being more work than it's worth.  Are you sure that you are
optimising the right thing here?

I'd want to see strong numbers from a real use case showing that the
complexity of trying to do this was worth it.

> But waiting for the spi_pump thread to wake up is wasting valuable
> time waiting for the scheduler - especially if you could submit the
> message to DMA immediately.

This is the sort of thing we can do sensibly enough once we don't have
to open code the logic in individual controller drivers, it doesn't seem
terribly connected with any external API changes though?

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