> From: "Girish" <[EMAIL PROTECTED]> > 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/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
