On Sat, Jun 9, 2012 at 12:12 PM, Andreas Färber <afaer...@suse.de> wrote: > Am 09.06.2012 03:53, schrieb Peter Crosthwaite: >> On Fri, Jun 8, 2012 at 7:45 PM, Andreas Färber <afaer...@suse.de> wrote: >>> 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 of >>>> these buses one for tx, one for rx. >>> [...] >>>> 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. >>> >>> If you dive into busses, note that Anthony has refactored QBus on >>> qom-next branch. >>> >> >> 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. >> >> 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 >> >> Inherit from SYSBUS >> implement interface AXI_STREAM_SLAVE >> have a link property "axi_stream_connected_slave" >> >> 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. >> >> 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 you >>> need a dedicated child<> object, of which a device can have multiple. >> >> 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... ;) >
Do you have a repo/branch you can point me to some good examples of using qom-interfaces? Regards, Peter > Regards, > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg