Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Feb 2013 19:49:20 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Aleksandr Rybalko <ray@freebsd.org>
Cc:        freebsd-arm@freebsd.org, ticso@cicely.de, freebsd-mips@freebsd.org
Subject:   Re: SPI, _sz fields in struct spi_command
Message-ID:  <62EDE91B-DDF3-462D-8802-7A7FBF00CE91@bsdimp.com>
In-Reply-To: <20130221022655.6f693eb6.ray@freebsd.org>
References:  <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <CAD44qMXkFH9iR=ym1XBtD88HRadpGkO=WRYvz5xhAVucEuoLEA@mail.gmail.com> <20130220174449.GB6976@cicely7.cicely.de> <CAD44qMXsdrhuNRbpA1a9ikj4BGffVfhv1WY6hsqCxHwVzQAdsg@mail.gmail.com> <20130221022655.6f693eb6.ray@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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

> On Wed, 20 Feb 2013 13:57:52 -0500
> Patrick Kelsey <kelsey@ieee.org> wrote:
>=20
>> 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:
>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>>> 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.
>>>=20
>>> This destroys the send data, which is not always welcome behavour.
>>>=20
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> -Patrick
>=20
> 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 =3D=3D 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!
>=20
> WBW
> --=20
> Aleksandr Rybalko <ray@freebsd.org>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?62EDE91B-DDF3-462D-8802-7A7FBF00CE91>