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

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

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