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

2008-02-24 Thread Atsushi Nemoto
On Fri, 22 Feb 2008 14:36:53 -0500, Ned Forrester <[EMAIL PROTECTED]> wrote: > Or are you and Atsushi talking about using spi_transfer.delay_usecs > *with* a zero length transfer to effectively put a delay between the > assertion of CS and the start of the first clock? If so, then I guess I > miss

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

2008-02-22 Thread David Brownell
On Friday 22 February 2008, Ned Forrester wrote: > > So, what I think you said is that it would be better for pxa2xx_spi to > silently ignore a zero-length message, passing it back with the rest of > the message when all is complete, than to reject the message. Yes. Remember that the reason to _

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

2008-02-22 Thread Ned Forrester
David Brownell wrote: >> This would be OK. It would not be hard to fix pxa2xx_spi, for example, >> to reject zero-length transfers in DMA mode, as long as it is acceptable >> to reject the message in mid-message. > > Such "illegal message" rejection is best done early; "fail-fast". > Mid-message

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

2008-02-22 Thread Ned Forrester
David Brownell wrote: >> 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

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

2008-02-22 Thread David Brownell
> > If the driver could not handle zero length transfer, then the driver > > should reject it (just like unsupported transfer mode). Then the > > behavior will be 'assert chip select and wait some time' or 'rejected > > by the driver'. > > This would be OK. It would not be hard to fix pxa2xx_spi,

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

2008-02-22 Thread David Brownell
> >> 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 t

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

2008-02-22 Thread David Brownell
Quoth Atsushi Nemoto on Fri, 22 Feb 2008: > On Fri, 22 Feb 2008 10:30:31 +0100, Marc Pignat <[EMAIL PROTECTED]> 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 s

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

2008-02-22 Thread 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 wo

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

2008-02-22 Thread Ned Forrester
Atsushi Nemoto wrote: > If the driver could not handle zero length transfer, then the driver > should reject it (just like unsupported transfer mode). Then the > behavior will be 'assert chip select and wait some time' or 'rejected > by the driver'. This would be OK. It would not be hard to fix