SPI, _sz fields in struct spi_command

[Warner Losh]

On Feb 20, 2013, at 5:26 PM, Aleksandr Rybalko wrote:

> On Wed, 20 Feb 2013 13:57:52 -0500
> Patrick Kelsey <kelsey at ieee.org> wrote:
> 
>> On Wed, Feb 20, 2013 at 12:44 PM, Bernd Walter
>> <ticso at 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
> 
> Thanks to all for interesting comments, some of my keys for that topic
> you all already said but I say it again anyway :)
> So why I ask about that:
> 1. Do we really need to allocate second unused buffer?

Yes, but we could push that requirement into the spi host adapter drivr.

> 2. Do we really need to spend clock cycles on that buffer?

The way SPI works is that the cycles are spent, because TX cycles have to equal RX cycles.

> 3. Ralink-s SPI can't do bidirectional transfer (IIRC I've tested it
> properly, only 1 8bits reg for both RX and TX and same data on read
> after TX byte) (Sorry for not commited yet, will do, hope soon :) )
> 4. Since we have sz for both direction and both types (cmd, data) why
> controller drivers force us to make it equal? (at91_spi_transfer
> KASSERT)

Because they must be equal.  However, if we're pushing the buffer management down a level, then we can remove them.

> What I think we need to do with that:
> 1. remove KASSERT in controller drivers, make driver to accept at least
> cases when (tx_sz == rx_sz), (tx_sz && !rx_sz), (!tx_sz && rx_sz). Plus
> if controller require some buffer to drain into it (don't know how to
> correctly say in English what men do after many beers :) ) allocate it
> or make some static buffer.

Yes, moving the responsibility from the driver to the spi controller would be possible.

> 2. teach consumers to give only correct numbers (very nice we have only
> two SPI devices in tree)

I thought the at45 was bidirectional...

> After that we will be able to make drivers for some (potential) devices
> which will require bidirectional communication. And controllers which
> can't do that, will just report error in that. I believe peoples thinks
> before attach such devices to controllers, so we will not have such
> incompatibility.

If this feature becomes optional, we should have some way for the controller to communicate that it can do bidirectional transfers. If we have that, then such a device could refuse to attach on machines with controllers that can't do htat.

> Hope I'm not forget something important :-D

No, that's OK.

Warner

> Thanks to all!
> 
> WBW
> -- 
> Aleksandr Rybalko <ray at freebsd.org>