Date: Wed, 20 Feb 2013 10:40:35 -0500 From: Patrick Kelsey <kelsey@ieee.org> To: Warner Losh <imp@bsdimp.com> Cc: Aleksandr Rybalko <ray@freebsd.org>, freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: Re: SPI, _sz fields in struct spi_command Message-ID: <CAD44qMXkFH9iR=ym1XBtD88HRadpGkO=WRYvz5xhAVucEuoLEA@mail.gmail.com> In-Reply-To: <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 20, 2013 at 9:15 AM, Warner Losh <imp@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD44qMXkFH9iR=ym1XBtD88HRadpGkO=WRYvz5xhAVucEuoLEA>