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

[Peter Crosthwaite]

On Sat, Jun 9, 2012 at 12:12 PM, Andreas Färber <address@hidden> wrote:
> Am 09.06.2012 03:53, schrieb 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?
>
> 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