> Hi Paul, > > Regarding using ssi, theres a few things that come to mind: > > Theres no sense of it being a multi-slave bus, its just a point to > point link. SPI devices universally have the notion of the CS pin that > tristates the device of the bus. Masters connect to a number of slaves > and one-hot-decode the active slave. It would be tedious if all SPI > controllers (of which i have two (only pushed one in this series), > omap have theirs, Nokia may have something out of tree too), had to > implement the\is common CS decoding behaviour. To that end, my SPI bus > implementation has some infra-structure for managing this - > spi_set_cs(). The spi_bus in this series is single master, > multi-slave, where as ssi is point-to-point. > > Also as mentioned in earlier discussions with Peter, that api has no > way of emulating the CS (sometimes called SS) pin. The m25p80 in this > series (and potenitally other devices) has side effect associated with > wiggling the cs pin, which can not be encapsulated by that ssi slave > interface. > > It may be a case though that ssi is a superclass of spi - all SPI > devices are SSI devices but not all SSI devices are SPI? To that end > can we make SPI a child object of SSI with the desired extra behaviors > mentioned in this thread? This kind of stuff is the whole reason for > QOM.
I don't believe there is any difference between SSI and SPI. It's the exact same thing - the same way that many devices support a "two-wire interface" that is actually just I2C with a different name. The behavior of the CS pin varies between devices. It sounds like you need a bit of extra logic not present in the current ssi code. You should fix that, not invent a whole new bus. Paul
