Date: Wed, 20 Feb 2013 13:57:52 -0500 From: Patrick Kelsey <kelsey@ieee.org> To: ticso@cicely.de 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: <CAD44qMXsdrhuNRbpA1a9ikj4BGffVfhv1WY6hsqCxHwVzQAdsg@mail.gmail.com> In-Reply-To: <20130220174449.GB6976@cicely7.cicely.de> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <CAD44qMXkFH9iR=ym1XBtD88HRadpGkO=WRYvz5xhAVucEuoLEA@mail.gmail.com> <20130220174449.GB6976@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 20, 2013 at 12:44 PM, Bernd Walter <ticso@cicely7.cicely.de> wrote: > On Wed, Feb 20, 2013 at 10:40:35AM -0500, Patrick Kelsey wrote: >> 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. > My comments are in the overall context of extending the functionality of the existing SPI bus interface in ways that provide programming conveniences to those who wish to use them. I am not suggesting in any way that the current interface be narrowed based on any set of assumptions, so in my view, there will always be a facility for fully independent transmit and receive buffers specified by the caller. My example (2) was for a slave device that does not have a data input pin and thus is oblivious to any data sent. Certainly, if you have a device that can receive data sent by the master and your code design calls for preserving the send data across bus transactions, you would continue to use two separate buffers. -Patrick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD44qMXsdrhuNRbpA1a9ikj4BGffVfhv1WY6hsqCxHwVzQAdsg>