LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* spi transfer with zero length
@ 2008-02-16 14:02 Atsushi Nemoto
  2008-02-16 18:58 ` David Brownell
  0 siblings, 1 reply; 3+ messages in thread
From: Atsushi Nemoto @ 2008-02-16 14:02 UTC (permalink / raw)
  To: David Brownell, spi-devel-general, linux-kernel

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.

Some SPI devices need slightly long delay before first CLK edge after
CS assertion.  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.

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

---
Atsushi Nemoto

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: spi transfer with zero length
  2008-02-16 14:02 spi transfer with zero length Atsushi Nemoto
@ 2008-02-16 18:58 ` David Brownell
  2008-02-17 14:16   ` Atsushi Nemoto
  0 siblings, 1 reply; 3+ messages in thread
From: David Brownell @ 2008-02-16 18:58 UTC (permalink / raw)
  To: Atsushi Nemoto; +Cc: spi-devel-general, linux-kernel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: spi transfer with zero length
  2008-02-16 18:58 ` David Brownell
@ 2008-02-17 14:16   ` Atsushi Nemoto
  0 siblings, 0 replies; 3+ messages in thread
From: Atsushi Nemoto @ 2008-02-17 14:16 UTC (permalink / raw)
  To: david-b; +Cc: spi-devel-general, linux-kernel

On Sat, 16 Feb 2008 10:58:48 -0800, David Brownell <david-b@pacbell.net> wrote:
> 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.

Thank you.  I suppose spi-bitbang can handle that right.  Then I'm
going to fix drivers if it cannot handle such case.

> > 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.

Well, the device I have is so special custom one implemented by PIC or
something.  It needs 100us or so with 200ns clock period.  Slowing
down might be an another solution but some spi driver cannot use such
a slow bitrate (~10KHz).

> > 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.

OK, if I had enough time to make a patch for uptodate version of the
driver ;)

---
Atsushi Nemoto

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-02-17 14:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-16 14:02 spi transfer with zero length Atsushi Nemoto
2008-02-16 18:58 ` David Brownell
2008-02-17 14:16   ` Atsushi Nemoto

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).