Re: propper support of 5 wire SPI (SPI_READY signal)

[Oleksij Rempel <linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1670 bytes --]

Am 12.03.2016 um 08:21 schrieb Mark Brown:
> On Mon, Feb 22, 2016 at 12:42:59PM +0100, Oleksij Rempel wrote:
>> Am 22.02.2016 um 12:09 schrieb Mark Brown:
> 
>>> Oh, so this isn't SPI_READY?
> 
>> Not 100%.
>> According to TI documentation, transfer initiated by master looks like:
>> 1. Master: SPIx_CS (on)
>> 2. Slave: SPIx_READY (on)
>> 3. Master: Date transfer
>> 4. Slave: SPIx_READY (off)
>> 5. Master: SPIx_CS (off)
> 
>> Bosch version of 5-wire transfer initiated by master:
>> 1. Master: SPIx_CS (on)
>> 2. Slave: SPIx_REQUEST (on)
>> 3. Master: Date transfer
>> 4. Master: SPIx_CS  (off)    <----- different order.
>> 5. Slave: SPIx_REQUEST (on) <-----
> 
> I can't tell the difference between these two cases.  In the first case
> the device gets busy after the data is transferred, in the second case
> it never changes the request line but really there's no meaningful
> difference I can see.
> 

There is no difference from device point of view, the difference is only
on Master side. The TI SPI Master can be stopped by Slave in the middle
of transfer, and if the data transfer was actually done, then Master
will dessert CS line.
This is why i'm trying to make a difference between slaves which will
only confirm start of transfer but will never try to stop it, and Slaves
which will do it.
Because if device can use Ready line to hold or stop data transfer, then
this support can be implemented only by limited number of SPI Master
controllers (for example, currently only by: spi-davinci and spi-gpio).

In case of Bosch implementation, the slave should actually confirm
change of CS.
-- 
Regards,
Oleksij


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]