lkml.org 
[lkml]   [2008]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: spi transfer with zero length
Date
On Saturday 16 February 2008, Atsushi Nemoto wrote:
> Hi. Is it legal to use zero for 'len' field of struct spi_transfer?
> I mean, len=0, tx_buf=rx_buf=NULL, delay_usecs!=0.

Yes that should work ... it's uncommon, but not illegal. Some
controller drivers may even handle that right!

If the delay were zero and cs_change didn't indicate a need to
briefly deselect the chip, it might make sense to reject such
a NOP transfer. But that's not the case you identify.


> Some SPI devices need slightly long delay before first CLK edge after
> CS assertion.

For future reference ... could you identify a few such devices,
and say what "long" is relative to the clock period?

Some folk have just slowed down the clock in such cases, but
that's rather sub-optimal.


> To achieve this, I think inserting using a zero length
> transfer before real transfers. But it seems some drivers do not
> handle this case properly.

Feel free to submit patches fixing those bugs.


> Is this driver's bug, or we need additional delay field in struct
> spi_device for such case?

I'd like to avoid new parameters to cover case that can already
be expressed in the programming interface. Cases that can't be
expressed ... different issue. I suspect any patches updating
timing parameters should use nanoseconds not microseconds, fwiw.

- Dave


\
 
 \ /
  Last update: 2008-02-16 20:01    [W:0.042 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site