On Saturday 23 February 2008, David Brownell wrote:
...
> No, it's fully defined. "Crash my engine" is not OK. The delay
> is controlled by transfer.delay_usecs ... possibly zero, which is
> best viewed as a degenerate case.
Ooops, I missed that (the delay *is* defined in transfer.delay_usecs).
On Saturday 23 February 2008, David Brownell wrote:
...
No, it's fully defined. Crash my engine is not OK. The delay
is controlled by transfer.delay_usecs ... possibly zero, which is
best viewed as a degenerate case.
Ooops, I missed that (the delay *is* defined in transfer.delay_usecs).
So 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
>
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
> > > 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
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
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 all controller drivers to
> > reject
Hi Dave!
On Thursday 21 February 2008, 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
Hi Dave!
On Thursday 21 February 2008, 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
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 all controller drivers to
reject such
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
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
> 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
Hi!
On Thursday 21 February 2008, Atsushi Nemoto wrote:
...
> Yes. I tested it on AT91SAM9260 and it seems ENDRX rises soon.
> Though it can be possible to avoid starting DMA for zero length
> transfer, I think it is not worth to optimize for such a rare case.
Ok, verified to work on at91rm9200,
Hi!
On Thursday 21 February 2008, Atsushi Nemoto wrote:
...
Yes. I tested it on AT91SAM9260 and it seems ENDRX rises soon.
Though it can be possible to avoid starting DMA for zero length
transfer, I think it is not worth to optimize for such a rare case.
Ok, verified to work on at91rm9200,
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
On Wed, 20 Feb 2008 18:55:01 +0100, Marc Pignat <[EMAIL PROTECTED]> wrote:
> > A spi transfer with zero length is not invalid. Such transfer can be
> > used to achieve delay before first CLK edge after chipselect assertion.
> How long will be that delay?
My funny custom device requires 100us or
Hi!
On Wednesday 20 February 2008, you wrote:
> A spi transfer with zero length is not invalid. Such transfer can be
> used to achieve delay before first CLK edge after chipselect assertion.
How long will be that delay?
If they are really users of that kind of thing, this should be fixed by
A spi transfer with zero length is not invalid. Such transfer can be
used to achieve delay before first CLK edge after chipselect assertion.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
diff --git a/drivers/spi/atmel_spi.c b/drivers/spi/atmel_spi.c
index 293b7ca..5dff5e0 100644
---
A spi transfer with zero length is not invalid. Such transfer can be
used to achieve delay before first CLK edge after chipselect assertion.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
diff --git a/drivers/spi/atmel_spi.c b/drivers/spi/atmel_spi.c
index 293b7ca..5dff5e0 100644
---
Hi!
On Wednesday 20 February 2008, you wrote:
A spi transfer with zero length is not invalid. Such transfer can be
used to achieve delay before first CLK edge after chipselect assertion.
How long will be that delay?
If they are really users of that kind of thing, this should be fixed by
On Wed, 20 Feb 2008 18:55:01 +0100, Marc Pignat [EMAIL PROTECTED] wrote:
A spi transfer with zero length is not invalid. Such transfer can be
used to achieve delay before first CLK edge after chipselect assertion.
How long will be that delay?
My funny custom device requires 100us or so.
36 matches
Mail list logo
