> >> 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
