Re: [spi-devel-general] [PATCH] atmel_spi: support zero length transfer

[Ned Forrester]

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

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                                       nforrester@xxxxxxxx
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/