SPI, _sz fields in struct spi_command

[Bernd Walter]

On Wed, Feb 20, 2013 at 10:40:35AM -0500, Patrick Kelsey wrote:
> 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.

The AT91 SPI always has data for both directions.
It has a register for word to send and a register for words received.
With DMA you tell to automatically fill/empty those registers from/to
one memory region.
You have two DMA buffers for each direction, so you can interleave.
They are automatically switched and you can recofigure the other.
If e.g. you only have something to send and only supply a DMA buffer
for send data, then the RX register gets filled, but never emptied.
There is no overflow in master mode, the controller just stops until
you empty the register.
You can either empty each time with single interrupt overhead or supply
some DMA memory as bit bucket.
Same with RX-only - you need to fill the send register with dummy data,
so easiest is to supply a dummy DMA-buffer.
Some devices expect the dummy send buffer to be filled with 0xff, so
that they don't interet it as a command.
Supplying dummy memory for DMA hurts for large transfers, but seems to
be unavoidable with some hardware.
With the AT91 SPI you can use smaller dummy buffers and interleave them
to reduce memory requirement, but I think the OS overhead is to big.

> 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.

If it is SPI hardware drivers decision you at least nee to take into
account that in some RX-only cases you need 0xff dummy data.
The slave chip driver knows if the device parses received data, but
the master chip driver won't.

> 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.

This destroys the send data, which is not always welcome behavour.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.