From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdBAI-0002a7-Mo for qemu-devel@nongnu.org; Fri, 08 Jun 2012 22:12:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SdBAG-0002Ub-Kp for qemu-devel@nongnu.org; Fri, 08 Jun 2012 22:12:34 -0400 Received: from cantor2.suse.de ([195.135.220.15]:58734 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdBAG-0002UR-B5 for qemu-devel@nongnu.org; Fri, 08 Jun 2012 22:12:32 -0400 Message-ID: <4FD2B105.2030202@suse.de> Date: Sat, 09 Jun 2012 04:12:21 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <4FD1C9D2.80206@suse.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Anthony Liguori , "qemu-devel@nongnu.org Developers" , Michal Simek , Paul Brook , Paolo Bonzini , "Edgar E. Iglesias" , John Williams Am 09.06.2012 03:53, schrieb Peter Crosthwaite: > On Fri, Jun 8, 2012 at 7:45 PM, Andreas F=E4rber wro= te: >> Am 08.06.2012 06:23, schrieb Peter Crosthwaite: >>> 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 >> [...] >>> 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 o= f >>> these buses one for tx, one for rx. >> [...] >>> A: Make AXI_STREAM_SLAVE an interface (not a sub-class of DEVICE). It= s >>> 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 i= s >>> getting an accessor so machine models can retrieve the slave >>> attachment and hook it up. >> >> If you dive into busses, note that Anthony has refactored QBus on >> qom-next branch. >> >=20 > How stable is this branch? It seems like I should use it as the > development point. Is the merge immenent. If the merge is delayed, can > I at least rely on the fundamental APIs define here (around links and > stuff) no changing? At this point we're pretty close to merging (hopefully next week) so I would advise against basing new work on that branch. Just be prepared to rebase onto the "qdev: Convert busses to QEMU Object Model" patch, i.e. BusInfo gets replaced by TypeInfo and creation uses TYPE_FOO. >> As Paul has already mentioned, the concept of tree-structured qdev >> busses is deprecated by QOM in favor of link<> properties. >=20 > Ive had a brief look at the refactorings on qom-next, I notice that > busses are now just children of the parent object TYPE_BUS. > Essentially for point-to-point links this means that link itself has a > QOM object. So for finer clarification, for new busses should or > should I not have an object (whether it inheritTYPE_BUS or some other > parent) for the link itself? Or should The master device interface > directly with its slave? Im thinking the latter, no need for an object > for a trivial point-to-point link. No bus expert myself, deferring to Anthony and Paolo. > Heres what i'm thinking now. each device will >=20 > Inherit from SYSBUS > implement interface AXI_STREAM_SLAVE > have a link property "axi_stream_connected_slave" >=20 > AXI_STREAM_SLAVE has a single function to push data down the link > (what I believe you called DMAPushFn), but I will rename to > axi_stream_push or the like as its not DMA specific. >=20 > Machine model then just sets axi_stream_connected_slave to each other. Doesn't sound wrong so far under the premise of that simplistic modelling approach. Not that I'm specifically advocating this approach. >> That would of course limit the number of channels to one. Otherwise yo= u >> need a dedicated child<> object, of which a device can have multiple. >=20 > Im not too worried about that, but Peter and Paul have opened the > discussion. Is the straight up interface on the sysbus device fine for > what im trying to do - or should I have proxy objects for the sake of > consistency? I'm not aware of any use of interfaces in upstream nor of any proxy object. In the end it'll be a compromise between fancy and quick... ;) Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg