SPI subsystem delays

Matt Wood mattwood2000 at gmail.com
Mon Apr 23 11:20:38 EDT 2012


On Mon, Apr 23, 2012 at 4:35 AM, Jassi Brar <jaswinder.singh at linaro.org> wrote:
> On 23 April 2012 02:37, Matt Wood <mattwood2000 at gmail.com> wrote:
>>
>> has some specific delay requirements - specifically
>> the delay between bytes in a single transfer
>>
> Sounds like your chip specific quirk. Apparently throughput would
> be the last of your concerns :D
> Perhaps you have to do single byte transfers with appropriate
> non-zero 'delay_usecs' and skilfully toggle 'cs_change' for
> each transfer.
>
>> delay between chip select assertion and the first clock edge
>>
> IMO that could already be done from within your controller driver.
>
>> and the delay between consecutive transfers.
>>
> Why not spi_transfer.delay_usecs ?
>
> -jassi

Hi Jassi, thanks for the reply.

> Sounds like your chip specific quirk. Apparently throughput would
> be the last of your concerns :D

Indeed, this is a very quirky device and throughput is not an issue.

> Why not spi_transfer.delay_usecs ?

This does not address the delay from chip select assertion to the
first edge of the serial clock, nor does it address the delay between
bytes within a single spi_message.  I agree that single byte transfers
might work especially with spi_transfer.cs_change = 0, however that
makes the code cumbersome with all those byte transfers and still does
not help with the CS to SPCK timings as I mentioned.

It would seem to me that if the hardware supports delays, then it
would be advantageous to add these attributes to the SPI framework.
Also, it would not be an expensive addition to add these attributes to
spi_device structure as my patch does.

Thoughts?

Thanks, Matt.



More information about the linux-arm-kernel mailing list