LKML Archive on
help / color / mirror / Atom feed
From: Ned Forrester <>
To: David Brownell <>
Subject: Re: [spi-devel-general] [PATCH] atmel_spi: support zero length	transfer
Date: Fri, 22 Feb 2008 09:07:48 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

David Brownell wrote:
>> David, do you think writing 0 bytes is a valid use of this API?
> Just a zero byte transfer ... no, though it depends what you mean
> by "valid".  (I'm not sure I'd expect all controller drivers to
> reject such requests.)  That has no effect on bits-on-the-wire,
> and would make trouble for various DMA engines.

FWIW, the pxa2xx_spi driver does not, near as I can tell, reject zero
length transfers, it will go through the motions, the same as for any
other transfer.

However, if the transfer is by DMA, note that the PXA255 and PXA270
Developer's Manuals have the following language regarding DMA lengths:

	"LEN = 0 means zero bytes for descriptor-fetch transactions.
	LEN = 0 is an invalid setting for no-descriptor-fetch
	transactions. Programming LEN = 0 in the descriptor-fetch mode
	when DCMD[CmpEn] is clear (normal data transfer mode) causes
	the channel to immediately discard the descriptor after it is
	fetched from memory. If the descriptor chain has more
	descriptors, the channel fetches the next valid descriptor.
	The channel stops if the descriptor chain has no more

Because the pxa2xx_spi driver does not currently use DMA descriptors,
zero length DMAs are invalid.  I don't know what the DMA controller will
do if given a zero length.  If it were using using descriptors (as in my
development code, useful only when chaining transfers that don't need
any SSP parameters or chip selects changed, nor any time delays), then a
zero length transfer would only introduce the insignificant delay of
fetching one 4-word descriptor.

If, on the other hand, DMA is not used, it looks like the zero length
case is handled gracefully.  The chip select and other SSP registers are
set, but no bytes are transferred.  It does not look like any particular
delay would be involved in this, as all transfers within a message are
handled in interrupt context with an ISR and tasklet.  There is not much
code being executed to limit the minimum delay, and the maximum would
depend on interrupt/tasklet latency.

> Passing zero bytes to get an inline delay at an exact spot in the
> overall protocol message ... I don't see why not.  Better than
> adding delay fields for every spot it might be needed by various
> oddball devices, for sure!!

I agree with Marc: any such delay will be undefined, in the general
case.  It might work for a specific driver implementation.

Ned Forrester                             
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA

  parent reply	other threads:[~2008-02-22 14:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-20 15:54 Atsushi Nemoto
2008-02-20 17:55 ` Marc Pignat
2008-02-21  1:52   ` Atsushi Nemoto
2008-02-21  9:26     ` Marc Pignat
2008-02-21 19:23       ` David Brownell
2008-02-22  9:30         ` Marc Pignat
2008-02-22 14:15           ` Atsushi Nemoto
2008-02-22 14:28             ` [spi-devel-general] " Ned Forrester
2008-02-22 19:06               ` David Brownell
2008-02-22 19:52                 ` Ned Forrester
2008-02-22 18:58             ` David Brownell
2008-02-23  2:55           ` David Brownell
2008-02-25  8:15             ` Marc Pignat
2008-02-22 14:07         ` Ned Forrester [this message]
2008-02-22 19:02           ` [spi-devel-general] " David Brownell
2008-02-22 19:36             ` Ned Forrester
2008-02-23  2:37               ` David Brownell
2008-02-25  0:25               ` Atsushi Nemoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [spi-devel-general] [PATCH] atmel_spi: support zero length	transfer' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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