Re: [Qemu-devel] [RFC] QOMification of AXI stream

[Peter Crosthwaite]

On Fri, Jun 8, 2012 at 7:45 PM, Andreas Färber <address@hidden> 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?

> 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.

>
> SysBus is also in the process of being deprecated, and Anthony is
> working on Pin objects for simple qemu_irq-style messaging.
>
> What you could try as option C today is deriving a type from SysBus with
> one added DMAPushFn and a link<> property of that type for
> unidirectional connection and form circular links for RX and TX...

Ok,

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.

> 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?

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