ommend that you read the archives of this mailing list to
understand the limitations of a potential slave mode. The archives can
be found at:
http://sourceforge.net/mailarchive/forum.php?forum_name=spi-devel-general
then look for threads with "slave" in the subject in the following
mo
to return the message with non-zero
spi_message.status if it has failed *after* execution has been
attempted. I don't look forward to making major changes, if we really
want all DMA mapping and error checking to be in transfer(), though I
see no reason why it could not be done.
--
Ned Forre
plemented between the last bit movement of a
transfer and any change of CS at the end of a transfer. Is that right?
I think that pxa2xx_spi is dropping CS, if requested, immediately at
the end of transfer, and then putting spi_transfer.delay_usecs between
that transfer and t
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.
--
Ned Forrester [EMAIL PROTECTED]
Oceanographic Systems Lab
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. If it were necessary to scan a
whole message for zero-length transfers and refuse to queue an offending
message, then that adds
5 matches
Mail list logo
