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

[Peter Crosthwaite]

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.

Regards,
Peter

On Wed, Apr 4, 2012 at 7:22 AM, Paul Brook <address@hidden> wrote:
>> 2012/4/3 Paul Brook <address@hidden>:
>> >> > I'm no SPI expert, but a bit of googling suggests that it's
>> >> > a synchronous duplex bus, so you always send a byte of data
>> >> > to the slave and get one back in return (even if for some slaves
>> >> > it might be random garbage).
>> >
>> > Waitaminute. So this is just basic synchronous serial?
>> >
>> > We already have an API for this. hw/spi.c.
>>
>> Er, no we don't, not in upstream QEMU. You'll notice that
>> the patch we're discussing creates hw/spi.c as a new file...
>
> Sorry, I mean hw/ssi.c
>
> Synchronous serial is something that pretty much every vendor has their own
> name for, but in practice they're actually all the same.
>
> Paul