From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SczyL-0000wh-DW for qemu-devel@nongnu.org; Fri, 08 Jun 2012 10:15:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SczyI-00030J-Q2 for qemu-devel@nongnu.org; Fri, 08 Jun 2012 10:15:28 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:51087) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SczyI-000304-KV for qemu-devel@nongnu.org; Fri, 08 Jun 2012 10:15:26 -0400 Received: by dadv2 with SMTP id v2so2664119dad.4 for ; Fri, 08 Jun 2012 07:15:24 -0700 (PDT) Message-ID: <4FD208F6.3020307@codemonkey.ws> Date: Fri, 08 Jun 2012 22:15:18 +0800 From: Anthony Liguori MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] QOMification of AXI stream List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Michal Simek , Anthony Liguori , "qemu-devel@nongnu.org Developers" , Paul Brook , "Edgar E. Iglesias" , =?ISO-8859-1?Q?Andreas_F=E4rber?= , John Williams On 06/08/2012 12:23 PM, Peter Crosthwaite wrote: > Hi all, > > Im looking to QOMifying and refactoring the AXI stream interfaces > between the AXI ethernet and AXI DMA modules. I could use some > guidance on how to do this as I can think of about 6 different > solutions. Sources are hw/xilinx_axienet.c and hw/xilinx_axidma.c. > > First ill start off by describing the real hardware: > > Each of the two core has three interfaces (+interrupt pins): > > 1: Sysbus attachment for device control > 2: AXI stream TX link > 3: AXI stream RX link > > Ethernet packet data is transferred from the ethernet device to/from > memory via the AXI stream links and the DMA core. Basically the DMA > core can be summed up as simply taking data to/from memory and putting > to/from the axi stream links. Axi stream is a trival point to point > protocol that allows for pushing 32-bit data words at a time. > > From an architecture point of view, the TX and RX links are completely > independent of each other. It doesnt make a lot of sense to have tx or > rx without the other for the ethernet with DMA case, but other > applications of the DMA could use only one of tx and rx. For this > reason I think its best we decouple the tx/rx pair. Currently it is > coupled in qemu (hw/xilinx_axdma.h): So is this something that should be modeled as a DMAContext ala dwg/benh's IOMMU patch series? Wouldn't the DMA controller expose two or more DMAContextes and then the Ethernet device expects a DMAContext for tx and rx. Of course, DMAContext could be made trivially into an Object and tx/rx could be turned into link<> properties. Regards, Anthony Liguori > > struct XilinxDMAConnection { > void *dma; > void *client; > > DMAPushFn to_dma; > DMAPushFn to_client; > }; > > So what im proposing is AXI stream is implemented as a unidirectional > point to point bus. The xilinx ethernet system would consist of two of > these buses one for tx, one for rx. > > Onto the QOM stuff: > > Currently the DMA interconnect is handled as this struct I pasted > above and a QDEV_PROP_PTR (which i understand is evil). The > interconnect mechanism obviously needs to change. So lets assume that > AXI stream is turned into a proper QEMU bus and devices can create > sub-busses which they are the tx'ing master: > > s->axi_stream_master = axi_stream_create_bus(&dev->qdev, "axi_stream"); > > Machine models can grab the bus to attach slaves: > > foo = qdev_get_child_bus(dev, "axi_stream"); > > Where my thinking goes pear shaped though is having proper QOMified > slaves. Each IP is a slave to both the sysbus and their respective > rx'ing AXI stream bus. This is something of a multiple inheritance > problem, I cant inherit from both SYSBUS and AXI_STREAM_SLAVE. So to > overcome this should I ... > > A: Make AXI_STREAM_SLAVE an interface (not a sub-class of DEVICE). Its > kind of annoying though if someone in the future whats the create a > device thats only and axi stream slave, as they would have to > explicitly inherit from DEVICE as well. > > or > > B: Have the slave attachment be a device within a device. Hard part is > getting an accessor so machine models can retrieve the slave > attachment and hook it up. > > Let me know what to do, > > Regards, > Peter >