lkml.org 
[lkml]   [2008]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [spi-devel-general] [PATCH] atmel_spi: support zero length transfer
> >> 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.

Makes sense to me ... although:

> 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. ...
>
> Because the pxa2xx_spi driver does not currently use DMA descriptors,
> zero length DMAs are invalid.

In that case the pxa2xx_spi driver should add a special case to
avoid starting such transfers in DMA mode.


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

Is that what Marc said? I couldn't tell. In any case, I disagree;
the semantics of that delay are clearly defined.

- Dave



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