* Hemanth V <heman...@ti.com> [090828 05:05]: > ---- Original Message ----- From: "David Brownell" <davi...@pacbell.net> > > >> On Sunday 05 July 2009, Hemanth V wrote: >>> Do you see any major changes required to support >>> slave mode in the SPI core driver. >> >> There *is* no such thing as a "SPI core driver"... >> > I was referring to > > spi.c - SPI init/core code > >> >>> We are able to use the existing interface for slave mode also, but >>> some APIs/ Structures could be made generic. >> >> Three things are obvious: >> >> - A spi_master is not a slave side driver! > > Yes a more generic or new structure would be good, > but the current one does work for slave mode also. > >> >> - Control model would need to be inverted >> * Chip select would be one input, >> not N outputs >> * No clock rate controls at all > > Conditional checks for slave/master mode have been added in > the driver where required. > >> * latency issues ... driver can't necessarily >> respond quickly enough to guarantee no data >> loss (FIFOs help) > > We currently support both FIFO and DMA for > slave mode > >> * Can't re-use /dev/spidev* >> * Request queue would have a very different role >> >> - Some primitives are likely missing, for flow >> control (when hardware has a READY handshake) >> >> I think a few proposals for how to handle slave >> side have been circulated. > > So would it be possible to merge the slave support also for > now, and could be modified to support the new slave interface > as and when available.
In general it's not good to merge half implemented patches. That's because it usually means that the work on getting things cleaned up stops right there. And then the community is left to deal with the mess. So I recommend doing it clean from the start rather than merging in hacks. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
