SPI subsystem delays

SPI subsystem delays

[Matt Wood]

Hi folks, this is my first post to the list, so I apologize if I
missed similar topics from the past.

I'm working on a driver for a SPI based peripheral but have run into
some issues with the timing requirements.  The device I'm working with
is very slow, and has some specific delay requirements - specifically
the delay between bytes in a single transfer, delay between chip
select assertion and the first clock edge, and the delay between
consecutive transfers.  The platform I'm developing on and most
comfortable with is the Atmel ARM9 series.

I notice in the spi_device subsystem structure there are no provisions
for the delays in the mainline instantiation although the comments
seem to suggest additions such as these are expected or at least
anticipated.

So I guess my question is am I the only one who has been working with
a device that require very specific timings?  I know most modern SPI
devices are application specific silicon and are designed to run as
fast as possible (i.e serial flash, etc.), but I know there are some
devices out there that require more strict timings.

I suppose what I'm getting at is a patch proposal to add attributes
such as DLYBCT (Delay Between Consecutive Transfers), DLYBS (Delay
Before Serial Clock), DLYBCS (Delay Between Chip Selects) - again as
I'm most comfortable with Atmel's ARM SPI peripheral, so I'm used to
these hardware features.

With the driver I'm working on I have had to patch the SPI subsystem
to get the device operate correctly, so the code is not a question,
but I wonder what other people's thoughts are on this, and if there
are reasons why not to add these attributes - they could simply be
zeroed out by default for hardware that does not need to or cannot
implement them.

Thanks for the read.

Regards, Matt.

SPI subsystem delays

[Jassi Brar]

On 23 April 2012 02:37, Matt Wood <mattwood2000@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

SPI subsystem delays

[Matt Wood]

On Mon, Apr 23, 2012 at 4:35 AM, Jassi Brar <jaswinder.singh@linaro.org> wrote:
> On 23 April 2012 02:37, Matt Wood <mattwood2000@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.