Messages in this thread | | | Date | Fri, 18 Feb 2011 12:35:27 +0100 | From | Wojciech Zabołotny <> | Subject | Proposed changes/improvements to SPI drivers |
| |
Hi, I've worked with a SPI hardware requiring a little longer delay between deactivation and activation of CS line. To improve throughput, I had to perform transmission with a single spi_message consisting of a few spi_transfers. When debugging my driver, it appeared, that the usecs_delay allows me only to introduce delay before CS gets deactivated. The delay between deactivation and activation of CS between transfers is hardcoded: (e.g. http://lxr.linux.no/linux+v2.6.37.1/drivers/spi/atmel_spi.c#L513 ).
I'd like to suggest adding another field (maybe "cs_inact_delay") like delay_usecs in the spi_transfer structure, which will define the time for which CS remains inactive: (for example in atmel_spi it should look as follows: 511 if (xfer->cs_change) { 512 cs_deactivate(as, msg->spi); 513 udelay(xfer->cs_inact_delay); 514 cs_activate(as, msg->spi); 515 } )
Another problem, which I've faced was a little misleading description of the cs_change. It has one additional functionality (at least in atmel_spi.c): When cs_change is set in the last transfer in a message, CS is not deactivated after the last transfer and is still active until the next spi_message is serviced (see http://lxr.linux.no/linux+v2.6.37.1/drivers/spi/atmel_spi.c#L395 , called from http://lxr.linux.no/linux+v2.6.37.1/drivers/spi/atmel_spi.c#L508 - if cs_change is non-zero, then "stay" is non-zero, and CS is not deactivated).
I don't know whether it is a bug or an undocumented feature... -- Best Regards, Wojciech Zabolotny
| |