From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roger =?ISO-8859-1?Q?Fr=F8ysaa?= Subject: Status of Linux SPI slave Date: Thu, 27 Sep 2007 10:16:39 +0200 Message-ID: <1190880999.29726.5.camel@shuttle> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0863046288==" To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org --===============0863046288== Content-Type: multipart/alternative; boundary="=-EbjcmQYbKDFduUcLPUUz" --=-EbjcmQYbKDFduUcLPUUz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi. I'm wondering if there are any plans to add SPI slave mode to the SPI driver framework in the "near" future? Is anyone working on something like this? If not, has anyone ever considered it - and estimated the amount of work it would be etc? Any feedback would be greatly appreciated. --=20 Roger Fr=C3=B8ysaa --=-EbjcmQYbKDFduUcLPUUz Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi.

I'm wondering if there are any plans to add SPI slave mode to the SPI driver framework in the "near" future? Is anyone working on something like this?

If not, has anyone ever considered it - and estimated the amount of work it would be etc?

Any feedback would be greatly appreciated.


--
Roger Frøysaa <roger-UslnteNVNtIXWF+eFR7m5Q@public.gmane.org>
--=-EbjcmQYbKDFduUcLPUUz-- --===============0863046288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ --===============0863046288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ spi-devel-general mailing list spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/spi-devel-general --===============0863046288==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Subject: Re: Status of Linux SPI slave Date: Sat, 13 Oct 2007 08:47:47 -0700 Message-ID: <20071013154747.2F7B023A5F4@adsl-69-226-248-13.dsl.pltn13.pacbell.net> References: <1190880999.29726.5.camel@shuttle> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, roger-UslnteNVNtIXWF+eFR7m5Q@public.gmane.org Return-path: In-Reply-To: <1190880999.29726.5.camel@shuttle> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org PiBGcm9tOiBSb2dlciBGcsO4eXNhYSA8cm9nZXJAYml0ZnJvc3Qubm8+Cj4gVG86IHNwaS1kZXZl bC1nZW5lcmFsQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAoKU29ycnkgZm9yIHRoZSBkZWxheWVkIHJl c3BvbnNlIC4uLiB5b3Ugc2VudCBpdCBhcyBIVE1MIG1haWwsIHNvIGl0CmxhbmRlZCBpbiBhIHNw YW10cmFwLgoKCj4gSSdtIHdvbmRlcmluZyBpZiB0aGVyZSBhcmUgYW55IHBsYW5zIHRvIGFkZCBT UEkgc2xhdmUgbW9kZSB0byB0aGUgU1BJCj4gZHJpdmVyIGZyYW1ld29yayBpbiB0aGUgIm5lYXIi IGZ1dHVyZT8gSXMgYW55b25lIHdvcmtpbmcgb24gc29tZXRoaW5nCj4gbGlrZSB0aGlzPwoKSSBk b24ndCBrbm93IG9mIGFueSBzdWNoIHBsYW5zLCB0aG91Z2ggaWYgeW91IGxvb2sgdGhyb3VnaCBs aXN0CmFyY2hpdmVzIHlvdSdsbCBmaW5kIG90aGVyIHBlb3BsZSB3aG8ndmUgYXNrZWQgYWJvdXQg aXQuCgoKPiBJZiBub3QsIGhhcyBhbnlvbmUgZXZlciBjb25zaWRlcmVkIGl0IC0gYW5kIGVzdGlt YXRlZCB0aGUgYW1vdW50IG9mIHdvcmsKPiBpdCB3b3VsZCBiZSBldGM/CgpUaGUgZmlyc3QgdGFz ayBpcyB0byBjb21lIHVwIHdpdGggYSB3b3JrYWJsZSBkZXNpZ24uICBUaGVuIHdvdWxkCmNvbWUg aW1wbGVtZW50aW5nIGl0LgoKClRoZSBmaXJzdCBpc3N1ZXMgdGhhdCBjb21lIHRvIG1pbmQgYXJl IHRlY2huaWNhbC4gIFRoZXJlJ3MgYW4gaXNzdWUKb2YgcmVzcG9uc2UgdGltZSAuLi4gc2luY2Ug U1BJIGhhcyBubyBmbG93IGNvbnRyb2wsIHR5cGljYWwgdHlwZXMgb2YKcmVxdWVzdC9yZXNwb25z ZSBwcm90b2NvbCBoYXZlIGhhcmQgcmVzcG9uc2UgdGltZSBsaW1pdHMuICBTbyB0aGUgUlQKc3Rh Y2sgbWF5IGJlIGltcGxpY2l0bHkgcmVxdWlyZWQsIGV4Y2VwdCBmb3IgdmVyeSBzbG93IHNsYXZl LgoKRXhhbXBsZTogIHByb3RvY29sIHNwZWMgc2F5cyBTUEkgbWFzdGVyIHNlbmRzIHR3byBieXRl cyBvZiBjb21tYW5kLAp0aGVuIHRoZSBTUEkgc2xhdmUgc2VuZHMgTiBieXRlcyBvZiByZXNwb25z ZS4gIFRoYXQgbWVhbnMgYXQgbGVhc3QKcGFydCBvZiB0aGUgcmVzcG9uc2UgbXVzdCBiZSBjb21w dXRlZCB0aGVuIGlzc3VlZCB3aXRoaW4gb25lIGJpdAp0aW1lLCByaWdodCBhZnRlciB0aGUgbGFz dCBiaXQgc2VudCBmcm9tIHRoZSBtYXN0ZXIuCgpDbGVhcmx5LCBpbmNyZWFzaW5nIGJpdCB0aW1l cyAoc2xvd2luZyB0aGUgU1BJIGNsb2NrKSBjYW4gaGVscC4KU28gY2FuIHN1cHBvcnRpbmcgcHJv dG9jb2xzIHRoYXQgdXNlIHN0dWZmIGxpa2UgZHVtbXkgYnl0ZXMsIHdoaWNoCmNhbiBhbGxvdyBt b3JlIHRpbWUgYmVmb3JlIHRoZSAicmVhbCIgcmVzcG9uc2UgbXVzdCBiZSByZWFkeSwgb3IKd2hp Y2ggYXJlbid0IHN0cnVjdHVyZWQgYXMgcmVxdWVzdC9yZXNwb25zZSBwcm90b2NvbHMuICAoU3Vj aCBhcwpwZXJoYXBzIGp1c3Qgc3RyZWFtaW5nIGRhdGEgc2FtcGxlcyBpbiBvbmUgZGlyZWN0aW9u IG9yIHRoZSBvdGhlci4pCgoKQSBzZWNvbmQgaXNzdWUgaXMgaG93IHRvIGZhY3RvciB0aGUgcHJv Z3JhbW1pbmcgaW50ZXJmYWNlLiAgVGhlCm5vdGlvbiBvZiBhbiBzcGlfbWVzc2FnZSBpc24ndCBu ZWNlc3NhcmlseSB3cm9uZywgYnV0IHdoZW4gc2hvdWxkCml0IGdldCBpc3N1ZWQ/ICBIb3cgd291 bGQgY29tbWFuZHMgc2VudCBieSB0aGUgaG9zdCBiZSBwYWNrYWdlZD8KSG93IHNob3VsZCBjaGlw c2VsZWN0L2Rlc2VsZWN0IGJlIHZpc2libGU/CgotIERhdmUKCgoKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpU aGlzIFNGLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IFNwbHVuayBJbmMuClN0aWxsIGdyZXBw aW5nIHRocm91Z2ggbG9nIGZpbGVzIHRvIGZpbmQgcHJvYmxlbXM/ICBTdG9wLgpOb3cgU2VhcmNo IGxvZyBldmVudHMgYW5kIGNvbmZpZ3VyYXRpb24gZmlsZXMgdXNpbmcgQUpBWCBhbmQgYSBicm93 c2VyLgpEb3dubG9hZCB5b3VyIEZSRUUgY29weSBvZiBTcGx1bmsgbm93ID4+IGh0dHA6Ly9nZXQu c3BsdW5rLmNvbS8KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18Kc3BpLWRldmVsLWdlbmVyYWwgbWFpbGluZyBsaXN0CnNwaS1kZXZlbC1nZW5lcmFsQGxpc3Rz LnNvdXJjZWZvcmdlLm5ldApodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0 aW5mby9zcGktZGV2ZWwtZ2VuZXJhbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ned Forrester Subject: Re: Status of Linux SPI slave Date: Sat, 13 Oct 2007 15:03:01 -0400 Message-ID: <47111665.7000005@whoi.edu> References: <1190880999.29726.5.camel@shuttle> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: =?ISO-8859-15?Q?Roger_Fr=F8ysaa?= Return-path: In-Reply-To: <1190880999.29726.5.camel@shuttle> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org Roger Fr=F8ysaa wrote: > Hi. > = > I'm wondering if there are any plans to add SPI slave mode to the SPI > driver framework in the "near" future? Is anyone working on > something like this? > = > If not, has anyone ever considered it - and estimated the amount of > work it would be etc? I have been waiting to respond until there was a response from someone knowledgeable. As David points out, true slave capability has serious real time implications, and the standard Linux kernel is not a real-time kernel, as I understand it. However, if you don't need completely general slave capability, there may be ways to accomplish some slave-like tasks. For example, I have an SPI master device that streams data to a Linux processor at 11Mbit/sec, but never expects any response from the processor; this data is written over the 100baseT network to an NFS file system at an effective 5GBytes/hour. To make it work, I have heavily modified the pxa2xx-spi driver for the target Gumstix system so that it can accept data driven by an external clock, and so that it uses a queue of DMA descriptors to prevent interrupt latency from limiting service of the receive FIFO. I did not have to modify a single line of code anywhere else in the SPI framework. All other parts of the SPI framework, as well as my protocol driver and user-space code, still operate as if they were part of an SPI master; they just keep full a queue of SPI messages that request buffers to be filled by SPI reads. Basically, this is a VERY limited slave function, where the Linux system is not in control of the timing, but also there is never any sort of query/response between the master and slave. -- = Ned Forrester nforrester-/d+BM93fTQY@public.gmane.org Oceanographic Systems Lab 508-289-2226 Applied Ocean Physics and Engineering Dept. Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA http://www.whoi.edu/sbl/liteSite.do?litesiteid=3D7212 http://www.whoi.edu/hpb/Site.do?id=3D1532 http://www.whoi.edu/page.do?pid=3D10079 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Girish" Subject: Re: Status of Linux SPI slave Date: Mon, 15 Oct 2007 21:13:59 +0530 Message-ID: <00a801c80f42$3612f790$6a8918ac@ent.ti.com> References: <20071013154747.2F7B023A5F4@adsl-69-226-248-13.dsl.pltn13.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "'David Brownell'" , , Return-path: In-reply-to: <20071013154747.2F7B023A5F4-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org >-----Original Message----- >From: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:spi-devel- >general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of David Brownell > >> If not, has anyone ever considered it - and estimated the amount of work >> it would be etc? > >The first task is to come up with a workable design. Then would >come implementing it. > > >A second issue is how to factor the programming interface. The >notion of an spi_message isn't necessarily wrong, but when should >it get issued? How would commands sent by the host be packaged? >How should chipselect/deselect be visible? I was looking for such discussion to be started on this thread from quite some time. Well, in my case, I have SPI hardware which can work in Master and Slave mode as well. Specifically speaking, Slave mode capabilities are as same as Master mode. Only major difference is in chipselect and clock generation. As such, in this case, notion of spi_message would definitely hold good for both and also to some extent the whole stack which exists today. I see in community, some use SPI slave for minimal functionality. As I understand, we have to have a stack support for 1. SPI in slave side transaction as similar as Master's. 2. SPI in slave side transaction with minimal functionality. I don't know how the latter one is. But, in my case I was able to modify the controller driver to work for Master/Slave with full transaction without any stack changes. I know this is bad, as stack would never come to know about the slave side transaction :). I would like to know the best way we can make the stack know slave side transaction happening? Regards, girish > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/ >_______________________________________________ >spi-devel-general mailing list >spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >https://lists.sourceforge.net/lists/listinfo/spi-devel-general ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Girish" Subject: Re: Status of Linux SPI slave Date: Mon, 15 Oct 2007 21:38:22 +0530 Message-ID: <00bc01c80f45$9d218980$6a8918ac@ent.ti.com> References: <20071013154747.2F7B023A5F4@adsl-69-226-248-13.dsl.pltn13.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "'David Brownell'" , , Return-path: In-reply-to: <20071013154747.2F7B023A5F4-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org Sorry, my outlook was wrapping up mail automatically, corrected it. >-----Original Message----- >From: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:spi-devel- >general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of David Brownell >The first task is to come up with a workable design. Then would >come implementing it. > > >A second issue is how to factor the programming interface. The >notion of an spi_message isn't necessarily wrong, but when should >it get issued? How would commands sent by the host be packaged? >How should chipselect/deselect be visible? I was looking for such discussion to be started on this thread from quite some time. Well, in my case, I have SPI hardware which can work in Master and Slave mode as well. Specifically speaking, Slave mode capabilities are as same as Master mode. Only major difference is in chipselect and clock generation. As such, in this case, notion of spi_message would definitely hold good for both and also to some extent the whole stack which exists today. I see in community, some use SPI slave for minimal functionality. As I understand, we have to have a stack support for 1. SPI in slave side transaction (as similar as Master's). 2. SPI in slave side transaction with minimal functionality. I don't know how the latter one is. But, in my case I was able to modify the controller driver to work for Master/Slave with full transaction without any stack changes. I know this is bad, as stack would never come to know about the slave side transaction :). I would like to know the best way we can make the stack know slave side transaction happening? Regards, girish > > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/ >_______________________________________________ >spi-devel-general mailing list >spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >https://lists.sourceforge.net/lists/listinfo/spi-devel-general ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Subject: Re: Status of Linux SPI slave Date: Mon, 15 Oct 2007 17:22:11 -0700 Message-ID: <20071016002211.6F45E23BCEC@adsl-69-226-248-13.dsl.pltn13.pacbell.net> References: <00bc01c80f45$9d218980$6a8918ac@ent.ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, roger-UslnteNVNtIXWF+eFR7m5Q@public.gmane.org, girishsg-l0cyMroinI0@public.gmane.org Return-path: In-Reply-To: <00bc01c80f45$9d218980$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org > From: "Girish" > Date: Mon, 15 Oct 2007 21:38:22 +0530 > > >The first task is to come up with a workable design. Then would > >come implementing it. > > > > > >A second issue is how to factor the programming interface. The > >notion of an spi_message isn't necessarily wrong, but when should > >it get issued? How would commands sent by the host be packaged? > >How should chipselect/deselect be visible? > > I was looking for such discussion to be started on this thread from quite > some time. You should feel free to start such stuff yourself, you know ... :) > Well, in my case, I have SPI hardware which can work in Master and Slave > mode as well. That seems moderately common, even for non-microcontroller hardware. For some reason, chip vendors don't design hardware with assumptions that they've got to stick with (current) Linux limitations ... they even (gasp!) allow for a variety of custom RTOS environments! ;) > Specifically speaking, Slave mode capabilities are as same as > Master mode. Only major difference is in chipselect and clock generation. And the interaction model. Masters choose when to interact with the hardware to send messages ... slave must react to those choices, e.g. by seeing that they've been selected/deselected and by processing the data they've been fed. Plus, there are faults that can appear only in slave mode (notably, "data arrived but nobody was listening"). > As such, in this case, notion of spi_message would definitely hold good for > both and also to some extent the whole stack which exists today. Yes, but how is that message used? One common scenario would be to have one message which reads the first N bytes (while transmitting something ... ones, zeroes, the last sample, whatever), then interpret those bytes as a command used to decide what a second message should do. That is, while a master might issue one request/response message, the slave would need to manage that same interaction as two messages. > I see in community, some use SPI slave for minimal functionality. As I > understand, we have to have a stack support for > 1. SPI in slave side transaction (as similar as Master's). > 2. SPI in slave side transaction with minimal functionality. > I don't know how the latter one is. I think that the current "minimal functionality" example is sample data streaming ... where there's always a message queue, and where the channel is never deselected. I think it's fair to say that is not a typical application for SPI. > But, in my case I was able to modify > the controller driver to work for Master/Slave with full transaction > without any stack changes. I know this is bad, as stack would never come to > know about the slave side transaction :). > I would like to know the best way we can make the stack know slave side > transaction happening? Well, you said that you already did it. What did you do? If I were to do that, I'd have a "spi_slave" struct wrapping the hardware, and drivers would normally keep some kind of message posted to it. Events visible to the slave driver would be the completion of a message (standard callback) and slave deselect (which might well terminate the pending message queue) ... also RX underrun (e.g. when there was no buffer for incoming data). I'd also spend time analysing interaction models. The one I sketched above is basic request/response. There would also be ways to stream data in one or two directions. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Girish" Subject: Re: Status of Linux SPI slave Date: Tue, 16 Oct 2007 19:20:50 +0530 Message-ID: <014101c80ffb$917d1200$6a8918ac@ent.ti.com> References: <20071016002211.6F45E23BCEC@adsl-69-226-248-13.dsl.pltn13.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "'David Brownell'" , , Return-path: In-reply-to: <20071016002211.6F45E23BCEC-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org >-----Original Message----- >From: David Brownell [mailto:david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org] >Sent: Tuesday, October 16, 2007 5:52 AM >That seems moderately common, even for non-microcontroller hardware. > >For some reason, chip vendors don't design hardware with assumptions >that they've got to stick with (current) Linux limitations ... they >even (gasp!) allow for a variety of custom RTOS environments! ;) > I got it :). Then, as of today I think not much of slave side transaction is needed by most of the RTOS, guess the use case is very limited. > >And the interaction model. Masters choose when to interact with >the hardware to send messages ... slave must react to those >choices, e.g. by seeing that they've been selected/deselected >and by processing the data they've been fed. Plus, there are >faults that can appear only in slave mode (notably, "data arrived >but nobody was listening"). Yes, the faults you mentioned should be taken care. And I think these faults would depend upon the type of device connected to slave spi. I think am not missing anything. > >Yes, but how is that message used? One common scenario would be to >have one message which reads the first N bytes (while transmitting >something ... ones, zeroes, the last sample, whatever), then interpret >those bytes as a command used to decide what a second message should >do. That is, while a master might issue one request/response message, >the slave would need to manage that same interaction as two messages. > I think interaction model shouldn't change drastically except couple of points you mentioned. As I understand, the spi device usually takes care of the interaction needed. I mean, once the command comes on mosi the device will reply to it as per its convention. As such SPI controller driver wouldn't worry about that, it only does the transfer/receive. Now we are changing the role what the SPI controller and the device is playing. SPI controller will now work as slave and device will be master to the slave SPI controller. If my understanding is right then, in this scenario too the device will take care of interpreting the data on somi. I mean in either case the SPI controller will only do the transfer functionality. Interpreting the data will be done by device interface, irrespective of its mode (master/slave). > >I think that the current "minimal functionality" example is sample >data streaming ... where there's always a message queue, and where >the channel is never deselected. I think it's fair to say that is >not a typical application for SPI. > Ok, I got that. > >Well, you said that you already did it. What did you do? > I had to only take care of module control registers and to deactivate the cs0 between spi words as required by slave. And also correct configuration of mosi/simo lines for slave. As such there was no real use case for testing SPI controller in slave mode. I had to use two SPI on the board connected externally with wires, making one as Master and other as slave. And pump data from slave/master. Yes, we can't rely on externally connected wires for data integrity on higher speed. This was more like a plane test scenario with not much interpreting of the data. Assuming interpreting the data would be taken care by the actual device connecting to SPI. >If I were to do that, I'd have a "spi_slave" struct wrapping the So, you mean to say that the controller driver would register with stack using spi_slave structure? If we have this new structure then we need to have registering mechanism for spi_slave too. If am not wrong, on a whole there could be some redundant code across master/slave in stack. Hope I'm not missing anything here. >hardware, and drivers would normally keep some kind of message >posted to it. Events visible to the slave driver would be the Here "slave driver" is SPI controller driver? >completion of a message (standard callback) and slave deselect >(which might well terminate the pending message queue) ... also >RX underrun (e.g. when there was no buffer for incoming data). > Yes, this looks meaningful. I am still thinking of the use case for SPI in slave mode. I haven't seen any device having Master SPI interface. I guess not even in community people seem to have such device. Just wondering is/can there be any such device which needs SPI controller in slave mode? I would be interested to know! >I'd also spend time analysing interaction models. The one I >sketched above is basic request/response. There would also be >ways to stream data in one or two directions. > Yes, and thanks for throwing light on this part of SPI, having good learning from you. :) Thanks and Regards, Girish ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Girish" Subject: Re: Status of Linux SPI slave Date: Tue, 16 Oct 2007 19:51:11 +0530 Message-ID: <014301c80fff$ceacd710$6a8918ac@ent.ti.com> References: <47111665.7000005@whoi.edu> Content-Type: multipart/mixed; boundary="===============1555113955==" Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: "'Ned Forrester'" , "'Roger Frøysaa'" Return-path: In-reply-to: <47111665.7000005-/d+BM93fTQY@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org --===============1555113955== >-----Original Message----- >Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >Subject: Re: [spi-devel-general] Status of Linux SPI slave > >Roger Frøysaa wrote: >> Hi. >> > >For example, I have an SPI master device that streams data to a Linux >processor at 11Mbit/sec, but never expects any response from the >processor; this data is written over the 100baseT network to an NFS >file system at an effective 5GBytes/hour. To make it work, I have >heavily modified the pxa2xx-spi driver for the target Gumstix system so >that it can accept data driven by an external clock, and so that it uses >a queue of DMA descriptors to prevent interrupt latency from limiting >service of the receive FIFO. I did not have to modify a single line of >code anywhere else in the SPI framework. All other parts of the SPI >framework, as well as my protocol driver and user-space code, still >operate as if they were part of an SPI master; they just keep full a >queue of SPI messages that request buffers to be filled by SPI reads. >Basically, this is a VERY limited slave function, where the Linux system >is not in control of the timing, but also there is never any sort of >query/response between the master and slave. Well, now I get the minimal use of slave side transfer. As David suggested of having spi_slave struct wrapping the hardware, have you thought of something like that and how would your existing pxa2xx-spi driver will be impacted? And thanks for starting this thread:). Actually, in my case I had to modify controller driver to support SPI in master and slave mode as well, with standard transfers (half/full duplex communication). Regards, Girish > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/ >_______________________________________________ >spi-devel-general mailing list >spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >https://lists.sourceforge.net/lists/listinfo/spi-devel-general --===============1555113955== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ --===============1555113955== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ spi-devel-general mailing list spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/spi-devel-general --===============1555113955==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ned Forrester Subject: Re: Status of Linux SPI slave Date: Tue, 16 Oct 2007 13:28:12 -0400 Message-ID: <4714F4AC.4020402@whoi.edu> References: <014301c80fff$ceacd710$6a8918ac@ent.ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Girish Return-path: In-Reply-To: <014301c80fff$ceacd710$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org Girish wrote: > = >> -----Original Message----- >> From: nforrester-/d+BM93fTQY@public.gmane.org >> Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >> Subject: Re: [spi-devel-general] Status of Linux SPI slave >> >> Roger Fr=F8ysaa wrote: >>> Hi. >>> >> For example, I have an SPI master device that streams data to a Linux >> processor at 11Mbit/sec, but never expects any response from the >> processor; this data is written over the 100baseT network to an NFS >> file system at an effective 5GBytes/hour. To make it work, I have >> heavily modified the pxa2xx-spi driver for the target Gumstix system so >> that it can accept data driven by an external clock, and so that it uses >> a queue of DMA descriptors to prevent interrupt latency from limiting >> service of the receive FIFO. I did not have to modify a single line of >> code anywhere else in the SPI framework. All other parts of the SPI >> framework, as well as my protocol driver and user-space code, still >> operate as if they were part of an SPI master; they just keep full a >> queue of SPI messages that request buffers to be filled by SPI reads. >> Basically, this is a VERY limited slave function, where the Linux system >> is not in control of the timing, but also there is never any sort of >> query/response between the master and slave. > = > Well, now I get the minimal use of slave side transfer. As David suggested > of having spi_slave struct wrapping the hardware, have you thought of > something like that and how would your existing pxa2xx-spi driver will be > impacted? I have not considered how to generalize slave functionality in Linux. I = did not feel that I needed to go that far to implement my project. My = goal was to make changes that would have some chance of being accepted = into the kernel distribution, so I avoided upsetting anything I did not = need to. In the end, what I have in pxa2xx-spi is still a major = departure from its base functionality, and full use of the new features = increases the memory footprint of the driver (for buffer space), so I am = doubtful that Steven Street (the pxa2xx-spi author) and David will be = interested in propagating it (I have not pursued this because the driver = is working but it is not ready to share, yet). I probably would have = spent much less time on the project if I had simply written a dedicated = driver for my data stream, rather than keeping all the master capability = of the original, as I have actually done. As for the concept of struct spi_slave, I haven't heard enough of this = discussion yet to have a clear image of how it might differ from = spi_master. Thus I don't know how my driver would be impacted. I don't = have a very clear view of all the ways that SPI must operate, because I = have only worked with a few SPI devices in my career. It seems that a slave implementation would either have to respond in a = timely manner to an interrupt; or, there would have to be messages = perpetually queued for service in case data arrived at the SPI port, as = David suggested, and as my system is implemented. The problem with = interrupts, is that they are comparatively slow, and would probably work = only for SPI devices with slow clocks (often an SPI master expects an = immediate response to an inquiry). The problem with queued messages is = that they have to anticipate all aspects of the next transfer that the = master will control; unless you have prior knowledge of the sequence of = actions that the master will take, it is impossible to predict what data = to make ready for transmission. My application works on the queue = principal exactly because I *can* predict what the master's actions will = be: it will transmit another block of data and the master will only = write and never read. I can imagine how an SPI slave could be programmed into a = micro-processor as a dedicated slave controller. In this case, the = processor can spin, waiting for SPI activity. When activity occurs, the = processor probably has at least one SPI clock cycle to compute the = required response to the master's request. On a multi-tasking system, = like Linux, the processor is likely to be doing something else when the = master makes a request. I don't see how the processor can respond = quickly enough to satisfy a non-deterministic request. Interrupt = latency is at least 10s to 100s of microseconds, and I have seen = milliseconds and surprisingly nearly a full second on my PXA255 = processor (I suspect the latter is due to a bug someplace, it happened = during a massive network transfer, but I report what I see). David has also raised the issue of how a Linux SPI slave would deal with = chip select from a master. If the Linux system is only one of several = slaves on the SPI bus, then it must not drive the bus, and it must not = run the receiver if it is not selected. It seems that only a hardware = solution can work to enable/disable the transmitter/receiver on changes = in chip select. I don't know if other processors implement similar = mechanisms, but in Motorola SPI mode (the mode normally supported by = pxa2xx-spi) the PXA255 uses the FRAME pin as the chip select input. The = port can be configured so that the TX pin is only asserted when FRAME is = asserted (low). I think, but don't explicitly see in the spec, that the = receiver will also be enabled only when FRAME is asserted; this is = important or else queued messages would be consumed, and/or interrupts = asserted, even when the Linux slave is not chip selected and the clock = and data are intended for another device on the bus. I am not intimately familiar with SPI protocols, but I don't think that = there is any mechanism for allowing multiple masters on a bus, except = with some external arbitration, not defined in the SPI protocol. (This = is unlike the I2C bus, where there is a defined mechanism for = arbitrating access by multiple masters.) Therefore, one might presume = that if the Linux system will operate in slave mode, then it will only = operate that way, and thus it will not be restrictive to assign a = single, dedicated pin (SSPSFRM, FRAME) as the chip select input from a = single external master. > And thanks for starting this thread:). > Actually, in my case I had to modify controller driver to support SPI in > master and slave mode as well, with standard transfers (half/full duplex > communication). Just to be clear, it was Roger who started the thread, and I replied = with a description of my limited slave application. I think David = accurately summarized my type of application as: "the current "minimal = functionality" example is sample data streaming ... where there's always = a message queue, and where the channel is never deselected." -- = Ned Forrester nforrester-/d+BM93fTQY@public.gmane.org Oceanographic Systems Lab 508-289-2226 Applied Ocean Physics and Engineering Dept. Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA http://www.whoi.edu/sbl/liteSite.do?litesiteid=3D7212 http://www.whoi.edu/hpb/Site.do?id=3D1532 http://www.whoi.edu/page.do?pid=3D10079 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Subject: Re: Status of Linux SPI slave Date: Tue, 16 Oct 2007 10:59:20 -0700 Message-ID: <20071016175920.7FA2923BCED@adsl-69-226-248-13.dsl.pltn13.pacbell.net> References: <014101c80ffb$917d1200$6a8918ac@ent.ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, roger-UslnteNVNtIXWF+eFR7m5Q@public.gmane.org, girishsg-l0cyMroinI0@public.gmane.org Return-path: In-Reply-To: <014101c80ffb$917d1200$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org > >And the interaction model. Masters choose when to interact with > >the hardware to send messages ... slave must react to those > >choices, e.g. by seeing that they've been selected/deselected > >and by processing the data they've been fed. Plus, there are > >faults that can appear only in slave mode (notably, "data arrived > >but nobody was listening"). > > Yes, the faults you mentioned should be taken care. And I think these > faults would depend upon the type of device connected to slave spi. I think > am not missing anything. No, that particular fault would depend on whether the driver provides adequate response time. A master clocking data too fast for the slave to keep up might cause such issues. > >Yes, but how is that message used? One common scenario would be to > >have one message which reads the first N bytes (while transmitting > >something ... ones, zeroes, the last sample, whatever), then interpret > >those bytes as a command used to decide what a second message should > >do. That is, while a master might issue one request/response message, > >the slave would need to manage that same interaction as two messages. > > I think interaction model shouldn't change drastically except couple of > points you mentioned. As I understand, the spi device usually takes care of > the interaction needed. I mean, once the command comes on mosi the device > will reply to it as per its convention. As such SPI controller driver > wouldn't worry about that, it only does the transfer/receive. SPI devices usually implement a state machine which resets when the chip deselects. The controlelr driver would need to change in order to expose that to the slave driver... > Now we are changing the role what the SPI controller and the device is > playing. SPI controller will now work as slave and device will be master to > the slave SPI controller. I don't follow that comment. What do you mean when you say "device"? I'm guessing I will disagree with your comment about being master to the slave. There's only one master in the system, and it's not on the slave side. The slave driver must *REACT* to the master, which is why I said the interaction model must be different. > If my understanding is right then, in this > scenario too the device will take care of interpreting the data on somi. > I mean in either case the SPI controller will only do the transfer > functionality. Interpreting the data will be done by device interface, > irrespective of its mode (master/slave). Again, I don't follow. Interpreting the data is in a layer above the device controller driver, certainly ... but what "device"? > >Well, you said that you already did it. What did you do? > > I had to only take care of module control registers and to deactivate the > cs0 between spi words as required by slave. And also correct configuration > of mosi/simo lines for slave. I'm still not following what you're saying here. By definition, a slave has no control of chipselect ... the master manages that signal. Configuration of MOSI and MISO lines sounds like what you've actually got is DI and DO lines, which would need to be manually interchanged if the M and S roles change. If the signal lines are true MOSI and MISO, the signal direction would change by the internal M/S switch. > As such there was no real use case for testing SPI controller in slave > mode. I had to use two SPI on the board connected externally with wires, > making one as Master and other as slave. And pump data from slave/master. > Yes, we can't rely on externally connected wires for data integrity on > higher speed. This was more like a plane test scenario with not much > interpreting of the data. Sounds like what I might call a concept or breadboard demo. I've done that, but saw signal glitching with 18 MHz signals. > Assuming interpreting the data would be taken > care by the actual device connecting to SPI. > > >If I were to do that, I'd have a "spi_slave" struct wrapping the > > So, you mean to say that the controller driver would register with stack > using spi_slave structure? If we have this new structure then we need to > have registering mechanism for spi_slave too. If am not wrong, on a whole > there could be some redundant code across master/slave in stack. Hope I'm > not missing anything here. Any badly written software can have redudant code. :) The controller driver might have lots of internal code sharing; basic data transfer logic would likely be the same. What would differ would be the control/interaction model. > >hardware, and drivers would normally keep some kind of message > >posted to it. Events visible to the slave driver would be the > > Here "slave driver" is SPI controller driver? No; using the terminology in Documentation/spi/spi-summary that'd be a "slave protocol driver", not a "slave controller driver". > >completion of a message (standard callback) and slave deselect > >(which might well terminate the pending message queue) ... also > >RX underrun (e.g. when there was no buffer for incoming data). > > Yes, this looks meaningful. Good. :) > I am still thinking of the use case for SPI in slave mode. I haven't seen > any device having Master SPI interface. I guess not even in community > people seem to have such device. Just wondering is/can there be any such > device which needs SPI controller in slave mode? I would be interested to > know! Again, what do you mean by "device"? Off the shelf parts are going to be either slave chips (EEPROM, flash, ADC, sensor, UART, etc) or some kind of SOC. SPI support on a SOCs usually supports either master or slave role, with master mostly used to talk to slaves (LCD panels, audio codec control, touchscreen, flash, FPGA, etc). Slave support in a SOC is, I've assumed, mostly used with custom chip-to-chip communications. > >I'd also spend time analysing interaction models. The one I > >sketched above is basic request/response. There would also be > >ways to stream data in one or two directions. > > Yes, and thanks for throwing light on this part of SPI, having good > learning from you. :) :) - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Girish" Subject: Re: Status of Linux SPI slave Date: Wed, 17 Oct 2007 19:13:09 +0530 Message-ID: <01af01c810c3$a86e09b0$6a8918ac@ent.ti.com> References: <4714F4AC.4020402@whoi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: "'Ned Forrester'" Return-path: In-reply-to: <4714F4AC.4020402-/d+BM93fTQY@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org >-----Original Message----- >From: Ned Forrester [mailto:nforrester-/d+BM93fTQY@public.gmane.org] >Sent: Tuesday, October 16, 2007 10:58 PM >To: Girish >Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >Subject: Re: [spi-devel-general] Status of Linux SPI slave > anism for arbitrating access by >multiple masters.) Therefore, one might presume that if the >Linux system will operate in slave mode, then it will only >operate that way, and thus it will not be restrictive to >assign a single, dedicated pin (SSPSFRM, FRAME) as the chip >select input from a single external master. > Thanks for this insight full information. This helped. Regards, girish >Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA >http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212 >http://www.whoi.edu/hpb/Site.do?id=1532 >http://www.whoi.edu/page.do?pid=10079 > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Girish" Subject: Re: Status of Linux SPI slave Date: Wed, 17 Oct 2007 19:30:03 +0530 Message-ID: <01b001c810c6$053fdea0$6a8918ac@ent.ti.com> References: <20071016175920.7FA2923BCED@adsl-69-226-248-13.dsl.pltn13.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "'David Brownell'" , , Return-path: In-reply-to: <20071016175920.7FA2923BCED-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org >-----Original Message----- >From: David Brownell [mailto:david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org] >Sent: Tuesday, October 16, 2007 11:29 PM >To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; roger-UslnteNVNtIXWF+eFR7m5Q@public.gmane.org; >girishsg-l0cyMroinI0@public.gmane.org >Subject: Re: [spi-devel-general] Status of Linux SPI slave > >> Now we are changing the role what the SPI controller and the device is >> playing. SPI controller will now work as slave and device will be master >to >> the slave SPI controller. >I don't follow that comment. What do you mean when you say "device"? Ok, I am adhering to the convention specified in Documentation/spi/spi-summary. We know that SPI controller driver is a master controller driver and spi protocol driver is for slave device. (e.g., TouchScreen will have a spi protocol driver and registers to stack with spi_driver_register() ). When I say "device" I meant SPI device (which is slave device for SPI master controller driver). Now, if the exisiting SPI controller driver (Which is a master controller as of now) is modified to work in slave, then we would be having a Slave SPI controller driver and spi device would be a master. I hope this time I'm making myself clear :D. > >I'm guessing I will disagree with your comment about being master to >the slave. There's only one master in the system, and it's not on the >slave side. The slave driver must *REACT* to the master, which is why >I said the interaction model must be different. Yes, agreed about interaction model part. Ok, to be clearer. I will be having a SPI slave controller registering to stack (Assuming Stack gives me spi_slave framework). Now, how does the protocol driver should fit in? It would still be for spi device(which will be a master). Right? This is what I meant. >> I had to only take care of module control registers and to deactivate >the >> cs0 between spi words as required by slave. And also correct >configuration >> of mosi/simo lines for slave. > >I'm still not following what you're saying here. By definition, a >slave has no control of chipselect ... the master manages that signal. > Actually, I have used the default master controller driver and modified it to work as slave controller driver. So, I had to remove the asserting of spi_cs between words which guess only works for master mode. This is what I meant. >Configuration of MOSI and MISO lines sounds like what you've actually >got is DI and DO lines, which would need to be manually interchanged >if the M and S roles change. If the signal lines are true MOSI and >MISO, the signal direction would change by the internal M/S switch. > Yes. > >Any badly written software can have redudant code. :) > I was just contemplating how much code can be reused for slave support in stack :) > >Slave support in a SOC is, I've assumed, mostly used with >custom chip-to-chip communications. > Ok. And ya, It would be better if I list down some points from top of my head, it will make me clear. Following things done for slave; 1. Make SPI controller work in Master and Slave. There won't be any separate controller driver for slave. (As of now there is no support from stack, so stack will be blind about slave transaction) 2. Protocol driver will still register as spi_driver. No change here, only difference is that the underlying device would be a master device and in spi_board_info table it will populate a SPI controller info which will be working as slave. 3. One more thing I wanted to ask was about spi_setup(). How about supporting selecting/deselecting SPI mode (master/slave) through spi_setup()? We can make protocol driver free enough to override selection of SPI mode(master/slave). 4. If only single controller driver is used for Master/Slave, then by default it should be registering as Master/slave with stack? Actually, I have couple of slave model floating in my mind with lots of questions :). I think I'll go back and try to understand more about transaction model required in slave, so that I can consolidate things upon that. Regards, Girish ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ned Forrester Subject: Re: Status of Linux SPI slave Date: Wed, 17 Oct 2007 17:36:41 -0400 Message-ID: <47168069.4000208@whoi.edu> References: <01b001c810c6$053fdea0$6a8918ac@ent.ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: 'David Brownell' , spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Girish Return-path: In-Reply-To: <01b001c810c6$053fdea0$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org Girish wrote: > >> -----Original Message----- >> From: David Brownell [mailto:david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org] >> Sent: Tuesday, October 16, 2007 11:29 PM >> To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; roger-UslnteNVNtIXWF+eFR7m5Q@public.gmane.org; >> girishsg-l0cyMroinI0@public.gmane.org >> Subject: Re: [spi-devel-general] Status of Linux SPI slave > > And ya, It would be better if I list down some points from top of my head, > it will make me clear. Following things done for slave; This is a good starting summary. > 1. Make SPI controller work in Master and Slave. There won't be any > separate controller driver for slave. (As of now there is no support from > stack, so stack will be blind about slave transaction) This is exactly how I have implemented my slave device. Major modifications to the controller driver, but the rest of the stack is blind to that, as you say. I'm not sure that such a simple scheme will work for a generalized slave. > 2. Protocol driver will still register as spi_driver. No change here, only > difference is that the underlying device would be a master device and in > spi_board_info table it will populate a SPI controller info which will be > working as slave. This is exactly the way I register my device, with minor changes to the board setup code, to compile in the new spi_board_info table. > 3. One more thing I wanted to ask was about spi_setup(). How about > supporting selecting/deselecting SPI mode (master/slave) through > spi_setup()? We can make protocol driver free enough to override selection > of SPI mode(master/slave). I have also implemented full control of master/slave, clock source/direction, etc. through the setup() call to pxa2xx_spi, so this is certainly possible. > 4. If only single controller driver is used for Master/Slave, then by > default it should be registering as Master/slave with stack? I guess the need to register as master or slave depends on whether there will be any demands on the stack that differ for the two modes. In my data streaming application, there is no impact on the stack, and so there is no need to differentiate whether the controller is acting as master or slave. If, on the other hand, slave functions eventually need to do something new, such as allocate, populate and pass a message autonomously, that might require changes the stack, and thus require the stack to know if the controller driver is registering as master or slave. There is an interesting point o consider regarding the protocol driver. If my previous assertion is true that a Linux slave is never a master, because there can be only one master on any SPI bus, then perhaps this extension is also true: that there is only one protocol driver also. This is certainly what I have implemented with my streaming data application, but I had not considered that a single protocol driver might be a consequence of slave operation. I suppose that if some SPI buses are implemented with multiple masters that are externally arbitrated, then the idea of a single protocol driver in slave mode would not be valid. > Actually, I have couple of slave model floating in my mind with lots of > questions :). I think I'll go back and try to understand more about > transaction model required in slave, so that I can consolidate things upon > that. I still think that the timing issues for a generalized slave are going to be a fatal flaw, except when the actions of the external master are completely predictable (like the data streaming case). Can anyone think of an example of a non-predictable master, for which a useful interaction can still take place without the need for zero latency response? -- Ned Forrester nforrester-/d+BM93fTQY@public.gmane.org Oceanographic Systems Lab 508-289-2226 Applied Ocean Physics and Engineering Dept. Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212 http://www.whoi.edu/hpb/Site.do?id=1532 http://www.whoi.edu/page.do?pid=10079 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/