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

[Paul Brook]

> To be able to create generic GPIO devices or other devices that have GPIO
> like pins (e.g MDIO), and hook those up to external buses through common
> frameworks, we need agreement on how to model tristate pins.
> A tristate pin model, or at least agreement on how to model these with
> multiple qemu_irqs.
> 
> hmm, feels like we've opened a can of worms...

Probably. I'm not going to insist you use/implement generic GPIO for MDIO, but 
I still think separation between the PHY register interface and the bitbang 
code is good (i.e. same as bitbang_i2c).
 
> Anyway, how would such a qemu_tristate_pin be modelled?
[point 1 moved later so my answers read in a sensible order]

> 2. Every connection point provides an output/value and an output_enable.

I think we'd be better providing a single state  i.e. an output of 0, 1 or Z.  
Possibly additional Z0/Z1 states to represent high-impedance with pull-up/down 
resistors.

> 3. There is a mean for reading the pin value, which is computed based on
> all connection points outputs and output_enables (can be cached).

For MDIO being able to read the value is sufficient.  However in general we 
don't want to have to poll it.  We want to be told when it changes.

> 4. The pin value can be invalid (multiple drivers or no drivers), 0 or 1.

I can't think of any cases where this is important.  In most cases it's 
undefined, in the rest it causes physical damage.

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

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.