propper support of 5 wire SPI (SPI_READY signal)

propper support of 5 wire SPI (SPI_READY signal)

[Oleksij Rempel]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

Hallo all,

i'm working on a project which depends on 5 Wire SPI communication. It
is probably identical to spi-davinci.c with SPI_READY signal. Only
difference is that SPI_READY is not supported by hardware, in this case
GPIO input is used.

Currently this project implements SPI_READY and CS on top of spidev
driver. What makes it really ugly, slow and complicated.

My question is, are there any better, upstreamable way to implement it?
For example directly insight of spi framework? Any suggestions and
comments are welcome.
-- 
Regards,
Oleksij


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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

On Fri, Feb 19, 2016 at 10:08:46AM +0100, Oleksij Rempel wrote:

> i'm working on a project which depends on 5 Wire SPI communication. It
> is probably identical to spi-davinci.c with SPI_READY signal. Only
> difference is that SPI_READY is not supported by hardware, in this case
> GPIO input is used.

> Currently this project implements SPI_READY and CS on top of spidev
> driver. What makes it really ugly, slow and complicated.

> My question is, are there any better, upstreamable way to implement it?
> For example directly insight of spi framework? Any suggestions and
> comments are welcome.

Unless the hardware support SPI_READY a GPIO is going to be as good as
it gets I think, someone else might have better ideas but nothing
springs to mind for me.  I'd be OK with a GPIO based implementation in
the core for systems that don't have hardware support for it but I don't
see anything that'd be fundamentally better in terms of system
performance right now.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Oleksij Rempel]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

Am 20.02.2016 um 20:56 schrieb Mark Brown:
> On Fri, Feb 19, 2016 at 10:08:46AM +0100, Oleksij Rempel wrote:
> 
>> i'm working on a project which depends on 5 Wire SPI communication. It
>> is probably identical to spi-davinci.c with SPI_READY signal. Only
>> difference is that SPI_READY is not supported by hardware, in this case
>> GPIO input is used.
> 
>> Currently this project implements SPI_READY and CS on top of spidev
>> driver. What makes it really ugly, slow and complicated.
> 
>> My question is, are there any better, upstreamable way to implement it?
>> For example directly insight of spi framework? Any suggestions and
>> comments are welcome.
> 
> Unless the hardware support SPI_READY a GPIO is going to be as good as
> it gets I think, someone else might have better ideas but nothing
> springs to mind for me.  I'd be OK with a GPIO based implementation in
> the core for systems that don't have hardware support for it but I don't
> see anything that'd be fundamentally better in terms of system
> performance right now.
> 

Ok, i'm working on it.

I would need some naming suggestions (we call our protokol SSI). It
looks like the protocol used by us has some differences with Davinci.
The Dav. using SPI_READY line only
to allow or pause transmission (fix me if i'm wrong)
We call it Request line and use it to: Ready to Receive; Receive
Finished; and Request data shift by slave.

In this case probably spi framework need to be extended with kind of
request call back. If data is currently not transmitted and Req line is
not used for flow control, then call driver specific function to
initiate data shift.

-- 
Regards,
Oleksij


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

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

[Geert Uytterhoeven]

Hi Oleksij,

On Fri, Feb 19, 2016 at 10:08 AM, Oleksij Rempel <linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> wrote:
> i'm working on a project which depends on 5 Wire SPI communication. It
> is probably identical to spi-davinci.c with SPI_READY signal. Only
> difference is that SPI_READY is not supported by hardware, in this case
> GPIO input is used.

Sounds interesting!

> Currently this project implements SPI_READY and CS on top of spidev
> driver. What makes it really ugly, slow and complicated.

Can you please point me to some SPI slave hardware that supports this?

Thanks a lot!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

On Sat, Feb 20, 2016 at 10:40:52PM +0100, Oleksij Rempel wrote:

> I would need some naming suggestions (we call our protokol SSI). It
> looks like the protocol used by us has some differences with Davinci.
> The Dav. using SPI_READY line only
> to allow or pause transmission (fix me if i'm wrong)
> We call it Request line and use it to: Ready to Receive; Receive
> Finished; and Request data shift by slave.

Oh, so this isn't SPI_READY?

> In this case probably spi framework need to be extended with kind of
> request call back. If data is currently not transmitted and Req line is
> not used for flow control, then call driver specific function to
> initiate data shift.

This is sounding awfully like SPI slave support?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Oleksij Rempel]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

Am 22.02.2016 um 10:21 schrieb Geert Uytterhoeven:
> Hi Oleksij,
> 
> On Fri, Feb 19, 2016 at 10:08 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> i'm working on a project which depends on 5 Wire SPI communication. It
>> is probably identical to spi-davinci.c with SPI_READY signal. Only
>> difference is that SPI_READY is not supported by hardware, in this case
>> GPIO input is used.
> 
> Sounds interesting!
> 
>> Currently this project implements SPI_READY and CS on top of spidev
>> driver. What makes it really ugly, slow and complicated.
> 
> Can you please point me to some SPI slave hardware that supports this?

It is automotive filed. Used for inter chip communication.
There are many products with it. Currently i can't say more :(

> 
> Thanks a lot!
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> 


-- 
Regards,
Oleksij


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

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

[Oleksij Rempel]

[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]

Am 22.02.2016 um 12:09 schrieb Mark Brown:
> On Sat, Feb 20, 2016 at 10:40:52PM +0100, Oleksij Rempel wrote:
> 
>> I would need some naming suggestions (we call our protokol SSI). It
>> looks like the protocol used by us has some differences with Davinci.
>> The Dav. using SPI_READY line only
>> to allow or pause transmission (fix me if i'm wrong)
>> We call it Request line and use it to: Ready to Receive; Receive
>> Finished; and Request data shift by slave.
> 
> 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) <-----


> 
>> In this case probably spi framework need to be extended with kind of
>> request call back. If data is currently not transmitted and Req line is
>> not used for flow control, then call driver specific function to
>> initiate data shift.
> 
> This is sounding awfully like SPI slave support?

Not completely. Transfer initiated by Slave has only one difference to
Master transfer.

Bosch version of 5-wire transfer initiated by slave:
1. Slave: SPIx_REQUEST (on) <----- different order.
2. Master: SPIx_CS (on)  <----
3. Master: Date transfer
4. Master: SPIx_CS (off)
5. Slave: SPIx_REQUEST (off)

-- 
Regards,
Oleksij


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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Oleksij Rempel]

[-- 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 --]