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
>
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
missed
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
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
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
> > 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
> >> 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
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
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
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
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
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
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 sure I'd expect
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
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, for
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
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 rejection
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
18 matches
Mail list logo
