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

[Edgar E. Iglesias]

On Fri, Jan 25, 2013 at 06:00:36PM +0000, Paul Brook wrote:
> > 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).

Sounds, good.

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

Makes sense, the output output-enable are parts of the user of the 
tristate_pin..

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

Agreed

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

I thought it might be useful for debugging, not sure how valueable it would be 
though...

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


Thanks for clarifying
Cheers,
Edgar

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