On Tue, Feb 16, 2010 at 1:48 PM, Ned Forrester <[email protected]> wrote: > On 02/16/2010 02:33 PM, Linus Walleij wrote: >> 2010/2/15 jassi brar <[email protected]>: >> >>> I don't think adding SPI_SLAVE support is just a matter of providing >>> additional callbacks and structures, as is pointed out in this thread.... >>> http://www.mail-archive.com/[email protected]/msg00368.html >> >> You mean that the responsiveness / control of latencies is the other thing >> that's needed? Yep so it is. But getting the infrastructure in place doesn't >> hurt because this is something many people (including self) need and Ken >> over at Intel is the only one actually doing something about it. >> >> Getting SPI slaves to actually work by spawning their worker threads as >> realtime under that patchset is of course a larger issue. One does not >> exclude the other tho. > > I'm a little fuzzy on what application you have in mind for this. It > doesn't seem productive to lay in a layer of changes for slave operation > before knowing if it is possible to create a useful slave. Putting the > infrastructure before determining feasibility seems the wrong way > around, especially since you wouldn't be sure what support to add unless > you have a working model.
exactly right. Otherwise it is premature generalization. > As pointed out in the above thread (by David Brownell, not by me), many > masters expect the slave to respond within one SPI clock cycle (between > the last bit of the command and the first bit of the response). On a > 400MHz PXA processor, I have measured interrupt latency in excess of > 600us (100us min, 200us typ), so that would imply a maximum SPI clock of > 1kHz for generalized slave operation. I'm not sure how many > applications would be happy with that; likely a few. I don't think use > of real time threads will decrease the latency significantly; that is to > say: whatever reduced latency is achievable is likely to still present a > significant limit on SPI clock rate for the general case. > > If, on the other hand, you mean to develop restricted slave capability, > such as the always-predictable case of data-streaming between a single > slave/master pair, that would be different. That is the way my slave > application (and likely others) work. Note that I did not need any > changes to the SPI core for that application, only to the device drivers. > > I don't mean to be negative, just realistic. It's only worth adding > this capability if there is a clear case that it will be useful in practice. Well said. You've pretty much nailed it from my perspective. g. ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
