On Tue, Feb 16, 2010 at 12:33 PM, Linus Walleij <[email protected]> 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.
No, the model needs to be in place first. That means describing the model for spi_slave transfers. Does the driver need to turn around and respond mid-transfer? Does there need to be latency controls? How are protocol drivers interfaced with spi slave controllers (1 to 1, or 1 to many, how is the protocol selected)? I appreciate the work Ken is doing, but the patches posted so far abuse the spi_master model in a way I'm not willing to merge. I think spi_slave is a different enough thing that it warrants an entirely different core infrastructure (but I do reserve the right to have my mind changed). > 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. Your right, the realtime issues are separate, but I still need to see how spi_slave devices are intended to work, and what the strengths/limitations of the model are. 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
