Re: [Qemu-devel] [RFC PATCH v1 1/4] SPI: initial support

[Paul Brook]

> 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