Status of Linux SPI slave

Status of Linux SPI slave

[Roger Frøysaa]

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

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>

[-- Attachment #1.2: Type: text/html, Size: 800 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: Status of Linux SPI slave

[David Brownell]

> From: Roger Frøysaa <roger@bitfrost.no>
> To: spi-devel-general@lists.sourceforge.net

Sorry for the delayed response ... you sent it as HTML mail, so it
landed in a spamtrap.


> 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?

I don't know of any such plans, though if you look through list
archives you'll find other people who've asked about it.


> 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.


The first issues that come to mind are technical.  There's an issue
of response time ... since SPI has no flow control, typical types of
request/response protocol have hard response time limits.  So the RT
stack may be implicitly required, except for very slow slave.

Example:  protocol spec says SPI master sends two bytes of command,
then the SPI slave sends N bytes of response.  That means at least
part of the response must be computed then issued within one bit
time, right after the last bit sent from the master.

Clearly, increasing bit times (slowing the SPI clock) can help.
So can supporting protocols that use stuff like dummy bytes, which
can allow more time before the "real" response must be ready, or
which aren't structured as request/response protocols.  (Such as
perhaps just streaming data samples in one direction or the other.)


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?

- 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/
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: Status of Linux SPI slave

[Ned Forrester]

Roger Frøysaa 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=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/

Re: Status of Linux SPI slave

[Girish]

>-----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/

Re: Status of Linux SPI slave

[Girish]

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/

Re: Status of Linux SPI slave

[David Brownell]

> From: "Girish" <girishsg-l0cyMroinI0@public.gmane.org>
> 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/

Re: Status of Linux SPI slave

[Girish]

>-----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/

Re: Status of Linux SPI slave

[Girish]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]



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




[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: Status of Linux SPI slave

[Ned Forrester]

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ø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?

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=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/

Re: Status of Linux SPI slave

[David Brownell]

> >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/

Re: Status of Linux SPI slave

[Girish]

>-----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/

Re: Status of Linux SPI slave

[Girish]

>-----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/

Re: Status of Linux SPI slave

[Ned Forrester]

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/