On Wed, Nov 20, 2013 at 04:27:06PM +0100, Martin Sperl wrote: > As mentioned before I will take the opportunity to move the flags into > spi_transfer for optimization hints, because there is where the change > really happens...
These are set by the caller? > The current bits come to my mind: > #define SPI_OPTIMIZE_FIXED_TX_BUF (1<<0) > #define SPI_OPTIMIZE_FIXED_TX_DMA ((1<<1)|(1<<0)) > #define SPI_OPTIMIZE_FIXED_RX_BUF (1<<2) > #define SPI_OPTIMIZE_FIXED_RX_DMA ((1<<3)|(1<<2)) > #define SPI_OPTIMIZE_FIXED_LEN (1<<4) > #define SPI_OPTIMIZE_FIXED_DELAY (1<<5) > #define SPI_OPTIMIZE_FIXED_SPEED (1<<6) > #define SPI_OPTIMIZE_FIXED_BITS (1<<7) > #define SPI_OPTIMIZE_FIXED_ALL (-1) > The flags argument now is of type gfp_t to allow for memory allocation > policies. I'd be tempted to start with assuming everything is fixed and then add flags to mark things as variable rather than the other way around since that's the most conservative option and should permit the greatest level of optimisation. > I will provide the patches as soon as I have pulled your tree - only > problem is that I can not really compile it on this tree on my RPI... You should at least be able to do build tests, it's OK if you can't do runtime tests - I can do validation myself, as can other people working with -next. > Each of those unfortunately would require a separate create/free function > to populate the caches. So generalizing this into spi_master would blow up > this structure... But then these cache structures would need to sit > somewhere anyway, so adding them to the master would need to happen > one way or another... But then maybe there are different ideas for something > like this (but I assume a driver making use of this would be required first) Yes, there's some tricky issues here... let's have a think about it and try to do this incrementally.
signature.asc
Description: Digital signature
