From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShV9F-0001Xx-NA for qemu-devel@nongnu.org; Wed, 20 Jun 2012 20:21:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ShV9D-0001F5-G3 for qemu-devel@nongnu.org; Wed, 20 Jun 2012 20:21:21 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:47626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShV9D-0001Eh-5J for qemu-devel@nongnu.org; Wed, 20 Jun 2012 20:21:19 -0400 Received: by bkwj10 with SMTP id j10so42422bkw.4 for ; Wed, 20 Jun 2012 17:21:16 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 21 Jun 2012 10:21:16 +1000 Message-ID: From: Peter Crosthwaite Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] SSI QOMification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "qemu-devel@nongnu.org Developers" , Anthony Liguori , Paul Brook , =?ISO-8859-1?Q?Andreas_F=E4rber?= , Paolo Bonzini Cc: "Edgar E. Iglesias" , John Williams , Peter Maydell Ping! Id really appreciate some input on this issue (rather than going ahead and doing it to discover that someone disagrees with the approach). Regards, Peter On Mon, Jun 18, 2012 at 3:13 PM, Peter Crosthwaite wrote: > HI All, > > Have another one of these long RFCs for you all RE some QOM > refactoring. This time around SSI/SPI and supporting multiple devices > connected to one chip select. > > I have a pending series that is in Limbo, mainly this patch is problemati= c: > > http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg00227.html > > Im trying to get some nice clean multi-device SPI device support going > to match the Xilinx XPI controller, but other machine models (mainly > stellaris) have a more ah-hoc approach to SSI around point-to-point > links. > > Lets start this again by describing the real hardware. We have two > machines to discuss this time, Stellaris, and Xilinx. I have attached > an image that sums up the Stellaris architecture > (stellaris_real_hw.jpg), Paul correct me if this is inaccurate. For > those who like words instead, it can be summed up as: > > - Two SSI devices (OLED + SD) attached to single controller, PL022 > - Tx and Rx lines shared between both devices > - One chip select (CS) line (for OLED) comes from the PL022 > - The other CS (for SD) comes from a GPIO > > Problem is, no SSI device in QEMU emulates CS behaviour, so there is > this virtual mux device in the stellaris machine model that emulates > the CS behaviour of each device (stellaris_emulated.jpg). I have > attached an image that sums it up. For those who prefer code (from > hw/stellaris.c): > > typedef struct { > =A0 =A0SSISlave ssidev; > =A0 =A0qemu_irq irq; > =A0 =A0int current_dev; > =A0 =A0SSIBus *bus[2]; > } stellaris_ssi_bus_state; > > static void stellaris_ssi_bus_select(void *opaque, int irq, int level) > { > =A0 =A0stellaris_ssi_bus_state *s =3D (stellaris_ssi_bus_state *)opaque; > > =A0 =A0s->current_dev =3D level; > } > > static uint32_t stellaris_ssi_bus_transfer(SSISlave *dev, uint32_t val) > { > =A0 =A0stellaris_ssi_bus_state *s =3D FROM_SSI_SLAVE(stellaris_ssi_bus_st= ate, dev); > > =A0 =A0return ssi_transfer(s->bus[s->current_dev], val); > } > > static const VMStateDescription vmstate_stellaris_ssi_bus =3D { > =A0 =A0.name =3D "stellaris_ssi_bus", > =A0 =A0.version_id =3D 1, > ... > }; > > The thing is, there is no actual hardware for this mux. its just three > copper traces on a board. > > Moving onto Xilinx, the real hardware is summed up in the attached > image (xilinx_real_hw.jpg). For those that prefer words: > > - N SSI devices attached to a single controller, xps_spi > - Tx and Rx lines shared between all devices > - N chip selects come from the xps_spi controller for the N devices > > So, here are the issues: > > A: We need to emulate CS behavior (without machine models having to > create these strange glue devices). > B: We need to emulate multiple devices attached to one SPI controller > (again without glue devices). > > Heres the proposal: > > -SSI bus is changed to multiple device. You can attach as many devices > as you want to a single SSI bus. When the master initiates a transfer, > all devices have their transfer() function called. The results are > logically or'ed together from each device (youll see how this works > out if you keep reading). There is no CS behaviour emulated in the bus > itself (which is contrary to my patch - its my new proposal). > > -SSI_Slave becomes an abstract device. which defines an abstract > function do_transfer(). The SSI Slave devices we have today inherirt > from this and the existing transfer() function for each SPI device > becomes this do_transfer function. The abstract class (SSISlave) > defines a single GPIO input for the CS line. The transfer() function > (which is called by the bus or controller) is implemented on the > SSISlave abstract layer, and will call and return do_transfer() if the > CS GPIO is set, otherwise is returns 0. The big advantage is there is > no or only trivial changes to the existing SSI devices. This all > happens at the abstract layer and a little bit of machine model > improvement - i.e. this means steallaris' virtual Mux will go away > completly (as the CS GPIOs are attached directly to the SSISlave > device). > > My Xilinx spi controller will have N GPIO outs that just connect to > the N SPI devices on the machine model layer. > > So here are the nitty-gritty details around the pending QOM stuff: > > Anthony is currently overhauling QBus, and im guessing the SSI bus is > part of that? qom-next stable enough in this area to look at or not? > Also Anthony mentioned recently some GPIO refactoring stuff - Are > GPIOs on multiple levels of abstraction supported yet? IE if I have a > SPI GPIO device, I need a GPIO on the SSISlave layer but also GPIOs on > my (concrete) device layer. I know this currently doesnt work cos of > qdev but thats going away right? > > Regards, > Peter