SPI, _sz fields in struct spi_command

[Patrick Kelsey]

On Wed, Feb 20, 2013 at 9:15 AM, Warner Losh <imp at bsdimp.com> wrote:
>
>
> On Feb 20, 2013, at 5:21 AM, Aleksandr Rybalko wrote:
>
> > Hello ARM and MIPS hackers!
> >
> > Sorry for cross-post, but we have supported SPI devices on both
> > platforms (and seems no others).
> >
> > Anyone know any reasons to keep both TX and RX _sz fields with same
> > values?
>
> I wrote them to be separate for a reason....  I think I'd thought there'd be cases when you'd want to throw away the results or transmit garbage...  I can't think of why right now...


Per the spec, there is always a data bit available to be received on
the bus for each data bit clocked out.  Per the application, all of
those bits are not always of interest.  There are a few examples that
exist in the world that I am aware of where the data transmitted or
received on the SPI bus is of no interest to at least one participant
in the transaction:

1. Some devices only implement SDI.  One example would be a low
cost/low pin count DAC such as the AD5662.  In this case, the host
would never be interested in the data received from the SPI bus during
transmissions to the DAC.

2. Some devices only implement SDO.  One example would be a low
cost/low pin count ADC, such as the AD7091.  In this case, the host
could safely transmit undefined data on the bus when retrieving data
from the ADC.

3. The protocol that rides on the SPI is in whole or in part half duplex.
    (a) The protocol for talking to MMC/SD cards over SPI is entirely
half duplex.  When information is sent to the card from the host, all
bits received from the card during the transmission are discarded.
When the host wants to read data from the card, it transmits all ones
bits.
    (b)  At least some Broadcom switch chips provide no meaningful
receive data during command transmit.


In (1) and (3) above, the drivers for those chips could usefully tell
the SPI bus interface that they aren't interested in received data
when transmitting to the SPI-attached devices, and certainly it would
be at least a small convenience to such SPI interface consumers to
have the lower level driver handle it.  Since not all host-side SPI
interface hardware supports discarding received data, to allow a
zero-sized receive buffer in the command passed down, at least some
SPI interface hardware drivers will have to dynamically allocate or
maintain a static discard buffer and provide error responses for
allocation-failure or transfer-too-large.

Example (2) is equally easy to handle on either side of the SPI bus
interface by pointing the transmit buffer pointer at the receive
buffer.

-Patrick