SPI, _sz fields in struct spi_command

[Warner Losh]

On Feb 20, 2013, at 7:32 AM, Ian Lepore wrote:

> On Wed, 2013-02-20 at 07:15 -0700, Warner Losh 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...
>> 
>>> sys/dev/flash/at45d.c
>>> static int
>>> at45d_get_mfg_info(device_t dev, uint8_t *resp)
>>> {
>>> 	...
>>> 	cmd.tx_cmd_sz = cmd.rx_cmd_sz = 5;
>>> 	...
>>> }
>>> 
>>> or sys/dev/flash/mx25l.c
>>> static int
>>> mx25l_read(device_t dev, off_t offset, caddr_t data, off_t count)
>>> {
>>> 	...
>>> 	cmd.tx_cmd_sz = 5;
>>> 	cmd.rx_cmd_sz = 5;
>>> 	...
>>> }
>>> 
>>> That always require second but unused buffer or writable tx buffer. And
>>> not all controllers able to TX with RX same time. (at least rt305x
>>> can't). So if nobody have any objections, I will update drivers (SPI
>>> controllers and SPI attached devices) to set unused _sz field to zero.
>>> IIRC, I will require help with AT91 controller update, at least with
>>> testing.
>> 
>> The AT91, I think, required a minimum size, which is why the at45d driver set it I think..
>> 
>> I can't imagine an SPI controller that can't do both, because when you write something with SPI, you usually have to read back the status at the same time...
>> 
>> Warner
> 
> I think with at91 you really must do same-sized xfers in both directions
> or you'll get underflow/overflow errors from the hardware.  It might be
> possible to just ignore the error, but even then the only useful way the
> xfer sizes could be different is one of them would be zero.  Different
> non-zero sizes just don't make sense.

Does 0 really work? I have a vague memory of trying to allow it when I first wrote the driver and having it fail badly on the AT91RM9200...

Warner

Warner