From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFTSP-0004to-Oj for qemu-devel@nongnu.org; Wed, 04 Apr 2012 12:53:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFTSG-00015Q-MS for qemu-devel@nongnu.org; Wed, 04 Apr 2012 12:53:14 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:59026) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFTSG-00014y-GE for qemu-devel@nongnu.org; Wed, 04 Apr 2012 12:53:08 -0400 From: Paul Brook Date: Wed, 4 Apr 2012 17:52:56 +0100 References: <201204032222.21836.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204041752.56850.paul@codesourcery.com> Subject: Re: [Qemu-devel] [RFC PATCH v1 1/4] SPI: initial support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , qemu-devel@nongnu.org, john.williams@petalogix.com, edgar.iglesias@gmail.com > 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