Date: Wed, 20 Feb 2013 07:34:32 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> 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: <5C3022E6-AEDB-4403-B5C1-E6EA6F9451EE@bsdimp.com> In-Reply-To: <1361370730.1185.10.camel@revolution.hippie.lan> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <1361370730.1185.10.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>>=20
>>> Hello ARM and MIPS hackers!
>>>=20
>>> Sorry for cross-post, but we have supported SPI devices on both
>>> platforms (and seems no others).
>>>=20
>>> Anyone know any reasons to keep both TX and RX _sz fields with same
>>> values?
>>=20
>> 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...
>>=20
>>> sys/dev/flash/at45d.c
>>> static int
>>> at45d_get_mfg_info(device_t dev, uint8_t *resp)
>>> {
>>> ...
>>> cmd.tx_cmd_sz =3D cmd.rx_cmd_sz =3D 5;
>>> ...
>>> }
>>>=20
>>> 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 =3D 5;
>>> cmd.rx_cmd_sz =3D 5;
>>> ...
>>> }
>>>=20
>>> 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.
>>=20
>> The AT91, I think, required a minimum size, which is why the at45d =
driver set it I think..
>>=20
>> 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...
>>=20
>> Warner
>=20
> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5C3022E6-AEDB-4403-B5C1-E6EA6F9451EE>