* Status of Linux SPI slave @ 2007-09-27 8:16 Roger Frøysaa 2007-10-13 15:47 ` David Brownell 2007-10-13 19:03 ` Ned Forrester 0 siblings, 2 replies; 13+ messages in thread From: Roger Frøysaa @ 2007-09-27 8:16 UTC (permalink / raw) To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f [-- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Status of Linux SPI slave 2007-09-27 8:16 Status of Linux SPI slave Roger Frøysaa @ 2007-10-13 15:47 ` David Brownell [not found] ` <20071013154747.2F7B023A5F4-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> 2007-10-13 19:03 ` Ned Forrester 1 sibling, 1 reply; 13+ messages in thread From: David Brownell @ 2007-10-13 15:47 UTC (permalink / raw) To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, roger-UslnteNVNtIXWF+eFR7m5Q > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20071013154747.2F7B023A5F4-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org>]
* Re: Status of Linux SPI slave [not found] ` <20071013154747.2F7B023A5F4-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> @ 2007-10-15 15:43 ` Girish 2007-10-15 16:08 ` Girish 1 sibling, 0 replies; 13+ messages in thread From: Girish @ 2007-10-15 15:43 UTC (permalink / raw) To: 'David Brownell', spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, roger-UslnteNVNtIXWF+eFR7m5Q >-----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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Status of Linux SPI slave [not found] ` <20071013154747.2F7B023A5F4-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> 2007-10-15 15:43 ` Girish @ 2007-10-15 16:08 ` Girish [not found] ` <00bc01c80f45$9d218980$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> 1 sibling, 1 reply; 13+ messages in thread From: Girish @ 2007-10-15 16:08 UTC (permalink / raw) To: 'David Brownell', spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, roger-UslnteNVNtIXWF+eFR7m5Q 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <00bc01c80f45$9d218980$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org>]
* Re: Status of Linux SPI slave [not found] ` <00bc01c80f45$9d218980$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> @ 2007-10-16 0:22 ` David Brownell [not found] ` <20071016002211.6F45E23BCEC-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: David Brownell @ 2007-10-16 0:22 UTC (permalink / raw) To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, roger-UslnteNVNtIXWF+eFR7m5Q, girishsg-l0cyMroinI0 > 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20071016002211.6F45E23BCEC-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org>]
* Re: Status of Linux SPI slave [not found] ` <20071016002211.6F45E23BCEC-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> @ 2007-10-16 13:50 ` Girish [not found] ` <014101c80ffb$917d1200$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Girish @ 2007-10-16 13:50 UTC (permalink / raw) To: 'David Brownell', spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, roger-UslnteNVNtIXWF+eFR7m5Q >-----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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <014101c80ffb$917d1200$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org>]
* Re: Status of Linux SPI slave [not found] ` <014101c80ffb$917d1200$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> @ 2007-10-16 17:59 ` David Brownell [not found] ` <20071016175920.7FA2923BCED-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: David Brownell @ 2007-10-16 17:59 UTC (permalink / raw) To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, roger-UslnteNVNtIXWF+eFR7m5Q, girishsg-l0cyMroinI0 > >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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20071016175920.7FA2923BCED-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org>]
* Re: Status of Linux SPI slave [not found] ` <20071016175920.7FA2923BCED-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> @ 2007-10-17 14:00 ` Girish [not found] ` <01b001c810c6$053fdea0$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Girish @ 2007-10-17 14:00 UTC (permalink / raw) To: 'David Brownell', spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, roger-UslnteNVNtIXWF+eFR7m5Q >-----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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <01b001c810c6$053fdea0$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org>]
* Re: Status of Linux SPI slave [not found] ` <01b001c810c6$053fdea0$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> @ 2007-10-17 21:36 ` Ned Forrester 0 siblings, 0 replies; 13+ messages in thread From: Ned Forrester @ 2007-10-17 21:36 UTC (permalink / raw) To: Girish Cc: 'David Brownell', spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Status of Linux SPI slave 2007-09-27 8:16 Status of Linux SPI slave Roger Frøysaa 2007-10-13 15:47 ` David Brownell @ 2007-10-13 19:03 ` Ned Forrester [not found] ` <47111665.7000005-/d+BM93fTQY@public.gmane.org> 1 sibling, 1 reply; 13+ messages in thread From: Ned Forrester @ 2007-10-13 19:03 UTC (permalink / raw) To: Roger Frøysaa; +Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <47111665.7000005-/d+BM93fTQY@public.gmane.org>]
* Re: Status of Linux SPI slave [not found] ` <47111665.7000005-/d+BM93fTQY@public.gmane.org> @ 2007-10-16 14:21 ` Girish [not found] ` <014301c80fff$ceacd710$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Girish @ 2007-10-16 14:21 UTC (permalink / raw) To: 'Ned Forrester', 'Roger Frøysaa' Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f [-- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <014301c80fff$ceacd710$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org>]
* Re: Status of Linux SPI slave [not found] ` <014301c80fff$ceacd710$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> @ 2007-10-16 17:28 ` Ned Forrester [not found] ` <4714F4AC.4020402-/d+BM93fTQY@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Ned Forrester @ 2007-10-16 17:28 UTC (permalink / raw) To: Girish; +Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <4714F4AC.4020402-/d+BM93fTQY@public.gmane.org>]
* Re: Status of Linux SPI slave [not found] ` <4714F4AC.4020402-/d+BM93fTQY@public.gmane.org> @ 2007-10-17 13:43 ` Girish 0 siblings, 0 replies; 13+ messages in thread From: Girish @ 2007-10-17 13:43 UTC (permalink / raw) To: 'Ned Forrester' Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f >-----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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2007-10-17 21:36 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-09-27 8:16 Status of Linux SPI slave Roger Frøysaa 2007-10-13 15:47 ` David Brownell [not found] ` <20071013154747.2F7B023A5F4-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> 2007-10-15 15:43 ` Girish 2007-10-15 16:08 ` Girish [not found] ` <00bc01c80f45$9d218980$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> 2007-10-16 0:22 ` David Brownell [not found] ` <20071016002211.6F45E23BCEC-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> 2007-10-16 13:50 ` Girish [not found] ` <014101c80ffb$917d1200$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> 2007-10-16 17:59 ` David Brownell [not found] ` <20071016175920.7FA2923BCED-ZcXrCSuhvln6VZ3dlLfH/g4gEjPzgfUyLrfjE7I9kuVHxeISYlDBzl6hYfS7NtTn@public.gmane.org> 2007-10-17 14:00 ` Girish [not found] ` <01b001c810c6$053fdea0$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> 2007-10-17 21:36 ` Ned Forrester 2007-10-13 19:03 ` Ned Forrester [not found] ` <47111665.7000005-/d+BM93fTQY@public.gmane.org> 2007-10-16 14:21 ` Girish [not found] ` <014301c80fff$ceacd710$6a8918ac-tAZopdYwApTQT0dZR+AlfA@public.gmane.org> 2007-10-16 17:28 ` Ned Forrester [not found] ` <4714F4AC.4020402-/d+BM93fTQY@public.gmane.org> 2007-10-17 13:43 ` Girish
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.