Re: [Qemu-devel] [PATCH V2 2/6] hw/mdio: Generalize etraxfs MDIO bitbanging emulation (fwd)

[Andreas Färber]

Am 25.01.2013 19:00, schrieb Paul Brook:
>> 1. It's not point-to-point, has an arbitrary nr of connection points.
> 
> QoM currently only does asymmetric 1-1 connections between objects.  However 
> I 
> don't think this is a fatal problem.  We can still retain an asymmetric API 
> (effectively equivalent to male and female physical connectors), adding 
> virtual "wire" objects where they don't match up.  It should be possible to 
> implement this as a backward compatible extension to qemu_irq[1].  In most 
> cases the additional wire should not be needed.

This sounds pretty much like Anthony's Pin series, no? He had shown some
of us a preview git branch but Peter didn't like the amount of
boilerplate code to use it IIRC. Haven't heard any update since...

Andreas

> For simple output->input (i.e. all existing code) we just need to ignore Z 
> states.  Preferably before they get to the input device.
> 
> For simple bidirectional point-point lines (which should include bitbang-i2c 
> and bitbang-mdio) the bitbang object controls the value when subject to a Z 
> output.
> 
> For arbitrary pin connections they all connect to a set of ports on a virtual 
> wire device.  It takes care of arbitrating line state and sending 
> notifications to the connected devices.
> 
> There are a couple of technical issues:
> 
> Fristly qemu_irq is currently stateless[2].  Giving it state is fine in 
> principle, but means a lot of load/save code needs fixing.  In pactice we can 
> probably avoid this, but there are some nice benefits from keeping state in 
> qemu_irq.
> 
> Secondly, the [parent of the] qemu_irq object needs to be able to signal 
> value 
> changes to the object on the other side of the link. Currently QoM allows a 
> property to be linked to an object, but provides no way for the object to 
> identify/communicate with the property/device linked to it.
> 
> 
> Paul
> 
> [1] I've no particular attachment to the name qemu_irq.  But I really don't 
> want to have to make anything other than purely mechanical changes to all its 
> users.
> [2] More precicely it has no state that changes over its lifetime.

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg