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:
signature.asc
Description: OpenPGP digital signature
