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

[Edgar E. Iglesias]

On Thu, Jan 24, 2013 at 02:21:09PM +0000, Paul Brook wrote:
> > > > It also worries me that there isn't a clean separation between the MDIO
> > > > bus and the bitbang interface.  IMO the bitbang interface should be a
> > > > separate device, and if we're wiring up bitbang interfaces then it
> > > > really should be via standard GPIO pins (aka qemu_irq).
> > > 
> > > Only the bitbang state machine is in the mdio layer. It says nothing
> > > about where those signals come from, gpio or otherwise. Not all cases
> > > will actually be GPIOs. For instance, the smc91c111 has dedicated pins
> > > for MDIO operations which are not GPIOs, even though the driver has to
> > > manage the bigbanging.
> 
> There's no such thing as a "dedicated pin managed by software".  That's 
> exactly what a GPIO pin is.  It may be that particular pins are usually used 
> for a particular purpose, but I don't think that is sufficient reason to 
> create a whole new API.  The way to solve that is to give the pins 
> appropriate 
> names.  Don't be distracted by the fact that the smc91c111 is two devices 
> (MAC 
> and PHY) on the same chip.
> 
> > > That said, I'm not opposed to changing the model if that is the design
> > > direction. However, I hope that the series won't be blocked on this
> > > point. This series moves and enhances existing code. A move to qemu_irq
> > > should be done as a follow-on patch.
> > 
> > Maybe we should do it like the i2c framework? It does very similar
> > things as mdio would need (with a nice split). It addresses Pauls comments
> > (I think) and also the split between slaves and the bus. It also makes it
> > possible to select PHY model from board code.
> 
> Yes.  Though on closer inspection the bitbang I2C module introduces 
> bitbang_i2c_set, which I'd preter to avoid.  This isn't quite as easy as it 
> should be because we don't have a nice solution for tristate pins (currently 
> modelled as a cross-wired output and input pair).

I see what you mean..

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

Anyway, how would such a qemu_tristate_pin be modelled?
1. It's not point-to-point, has an arbitrary nr of connection points.
2. Every connection point provides an output/value and an output_enable.
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).
4. The pin value can be invalid (multiple drivers or no drivers), 0 or 1.

Am I missing something?

Cheers