qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V2 2/6] hw/mdio: Generalize etraxfs MDIO bitbang


From: Paul Brook
Subject: Re: [Qemu-devel] [PATCH V2 2/6] hw/mdio: Generalize etraxfs MDIO bitbanging emulation (fwd)
Date: Thu, 24 Jan 2013 14:21:09 +0000
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

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

Paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]